A roadmap is set from a confident stakeholder's hunch. Engineering spends a quarter building it, ships it, and almost nobody uses it. The idea was never tested against a real user or a real problem; it went straight from opinion to backlog to production. The most expensive way to discover an idea is bad is to build the whole thing first, and that is exactly what happened.
This is more than a wasted quarter. It is a failure to test ideas before building them.
Ambient Clinical Documentation Needs Better Infrastructure
The three engineering challenges that determine whether ambient AI documentation ships into a health system or fails security review.
Product discovery is more than gathering requirements. It is the practice of testing whether an idea is worth building, against real problems and real evidence, before it reaches the roadmap, so bad ideas are killed cheaply with a prototype or a conversation rather than expensively with a shipped feature.
However, many teams run discovery as a formality or skip it, and discover which ideas were bad only after engineering has built them.
If you are a CTO or VP of Product Engineering tired of building features nobody uses, the intent of this article is:
- Define what product discovery actually is
- Show why killing bad ideas cheaply is the whole point
- Lay out how evidence should precede the roadmap
To do that, let's start with the basics.
What Is Product Discovery? The Basic Definition
At a high level, product discovery is the work of deciding what is worth building before committing engineering to build it. It tests an idea against a real problem and real users using the cheapest evidence that can disprove it, a conversation, a prototype, a small experiment, so that only validated ideas reach the roadmap and bad ones die before they cost much.
To compare:
Discovery is tasting the sauce before cooking the whole banquet. A spoonful tells you if it is wrong for the cost of a spoonful. Skipping discovery is cooking the banquet, serving it, and finding out at the table. The point of discovery is to fail on the spoon, not the feast.
Why Is Product Discovery Necessary?
Issues that product discovery addresses or resolves:
- Ideas go from opinion to roadmap without evidence
- Engineering builds features nobody uses
- Bad ideas are discovered only after they are built
Resolved Issues by Discovery
- Ideas are tested before they reach the roadmap
- Bad ideas die cheaply, on a prototype or a conversation
- Engineering builds what is validated, not assumed
Core Components of Product Discovery
- A real problem defined, not just a solution
- Evidence gathered before commitment
- Cheap prototypes to test ideas
- Clear criteria for killing an idea
- A handoff of validated ideas to the roadmap
Modern Product Discovery Practices
- Customer interviews and problem validation
- Prototypes and experiments before full builds
- Evidence tied to real user behavior, not opinion
- Kill criteria defined before testing
- Discovery running continuously, ahead of delivery
The practices work only if the goal is to disprove ideas cheaply, not to justify ones already decided.
Other Core Issues They Will Solve
- Roadmaps carry validated bets, not hunches
- Engineering effort goes to ideas with evidence behind them
- Stakeholders align on problems, not pet solutions
In Summary: Product discovery tests ideas against real evidence before the roadmap, so bad ones die cheaply and engineering builds what is validated.
Importance of Product Discovery in 2026
Building is faster and cheaper than ever, which makes choosing what to build the real constraint. Four reasons explain why it matters now.
1. Building the wrong thing is the biggest waste.
When AI accelerates delivery, the risk shifts from can we build it to should we. Fast building of unvalidated ideas just produces unused features faster.
2. Cheap building tempts skipping discovery.
Because a prototype or feature is now quick to build, teams are tempted to build instead of test. But building the whole thing is still the most expensive way to learn an idea is bad.
3. Opinion scales badly.
As organizations grow, roadmaps driven by whoever is most confident produce more unused features. Evidence is what replaces opinion at scale.
4. Discovery is a competitive edge.
Teams that kill bad ideas cheaply spend their capacity on ideas that work, outbuilding teams that ship every hunch.
Traditional vs. Modern Product Practice
- Requirements from opinion vs. ideas tested against evidence
- Build then learn vs. learn then build
- Discover bad ideas in production vs. kill them on a prototype
- Roadmap of hunches vs. roadmap of validated bets
In summary: A modern approach gathers evidence before the roadmap and kills bad ideas cheaply, rather than building first and learning last.
Details About the Core Components of Product Discovery: What Are You Designing?
Let's go through each dimension.
1. Problem Layer
The real problem worth solving.
Problem decisions:
- A validated problem, not a chosen solution
- Evidence that users actually have it
- The problem framed before any feature
2. Evidence Layer
What would disprove the idea.
Evidence decisions:
- The cheapest test that could kill the idea
- Real user behavior over stated opinion
- Evidence gathered before commitment
3. Prototype Layer
Testing the idea cheaply.
Prototype decisions:
- A prototype or experiment before a full build
- Just enough to test the risky assumption
- Fast, disposable, and honest
4. Kill Criteria Layer
Deciding in advance what would stop it.
Kill-criteria decisions:
- What result would kill the idea, set beforehand
- A willingness to actually kill it
- No moving the goalposts to save a favorite
5. Handoff Layer
Moving validated ideas to delivery.
Handoff decisions:
- Only validated ideas reaching the roadmap
- The evidence carried with the idea
- Discovery running ahead of delivery
Benefits Gained from Cheap Failure
- Bad ideas killed before they cost a build
- Engineering effort spent on validated ideas
- Roadmaps that carry evidence, not hunches
How It All Works Together
Discovery starts with a real problem, validated as something users actually have, not a solution someone likes. The team identifies the riskiest assumption and the cheapest test that could disprove it, then runs that test, a conversation, a prototype, a small experiment, watching real behavior rather than opinion. Kill criteria are set in advance, and the team is willing to act on them, so a failing idea dies cheaply instead of being rationalized forward. Only ideas that survive reach the roadmap, carrying their evidence with them. Discovery runs ahead of delivery continuously, so engineering always has validated work to build and bad ideas never make it to production.
Common Misconception
Discovery is a phase of gathering requirements before building.
Requirements gathering assumes the idea is right and documents it. Discovery assumes the idea might be wrong and tries to disprove it cheaply. The goal is not a spec; it is evidence, and specifically evidence that could kill the idea. A discovery process that only ever confirms what was already decided is not discovery.
Key Takeaway: Discovery is about trying to kill ideas cheaply, not documenting ones already chosen. If it never kills anything, it is not working.
Real-World Product Discovery in Action
Let's take a look at how discovery operates with a real-world example.
We worked with a team that kept building features nobody used, with these constraints:
- Test ideas before committing engineering
- Kill bad ideas cheaply, not in production
- Put validated bets on the roadmap, not hunches
Step 1: Validate the Problem
Start with the problem, not the solution.
- The problem confirmed as one users actually have
- Evidence gathered, not assumed
- The solution held back until the problem was real
Step 2: Find the Cheapest Disproving Test
Aim to fail cheaply.
- The riskiest assumption identified
- The cheapest test that could kill it chosen
- Real behavior favored over opinion
Step 3: Prototype and Experiment
Test before building.
- A prototype built just to test the assumption
- Kept fast and disposable
- Run with real users
Step 4: Set and Honor Kill Criteria
Decide in advance what stops it.
- Kill criteria set before the test
- The team willing to act on them
- Goalposts kept fixed
Step 5: Hand Off Validated Ideas
Move only survivors to delivery.
- Only validated ideas reaching the roadmap
- Evidence carried with the idea
- Discovery kept running ahead of delivery
Where It Works Well
- Teams building features that turn out unused
- Products where the cost of building the wrong thing is high
- Organizations willing to actually kill ideas
Where It Does Not Work Well
- Tiny, obvious changes where testing costs more than building
- Cultures where killing a leader's idea is politically impossible
- Teams that run discovery only to confirm decisions already made
Key Takeaway: Discovery pays off wherever building the wrong thing is costly and the organization is honestly willing to kill ideas that fail the evidence.
Common Pitfalls
i) Going from opinion to roadmap
Letting confident hunches become roadmap items without evidence produces features nobody uses. Test the idea cheaply first.
- Ideas skip validation entirely
- Engineering builds on assumption
- Bad ideas surface only in production
ii) Discovery that only confirms
Running discovery to justify a decision already made, and never killing anything, is theater. The point is to be able to disprove the idea.
iii) Skipping discovery because building is cheap
Fast building tempts teams to build instead of test, but the full build is still the most expensive way to learn an idea is bad.
iv) Not setting kill criteria
Without deciding in advance what would stop an idea, teams rationalize weak evidence forward and never actually kill anything.
Takeaway from these lessons: The failure is treating discovery as confirmation or skipping it. Define the disproving test, set kill criteria, and be willing to act.
Product Discovery Best Practices: What High-Performing Teams Do Differently
1. Validate the problem first
Confirm users actually have the problem before designing a solution, so you are not solving something imaginary.
2. Aim to disprove cheaply
Find the riskiest assumption and the cheapest test that could kill the idea, and run that.
3. Prototype before building
Test with a fast, disposable prototype and real behavior, not a full build and opinion.
4. Set kill criteria in advance
Decide what result would stop the idea before you test, and be willing to act on it.
5. Run discovery ahead of delivery
Keep discovery continuous, so the roadmap always has validated ideas and engineering never waits on hunches.
Logiciel's value add is helping technical teams build a discovery practice that kills bad ideas cheaply, so engineering capacity goes to validated bets.
Takeaway for High-Performing Teams: Spend cheaply to learn an idea is bad, so you spend engineering only on ideas that are good.
Signals Your Discovery Is Working
How do you know discovery is testing ideas rather than rubber-stamping them? Not by how much you research, but by what gets killed and what gets built. These are the signals that separate real discovery from confirmation.
Bad ideas die cheaply. Ideas fail on a prototype or a conversation, not in production.
Evidence precedes the roadmap. What reaches delivery carries validation, not just confidence.
Kill criteria are honored. Ideas that fail the pre-set test actually get stopped.
Fewer features go unused. What ships is used, because it was validated first.
Discovery runs ahead of delivery. Engineering always has validated work, and never waits on hunches.
Adjacent Capabilities and Connected Work
This work does not exist in isolation. Product discovery depends on, and feeds into, the delivery and design disciplines around it. Ignoring the adjacencies is the most common scoping mistake.
The roadmap and delivery consume the validated ideas discovery produces. The prototyping capability, faster now with AI, is how ideas get tested cheaply. The design and product practices carry discovery findings into what gets built. Naming these adjacencies upfront keeps the work scoped and helps leadership see discovery as the front of the delivery system, not a separate research function.
The common mistake is treating each adjacency as someone else's problem. The kill criteria are your problem. The evidence behind roadmap items is your problem. The prototypes that test ideas are your problem. Pretend otherwise and unvalidated ideas flow straight to the build. Own the adjacencies you depend on, partner with the teams that hold them, and share the timeline.
Conclusion
The most expensive way to learn an idea is bad is to build the whole thing. Product discovery front-loads that learning: it tests ideas against real problems and real evidence, sets criteria for killing them, and lets bad ones die on a prototype instead of in production. Run honestly, with a willingness to kill, it means engineering builds what is validated and stops shipping features nobody wanted.
Key Takeaways:
- Discovery tests whether an idea is worth building before engineering commits
- The goal is to kill bad ideas cheaply, not to document decisions already made
- Cheap, fast building makes discovery more important, because the full build is still the costliest way to learn
Running product discovery well requires testing ideas against evidence and being willing to kill them. When done correctly, it produces:
- Bad ideas killed before they cost a build
- Engineering effort spent on validated ideas
- Roadmaps that carry evidence, not hunches
- Fewer shipped features that nobody uses
EHR Integration Problems Engineers Actually Face
The three gaps between Epic's FHIR R4 documentation and production behavior.
What Logiciel Does Here
If you keep building features nobody uses, build a discovery practice that tests ideas against real evidence and kills the bad ones cheaply, before they reach the roadmap.
Learn More Here:
- Design Systems at Scale: Governance That Doesn't Choke Speed
- Frontend Performance: The Conversion Lever Engineering Owns
- Product Analytics Implementation: From Events to Decisions
At Logiciel Solutions, we work with CTOs and VPs of Product Engineering on discovery practices that put validated bets on the roadmap. Our reference patterns come from production deployments.
Read the guide to killing bad ideas cheaply.
Frequently Asked Questions
What is product discovery?
The work of deciding what is worth building before engineering commits, by testing an idea against a real problem and real users with the cheapest evidence that could disprove it, so only validated ideas reach the roadmap.
How is discovery different from gathering requirements?
Requirements gathering assumes the idea is right and documents it. Discovery assumes the idea might be wrong and tries to disprove it cheaply. The output is evidence, not a spec, and it must be able to kill the idea.
Doesn't cheap, fast building make discovery less necessary?
No. Building is cheaper, but building the whole thing is still the most expensive way to learn an idea is bad. Fast building without discovery just produces unused features faster.
What are kill criteria?
The results, decided before testing, that would stop an idea. Setting them in advance and being willing to act on them is what keeps discovery honest, rather than rationalizing weak evidence forward.
How does discovery reach engineering?
Only validated ideas move to the roadmap, carrying their evidence. Discovery runs continuously ahead of delivery, so engineering always has validated work to build and never waits on unproven hunches.
