5 Core Ideas of Adaptable
Product Discovery

Tell me a Product Discovery horror story in five words or less. I’ll start: Didn’t execute a validated idea. How can things like this happen? Some might say that management is to blame or the lack of skills and resources. Let’s face it: There will never be a perfect time or circumstance to get started with Product Discovery. There will always be other distractions and priorities waiting for you to deal with.

Written by Tim Herbig 

Reading Time: 12 minutes

Last Updated: May 2nd, 2022

5 Core Ideas of Adaptable Product Discovery Header Graphic

It’s also easy to feel like you need to wait until there’s enough buy-in, a perfect product strategy, better OKRs, etc. But as Product Managers, you have the responsibility to own the process of creating better conditions for Product Discovery.

The complexity of Product Discovery can feel overwhelming, but trying to overcome it with blueprints developed by other companies is rarely a viable solution. It’s way more important to evolve your own approach.

That's why I break down the different key phases of Product Discovery as a range of options Product Teams can choose from in this video:

While explaining how Discovery and Delivery go hand-in-hand, the most popular visualization of Dual-Track Agile also suggests a kind of linearity that is detached from the messy reality teams face every day. It is limiting to make discovery iterations fit into the existing sprint cadence. Likewise, teams should not feel obliged to transition every new discovery idea into a development sprint.

I believe this rigidity exists because of the “comfort zone” the repetitive focus on outputs in sprints provides for stakeholders and teams. As long as new ideas get pushed into the sprint backlog, the team utilization stays high, which means there’s always more (perceived) value that gets created.

Here’s how this article will help you:

The Importance of Adaptability

While individual Product Discovery phases benefit one another, there’s no need to follow a rigid, prescribed order to succeed. Depending on the context, they may not even be necessary. Working through one area doesn’t guarantee success (nor does working through all of the areas). In a sense, you have to write your own playbook. You should feel confident to go back, jump ahead, or repeat any of these phases as you gather new insights.

This has caused me to rethink how to help teams find their own path through the Product Discovery “jungle”. I’ve come to believe that there is no one path to rule them all. Instead, it’s about equipping teams with the skills, methods, and confidence to define and execute their individual approaches.

For product teams, it’s essential to stay focused on the things they can own to make real progress during Product Discovery. And one of these things is their ability to adapt.

Adaptability in Product Discovery Definition - Updated

Adaptability in Product Discovery Definition

The ability to adapt during and between Product Discovery is driven by several factors, such as your product’s nature, team composition, industry, company culture, and more.

While it’s easy to agree on the non-linearity of Product Discovery in theory, it’s harder to justify jumping and looping through activities in reality. In this case, the benefit of having alignment around the problem space is an important anchor. When a discovery/insight doesn’t propel the team “forward”, but instead requires taking a step back or simply repeating, the team needs to have a foundation to argue for that.

But that means that the idea of Adaptable Product Discovery addresses four of the most common Product Discovery antipatterns:

  1. Measuring the success of the team based on the velocity of discovery activities completed. This might help you determine the diversity of discovery methods, but will not help you understand whether those methods were a match for the challenge.
  2. Routinely turning every new idea into another version of an original stakeholder’s idea.
  3. Endless iterations without new insights. At a certain point you need to reconsider your approach.
  4. Not committing the resources/time, and doing “discovery work” in name only.

Here are five core ideas that help to combat these.

Framing Discovery Intent

To avoid aimlessly chasing opportunities, teams need a precise framing of Discovery intent. This intent can come in many shapes and forms. But they all share a common attribute: Their explicit focus on WHY a Discovery matters and WHAT results are expected to be driven.

Sending product teams on a discovery mission requires a different mindset (especially if the company has been focussing on output). What works for delivery doesn’t translate to discovery work. Teams have to unlearn some habits.

Typical ingredients for framing Discovery intent are your Product Strategy Choices, a holistic and quantitative description of how the success of your product looks like, as well as a roadmap approach that emphasizes chosen priorities over deadlines and release cycles.

Contributing Processes to Adaptable Product Discovery - Updated

Contributing Processes to Adaptable Product Discovery

But besides these three contributing processes, there’s also the act of framing intent as part of Product Discovery. While the details are for another newsletter, collaborative alignment is a crucial ingredient for setting up effective, problem-focused Discovery. It’s very dependent on the quality and nature of these adjacent processes, though.

Whereas solution-focussed Alignment tries to create clarity through details about the solution, problem-focused alignment emphasizes tangible goals and ambition levels. Whether these exist in the form of "normal" KPIs or are represented through OKRs in Product Management. And while solution-focused Alignment sets priorities based on defining specific tasks, problem-focused Alignment lists the areas of highest uncertainty.

As a first step, collaboratively agree on a fixed timebox for a discovery mission. Consider this timebox as an enabling constraint, not as a race to check off as many boxes as possible. Teams should approach solving the challenge with a “best-effort” approach and try to reduce the uncertainty of the mission as much as possible.

It’s vital that the team picks the phases to focus on and methods to use themselves. However, in order to avoid a “black box” perception of a product discovery process, it should share those decisions with the rest of the organization.

Choose Techniques and Actors wisely

Remember that solving user problems is the means, not the end. Make sure to clearly state your research intent based on overarching strategic goals and existing insights before rushing into your first interview.

Ensure that you don’t execute research measures to tick a box but gain insights that matter for your problem space. To avoid burning unnecessary matches, to whom you’re talking matters as much as how you’re talking to them.

