Skip to main content
Continuous discovery is the steady heartbeat of a mature product team. But every product - and every major new initiative - has a beginning. A moment where you’re staring at a blank page, a vague idea, and a lot of uncertainty. That’s where initial discovery comes in. Initial discovery is what you do before you have a product. Or before you have a feature. Or before you commit to a direction. It’s the work of figuring out whether there’s a real problem worth solving in the first place.

​
How it’s different from continuous discovery

Continuous discovery assumes you already have a product, a customer base, and an outcome to work toward. Initial discovery has none of that. You’re operating in much higher uncertainty - you don’t know who the customer is yet, what their problem really looks like, or whether your idea even makes sense. The methods overlap (you’re still talking to people, still testing assumptions), but the mindset is different. In continuous discovery you’re navigating. In initial discovery you’re orientating - figuring out which direction is worth going in before you start moving.

​
The question you’re trying to answer

Initial discovery is fundamentally about one question: is there a real problem here, and are we the right team to solve it? Everything you do in this phase is designed to stress-test that question. You’re not trying to prove your idea is right. You’re trying to find out if it’s wrong as quickly and cheaply as possible. Alberto Savoia calls this “pretotyping” in The Right It - validating the right it before you build the thing right. It’s one of the most underrated ideas in product.

​
What initial discovery looks like in practice

There’s no single playbook, but most good initial discovery covers a few bases: Desk research - Before you talk to anyone, understand the space. What solutions already exist? Who are the players? What do customers say about them in reviews, forums, social media? You can learn a lot without leaving your chair - and it makes your customer conversations much sharper. Problem interviews - Talk to people who might have the problem you’re trying to solve. Not to pitch your idea - to understand their world. What are they doing today? What’s frustrating? What have they already tried? Rob Fitzpatrick’s The Mom Test is the essential guide here - specifically how to ask questions that give you real signal instead of polite encouragement. Assumption mapping - Write down everything you’re assuming to be true about your idea. Who has this problem? How often? How much does it cost them? Are they willing to pay for a solution? Rank those assumptions by importance and how confident you are in each. The ones that are both critical and uncertain are where you focus first. Early signal testing - Before building anything, find the cheapest way to test your most critical assumption. A landing page. A concierge. A fake door. Five customer conversations. The goal is evidence, not a prototype.

​
The failure mode to avoid

The most common mistake in initial discovery is confirmation bias dressed up as research. You go in with an idea you already love, you talk to people who are too polite to tell you it’s a bad idea, and you walk away with a deck full of quotes that support what you already believed. The fix is to go in genuinely curious rather than looking to confirm. Invite people to tell you your idea is wrong. Ask “what would have to be true for this to be a problem worth solving?” and then find out if those things are actually true. Lesson learned: the best initial discovery I’ve done always ended with the original idea looking significantly different - or being scrapped entirely. That’s not failure. That’s the point 👊

​
When is initial discovery done?

It’s done when you have enough confidence to make a call - one way or the other. Either you’ve found enough signal that the problem is real, the market exists, and you have a credible hypothesis for a solution. Or you’ve found enough evidence that it’s not worth pursuing. Both outcomes are good. The expensive outcome is staying in discovery forever because you’re afraid to commit - or rushing out of it because you’re impatient to build. A rough heuristic: if you’ve talked to 10-15 people who have the problem you’re describing, and most of them have tried to solve it (badly), and at least some of them would pay for something better - you probably have enough to take a step forward. What that step looks like is a whole other conversation. But that’s what the rest of this section is for.