Hey I’m Ant and welcome to my newsletter where you will find practical lessons on building Products, Businesses and being a better Leader

You might have missed these recent posts:

- Product Roadmaps are NOT Todo Lists
- Bring it back to the problem
- Escape OKR Theatre

As part of my discovery for the Product Discovery course I’m working on - yes going very meta here - I decided to ask a bunch of product leaders, how do they define product discovery?

I then expanded that to the 35,000+ followers I have and ended up with 40 different definitions for product discovery.

Of course this shows that if you get 10 product people in a room, the chances of us all agreeing on something is slim to none 😆 but I was genuinely curious on what themes would emerge and if there were any better ways to frame product discovery.

Because whilst I jest. For the most part we’re just using different words to describe the same thing.

So what were some of the themes that came out?

Well, whilst I did my own synthesis I also gave ChatGPT, Claude and Miro’s AI a go - which you can watch the results of in this video.

Here were the top themes 👇

FYI if you're interested in the course you can join the waitlist here.
(I’m also considering running a live co-hort version, if you’re interested in that, reply to this email and let me know! If there’s enough interest, I’ll do it.)

Reducing Risk

A top theme was reducing risk.

This was framed in many different ways. Some specifically called it out like Amy Johnson, CPO Propel Ventures did;

“My view of discovery is that it is what you do to reduce risk - that users want it, it works for your business and you can build it (DVF). It helps avoid waste. How you go about that comes in many shapes and sizes rather than any prescriptive process.”

Others framed it as avoiding building the wrong thing:

“Writing code and delivering features in your product is a slow and expensive way to find out you're wrong. Discovery is about using quicker and usually less expensive approaches to decrease risk that you are building the wrong thing.” - Maarten Dalmijn, Author of 'Driving Value with Sprint Goals'

Others used similar phasing such as ‘reducing waste’:

“it’s about reducing risk before you build which helped me identifying the right problem.”
“Product discovery is an ongoing process of uncovering and validating real user problems, so we don't waste time building the wrong things.”
“…and paying down risks until we’re confident we’re building the right thing in the right way.”
“Risk mitigation approach in trying to building the right thing”
“derisking process or actions”
“It is about figuring out what’s worth building before you even build it!”
“Product discovery is the work of figuring out what’s actually worth building, before you burn cycles on code.”

Before writing a single line of code

A more contentious theme that came up was whether product discovery is something that is continuous or a phased ‘before writing a single line of code’.

“It is about figuring out what’s worth building before you even build it!”
“Product discovery is the work of figuring out what’s actually worth building, before you burn cycles on code.”
“Product discovery is about deeply understanding your users’ needs, pain points, and context to help you uniquely define the problems worth solving—and why—before a single line of code is written”
“A truth seeking mission before placing a bet.”
“…it’s about reducing risk before you build
“It’s research and the process of truly understanding customer needs, problems, and opportunities before building a solution.”
“Product Discovery is the process of understanding user needs, validating problems, and testing solutions before building the product.”

Vs those who framed it as a continuous process:

“Product discovery is an ongoing process…”
“...continuously discovering…”
“Continuous work that increases confidence in what problems to tackle and which solutions to thrive for.”
“Answering questions. And yes, discovery is continuous.”
“It’s a constant loop…”
“It’s the ongoing process…”

Of course these are only 1-2 line definitions so I do believe there’s a good chance that it’s semantics but I also know that continuous discovery and delivery (also known as dual track) is not something that every company has mastered.

Discovery in many places is still largely run like a project.

And that’s not a criticism either, I’ll always take some discovery over none, so I’m generally happy they’re at least doing something!

Not to mention that it also depends on your context. I’ve had clients who are in the healthtech space and it’s not so easy to drop regular updates - even harder if physical hardware is involved, which it often is, so being a bit more ‘waterfall’ so to speak, is how you have to work.

Which is why I like to bring it back to first principles and ask questions like, how do we derisk? And how much discovery is enough? Does a longer, more phased approach make sense for us? or can we be more continuous?

So let’s dig into some of those!

Clarity

When we start a new idea there’s high risk as we already covered, that risk exists because there’s uncertainty and things aren’t clear.

As one person framed it; “Product Discovery is.. transforming uncertainty into clarity…”

This is what product discovery is all about, it’s taking something that’s inherently uncertain and making it clearer.

