How to Stop Shipping Perfect Features Nobody Uses
Using Product Discovery to build products people truly want.
Hey, Dmytro here — welcome to Atomic Product (FREE edition).
Every week, I share practical ideas, tools, and real-world lessons to help you grow as a product thinker and builder.
If you're new here, here are a few past posts you might find useful:
Hit subscribe if not on the list yet— and let’s roll 👇
Have you ever caught yourself thinking your team is moving fast, building beautifully… and completely missing the mark?
The feature is polished, deadlines met, the demo went great. But users? They smile politely — and never come back.
That’s the classic story of building “by gut feeling” or chasing the loudest stakeholder’s request — instead of checking if anyone actually needs it.
Product Discovery isn’t just a trendy term from a book. It’s your insurance against shooting in the dark. And today, I’ll show you how to make it part of your workflow without turning it into yet another box-ticking exercise.
1. What is Product Discovery
Ask ten product managers what Product Discovery is, and you’ll get ten different answers.
For some, it’s “the step before handing work to engineering.”
For others, “a couple of user interviews.”
And for some, it’s that mysterious ritual “UX researchers do.”
In reality — it’s the process of finding and validating opportunities that are actually worth building.
And process is the key word here. Discovery isn’t a one-off phase at the start of a project. It’s a habit of checking whether we’re still heading in the right direction — while we’re moving.
The simplest distinction:
Discovery answers “what” and “why.”
Delivery answers “how” and “when.”
I like Product School’s take — three checkpoint questions for any idea:
Is this problem worth solving?
Will this solution work?
Will it be better than the alternatives?
If the honest answer to even one of these is “no” — better not to waste the team’s time and the company’s budget.
In framework terms, this fits neatly into the first half of the Double Diamond — where we start by exploring the problem as broadly as possible, then narrow the focus to a clearly defined challenge.
Product Discovery is closely connected to Customer Development and Jobs To Be Done. The difference is that Customer Development is a method of collecting data, while Discovery is a broader process that brings together data, hypotheses, tests, and decision-making.
2. Why it matters
Most companies have two favorite ways of deciding what to build next:
Ask the loudest (or highest-ranking) stakeholder.
See what competitors are doing — and copy it.
Both are convenient. No need to waste time asking “extra” questions — you can jump straight into Jira, create tickets, and start “working.”
Except… that’s not really work. That’s a lottery.
If you’re lucky — you’ll guess right.
If not — you’ll bury months of effort and a chunk of budget into something nobody needs.
Product Discovery exists to remove the guesswork.
To stop measuring success by the number of features in your release notes, and start measuring it by how much those features actually move the product toward its goals.
In short — it’s the shift from a project mindset (“we shipped the project — success”) to a product mindset (“we changed user behavior — success”).
Instead of bragging about output, we focus on outcomes.
B2C example
In B2C, you can test dozens of hypotheses a month.
Ship a quick feature, release it to part of your audience, measure the metrics, kill it or improve it.
The cost of a mistake is low, and cycles are short.B2B example
In B2B, the stakes are higher.
Build the wrong feature — and you don’t just lose one user, you lose a contract worth hundreds of thousands of euros.
Implementation cycles are long, and fixing a miss takes time you often don’t have.
That’s why Discovery here isn’t just “nice to have” — it’s survival.
3. The risks of skipping Discovery
If you think skipping Discovery saves time — in reality, you’re just moving the cost of mistakes down the line. And that cost always grows.
Risk #1: “We already know”
One of the most common scenarios: the team and stakeholders are convinced they know what users need.
So instead of testing the hypothesis, they jump straight into development.
Later it turns out people use the product differently — or the “problem” you solved ranks about tenth in their priorities.
B2B case: In one document management SaaS, the team decided to add a “team comments module” to make collaboration “easier.”
After launch, they found all major clients were already using Slack or Teams — and had no intention of duplicating conversations inside our product.
The feature sat unused, yet we kept maintaining it for six months.
Risk #2: Falling in love too early
Once the team has a concrete idea, the brain switches to defending it.
We stop seeing alternatives and start bending any data to fit the desired outcome.
Discovery helps you avoid falling in love with the first thought, keep a portfolio of options, and test them with real users.
Risk #3: Fake success metrics
Without Discovery, we often treat the mere fact of shipping as success.
“We launched” = “We built something useful.”
In reality, user behavior might not change at all — or might even get worse.
In B2C, this means marketing spend goes down the drain.
In B2B, it means that at the next contract renewal, the client will ask you to remove that “useless” feature.
Risk #4: Expensive fixes
Any flaw caught before coding is cheaper to fix than after release.
In large systems with lots of integrations, rework can cost 10–20 times more than validating the idea with a prototype.
4. How the Discovery process works
Discovery isn’t a “one-off” workshop. It’s an ongoing process, built into the way the product team works.
To avoid drowning in it, it’s useful to understand the basic logic.
If we simplify, there are three key steps:
Define what outcome you want to achieve
Find opportunities that could lead to that outcome
Test potential solutions
One of the clearest ways to visualize this is Teresa Torres’ Opportunity Solution Tree:
Top of the tree – a clearly defined product outcome linked to a business goal.
(For example: reduce churn among paying users by 15% in six months.)Opportunity branches – what we’ve learned about user needs, pains, and desires that could help reach that goal.
Solution leaves – specific ideas for features, improvements, or processes that could address those opportunities.
Based on Teresa Torres’ Opportunity Solution Tree. You can read the original explanation here
Double Diamond in Discovery
Another useful lens is the Double Diamond:
Discover – widen the view, collect insights, talk to users, research the market.
Define – narrow down to the key problem you’ll solve.
Develop – open up again, generating multiple possible solutions.
Deliver – narrow down to the best ideas and test them quickly.
In Discovery, we’re especially focused on the first half (Discover + Define), but the best teams keep going and run hypotheses through the whole “figure-eight.”
What it looks like in practice (weekly rhythm)
Strong Discovery teams maintain constant contact with users.
Instead of “doing a round of interviews once a quarter,” they:
Run at least one interview or test every week.
Regularly update their opportunity map so they’re not working with outdated insights.
Run assumption testing to check if an idea is truly desirable, viable, feasible, usable, and ethical — an adaptation of the approach popularized by Marty Cagan and the Silicon Valley Product Group.
Minimum Discovery toolkit:
Customer interviews – not “What do you want?” but real usage stories.
(More on this here → User interviews: how to understand real needs)Journey mapping / Story mapping – to see context and critical steps.
(More on this here → Starting a new product: use CJM and story mapping)Prototyping – from paper sketches to clickable mockups.
A/B and demand tests – to validate demand without a full launch.
5. Who Owns Discovery
Short answer — everyone who will have to live with the product later.
But there’s a core to the process, and it’s definitely not “a lone genius PM doing everything.”
Product Trio
In many teams, the core of Discovery includes:
Product Manager — connects the work to business goals and sets priorities.
Design Lead — ensures the solution delivers a great user experience.
Tech Lead / Engineering Lead — evaluates technical feasibility and risks.
Important: a Tech Lead’s involvement in interviews and research depends on the product and context.
In B2C products, they may actively join early research to quickly understand constraints and opportunities.
In B2B — especially with complex architecture and long sales cycles — their role often focuses on assessing feasibility and integrations after the initial user interviews are done.
How others get involved
Discovery isn’t a closed club. The exact list of participants depends on the product, market, and stage. For example:
Analysts — find patterns in the data and confirm (or disprove) insights.
Marketing — understands which audience segments respond best to new ideas.
Support — hears the real customer pain every single day.
Sales (B2B) — give context on the needs of key accounts.
Supply / Vendor Ops (marketplaces, e-com) — know the real experience of sellers and suppliers.
Legal / Compliance (fintech, healthtech) — flag regulatory and ethical risks early.
A common mistake
Turning Discovery into “the PM’s side project.”
Decisions end up being made in a vacuum, and the team only hears about them once development starts.
This kills engagement and often leads to:
“We built exactly what you asked for, but we don’t believe in it ourselves.”
💡 Bottom line: yes, there’s a core trio — but it’s not a closed circle.
If you want strong results, involve everyone who can contribute a unique piece of the puzzle.
6. How to Make Discovery Part of Your Everyday Work
The biggest mistake is thinking Discovery is just a “phase” at the start of a project.
In reality, it’s not a stage — it’s a way of working.
1. Set a minimum cadence
The more often you talk to users, the less likely you are to miss the mark.
In startups, this can happen almost daily.
In corporations, you can bake it into sprints.
The key is to make sure you’re getting fresh feedback every month — not relying on a slide deck from a year ago.
2. Embed Discovery into sprints
Before sprint planning: validate key hypotheses.
During the sprint: run quick assumption tests on prototypes.
After the sprint: review metrics to decide where to dig deeper.
This way, Discovery stops being “a separate process” and becomes part of delivery.
3. Make small bets
Don’t wait for “the perfect study.”
Three quick tests on clickable prototypes will teach you more than a massive survey of 2,000 people six months from now.
Better to have 10 small iterations than one giant, painful rework.
4. Save and reuse insights
In B2B — especially with long sales cycles — one interview can stay relevant for years.
Set up a central repository (Notion, Confluence, Airtable) with:
a short description of the pain/need,
the source (link to recording or notes),
date and context.
This is your capital, not “waste material.”
5. Balance the plan with flexibility
Yes, you have a roadmap and quarterly goals (more on roadmaps here).
But if Discovery shows you’re heading in the wrong direction, it’s better to adjust than to stubbornly build something nobody needs.
💡 Bottom line: Continuous Discovery isn’t about “research for the sake of research.”
It’s about constantly fine-tuning your course so every week of development moves the product toward real value for users and the business.
Final thought
Product Discovery isn’t “research first, build later.”
It’s making sure you never build into the void.
Whether you work in B2B with half-year sales cycles or in B2C where every week counts — the team that learns faster what users truly need (and tests it in practice) will win.
Discovery is your filter — saving resources and sanity by keeping bad ideas out of the build queue.
If you like the Double Diamond logic or want to go deeper into combining Discovery with Design Thinking, I’ve covered it here with concrete steps and examples:
👉 Double vs. Triple Diamond — Why Two is Enough
👉 Design Thinking: How to Think Like a Designer
Recommended books on Product Discovery:
Continuous Discovery Habits — Teresa Torres
Inspired: How to Create Tech Products Customers Love — Marty Cagan
Lean UX — Jeff Gothelf & Josh Seiden
If you would like more recommendations for books, YouTube talks, or product creators to follow, check out my resource collection in 👉 the Atomic Product Library.
Thanks for staying with Atomic Product!
Take care😉
— Dmytro