What Is Product Discovery: A Founder’s Guide

You won’t find the root of most product failures in engineering. They have their origins months before that, in a strong opinion being taken for evidence. The Standish Group’s 2024 CHAOS report (see the Atlassian overview of product discovery) has software project success running at some 31 per cent. About half are up against it and 19% are straight out failures. And they are rarely technical ones; more often than not, they are bad wagers on the wrong user or the wrong first version.

Product discovery is your way of staying off those charts. For a founder it means making the call on what to build, what to leave alone and what to test next, all before the engineering invoice comes due. We put together this guide to cover what discovery is, how it is distinct from delivery, how to do it in weeks as opposed to months and where you are likely to trip up.

What Product Discovery Actually Is

In essence, product discovery is an ongoing, evidence-based exercise in de-risking before you make a major commitment to a build. Modern practice tends to look at four risks: value, usability, feasibility and viability. Discovery is there to take the uncertainty out of each.

The distinction is important. It is easy to conflate discovery with user research, which is merely one part of it, or with a one-off workshop that is too limited. As Product Talk’s guide to product discovery will tell you, discovery is deciding what to build; delivery is the act of building it. In any mature team the two happen in parallel.

When you are a founder in the early stages, it takes on a more pragmatic form: you are looking for enough evidence to do one of four things.

• Build it. You have a clear problem and the solution checks out.
• Change course. The need is there but the concept is off.
• Narrow the scope. Too big for a v1.
• Stop. Not worth the spend.

That final option can be hard to swallow but it is where you save the most. Put an end to a weak idea in week three and you have saved six months of engineering and a year of marketing it into the ground.

Discovery isn’t for proving your idea is brilliant. You do it to see where it breaks before your budget does.

What You Are Actually Reducing Risk Around

The four-risk framework may sound like theory until you apply it to the questions a founder has to ask.

With Value you want to know if the people you are after will actually put down money or alter their behaviour. Don’t be fooled by polite interest. Look at past behaviour. If someone is already cobbled together a Zapier flow or a spreadsheet to get around the problem, that is value. “That sounds interesting” is not.

Usability is about whether your intended workflow is the one users live in. This is where many an internal tool or B2B offering quietly dies. The buyer may have signed but the person using it every day is working around the product.

Then there is Feasibility. Can you put it together with the data and integrations at hand? All too often a founder has done a fine job of validating desirability only to find the whole thing hinges on an API the source platform won’t give you.

And Viability: will the business model stand up to the realities of pricing, support and competition? A product can be popular and unviable in equal measure.

If your discovery is all about user love and you have ignored the rest, you are doing what most “validated” products do and fail once they are out the door.

From Founder Opinion to Validated Decision

Itamar Gilad has a confidence model that is a good way to view progress – you move from opinions to assessments to hard data and test results. As he makes the case for, you should never launch on an opinion, but don’t go chasing absolute certainty either. You stop when the cost of another test outweighs the risk.

For a first-time founder this is a short, structured affair. Most teams will follow the same pattern no matter what they name it:

1. Understand. Watch what people with the problem are doing today.
2. Define. Make a problem statement, not a feature wish list.
3. Ideate and prototype. Get some cheap sketches of solutions down.
4. Test and decide. Show the users and then build, change or walk away.

Product School refers to it as the Double Diamond because you diverge to get your bearings and then converge on something to build. The nomenclature changes, the cycle doesn’t.

What good interview questions sound like

When discovery goes wrong it is usually an interview problem, not a method one.

Ask a bad question and you get a prediction of the future. “Would you use an app for X?” People are obliging and will say yes to something that doesn’t exist.

Better to be specific and talk about the past.

• Tell me about the last time this came up.
• What was the consequence of getting it wrong?
• What did you do in lieu of a proper fix? What have you put in place before the current workaround?

Future promises don’t hold as much water as past behavior. And if you are looking to put some structure on your interview signal and cast a wider net for feedback, voice of customer programs make for a good complement once you have a prototype or product in hand.

What a real problem statement looks like

When you get that raw input, you need to refine it. A proper problem statement will tell you who the user is, what job they have to do and what stands in their way. Take these for instance:

• The membership manager is dependent on a developer to update gated content, adding support overhead and slowing down publishing.
• On mobile, the wholesale buyer can’t reorder with any speed, so repeat business has to go through email or the phone.

Don’t confuse “build a dashboard” with a problem statement; at best it is an answer and not always the right one. For those looking to translate founder vision into something a team can scope, we go over how to write a product brief in more detail.

A Four-Week Discovery Rhythm That Works

If you are a founder without a full product org to lean on, the best form of discovery is a short sprint with a time limit and a decision to be made.