Frequently talking to customers that don’t match your target audience for a given Discovery is like scratching a mosquito bite. It feels good at the moment and might relieve some pressure. But in the long term, it only gets worse, and you wonder why you did it in the first place.

Identifying Actors during Adaptable Product Discovery - Updated

Identifying Actors during Product Discovery through Impact Mapping

An effective way to look beyond obvious power users to focus on during research is the Adjacent Actors categorization. By asking yourself, “Who has a problem that prevents us from achieving our strategic goals?” you make sure to think beyond your usual suspects and avoid talking to randomly selected strangers.

Connect the Dots

Don’t get caught up in isolated “research activities.” Instead, focus on connecting the dots quickly and scale Discovery activities and insights to bring stakeholders and team members on board.

One crucial aspect is the idea of crafting job stories based on the insights you have gathered.

Context-driven Job Stories with Outcomes

Context-driven Job Stories with Outcomes

They allow you to synthesize and communicate the essence of your research insights. By summarizing the situation a specific group of users is in, the problem they are experiencing, the underlying motivation, and, most importantly, the behavior change they need to share to succeed.

Uncovering and understanding the problem space is challenging. But the challenges don’t stop there. The insights are often hard to connect with actual business value, making them less tangible for peers and stakeholders external to the discovery team. Instead of getting pseudo-buy-in through early feature discussions, the team must stay focused on the problem and outcome space. While you can plan the immediate next step in discovery in more detail, the overarching path often remains non-obvious until the next experiment ends.

All of this requires thorough research. But all of your research isn’t worth much if you can’t make it actionable. This is why the act of connecting the Outcomes you want to drive to the overarching business Impact is so crucial.

For example, through Impact Mapping.

Structuring Product Discovery through Impact Mapping

Structuring Product Discovery through Impact Mapping

Focus on actionable Evidence

When I received my CSPO certificate back in 2012, I was sure that I knew everything about building great digital products. I was convinced that my breakthrough success as a product manager was now inevitable. All I had to do was to make sure that my user stories contained enough detail and followed the template. I was able to recite the Agile Manifesto on demand.

I defined the success of my role mainly through the team’s output and the degree to which stakeholders were satisfied with the solution. I prioritized increasing sprint velocity and keeping deadlines over continuously improving user behavior. It’s all I cared about.

But at one point I started to question the way new ideas found their way in our backlog. There had to be a better way than copying competitors, jumping on new design trends, and waiting for the CEO’s latest “great idea”.

After following the path of being a busy Product Manager for a while, I got introduced to the idea of Product Discovery and Dual-Track Agile. I immediately fell in love with both ideas.

Unfortunately, this love story didn’t end well. I got lost in endless Product Discovery iterations and tried to follow the processes of other “famous” companies step-by-step. When I couldn’t follow their approaches exactly, I felt like I had somehow failed. Instead of exploring the problem space and deriving new solutions, we were becoming a victim of the models we picked up on Twitter and Medium.

The decision about which solutions to ultimately pursue should be based on strong, first-hand evidence. Meaning, you want to articulate how confident you are that an identified solution can drive the Outcomes (and even going beyond a rigid focus on them) you have prioritized.

But after all, Marty Cagan once said it best:

More broadly, avoid getting stuck analyzing data that is interesting but doesn’t help you advance in your innovation quest. Learning is NOT your goal. Making data-influenced decisions to move from naked idea to validated business opportunity is.

Adaptable Product Discovery is not about learning for the sake of it. But to make progress based on the insights you have.

Plan to drive Outcomes

Discovery shouldn’t stop after looking at A/B testing results. Instead, the gained insights need to inform the slicing of validated solutions. 

But you need to stay away from the common pitfall that MVPs are just a low low-quality version of all possible features included in the prototype you used to validate an idea.

Instead, an MVP is about building the most critical value proposition to further prove your product idea’s potential and product-market fit and shipping it in the best possible quality. It is not about building slimmed down or extremely compromised versions of all your features."

After all, we should use the previously identified and set Outcomes as the primary way to measure the success of a solution. And to increase our chances of creating that success, the urgency of user problems should inform our slicing of scope. But the collection of Outcomes through research and experiments should also not just happen for the sake of it. Instead, these insights should be used as valuable inputs for an eventually following OKR drafting of a product team.

Adaptable Product Discovery is not just about understanding the problem space. It’s also about the quality and effectiveness of the solution space, which makes skipping the slicing of validated solutions a familiar yet costly mistake.

Where to start with Adaptable Product Discovery

I think it’s time to challenge the idea of “correct” Product Discovery. Complex environments and ever-changing business challenges require adaptability and challenging the idea of a linear, rigid product discovery process.

It is important that teams are fully aware of which methods are appropriate for the challenges they are facing, and know how to combine them in effective ways. Companies don’t succeed because of a specific predefined Product Discovery process. They succeed because they encourage teams to find their own path and support this development with training and psychological safety.

Adaptable Product Discovery Phases and Process

Adaptable Product Discovery Phases and Process

The key is to identify the right starting point for understanding the problem space for YOUR next Product Discovery, considering your company culture and industry.

Don’t get intimidated by how to do things “right”. Focus on the measures that help you make progress in the environment YOU are in and the challenges YOU face.

In my Adaptable Product Discovery Course, I don’t just teach the techniques required to work through Product Discovery in the best possible quality. I also help you to connect the dots in a way that allows you to make progress towards meaningful goals through self-determined learning.