Part 2 - The Refusal of the call & The Mentor - The Hero's Journey for Product Discovery

This is the second of series where we are exploring how The ‘Hero’s Journey’ model used by the world’s greatest authors

To read an overview of the Hero's Journey format. Click Here

This model has a series of distinct steps that all great stories possess.

The Refusal of the Call: Why We Resist Discovery

In every hero's journey, there's a moment of resistance. The refusal of the call.

The hero knows change is needed but finds reasons to stay in the familiar world. For product managers, this resistance is both predictable and understandable.

"We Don't Have Time for Discovery"

This is the most common refusal, and on the surface, it makes sense. Stakeholders want features shipped. Leadership wants to see progress. The roadmap has commitments. Where do you find time for discovery?

But this thinking is backwards. Sacrificing discovery usually leads to a disconnect between user needs and the products that are built. You don't have time NOT to do discovery. Every hour spent in discovery saves weeks of development time later.

The Time Paradox

Teams that feel too busy for discovery are usually busy building the wrong things. Discovery doesn't slow you down—it ensures you're running in the right direction.

"We Know What Our Users Want"

This refusal comes from experience and confidence. You've been in the industry for years. You understand the market. You've seen what competitors are doing. Surely that's enough?

Worse still, the refusal may come from experience with stakeholders, fighting the ‘good fight’ can be exhausting…

The problem with this assumption is that user needs evolve constantly, and our own expertise can become a liability. The more we know about our domain, the more we assume others share our knowledge and priorities. Discovery keeps us humble and accurate.

"Stakeholders Won't Wait for Research"

This refusal acknowledges a real organisational challenge. Stakeholders often want immediate action, not research and validation. But this creates a false choice between stakeholder happiness and user value.

The reality is that stakeholders want business results, not just feature delivery. When discovery leads to better outcomes, stakeholders become discovery advocates. The key is showing, not telling.

"Discovery Is Too Expensive"

This refusal focuses on the upfront costs of research, tools, and time investment. But it ignores the massive costs of building wrong solutions. Discovery is insurance—you pay a small premium upfront to avoid catastrophic losses later.

Cost-Benefit Reality: The cost of discovery is measured in hours and small budgets. The cost of building wrong solutions is measured in months and major budgets.

Meeting Your Mentor

Every hero needs a mentor, a wise guide who provides the tools and wisdom necessary for the journey ahead. In product discovery, frameworks serve as mentors, giving you structure and guidance as you navigate uncertain territory.

The Double Diamond Framework

Your first and most important mentor is the Double Diamond framework, a battle-tested approach that has guided countless teams from assumption-driven to evidence-driven product development.

The Double Diamond consists of four distinct phases arranged in two diamond shapes:

First Diamond: Problem Discovery

Discover: Explore and understand the problem space through research, user interviews, and data analysis

Define: Synthesise findings to clearly articulate the right problem to solve

Second Diamond: Solution Discovery

Develop: Generate and prototype multiple solution approaches

Deliver: Test, refine, and implement the best solution

Why the Double Diamond Works as a Mentor

Structure Without Rigidity

The framework gives you a clear process while allowing flexibility in how you execute each phase.

Prevents Common Mistakes

By separating problem and solution discovery, it prevents the most dangerous product mistake—solving the wrong problem brilliantly.

Builds Confidence

Having a framework reduces anxiety about "doing discovery right" and gives you concrete steps to follow.

Communicates Intent

Stakeholders understand the logic of exploring before building, especially when presented as a structured approach.

Your First Discovery Quest: The Problem Diamond

Start your discovery journey by focusing on the first diamond—truly understanding the problem before jumping to solutions.

Week 1-2: Discover Phase

• Schedule 5 user interviews with people who represent your target market

• Analyse your support tickets and user feedback for common themes

• Review any existing user research or analytics data

• Interview internal team members about the problems they hear most

Week 3: Define Phase

• Synthesise your findings into common problem themes

• Prioritise problems based on frequency, impact, and strategic importance

• Write clear problem statements that focus on user needs, not solutions

• Share findings with your team and stakeholders

This four-week investment will transform how you think about your product and give you evidence-based direction for future development.