“Product discovery is the art of separating noise from signs” - David Pereira, Product Coach & Author ‘Untrapping Product Teams’

This is why I like to frame the output of product discovery as confidence.

It’s the confidence that we’re solving a meaningful problem, that the solution meets the users needs in the best possible way and that it works for our business.

Continuous work that increases confidence in what problems to tackle and which solutions to thrive for.
Getting to the minimum level of confidence required, to unlock the next level of investment in the project.
“…and paying down risks until we’re confident we’re building the right thing in the right way.”
Getting to the minimum level of confidence required to justify/unlock the next step.
Discovery helps us figure out which ideas are truly worth the investment before we commit.

Learning

The primary way that we build confidence and clarity is through learning.

This was a key theme with some people even calling to re-frame ‘discovery’ as ‘learning’ instead.

“Discovery can be a bit of a loaded term in a lot of orgs... I've had some success with language like "Learning Goals" instead:- We assume X and need to validate it- We will do Y to validate that (experiment, research, spike)- We will take Z action if we are correct.”

“A truth seeking mission before placing a bet.”
“Answering questions. And yes, discovery is continuous.”
“Time spent exploring the problem space to understand where the team could add value, primarily focused on learning and validating hypotheses.”
“REGULAR structured learning with customers to validate hypotheses and uncover insights that inform new product opportunities.”
“…Learn through qualitative and quantitative signals…”

And how do we learn? Research.

Research

Product Discovery = research.

Or as John Culter hilariously put it:

“Research, but framed in a way not to hurt product people's feelings and ego.”

Product Discovery is really just applying research techniques to learn more, to gain confidence and clarity.

And we want to do that to reduce the risk of building something nobody wants.

Of course it’s a bit deeper than that, we have many different kinds of risks, such as:

The problem doesn’t exist or isn’t big enough for people to care.
It doesn’t affect enough people.
and/or that the solution to that problem is not feasible.
and/or that the solution isn’t usable or desirable.
and/or that it doesn't work for our business (eg strategy, legal, ethics, return on investment, costs, etc)

We often bucket these into problem vs solution space and DVF (desirability, viability and feasibility).

Which no surprise came out strongly in the different definitions:

“It’s the ongoing process of getting super clear on the problem we’re solving and how we’re solving it.”
“It’s about identifying real problems worth solving…”
“Product discovery is the process of identifying how to deliver more value to your customers in ways that, in turn, create greater value for your business.”
“Product discovery is often framed around business viability and tech feasibility”
“Time spent exploring problems & solutions”
“answers three critical questions on risk which are usability, viability and feasibility risks.”
“My view of discovery is that it is what you do to reduce risk - that users want it, it works for your business and you can build it (DVF)”

Side bar: Problem vs Solution

Interestingly 21 out of the 40 definitions all mentioned the problem space yet only 8 mentioned solutions.

You could expand that analysis to include words like “build” as a proxy for solutions bringing it up to 17 out of the 40 definitions, but I noticed there was still a large emphasis on the problem space.

Now I hypothesize that this is largely a reaction to a “build it and they will come”, solution first mentality that has dominated many companies for decades. But I thought it was worth calling out this out because discovery is more than just ‘validating the problem’.

For starters, the solution and problem space aren’t mutually exclusive.

Of course we want to avoid the bias of a solution at the start but how we solve the problem has an impact on how desirable something is.

It’s not enough to say this is a big problem and therefore it’s desirable. If your solution is crap then it won’t be desirable.

There’s also a relationship between value and effort.

This is best described by the Fogg Behavioural model where tasks that have a low barrier in terms of skill or effort require low motivation to do them, whilst tasks with high barriers will require high motivation otherwise we simply won’t do them.

*Fogg Behavior model* *with my adaptation* *of reframing “Ability” to “Barrier”*

Motivation on a customers side; eg how big is the problem for them needs to be disproportionate to the effort required.

This is why reducing friction, minimizing clicks, steps, etc (in most cases) are effective at increasing adoption, conversion, etc. We’re reducing that effort threshold and therefore capturing more people who might have lower levels of motivation.

All this means that don’t be surprised if you need to spend more time in the solution space.

Marty Cagan has talked about this before. It’s worth reading this post on ‘Discovery – Problem vs. Solution’. Here’s a snippet:

