Skip to main content

Product Discovery Before Design

What This Concept Is​

Product discovery is the disciplined reduction of uncertainty about the user, problem, context, and success condition before committing to an interface or architecture. The output is not a feature list. It is a testable account of who is trying to do what, what obstructs them, and what observable change would count as improvement.

Why It Matters Here​

Software design can be internally elegant and externally useless. Semester 3 already asks whether an abstraction fits its pressure; discovery applies the same judgment to the product boundary. A design review is incomplete when it evaluates class structure but never tests whether the proposed workflow solves the right problem.

Concrete Example​

A team proposes a dashboard for reviewing failed imports. Before implementing filters and charts, interview three people who currently handle failures. Observation shows their real bottleneck is not finding failures; it is determining whether retrying will duplicate data. The first design becomes a failure-detail view containing cause, affected records, idempotency state, and a safe retry action. The rejected dashboard optimized visibility while leaving the decision unsafe.

Common Confusion / Misconception​

“Ask users what features they want” is not discovery. Requested features are possible solutions. Ask for recent concrete behavior: what happened, what they tried, where they hesitated, what information was missing, and what the consequence was.

How To Use It​

  1. Name one user and one consequential task.
  2. Collect three recent examples through observation or interview.
  3. Separate evidence, interpretation, and proposed solution.
  4. Write the riskiest assumption and the cheapest test that could disprove it.
  5. Define a task-level success measure before choosing interface structure.
  6. Carry unresolved uncertainty into the design document rather than hiding it.

Check Yourself​

  • Can you quote observed behavior rather than a preference?
  • What evidence would make you cancel or substantially change the feature?
  • Does the success measure describe a user outcome rather than implementation completion?

Mini Drill or Application​

Choose one feature in the Semester 3 project. Write a five-line discovery brief: user, situation, current behavior, costly obstacle, and falsifiable success condition. Then name one attractive feature that the evidence does not yet justify.

Read This Only If Stuck​