Make week 1 about evidence. Do your interviews and review the workflow. Look at your analytics and search queries, listen to sales calls and support tickets and see what your closest users are up to.

In week 2 you synthesize. Find the pain points and constraints that keep coming up, segment the patterns and pick the one problem you want to solve first. Put your assumptions on the table so they can be tested and write up the problem statement.

Week 3 is for rough concepts and a prototype. You don’t need engineering for this. A clickable Figma flow or a concierge process handled by humans behind the scenes will be enough to get a reaction.

Then in week 4 you test and decide. Run some sessions and watch for where people misread things or have to invent a workaround. Make your call out loud: build it, change it, or stop. Should you need a light touch to gather comments on an early web prototype without the review going off the rails on Slack, there is a guide to collecting feedback on early prototypes.

Time-boxing is important. If discovery drags on it ceases to be discovery and is just a means of putting off the decision.

Who needs to be in the room

You will see the same thing in mature product teams: an empowered trio of a product lead, designer and engineer from day one. Getting engineering involved early is the only way to spot feasibility issues before they turn into rewrites. Waiting until “the idea is ready” is a known way to fail.

For a solo founder you may not have the titles but you need the perspectives before you commit. Someone to know the user, someone to make the idea concrete and someone to tell you straight whether the systems and integrations will play nice.

That is the point of having a strategy phase before you start building. We saw it when we did discovery on the Workform AI MVP. The founder had a wide ranging vision for an AI assistant to help project managers with “everything.” The hard part was not the build. It was to pare the scope back to an MVP that could pull data from Asana, Slack and email and focus on a problem the user actually faced on a daily basis.

Where Founder Discovery Usually Goes Wrong

The tools come and go but the mistakes tend to follow a pattern.

Falling in love with the solution

You might be set on a custom dashboard or an AI chatbot. Your users may have a different, simpler need. Ambition is not the problem, attachment is. When you have made up your mind on the answer you are no longer listening for the problem.

Running validation theater

This is the costliest failure mode in product work today. The roadmap is done, the interviews are in the calendar but they are there to justify the plan, not alter it. Any negative evidence is rationalised and the build ships regardless.

You have to define your kill criteria before the test. Decide ahead of time what would make you pivot or stand down. Discovery is only any good if you let “no” win.

Treating AI synthesis as validated insight

AI is handy for sifting through reviews and support tickets but it won’t tell you what is true. The MIT 2024 study on enterprise generative AI is worth remembering; it found roughly 95% of pilots had no measurable ROI. An AI summary may sound clean but it is not evidence, merely a starting point for you to frame your hypotheses.

Skipping feasibility and viability

A lot of founders do their desirability research and call it a day. Then the engineering team can’t ship the idea on budget or the unit economics don’t add up. Don’t leave the questions of feasibility and business model for a post-mortem.

Building too much before testing

You don’t need a polished MVP to get real feedback. In a few days a rough one will show you where the trust signals are missing or the workflow doesn’t fit. That alone can save weeks of engineering time. Have a look at our minimum viable product guide if you are scoping a first build and want to keep it honest.

Discovery Is Continuous, Not a Phase

And remember, what works for discovery once won’t necessarily keep working. After you launch the market will move, competitors will ship and your users will find new ways around things. A team that thinks of discovery as a one-off will be starting from scratch in two years’ time.

You will find a more sound model is one that is continuous in nature. It means having weekly talks with customers and a running list of assumptions you can put to the test. You make it a habit to scale back or scrap an initiative when the evidence calls for it, not because someone made the most noise in the room. This is what allows for true prioritization. Should you be at odds over what goes into version one and what can wait, we have a working method for prioritizing product features you can follow.

In practice, it is straightforward for the majority of founders. Put aside time each week to speak with users, post-launch and all. Make note of your riskiest assumptions and test the top one off that short list.

Your Next Step Toward Clarity

Some see product discovery as a prelude to the real work, a delay. We see it as the thing that spares you from costly errors you could have avoided. A founder does not need another code option at the outset. What is needed is a better answer to some hard questions: who has this problem, how are they dealing with it today and why their workaround is no good? What is the most parsimonious solution? Does the evidence point to building, altering, narrowing or calling it quits?

Confidence in product work is not about being certain; it is about having better evidence. A good partner will help you get there without making a theatre of it. You want short cycles and unvarnished feedback, and the fortitude to put down a weak idea before it has turned into an expensive system.

So if you are mulling over an MVP, a migration or a rebuild, do not go looking for a quote just yet. Ask yourself if the problem is well enough defined to warrant the effort. That is the kind of decision-making our product design and discovery process is meant to resolve, and we go into further detail on how we view the whole process. And if you have not put those underlying assumptions through their paces, validating the business idea should be your first step.