So this is an important principle to understand about product discovery, but beyond this, one consequence of this problem vs solution space thinking is how often I find product teams that associate product discovery only with “exploring the problem space.”
These people have this overly simplistic notion that product management and product design work to define the problem, and then engineering works to build a solution.
[...]
The vast majority of product efforts fail not because of demand, but because they can’t come up with a solution good enough to get people to switch.
Ultimately our job in product discovery is not just to validate the problem, but to come up with a solution that customers love, yet works for our business. What this means specifically is to come up with a solution that is valuable, usable, feasible and viable.
And this is why in strong product companies, the vast majority of our product discovery work is spent – and needs to be spent – on the solution.

The last thing I want to add is whilst we want to avoid jumping too quickly to solutions and the bias that comes with it, it is ok to start with a solution and leverage that to explore the problem space. Just be mindful that you’re using it as a tool to learn more about the problem space, not validating that the solution is a good one (eg confirmation bias).

"While many teams work top-down, starting by defining a clear desired outcome, then mapping out the opportunity space, then considering solutions and finally running assumption test… the best teams also work bottom-up. They use their assumption tests to help them evaluate their solutions and evolve the opportunity space.” - Teresa Torres, Continuous Discovery Habits

This is why I much prefer the visualization where the problem and solution spaces are viewed as two wedges.

Because there’s no real point where you tick off the problem and move to the solution, you’re always working on both at the same time - you just might be more problem focused at the start and more solution towards the end.

Cool, I’ll leave it there for today.

Last thing before I drop all the definitions is my definition of product discovery:

Product Discovery is about reducing risk through learning. We do this by applying research techniques to gain confidence that:
- we're solving a meaningful problem (desirability)
- it works for the business (viability)
- and we're solving it in the best possible way (feasibility)

I hope that was valuable, I’ll drop all the definitions below for those who are interested 👇

And as usual, if you got value from this someone else will too - so share the love - send it to a friend!

Oh and big shoutout to Amy Johnson, Elizabeth Griffiths, Shannon Vettes, David Pereria, Maarten Dalmijin, Georgie Smallwood, Janna Bastow, Robin Zaragoza, Corinna Stukan, Navya Gupta and anyone else I missed who I DM’d for their take on Product Discovery 🙏

All Definitions

