The Most Expensive Mistake in Product

Roughly 70% of features shipped by product teams are never or rarely used by customers. Think about that — the engineering time, the design work, the QA cycles, the deployment — most of it building things people don't care about. This is what happens when teams skip or rush product discovery.

Discovery is the process of figuring out whether a problem is worth solving and whether your proposed solution will actually solve it — before you commit to building it.

It is not a phase you do once. It is a continuous practice that runs in parallel with delivery, always staying a few steps ahead of what the team is currently building.

Why Teams Skip Discovery

Discovery is uncomfortable for a few reasons:

• Stakeholders want to see output. Roadmaps, features, releases — these are tangible. Sitting in a room talking to users feels less productive.
• Discovery creates uncertainty. You might find out the idea you've been planning for weeks isn't worth building. That's hard to deliver.
• Teams have opinions. Engineers, designers, and executives all have strong intuitions about what users want. Research often challenges those intuitions.

The Double Diamond Model

One of the most useful mental models for discovery is the Double Diamond, developed by the Design Council. It describes how good product thinking moves through four phases:

• Discover — Explore broadly. Gather user research, data, market context. Don't narrow yet.
• Define — Synthesize what you learned. Identify the specific problem worth solving.
• Develop — Explore broadly again — generate multiple possible solutions.
• Deliver — Narrow down. Test, iterate, ship.

The key insight: you should be *divergent* before you're *convergent*. Most teams rush to "Deliver" without doing the Discover and Define work.

What Discovery Actually Looks Like

Quantitative Discovery: - Analyzing product analytics (what are users actually doing?) - Reviewing funnel metrics (where are users dropping off?) - Mining support tickets and NPS feedback

Qualitative Discovery: - User interviews (deep dives on problems, not solutions) - Usability testing (watching users interact with prototypes) - Customer advisory boards and sales calls (listening, not pitching)

Assumption Mapping: - Writing down the assumptions your product idea depends on - Ranking them by risk and unknownness - Designing experiments to test the riskiest ones first

The Problem With Jumping to Solutions

New PMs have a reflex: when a stakeholder says "we need a notification feature," the instinct is to start designing the notification feature. Resist this.

The question isn't "what should the notification look like?" The question is: "What problem is this person actually trying to solve?"

Maybe users are missing important updates — but maybe they're missing them because the updates are buried in the UI, not because there's no notification. The solution might be better information hierarchy, not a push notification system.

Continuous Discovery vs. Big-Bang Discovery

• Big-bang discovery: You do a research sprint before a major initiative, produce a report, and move on. The findings go stale quickly.
• Continuous discovery: You touch customers every week, even briefly. You build learning into your regular rhythm.

The goal is weekly customer contact. Even 20 minutes of user research per week compounds into deep customer understanding over months.

Key Takeaway: Discovery is how you avoid building the wrong thing. It means continuously testing your assumptions about the problem and the solution before and while you build — not just at the start of a project.