Discovery is my favorite part of the job. 

I love seeing a need become a valuable action. I still remember the astonished gasp from a customer when she realized the new feature solved her most time-consuming workflow problem. Or the wave of relief from a team who discovered a simpler, and less expensive, approach to solve a customer’s complex problem. And the joy from a former client who celebrated achieving their goal using a tool we helped them build? One of the highlights of my career.   

Everyone wants their work to have meaning. For me, discovery means an opportunity to learn. It means collaborating as a cross-functional team to make a meaningful impact on a customer’s experience. The work we do to build a shared understanding of the “why” behind our work pays off time and time again. It informs our decisions and brings us closer to a moment of value and delight.

Discovery is key to our success

Lab Zero has helped early-stage organizations find their product-market fit. We've helped enterprise organizations tackle their most challenging problems. We’ve helped teams engage with their customers and reach across silos to do impactful work. Our discovery process has helped us help our clients connect to customer value by finding the confluence of customer needs and business value. 

Not all organizations initially see the value of discovery. For some, discovery might not even be on their radar. Others view it as a luxury. Our clients have diverse needs, challenges, and working styles. We meet clients where they are and advocate for discovery while remaining flexible.

Being flexible can be tricky! It's incredibly challenging when the team we are joining is already working on a solution. We have tools to ensure the team accesses the information and insights needed to succeed, while not stopping forward progress. 

This article will discuss a lightweight strategy for uncovering insights behind a solution. This strategy only takes a day or two and uses Teresa Torres’s “Opportunity Solution Tree” framework to ensure we're on the right track. 

We’ll cover:

• What we hope to learn
• The questions to ask
• Who should do the asking and when

The Opportunity Solution tree

The Opportunity Solution Tree concept comes from Torres’ book “Continuous Discovery Habits.” A team engaged in Continuous Discovery includes a product manager, designer, and engineer empowered to solve a problem. The Opportunity Solution Tree maps the team's paths to moving a business goal forward. 

The Tree includes four components:

1. The Business Outcome is the business value we intend to advance with our work.
2. Opportunities are the insights we learned from talking to customers about their unmet needs, goals, and pains.
3. Solutions are the potential ways we might meet those needs.
4. Assumption Tests determine if our solutions meet the conditions for success. We test the riskiest of these assumptions to validate our solutions. If our solution passes, we can be confident enough to invest in delivery. 

 

In an ideal situation, the team builds and revises this tree as they move through discovery cycles. They end with a strong, valuable solution that advances the business outcome.

As consultants, we might approach our tree a little differently.  

 

Reversing the tree to uncover outcomes and insights

When joining a new team or organization, we often find solutions already in progress. The team has context and assumptions that we don’t yet share. There often isn’t documentation on hand to help us onboard. To get up to speed quickly, we can reverse the tree to uncover the “why” behind our new team's work. 

Our goals are to: 

1. Clarify the solution's target customer and intended benefit.
2. Understand and evaluate the source of customer insights.
3. Ensure we’re aligned on the business impact and metrics to measure success.
4. Identify critical assumptions and test them before full-scale delivery.
5. Highlight potential gaps so we can help reduce risk or strengthen a solution's impact.

We do this by asking questions. 

 

What should we ask?

We'll start by adding the in-progress solution to our tree. 

To understand what customer needs we expect the solution to address, we will ask:

What customer is this solution for? How will that customer benefit from our solution? Remember, stay curious. This conversation isn’t an interrogation. We want the team to share their thinking; we don’t need them to justify their work.   

To understand how much confidence to have in our insights, we'll ask:

Where did these customer insights come from? Did we hear that from talking to a customer? If so, could our teammate point us toward a recording or notes? Did it come from a stakeholder? A customer service conversation? What gives us confidence that this solution is valuable to customers?

From there, we ask about the business impact expected from this solution. What does success look like? How will we measure success? Who does this business impact matter to most? Is there a stakeholder who owns this? Is the team aligned on this outcome? Is the team aligned with the stakeholders?  

To build out our tree’s assumptions, we ask: what must be true for the solution to succeed? How did we arrive at those assumptions? Which assumption seems the most uncertain or scary? Before starting delivery work, how might we test that assumption with a real customer? If the team resists testing with or talking to customers, what is causing that friction? How will we know our solution passed the test? 

As we get answers, we can fill out our Opportunity Solution Tree with what we’ve learned. It is helpful to note on the tree where we see uncertainty or suspect the team is not in alignment. 

 

Who should ask the questions? 

Many teams assume that product managers should ask these questions. Everyone should feel empowered to ask questions about the "why" behind the work. The "why" impacts you, whether you are a product manager, designer, engineer, leader, or stakeholder. We all can contribute to building a shared understanding, no matter our role on the team. If two or more new people are on the team, it's worth coordinating to avoid duplicating effort. 

In a future article, we’ll discuss ways you, as an established team member, can support communicating the “why” to a new team member during their onboarding. 
 

How long does it take? 

Depending on our team's size and availability, this process may take a day or two. It’s worth asking questions to several people to gauge the team's alignment. These questions may come up casually, or we may need to book time to talk. 

 

Gaps, uncertainty, and risk

Building our tree this way allows us to highlight gaps in the team’s understanding or alignment. Our team may not have a strong understanding of the problem or alignment on the outcome. These gaps may leave the team vulnerable to the risk of wasted time and effort. How do we know when to double back and address problem areas and when to press on with guardrails in place?  

Our next article will cover a method for prioritizing and addressing these gaps.  

 

What is the “why” behind your team’s work? 

Does your team have a shared understanding of why they’re working on what they’re working on? Do they know their assumptions and have a plan to test them? If the answer is no, we can help. 

We offer resources and coaching to help you level up your team’s discovery practice.
Check out some of our past articles: 

• Product Discovery at Lab Zero
• How does Discovery Add Value?
• Bootstrapping Discovery

Need a strategy to address your team’s unique challenges? Contact us to explore how we can help your team connect with the “why” behind their work.

 

Notes

• Photo by Felix Mittermeier
• This article was originally published on Mind The Product.