Discover what to build before you code it

It was 2015. I was finishing my Bachelor's degree at the Wrocław University of Economics, working part-time at McKinsey, and running a student club. And I launched a startup.

I called it Eminatio. A membership web app providing restaurant concierge services to entrepreneurs and corporate employees. We had a co-founder, a software house, a built platform, over ten partners signed up. And then — nothing. Nobody wanted it. A few months of co-founder issues and a total absence of customer validation later, we shut it down.

Here's what stings in hindsight: we never asked whether anyone actually wanted it before we built it. We assumed they would.

The assumption epidemic

What happened to me happens constantly, at every scale. Early-stage startups. Mid-market scaleups. Enterprise product teams with dedicated roadmaps and quarterly OKRs. They all build things that end up unused.

The numbers are brutal:

• Over 40% of startups fail because of a lack of product-market fit — not because they couldn't execute, but because they built the wrong thing.
• 80% of features in the average software product are rarely or never used — meaning most of what product teams ship is, in a meaningful sense, waste.

These aren't edge cases. They're the industry average. And the root cause is almost always the same: teams decided what to build before they understood whether it was worth building.

What Product Discovery actually is

Definitions vary, but the core idea is consistent:

Product Discovery is an iterative decision-making process where you figure out what to build by identifying opportunities and validating them with the right customers — before committing to building them.

It's the process that sits before Product Delivery. Discovery answers: what should we build, and why? Delivery answers: how do we build it well?

In practice, it means:

• Exploring a Problem Space — understanding customer pains, needs, and desires deeply, through interviews, research, and data
• Then tackling the Solution Space — generating ideas, prototyping, and validating them cheaply before a single line of production code is written

The goal is to reduce uncertainty around your assumptions — so when you do build, you're building something your customers actually need, your business can sustain, and your engineers can ship.

A brief history of a big idea

Product Discovery isn't new. The frameworks have been accumulating for decades:

• In the 1990s, IDEO popularized Design Thinking — a human-centered approach that starts with people, not solutions.
• Clayton Christensen's Jobs-to-be-done framework reframed why customers "hire" products.
• Frank Robinson introduced the Minimum Viable Product in 2001 — "right-size product for your company and customer."
• Steve Blank's Customer Development Model in 2005 told founders to "get out of the building."
• In 2008, Marty Cagan's Inspired made "product discovery" a mainstream term — figuring out solutions rather than dictating requirements.
• Google Ventures invented the Design Sprint in 2010 — five days to answer a critical business question through design and customer testing.
• Eric Ries brought MVP to the masses through The Lean Startup in 2011.
• Teresa Torres' Continuous Discovery Habits in 2021 moved the conversation from "do discovery sometimes" to "make it a weekly discipline."

Every one of these frameworks, despite their differences, insists on the same underlying principle:

Understand the problem deeply before you commit to a solution.

Why most teams skip it anyway

Here's the uncomfortable truth: almost every product team does some version of "deciding what to build." The difference is whether that decision is informed by customer reality or by whoever speaks loudest in the planning meeting.

Teams skip real Discovery for a few reasons:

• Time pressure — shipping code feels tangible. Research feels like a delay.
• Comfort zone — talking to customers requires leaving your desk, tolerating ambiguity, and hearing things you don't want to hear.
• The illusion of knowing — "We already talk to customers" or "we have data" often means "we had one call six months ago and the data supports what we already believed."

The problem with skipping it is that software development is expensive. Building the wrong thing first — and then discovering it was wrong after launch — costs far more than a few weeks of structured discovery upfront. You end up with customers who are dissatisfied, senior management asking hard questions, and a product team wondering where it went wrong.

What Product Discovery gives you in return

The payoff is concrete. A Nielsen Norman Group study of 240 participants found that well-conducted Discovery:

• Lowers the risk of product failure by 75%
• Increases the chance of product success by 59%

Those numbers aren't from a niche or a single team type. They're averages across companies that chose to validate first. The mechanism is straightforward: when you test assumptions cheaply — through customer interviews, fake-door prototypes, lightweight experiments — you learn whether something is worth building before you've sunk a sprint (or a quarter) into it.

Good Discovery leads to better outcomes by:

• Exploring and defining the right problem to be solved
• Supporting evidence-based decisions with real user insights
• Aligning teams on a shared product direction before execution begins
• Validating solutions with the people who'll actually use them
• Minimizing the risk of building something undesired, unviable, or unfeasible

Where to start

If your team isn't doing Discovery today, the entry point is simpler than most frameworks suggest. Start with one thing: talk to five customers before the next planning cycle.

Not to pitch them your roadmap. Not to gather requirements. To understand what they're actually struggling with — in their own words, in their actual context. Five conversations won't give you statistical certainty. They'll give you something better: the signal that tells you what's worth building next.

From there, you can build the habits. Weekly interviews. Opportunity mapping. Assumption testing. But none of that works until you've had those first uncomfortable conversations with real customers and heard something you didn't expect.

I learned that lesson the hard way with Eminatio. You don't have to.