Explain the difference between discovery (understanding the problem with interviews, observation, and data) and delivery (building the solution), and order the steps so problem-validation comes before building.
Discovery vs Delivery: Why order matters
Discovery vs Delivery: Why order matters
Product work has two distinct modes. Discovery is the phase where you understand the problem — you talk to users, observe their behaviour, and look at data to find out what is actually worth building. Delivery is the phase where you build and ship the solution. Most beginner teams skip discovery and jump straight to delivery: they have an idea, they build it, they launch it — and then nobody uses it. This is the single most common and most expensive mistake in product development.
Discovery has three main inputs. Interviews let you hear directly from users what they struggle with and why. Observation (watching people do the actual task) reveals what they do rather than what they say. Behavioural data (analytics, logs, usage patterns) shows what is actually happening at scale. Together these three inputs give you enough signal to decide whether a problem is real and worth solving before you invest weeks of engineering time.
Consider two teams. Team A hears 'users need a dashboard' and spends three months building one — it launches to near-zero adoption because the real pain was slow email notifications, not missing dashboards. Team B spends two weeks interviewing users, discovers the email-speed insight, builds a small fix in one week, and sees immediate engagement. The difference is not talent — it is sequence: problem first, solution second.
The correct order is always: (1) identify a problem candidate, (2) gather evidence that it is real and frequent, (3) design and build the solution. Skipping step 2 is not faster — it is slower, because you build the wrong thing and then have to rebuild.
Lesson notes
Discovery vs Delivery: Why order matters
Product work has two distinct modes. Discovery is the phase where you understand the problem — you talk to users, observe their behaviour, and look at data to find out what is actually worth building. Delivery is the phase where you build and ship the solution. Most beginner teams skip discovery and jump straight to delivery: they have an idea, they build it, they launch it — and then nobody uses it. This is the single most common and most expensive mistake in product development.
Discovery has three main inputs. Interviews let you hear directly from users what they struggle with and why. Observation (watching people do the actual task) reveals what they do rather than what they say. Behavioural data (analytics, logs, usage patterns) shows what is actually happening at scale. Together these three inputs give you enough signal to decide whether a problem is real and worth solving before you invest weeks of engineering time.
Consider two teams. Team A hears 'users need a dashboard' and spends three months building one — it launches to near-zero adoption because the real pain was slow email notifications, not missing dashboards. Team B spends two weeks interviewing users, discovers the email-speed insight, builds a small fix in one week, and sees immediate engagement. The difference is not talent — it is sequence: problem first, solution second.
The correct order is always: (1) identify a problem candidate, (2) gather evidence that it is real and frequent, (3) design and build the solution. Skipping step 2 is not faster — it is slower, because you build the wrong thing and then have to rebuild.