The urgency to release, iterate, and scale can mean we risk completely missing the mark on impact.
Joe Fields
Product Management runs on momentum; speed is like currency. The urgency to release, iterate, and scale can drown out a more vital question: Are we even solving the right problems?
This is the heart of the Product Discovery dilemma. Teams get laser-focused on building solutions, shipping features, launching MVPs and ticking boxes, but in the rush, we risk completely missing the mark on impact.
"No matter how good the team… if we’re not solving the right problem, the project fails." Woody Williams
Product Discovery is the most underestimated and misunderstood phase of the product lifecycle. It's where we should challenge assumptions, interrogate user behavior, and build confidence in what we’re choosing to solve. But too often, discovery is either too shallow or skipped entirely in favor of diving into delivery.
The cost? You might ship a slick, polished solution that solves… the wrong problem.
And that’s not just a waste of engineering effort, it’s a missed opportunity to create real value.
“Many companies put a heavy emphasis on delivery… while under-investing in discovery, forgetting to assess if you built the right stuff.” Teresa Torres
Modern teams have become exceptionally adept at moving quickly. Agile ceremonies, delivery sprints, productivity tools, they all make it feel like work is getting done. And technically, it is. But shipping isn’t the same as solving.
If your roadmap is packed with features and fixes based on gut feel, stakeholder whims, or legacy assumptions, you’re not moving forward; you’re just moving.
As Product Managers, the real leverage lies not in delivering more, faster, but in deciding what to build and why.
"Roadmaps are evidence of strategy. Not a list of features." Steve Johnson
So how can you tell if your team is sprinting in the wrong direction? Here are a few red flags:
🚩 You’re measuring output, not outcomes
🚩 Customer feedback starts with “I don’t really use that because…”
🚩 Team members build with uncertainty or detachment
🚩 Research is treated like a one-off exercise, not a continuous loop
🚩 Success is defined by delivery velocity instead of problem resolution
If any of this feels familiar, you’re not alone. But the fix requires more than just retrofitting your backlog—it demands a cultural shift toward problem-first thinking.
Let’s state the obvious: your users don’t care about your roadmap. They care about their own pain points, goals, and workarounds. Our job in Product Management is to bridge that gap, not with features, but with meaningful solutions to validated problems.
This starts by reframing the purpose of Product Discovery: it’s not about validating your pet idea—it’s about uncovering the right problems to solve.
“Your job isn’t to build more software faster: it’s to maximize the outcome and impact you get from what you choose to build.” Jeff Patton
✅ Understand the ‘why’ behind customer behavior
✅ Validate whether a problem is worth solving
✅ Explore multiple solutions before committing to one
✅ De-risk your build process before writing a line of code
✅ Align your team around context, not just features
With this mindset, you turn discovery into a tool for deciding what to build, not just a checkbox to get through before delivery.
Even experienced teams can fall into what we might call "solution seduction." Someone has a good idea. There’s energy, enthusiasm, maybe a few slick mockups. Before long, the backlog is full and build mode kicks in.
The danger here is that early momentum disguises weak insight. If you’re not grounding your concept in real, observed customer need, the risk of irrelevance skyrockets.
This is where qualitative discovery techniques come in. User interviews, shadowing, hypothesis mapping, and opportunity solution trees. They’re not just activities, they’re assets for solving problems before you start building solutions.
“Fall in love with the problem, not with the solution." Ash Maurya
One of the most powerful shifts a team can make is treating discovery as a collaborative practice. Involve engineers early. Invite designers to research calls. Share insights in the open.
When everyone is bought into the context, not just the tasks, you create more alignment, more ownership, and ultimately, better products.
Discovery done in silos leads to disconnected decisions. Shared discovery turns insight into strategy.
"Continuous discovery depends on the full product trio (PM, designer, engineer), making user understanding a shared responsibility." Carlos Gonzalez de Villaumbrosia
There’s no universal blueprint, but high-functioning product teams often show similar traits:
🔷 They frame problems clearly and revisit them often
🔷 They prioritize learning over guessing
🔷 They test assumptions continuously, not just during inception
🔷 They articulate desired outcomes before jumping to features
🔷 They kill weak ideas early and without guilt
These habits lead to stronger team confidence, not because they know what the solution is, but because they know the problem matters.
It’s easy to conflate velocity with progress. But moving fast in the wrong direction just gets you nowhere quicker. If you take one thing from this, slow down before you speed up. Pause and ask ... are we solving the right problem?
