Discovery: understanding users and choosing problems

Users first

• User interviews: ask about real past behaviour and pain, not hypothetical features.
• Jobs to be done (JTBD): what "job" is the user hiring the product for? "When I'm in my final semester, I want to get a job without wasting weeks on applications that go nowhere, so I can relax about my future."
• Personas and journey maps to share understanding.
• Data: funnels, cohorts and retention to find where users struggle or drop off.
• Support tickets, reviews, sales calls: rich sources of pain points.

Sizing opportunities

For each problem: how many users have it, how often, how painful is it, how well is it solved today, and how does solving it move our goals? Rough market sizing (TAM/SAM/SOM) and impact estimates help compare.

Validating before building

Cheap tests reduce the risk of building the wrong thing:

• Prototypes and usability tests.
• Fake door tests (a button for a feature that doesn't exist yet, measuring interest).
• Concierge or Wizard-of-Oz MVPs (doing it manually behind the scenes).
• Landing pages and waitlists.
• Small beta groups.

An MVP (minimum viable product) is the smallest thing that tests the riskiest assumption, not a half-built version of the full product.

Check yourself

• Write the job to be done for someone ordering groceries on a quick-commerce app.
• How would you test demand for a paid resume-review feature before building it?