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.
My company, 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:
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:
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.
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:
We do this by asking questions.
We'll start by adding the in-progress solution to our tree.
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.
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.
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.
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.
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.
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? We highly recommend asking these questions to get your team aligned and on target.
Explore more great product management content by exploring our Content A-Z
Comments
Join the community
Sign up for free to share your thoughts