Bringing Discovery to Engineers
|
Dear Reader,
I've coached product teams where engineering managers push back on discovery work, convinced that buildins is always faster than validating. They might see testing and validating ideas as obstacles between them and shipping cooler and shinier features. And, should you always extend your Discovery to a quarter because "that's how long we've planned for it," they might be right, but that's another topic.
The problem isn't that engineers hate learning—it's how we're framing discovery.
A product manager I once coached shared a helpful reframe that: "Product discovery is about protecting a company's investment."
This perspective helps explain discovery's value to stakeholders who might be more focused on business outcomes than user-centered processes. When engineers hear "let's do more user interviews," they think academic exercises. When they hear "let's protect our development investment," they might think risk management.
Engineers respect evidence. So show them the difference between assumptions and actual evidence using this simple question: "How real is this insight, and how relevant is it?"
Most "logical" feature ideas are built on what I call lip service evidence—things like:
Compare that to serious commitment evidence:
Engineers understand this difference immediately. They wouldn't ship code without testing it (no matter how automated). So, why ship features without testing assumptions?
The biggest objection? "Couldn't I have just built the feature in the time it took to validate it?"
This reveals a crucial discovery skill: knowing when you have enough evidence to move forward confidently. And acknowledging costs beyond the time it takes to build a solution (distributing and maintaining everything that gets built - hello, supercharged AI shipping cadence).
Low-stakes decisions (reversible changes): Quick conversations, simple analytics. Discovery effort: Hours.
Medium-stakes decisions (cross-team features): Prototypes over builds, targeted validation. Discovery effort: Days (building in hours, testing it with the right customers takes the rest).
High-stakes decisions (platform changes): Extensive validation justified by the cost of being wrong. Discovery effort: Weeks.
The goal isn't perfect certainty, but sufficient conviction relative to the cost of being wrong.
Don't try to convert your entire engineering team overnight. Start with one activity to reduce uncertainty that takes less time than building the feature would. When it prevents building the wrong thing, you've made your point.
The most ambitious discovery advocates aren't the ones who followed perfect processes. They're the ones who protected their team's time by learning what not to build.
Thank you for Practicing Product,
Tim
Flying the team out, stepping away from day-to-day business, blocking precious time—it’s a big commitment. The real question is: will your offsite deliver lasting impact? With Sonja Mewes’ facilitation, your leadership team turns time together into a clear shared direction, practical outcomes, and momentum that lasts long after you return.
| 👉 Learn More |
I highly recommend working with Sonja. Not only because she's my life partner, but also because I have experienced firsthand how she creates space for individuals and groups to discover their path.
As a Product Management Coach, I guide Product Teams to measure the real progress of their evidence-informed decisions.
I focus on better practices to connect the dots of Product Strategy, Product OKRs, and Product Discovery.
1 tip & 3 resources per week to improve your Strategy, OKRs, and Discovery practices in less than 5 minutes. Explore my new book on realprogressbook.com
Product Practice #381 How to ConnectNorth Star Metrics and OKRs READ ON HERBIG.CO PUBLISHED Oct 23, 2025 READING TIME 5 min & 25 sec Dear Reader, I once worked with a team whose OKRs read like a best of every company's KPI dashboard: user engagement up 15%, conversion rate improved by 10%, feature adoption increased by 20%. When I asked how these connected to the specific intentions they want to pursue to drive long-term customer and business value, they couldn't link them. Their OKRs looked...
Product Practice #380 How to put Real Progressinto Practice READ ON HERBIG.CO PUBLISHED Oct 16, 2025 READING TIME 4 min & 28 sec Dear Reader, When I wrote my book Real Progress, I didn't want it to feel like a light read you browse front-to-back. Instead, I wanted it to feel dense. Dense with practical knowledge. I couldn't finish more than two pages in a row of the best non-fiction books I've ever read. Every two pages brought a new insight, nugget, or practical tip that I wanted to capture...
Product Practice #379 OKRs for MeasuringAI Adoption & Effectiveness READ ON HERBIG.CO PUBLISHED Oct 9, 2025 READING TIME 5 min & 32 sec Dear Reader, In The OKR Parallel Universe Syndrome, I wrote about an interesting cycle: Teams model their OKRs after the company OKRs. The company insists that other things are "also important." So when teams share their roadmap items connected to the OKRs, but get pushback on where the work on these "other important things" is happening. I'm not sure if this...