When a Product Team starts a new Product Discovery mission, their primary job is to reduce uncertainty. Initial alignment and research might feel predictable and almost linear. But as soon as the first hypothesis turns out to be wrong, teams need to course correct.
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. In this article, I want to share why I believe that the individuality of your product team is the secret superpower for .
A Personal Story: Velocity-Fixation, Paint-by-Numbers Product Discovery, and a Realization
I’ve experienced rigid (and “predictable”) product discovery approaches first hand. And I’ve caused my own fair share of endless iteration without creating clarity.
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.
Example: We looked at the concept of running “”, because it was suggested by some of the stakeholders. We hoped to clearly scope an MVP and chart a path forward. Unfortunately, we didn’t have robust user insights. We weren’t clear whether the problem was worth solving, and lacked a truly cross-functional perspective. Lean Inception is a “proven” process for kicking off an “Agile Project”, and it was seen as a very progressive move internally. Alas, while the inception was “great”, we ended up in pure HIPPO-driven, waterfall mode (which ironically was the main input for the workshop right from the start).
Since then, I have worked with a diverse range of teams across industries and company sizes — both as in-house product owner/manager and as an external product coach. My perspective on what it takes to make Product Discovery effective has changed dramatically (and for the better, I believe).
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.
In my work with teams, I regularly observe teams trying to address the uncertainty inherent to product discovery with ever more detailed plans and checklists.
Once, I worked with a team where the executives demanded a “big swing” to really make a difference with the next version of the product. So the team was granted resources to explore new directions. At the same time, the impatience to see concrete results was tangible from day one. One attempt to keep this impatience in check, was to outline which specific discovery activities would happen over the next few weeks. And while this approach was helpful for scheduling user interviews and cross-functional ideation workshops in advance, it quickly became a “promise” with little room left to correct.
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.
Obviously, this depends a lot on the company culture. But it’s a change in behavior which can also be sparked by individual team members. Taking ownership for Product Discovery and its results are one of the most important steps to go from being a to being an empowered Product Team.
Shifting the Focus from Delivery towards outcome-oriented Discovery
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.
Many companies use Scrum artifacts and rituals to clarify their deliver efforts—the “what needs to be done”. And while a 2-week sprint is, in theory, supposed to be focussed on the qualitative sprint goal, the ultimate measure of success for a majority of teams is defined by delivering the “output” (aka the number of stories). In this model, a team improves when its velocity improves.
This mental model breaks down during Product Discovery. Why? From a bird’s eye view, the possible can be broken down like this:
The phases build on each other, but are not sequential/linear. 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.
Example: I was working on a JIRA integration for a b2b enterprise tool. After some thorough discovery work, some struggles started to emerge when we tried to drive adoption of the MVP. Even though we had identified the JIRA administrators as actors which are worth paying attention to, we didn’t talk to them first hand.
That really caught up with us.Even though we had a product our actual users liked (and confirmed it solved a problem), the JIRA administrators had a completely different perspective. Due to not talking to them directly, we completely missed the changes in behavior we needed to create for them. This realization made us go back to the drawing board (aka our Impact Map), to rethink the outcomes we needed to drive not only for our primary users, but also secondary users like the JIRA administrators.
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.
To reiterate the point above, this is a far cry from delivery-focused product management. The team is on a mission to reveal the changes in behavior which truly matter before it can start brainstorming solutions. Until that happens, the team must adapt its approach. You’ll need the necessary support.
Common antipatterns include:
- 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.
- Routinely turning every new idea into another version of an original stakeholder’s idea.
- Endless iterations without new insights. At a certain point you need to reconsider your approach.
- Not committing the resources/time, and doing “discovery work” in name only.
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.
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.
In most cases, this should be how the last piece of insight increased or decreased the team’s confidence to contribute to the desired impact. If it just “doesn’t feel right”, teams will have a hard time making the case for non-linearity.
I try to encourage teams to build up their own product discovery toolbox, instead of sticking to popular frameworks and processes. It’s not about “getting through” the next discovery effort. Rather, teams should endeavor to build this muscle and increase confidence for future discovery efforts. Creating a toolbox, and increasing the trust of the organization are critical steps towards teams taking ownership of their product discovery efforts.
Summary
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.
Ready to get started? Here’s a bonus to help you out.
It’s important to me that you can take something tangible away from the stories shared in this article. To help you do just that I’ve set up a for you.
The free bonuses include:
- A free 6-day Product Discovery Navigator email course to help you with staying on course during Product Discovery
- My best practices for overcoming Confirmation Bias in Product Discovery
- What I wished I knew when I ran my first Discoveries
You can .