My view of discovery is that it is what you do to reduce risk - that users want it, it works for your business and you can build it (DVF). It helps avoid waste. How you go about that comes in many shapes and sizes rather than any prescriptive process. - Amy Johnson, CPO Propel Ventures
To me, product discovery is about gaining clarity and reducing uncertainty. It’s the ongoing process of getting super clear on the problem we’re solving and how we’re solving it. It’s about deeply understanding customer needs, validating assumptions, and paying down risks until we’re confident we’re building the right thing in the right way. - Elizabeth Griffiths, CPO Haast
It’s the ability to explore the problem space just enough to find a problem worth solving. This ensures your investments will bring a return in value. - Shannon Vettes, CPO and CEO Usesnap
Product discovery is the art of separating noise from signs, enabling teams to focus on what drives value and ditching what distracts them. - David Pereria, Product Coach & Advisor
Writing code and delivering features in your product is a slow and expensive way to find out you're wrong. Discovery is about using quicker and usually less expensive approaches to decrease risk that you are building the wrong thing. - Maarten Dalmijn, Product Coach and Author of Sprint Goals
I believe great product discovery starts with deep curiosity and a clear understanding of the customer’s world. It’s about identifying real problems worth solving, not just validating ideas we’ve already fallen in love with. At its best, discovery aligns cross-functional teams around insight, not assumption, and unlocks genuinely valuable outcomes.
I often explain product discovery as due diligence—especially for people outside of product. Just like an investor wouldn’t fund every pitch that lands on their desk, we don’t build every idea we hear. Discovery helps us figure out which ideas are truly worth the investment before we commit time, people, and money- and we figure that out by the first paragraph - **Georgie Smallwood,** CPTO Moonpig
Product discovery is the process of identifying how to deliver more value to your customers in ways that, in turn, create greater value for your business. - Robin Zaragoza, Fractional CPO & Product Management Coach
Product discovery is an ongoing process of uncovering and validating real user problems, so we don't waste time building the wrong things. It's about continuously testing assumptions, gathering feedback, and iterating to create solutions that deliver genuine value. - Janna Bastow | CEO & Co-Founder ProdPad
Product Discovery is about figuring out what truly matters - to the customer and the business. - Corinna Stukan, CEO @ Bizzy and Author of Insights Driven PM
Product discovery is about deeply understanding your users’ needs, pain points, and context to help you uniquely define the problems worth solving—and why—before a single line of code is written. - Navya Gupta, Chief Product Officer at Talent.com
Research, but framed in a way not to hurt product people's feelings and ego. - John Cutler, Head of Product @ Dotwork
A truth seeking mission before placing a bet.
The creation of new institutional knowledge that gives our organisation competitive advantage in the products and services it offers. Framing discovery without business value or continuously discovering what you already know (i.e., not 'discovering' anything at all) is what has given "discovery" the bad name it has.
Discovery can be a bit of a loaded term in a lot of orgs... I've had some success with language like "Learning Goals" instead:- We assume X and need to validate it- We will do Y to validate that (experiment, research, spike)- We will take Z action if we are correct. Bonus points for a time-box that keeps the cost of learning appropriate / proportional to the cost of being wrong
Bridge that connect business needs with users pain points to create value with minimum risk
Continuous work that increases confidence in what problems to tackle and which solutions to thrive for.
Discover what your users love and deliver that outcome, because this is what drives your business results up.
It’s less about answers, more about asking the right questions early. Also, it’s about reducing risk before you build which helped me identifying the right problem.
Risk mitigation approach in trying to building the right thing
Product discovery is often framed around business viability and tech feasibility; but it’s just as important to define it by what it isn’t. It’s not about validating a pre-decided outcome, confirming bias, or finding ways to solution what was assumed from the start. True discovery challenges assumptions and opens up unexpected opportunities
Getting to the minimum level of confidence required to justify/unlock the next step.
Answering questions. And yes, discovery is continuous.
Discovery is not a stage. It’s a loop. The loop is simple: explore, learn, decide, repeat.- Explore the problem space: user context, pain points, constraints- Learn through qualitative and quantitative signals: interviews, data, prototypes, objections.- Decide what’s real, what matters, and what’s worth committing to.- And then loop again because discovery isn’t linear, and context shifts. New evidence reopens the problem. New framing reshapes the opportunity. What makes it a loop is that the outcome of one cycle feeds the next. The team learns faster, the framing sharpens, and the cost of bad decisions drops. The mistake most teams make? They treat discovery as a gateway. In reality, it’s a judgment loop that runs the entire product lifecycle, especially under pressure.
Time spent exploring problems & solutions with the intention to maximise chances of success.
Discovery = figuring out what to build.
It’s research and the process of truly understanding customer needs, problems, and opportunities before building a solution.
The first parts of a proper human-centric design process, simplified for amateurs.
derisking process or actions that may be applied to the problem or solution space in order to drive positive outcomes.
Aligning bets with the capabilities and environment of the team placing them.
So much of discovery is about finding and solving the right problem, but the work won't be worth it if a team isn't aligned to deliver on what they learn.
The work you do to find the next best opportunity / problem to solve (= why). It's distinctly separated from validation (= how).
It is about figuring out what’s worth building before you even build it! By validating real user problems ,not just great ideas!
Product discovery is the work of figuring out what’s actually worth building, before you burn cycles on code. It’s not a phase or a checklist. It’s a constant loop of talking to customers, poking at assumptions, and running small experiments to see what breaks. It's a team sport: engineers, designers, and PMs all in the same room, hearing the same feedback, seeing the same data. That’s how you avoid building for ghosts and start solving real problems.The goal isn’t to validate your idea. It’s to find out, as quickly as possible, if you’re wrong, and then get to something that’s actually valuable. Most of what you try won’t work. That’s the point. The faster you learn, the less you waste.
Time spent exploring the problem space to understand where the team could add value, primarily focused on learning and validating hypotheses. End result should be a well-defined problem tied to a business metric/outcome and a shortlist of validated solution ideas.
REGULAR structured learning with customers to validate hypotheses and uncover insights that inform new product opportunities.
Product Discovery is the cornerstone of successful product development, transforming uncertainty into clarity by ensuring that every decision is rooted in user needs and business context
Product Discovery is the process of understanding user needs, validating problems, and testing solutions before building the product.
Getting to the minimum level of confidence required, to unlock the next level of investment in the project (where that investment might be time, headcount, budget, focus, etc)
Product discovery is a moment that got product manager, designer and tech lead answers three critical questions on risk which are usability, viability and feasibility risks. Viability is just will the user see value In our product? This is more about solving users problems.