Module 97: Product Development

Why each option is right or wrong

• “Getting users to agree that the planned features are good” (Incorrect): Seeking agreement leads to polite answers; research looks for real problems.
• “Choosing the colours and fonts the users like best” (Incorrect): Visual choices come later; research is about problems.
• “Collecting email addresses for the launch announcement” (Incorrect): That's marketing; research is about understanding users.
• “Understanding real users' problems and how they work today” is correct.

  Before deciding what to build, you learn how people currently handle the problem, what frustrates them and what they've tried. This stops you building something nobody needs, the most expensive mistake a product can make.

  • Methods: interviews, observation, looking at their current tools.
  • Look for: patterns across several people.

📖 Revise: Lesson 1: User research

Why each option is right or wrong

• “'Would you use an app that finds and books good tutors for you?'” (Incorrect): People often say yes to be polite; it doesn't predict behaviour.
• “'What do you think of our idea for a tutor-booking app?'” (Incorrect): This invites compliments, not useful facts.
• “'How much would you pay each month for an app like this?'” (Incorrect): Guesses about future spending are unreliable.
• “'Tell me about the last time you booked a tutor. What happened?'” is correct.

  Asking about a real past event gives facts: what they actually did, where it went wrong, what they used. Questions about the future or your idea invite polite guesses, and people are poor at predicting what they'd do.

  • Follow up: "What was hardest about that?"
  • Avoid: pitching your idea during research.

📖 Revise: Lesson 1: User research

Why each option is right or wrong

• “The first version, with every planned feature included” (Incorrect): Including everything defeats the purpose of learning quickly.
• “A detailed prototype that only the team gets to use” (Incorrect): An MVP needs real users to learn from.
• “The finished product after all user feedback is applied” (Incorrect): That comes much later; the MVP is the first test.
• “The smallest product that tests whether you're solving a real problem” is correct.

  A minimum viable product is built to learn, not to impress. It's the least you can make that real users can try, so you find out whether the problem and your solution matter before investing months.

  • Viable: it must actually solve the problem, even simply.
  • Measure: what users do, not just what they say.

📖 Revise: Lesson 2: The MVP

Why each option is right or wrong

• “A full app for every subject with AI matching and payments in many currencies” (Incorrect): That's a huge build before knowing anyone wants it.
• “A landing page with a logo and a sign-up button only” (Incorrect): Sign-ups show some interest, but don't test whether booking works.
• “A 50-page business plan describing the future app” (Incorrect): Plans don't test anything with real users.
• “A simple booking page for one subject and a few tutors, used by real students” is correct.

  This tests the core question, will students book tutors this way?, with little effort. If it works, you add subjects and features based on what you learn. If it doesn't, you've lost weeks, not months.

  • Could even be: a form and a spreadsheet behind it.
  • Track: bookings, repeat bookings and feedback.

📖 Revise: Lesson 2: The MVP

Why each option is right or wrong

• “Showing the price only at the last step, to reduce drop-off early on” (Incorrect): Hidden prices feel like a trick and cause drop-off at the end.
• “Pop-ups at each step offering extra services and discounts” (Incorrect): Interruptions slow people down and cause mistakes.
• “Many small buttons, so every option fits on one screen” (Incorrect): Small buttons are hard to tap, especially on phones.
• “Few steps, clear labels, helpful errors and a clear confirmation” is correct.

  People should be able to book quickly without wondering what to do next. Clear labels, errors that explain how to fix the problem, and a confirmation that shows exactly what was booked reduce drop-offs and support requests.

  • Show: price and time early.
  • Test: on a phone, where most users are.

📖 Revise: Lesson 3: UX

Why each option is right or wrong

• “Because testing with more than five users is too expensive” (Incorrect): Cost matters, but the reason is that problems repeat after a few users.
• “Because five testers is the minimum the law requires” (Incorrect): There's no such legal rule.
• “Because five users give a statistically exact result” (Incorrect): Small tests find problems; they don't give exact statistics.
• “Most big usability problems show up with just a few users” is correct.

  Research by usability experts found that a handful of users uncover most major problems; after that, you mostly see the same issues again. It's better to test with five, fix, and test again than to test once with many.

  • Repeat: small rounds after each change.
  • Choose: people like your real users.

📖 Revise: Lesson 3: UX

Why each option is right or wrong

• “A list of features with exact delivery dates for the next two years” (Incorrect): That's a fixed feature roadmap, which struggles when plans change.
• “A Git branch where the team stores future features” (Incorrect): A branch holds code, not a product plan.
• “A chart of which developer will work on which feature” (Incorrect): That's a staffing plan, not an outcome roadmap.
• “Organised around problems to solve and results to reach, not a fixed feature list with dates” is correct.

  Instead of "build chat by March", it says "help students find a tutor in under 5 minutes this quarter". The team then chooses features that reach that result, and can change course as they learn.

  • Near term: more detail; later: broader themes.
  • Measure: whether the outcome was reached.

📖 Revise: Lesson 4: Roadmaps

Why each option is right or wrong

• “The number of lines of code the team writes and ships each month” (Incorrect): Code volume doesn't show value to users.
• “The total number of visits to the home page from all sources” (Incorrect): Visits alone don't show whether people book.
• “The number of new features released to users this quarter” (Incorrect): Shipping features doesn't mean users benefit.
• “The share of visitors who complete a booking, and how many book again” is correct.

  Completed bookings show the app does its job; repeat bookings show people found it valuable enough to return. These guide decisions: if many start but don't finish, you improve the flow.

  • Also: time to complete a booking, cancellations.
  • Track: over time, not once.

📖 Revise: Lesson 5: Measuring product success

Why each option is right or wrong

• “Revenue, since it only shows money coming in and says nothing about users” (Incorrect): Revenue is a key business measure, not a vanity metric.
• “Retention, since it only counts returning users and ignores new ones” (Incorrect): Retention is one of the most useful product metrics.
• “Any metric that is about the look of the design, such as colour choices” (Incorrect): "Vanity" refers to numbers that flatter, not to design.
• “A number that looks good but doesn't guide decisions, like total page views” is correct.

  Total page views or total sign-ups usually go up over time, which feels good, but they don't tell you what to do next. Useful metrics, like conversion or retention, show whether something is working and change your decisions.

  • Test: "If this number changed, would we act differently?"
  • Prefer: rates and ratios over running totals.

📖 Revise: Lesson 5: Measuring product success

Why each option is right or wrong

• “Remove the pricing page so the confusion goes away” (Incorrect): People still need to know prices; removing it adds confusion.
• “Add more explanation text everywhere on the page” (Incorrect): More text can make it harder to understand.
• “Wait until more feedback arrives before doing anything” (Incorrect): The signal is already there; investigating is cheap.
• “Watch a few users try it, change it, and measure again” is correct.

  Seeing real users struggle shows exactly where the confusion is. You make a focused change, then check whether understanding improves, for example by watching again or tracking fewer support questions.

  • Ask them: to explain the price back to you.
  • Measure: questions, sign-ups or completion.

📖 Revise: Lesson 5: Measuring product success