3 Universal Truths to Cut
|
Dear Reader,
"We need more user research!" "Let's run a design sprint!" "Have you tried jobs-to-be-done?" Product Discovery can feel like drowning in an ocean of frameworks and methods. But after coaching dozens of product teams, I've found that successful Discovery isn't about following perfect processes—it's about understanding three fundamental truths that cut through the noise.
Truth #1: Evidence Beats Process
The strength of your evidence matters more than the steps you took to get it. Teams frequently get caught up in following the "right" process, but what truly drives progress is gathering reliable evidence about customer problems and potential solutions. Real, observed behavior will always trump reported feedback, and evidence showing meaningful commitment beats casual interest every time.
Truth #2: Context Beats Convention
There is no one-size-fits-all approach to Discovery. What works for a B2B enterprise product won't necessarily work for a consumer mobile app. The key is matching your method to what you need to learn next. Sometimes, that means running quick experiments instead of extensive research. Other times, it means conducting deep customer interviews before prototyping. Your context—including your customer type, business model, and constraints—should guide your choice of methods.
Truth #3: Focus Beats Completeness
Not every customer problem needs to be solved, and not every feature idea is worth pursuing. Valuable Discovery means choosing which problems matter most to your strategic goals. Teams need to evaluate the reliability of their customer insights and use that information to decide what to work on. This means being deliberate about which customer segments to focus on and which problems to prioritize.
The most successful teams I've worked with embrace these truths by:
Remember: The goal isn't perfect certainty—it's gathering enough reliable evidence to make confident decisions about what to (or not to) build next. When teams focus on these fundamentals instead of getting lost in the process, they consistently deliver solutions that matter for both users and the business.
Did you enjoy the newsletter? Please forward it. It only takes two clicks. Creating this one took two hours.
Thank you for Practicing Product,
Tim
There is ONE last ticket available for my in-person Product Discovery workshop on March 10 in London (as part of Mind the Product conference).
GET THE TICKET! |
(In case it's gone already,
check out one of the other amazing workshops)
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.
Product Practice #356 4 Opportunities to Layer AI into Your Product Discovery Activities READ ON HERBIG.CO PUBLISHED Mar 28, 2025 READING TIME 4 min & 32 sec Dear Reader, To use AI to shorten your lead time and reduce uncertainty, consider it a layer to supercharge your existing workflow. Instead of generating with AI, think about supercharging with AI. Here are four common Product Discovery activities where thoughtful AI integration can dramatically reduce uncertainty without sacrificing...
Product Practice #355 You’re Not Writing OKRs.You’re Reformatting KPIs READ ON HERBIG.CO PUBLISHED Mar 21, 2025 READING TIME 5 min & 32 sec Dear Reader, Every product organization has seen it - "OKR Theater" - Teams meticulously craft perfect objective statements, debate whether something is "outcome enough," and create elaborate tracking systems that generate more busy work than value. Behind this theater lurk predictable patterns: We adopt "best practices" without a clear why. Instead of...
Product Practice #354 Stop Looking at Flat Dashboards READ ON HERBIG.CO PUBLISHED Mar 29, 2025 READING TIME 4 min & 06 sec Dear Reader, Jeff Patton explained why flat backlogs don’t work for prioritizing user stories more than 16 years ago: Arranging user stories in the order you’ll build them doesn’t help me explain to others what the system does. Try handing your user story backlog to your stakeholders or users when they ask you the question “what does the system you’re building do?” I...