Bringing Discovery to Engineers
Who 'Just Want to Build'

​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.

Reframe Discovery as Investment Protection

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.

Show Them the Evidence Gap

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:

• Feature requests without consequences for submitters
• Stakeholder opinions based on personal experience
• Competitive moves we assume are working

Compare that to serious commitment evidence:

• Users who actually sign up for waitlists
• Analytics data showing specific behavior patterns
• Customers willing to pay for beta access

Engineers understand this difference immediately. They wouldn't ship code without testing it (no matter how automated). So, why ship features without testing assumptions?

Right-Size Discovery Investment

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​

Make Your Leadership Offsite
Worth the Investment

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.

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.

Content I found Practical This Week

How to validate your B2B startup idea Read it here

Who is Tim Herbig?

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.