Essentials
8 guided hoursModules 1-2. An introduction with practical exercises and a small reviewed artifact.
PRODUCT · BEGINNER FRIENDLY
Product Management
Find the right problem. Build the right next step.
Learn to discover user needs, prioritise opportunities and guide a digital product from an idea to a measured release. Build a product brief, roadmap and experiment plan using a practical case study.
COURSE OVERVIEW
What does the product management course cover?
Work from customer discovery through prioritisation, requirements, success metrics and launch planning. Build an evidence-based product plan with a research brief, roadmap and measurement plan.
OPTIONAL AI PRACTICE
Apply AI to a relevant task.
Selected modules include an optional prompt-and-review exercise. Verify the result using the underlying skills taught in this course.
Explore the Prompting FoundationA STARTING POINT THAT FITS
Three learning levels.
Practitioner
24 guided hours totalModules 1-6, including Essentials. Complete the core labs and an assessed practical project.
Advanced
12 additional guided hoursTwo extension modules and a four-hour project clinic after practitioner readiness.
These are curriculum planning options. We confirm the timetable, delivery format, fees and required accounts before enrolment. Practitioner includes Essentials; the two durations are not added together.
Download the Curriculum PDFCheck your starting point
- Separate a feature output from a user outcome. Essentials if unfamiliar; advanced experience alone does not waive evidence.
- Write a missing-email acceptance criterion and calculate 40/80. Practitioner after early outcomes are demonstrated.
- Interpret 10% versus 12% without unsupported causal claims. Advanced after Practitioner capstone or equivalent review evidence.
WHAT YOU’LL LEARN
Skills to put into practice.
- Connect a user problem to a business goal and a useful success measure.
- Use discovery evidence to compare opportunities and prioritise a small first release.
- Write a product requirement with acceptance criteria and understandable trade-offs.
- Plan an experiment, interpret results and communicate the next decision.
Who this is for
Aspiring product managers, founders, designers and professionals who want to turn user problems into clear product decisions.
Before you begin
Basic computer skills. No coding background is required; bring a product idea or use the sample case.
THE COURSE OUTLINE
A clear path, module by module.
Each module connects a concept to a practical task. Open a module to see its topics and exercise.
01Understand the product role
- Distinguish product outcomes from a list of features.
- Map the user, customer, business model and delivery team.
- Define a problem statement, assumptions and initial success measures.
What you will understand
Product management connects user needs, organisational goals and feasible solutions. A product manager helps a team decide what problem to address and how to evaluate progress, working with design, engineering and stakeholders. The role is not simply assigning tasks or demanding features. Ownership and decision authority must be clarified in the organisation. A project coordinates a bounded delivery effort; a product requires ongoing decisions about value, adoption and improvement. Shipping a course comparison page is a delivery milestone. Helping more suitable learners choose confidently is a product outcome. Both matter, but completing a timeline does not prove the interface solved the user problem. State one goal, the evidence available and constraints such as staffing, budget or privacy. Identify learners, teachers, support and the business owner, including who approves claims and operational promises. Stakeholder wishes are inputs rather than automatic requirements. Keep disagreements visible so trade-offs are resolved deliberately instead of quietly buried in a feature list.
PUT IT INTO PRACTICE
Create a one-page product canvas for a course discovery service.
02Discover user needs
- Plan interviews around recent behaviour rather than hypothetical preferences.
- Organise observations, pain points and existing alternatives.
- Separate evidence from assumptions and identify unanswered questions.
What you will understand
Discovery reduces uncertainty about a problem and its possible solutions. Use interviews, task observations and permitted existing information to explore needs. Write the decision the research should inform before choosing a method. Discovery can reveal that a request is not worth building; its value is better judgement rather than a guaranteed feature specification. Ask about recent decisions and workarounds rather than only future intentions. A learner saying they would buy a course is not a confirmed purchase. Record what happened, what they said and your interpretation separately. Classroom role-play teaches the method but cannot validate market demand; genuine volunteer sessions still have recruitment and sample limitations. Convert observations into a focused need and identify the affected situation. For example, a working learner needs visible lesson times before committing. Keep opportunity wording independent of a solution so several approaches remain possible. Include contradictory evidence and note what further observation could change your recommendation instead of treating the first interview as final truth.
PUT IT INTO PRACTICE
Create an interview guide and synthesise a set of sample research notes.
03Prioritise useful opportunities
- Compare impact, evidence, effort and dependencies.
- Make trade-offs visible and define what is outside the first release.
- Translate an outcome into a focused roadmap and discovery tasks.
What you will understand
Prioritisation makes trade-offs explicit when a team cannot do everything at once. Start with agreed goals and constraints, then compare opportunities using evidence and uncertainty. A numerical score is a conversation aid, not an automatic command. Accessibility blockers, legal obligations and critical incidents may need different handling from ordinary feature opportunities. RICE combines reach, impact, confidence and effort using a consistent time period and scale. Define each input so comparisons are meaningful. Confidence should reflect evidence strength rather than enthusiasm. Estimated numbers can create an illusion of precision; show the calculation and test whether plausible changes would reverse the ranking. A highly scored idea may depend on a missing capability or approval. Sequence work to learn early and reduce risk, not merely to complete the largest feature first. Separate necessary foundations from optional enhancements. Document what is deferred and why, so stakeholders can understand the next step and the conditions for reconsideration.
PUT IT INTO PRACTICE
Prioritise a backlog and explain the scope of a small first version.
04Write a clear product requirement
- Define the user journey, requirements and acceptance criteria.
- Describe errors, access needs and important edge cases.
- Work with design and engineering to resolve unknowns before delivery.
What you will understand
A useful requirement explains the problem, intended outcome and scope before listing behaviours. Separate what is included from what is deferred. For a course enquiry, collect enough information to follow up without adding unnecessary sensitive fields. Record dependencies and unresolved questions so delivery can start with shared understanding rather than conflicting assumptions. Acceptance criteria describe observable behaviours that can be checked. For example, missing email shows a specific error while retaining the selected course. Avoid vague criteria such as 'easy to use'. Include normal, error and recovery cases, plus accessibility and data-handling expectations. A criterion should identify the condition and expected result without dictating every implementation detail. Requirements improve through discussion with design, development and operational owners. A product manager should invite questions about feasibility, edge cases and support procedures. In Scrum, Product Owner is a specific accountability; it is not automatically identical to every organisation's product-manager title. Agree local responsibilities rather than treating a job label as a universal process rule.
PUT IT INTO PRACTICE
Write a requirement brief for an enrollment wizard with review and failure states.
OPTIONAL AI PRACTICE
Try this brief
Turn these sample discovery findings into a draft problem statement and acceptance criteria. Separate evidence from assumptions.
Check the result
Check traceability to the findings and review the criteria with the intended user before prioritising.
05Measure and learn
- Choose outcome metrics, leading indicators and guardrails.
- Design a small experiment with a baseline and decision rule.
- Recognise bias, small samples and the limits of attribution.
What you will understand
A metric needs a numerator, denominator, period and data source. Define enquiry completion as valid submissions divided by started enquiries within a stated analysis window. Visits, starts, submissions and qualified enquiries answer different questions. Without clear definitions, teams can report apparently conflicting results while counting different actions or user populations. Calculate each stage deliberately and distinguish overall conversion from step conversion. In a sample with 1000 visits, 80 starts, 40 submissions and 20 qualified enquiries, visit-to-submission conversion is 4%, start-to-submission completion is 50%, and submission-to-qualified rate is 50%. These describe the sample and do not explain the cause of drop-off. A before-and-after change can be affected by traffic sources, seasonality or measurement changes. Do not claim causality from timing alone. Define a hypothesis, measurement plan and guardrails before a test. Experiments need appropriate design and sufficient data; classroom samples practise reasoning, not reliable proof of commercial improvement. Record uncertainty and possible alternative explanations.
PUT IT INTO PRACTICE
Create an experiment plan for improving course enquiry completion.
06Launch and communicate
- Prepare release checks, ownership and support arrangements.
- Communicate decisions and risks to different stakeholders.
- Review results, explain uncertainty and choose the next iteration.
What you will understand
A launch requires evidence that the critical flow works and that support can operate it. Use a checklist covering functional tests, content approval, accessibility evaluation, tracking and ownership. Staging a limited release can reveal issues before wider exposure. A release date should not override unresolved task-blocking failures or an unowned enquiry process. Learners need clear changes and next actions; staff need procedures, responsibilities and escalation routes; leaders need outcomes, risks and open decisions. Tailor the same facts to each audience without inventing certainty. Release notes should explain meaningful behaviour changes rather than dumping technical details that users cannot act on. Decide who watches which signals, when the team reviews evidence and how to pause or roll back. Compare outcomes with a defined baseline and inspect support feedback. A launch is the start of learning from real use, not the end of product responsibility. Keep approved operational promises separate from future aspirations.
PUT IT INTO PRACTICE
Present a launch plan and a short product review using sample results.
AFTER THE CORE COURSE
Advanced extension.
07Advanced product strategy and portfolio choices
- Strategic choices
- Portfolio allocation
- Roadmaps and uncertainty
ADVANCED PRACTICE
Defend a focused product strategy
08Advanced experiment review and product governance
- Experiment validity
- Segmentation and hidden effects
- Decision logs and governance
ADVANCED PRACTICE
Chair an evidence review clinic
Complete both four-hour extension modules and a four-hour project clinic. Entry uses the core project and readiness evidence.
BRING THE SKILLS TOGETHER
A product plan from discovery to launch
Develop a course discovery product case study: research synthesis, a focused first release, a requirement brief and a measurement plan. Explain the evidence and trade-offs behind your decisions.
Your project deliverables
- Problem brief and research synthesis
- Prioritised roadmap and product requirement
- Experiment, launch plan and stakeholder presentation
A learning project using sample or permitted material. The final scope is agreed for your learning plan.
Course outline published by Hawa Enterprises. Updated . Ask about the learning plan.
GOOD TO KNOW
Before you take the next step.
Do I need to be a developer?
No. You will practise framing problems, working with evidence and communicating requirements. Technical constraints are discussed in plain language.
Is the final project a real product launch?
The capstone is a learning case study. You can use a permitted product idea, but no launch, customer traction or commercial result is implied.
What are the fees, schedule and delivery format?
These details are confirmed by email before you commit. The curriculum gives guided-hour options for Essentials, Practitioner and Advanced. Actual schedules, fees and delivery arrangements are confirmed before enrolment. Ask about the course you want and your preferred timeline.
How do I enrol?
Choose a course and complete the enrollment wizard with your name, email and WhatsApp number. Review your details before sending the enquiry. Hawa Enterprises will discuss your starting level, goals and course arrangements before enrolment is confirmed.
YOUR NEXT SKILL STARTS HERE
Let’s find the right
course for you.
Tell us your goal, starting level and preferred timeline.