Start with the problem: Taking your product idea from ambiguity to clarity | Rangle.io

We’ve all had ideas for a new game-changing product. Maybe it was a “shower thought”. Maybe you had an “aha” moment while struggling for the 15th time to complete a routine task. Or recent market research completed by your team showed a promising new market to exploit. Regardless of the inspiration, you were probably very excited to build out and launch this new product right?

But before investing all your time and energy (and money) into it, how do you know if enough people face the same problem you want to solve? Will they all seek a solution to solve it? How would your idea solve it better than what’s already out there?

It’s why we feel this first phase of the product lifecycle was so aptly named as “Problem-Solution Fit” by Ash Maurya, author of Running Lean and Scaling Lean and creator of the Lean Canvas. The name zeroes in on the most critical goal of this phase — that just because you have a new solution idea does not mean it will actually solve a real need in a meaningful way. There are also so many other significant unknowns at this phase, making it the most ambiguous phase in the product’s lifecycle.

How do you know if your product resides in Problem-Solution Fit?

It should be of no surprise then that the Problem-Solution Fit phase is typically defined by product discovery activities, including ideation, research, and validation. Organizations are seeking to solve problems or exploit new opportunities in ways that do not yet exist in the market, or are currently being poorly addressed by existing solutions. Given the many unknowns and assumptions during the phase, the main goal of most organizations is to prove out the key assumptions of their new product ideas, in a way that reduces the three most common risk areas of product development:

• Desirability: Will customers want it and want to use it?
• Feasibility: Can we build it?
• Viability: Does it make sense for the business to build?

The sweet spot in the middle of this Venn diagram is where great products live. But getting to that spot means addressing the key assumptions and unknowns of each risk area — desirability usually being the most vital area to start with — and all three risk areas are simply umbrella categories with many more underlying considerations. And the journey to get there also extends well beyond just this phase. It’s why product teams often use lean tools, like canvases and visual thought mappings, to quickly identify and plan how they will address their key desirability, feasibility, and viability risks. This approach holds true regardless of whether you’re a bootstrapped startup or an enterprise focused on exploring new product ideas and ventures.

As Ash Maurya puts it: “[the] business model is ‘the product’.” This deceptively simple statement sums up what defining product strategy during this phase ultimately focuses on — defining a focused-but-adaptable plan to work through the key assumptions of all the aspects that build and support a nascent product. These include knowing if the problem is worth solving in a way that customers are willing to exchange value for it, if key technical unknowns are potentially solvable, if the economics are favourable when major expenses are considered, etc. These are all elements of a typical business model, extending beyond what most will think of when they hear the word “product”.

If you haven’t read our previous piece on why product strategy is critical throughout the product lifecycle, we’d recommend giving that a read as well to understand how the primary objectives of product strategy change as the product evolves.

Let’s take a deeper look at the Problem-Solution Fit phase:

The primary objectives of product strategy

1. Understand the internal “Why”: Align with broader company strategy and stakeholders, including being explicit about the motive and triggers behind the product idea, and how it fits the existing product ecosystem (if the new product development is within an established company)
2. Understand the external “Why”: Ensure that the product idea fulfils a pressing and unmet customer need
3. How the new product explicitly solves for customer needs and generate commercial opportunities
4. What should be prototyped to address the riskiest technical and business hypotheses

Product strategy during this phase of the product lifecycle seeks to achieve four primary objectives:

What do you need to look out for?

In order to successfully implement product strategy at the beginning of the product lifecycle, there must be at least one executive who will champion the design and implementation of the strategy, and a core dedicated product team that can move in tandem through the evolving context and learnings gained from the discovery process.

We’ve had the opportunity to work with many startups at this phase and learned that there are common patterns and anti-patterns that you should look out for. It’s critical to know if your product teams are moving in the right direction when capturing and implementing product strategy during Problem-Solution Fit.

Below are some of our key lessons learned from past projects:

• Stakeholders demonstrate high engagement and/or involvement in research activities, ideation and strategy workshops, experiment design and execution
• The product team does not routinely get stuck in debating opinions and options, instead demonstrating a bias to action (such as structuring opinions as assumptions to test, making informed leaps of faith if research efforts are constricted, etc.)
• The product team remains cross-functional throughout the phase, resisting the temptations of falling into role-based silos

Patterns

• Oversized teams that lose the agility to prioritize quick and meaningful learnings over all other activities (“too many cooks in the kitchen”)
• Stakeholders demonstrate a lack of patience to test hypotheses, often taking the form of pushing the product team to skip prototyping and jump straight to building
• Experiments are overtly designed to confirm, rather than disprove, assumptions
• Lack of alignment among team members and stakeholders on how to measure successful outcomes
• Lack of focus or clarity on the key assumptions to test, commonly materializing as symptoms like pursuing a broad value proposition (i.e. “be everything to everyone”) or using tools and frameworks that are are overly comprehensive

Anti-Patterns

• Oversized teams that lose the agility to prioritize quick and meaningful learnings over all other activities (“too many cooks in the kitchen”)
• Stakeholders demonstrate a lack of patience to test hypotheses, often taking the form of pushing the product team to skip prototyping and jump straight to building
• Experiments are overtly designed to confirm, rather than disprove, assumptions
• Lack of alignment among team members and stakeholders on how to measure successful outcomes
• Lack of focus or clarity on the key assumptions to test, commonly materializing as symptoms like pursuing a broad value proposition (i.e. “be everything to everyone”) or using tools and frameworks that are are overly comprehensive

How do you go about defining product strategy in this phase?

There are many tools and frameworks product teams can use to define product strategy during this phase. Here are a few we’ve found successful when defining product strategy with our clients during Problem-Solution Fit.

Opportunity-Solution Tree

The Opportunity-Solution Tree, popularized by product discovery coach Teresa Torres, is a product discovery planning tool that visualizes how the discovery work is in service to a desired outcome. It makes explicit the assumptions stakeholders have on the opportunities related to the desired outcome, the potential solutions to address these opportunities, and the experiments needed to prove out the value of the potential solutions.

It’s also incredibly flexible, allowing teams to add additional layers specific to their context, such as showing how a broad opportunity space is made up of narrower and more addressable opportunities, or bridging opportunities to the desired outcome through a layer of specific measures of success.

The tool’s primary strength is its hierarchical approach to visually organizing opportunities and experiment — it allows stakeholders to logically break down large opportunity spaces into specific opportunities. This in turn allows stakeholders to directly compare and contrast solution ideas, instead of debating conditional opinions. It can also be leveraged to encourage brainstorming of experiments for each potential solution.

• Stakeholders are struggling to organize their thoughts and/or brainstorm on how achieve a desired outcome, or
• Stakeholders show patterns of endlessly debating multiple options on potential opportunities or solutions, or
• The team has a habit of running new experiments on a whim, or
• Experimentation is not a cultural norm in the existing product discovery process

It’s best used when:

• It requires a clear understanding of and alignment on a primary desired outcome
• It does not detail how to prioritize different opportunities
• Team members who don’t conceptualize using hierarchical thinking may find it too restrictive or limiting to their process

However, there are some key things that teams should be aware of:

Teams will get the most out of the tool when they’ve already completed organization goal-setting activities, and conducted market research and ideally user research as well. After completing workshops to build out the Opportunity-Solution Tree, teams should organize and prioritize the brainstormed opportunities and/or experiments into backlogs that they can then work on pursuing. Any key assumptions identified in the tree that the team is unsure of how to handle should be plotted onto an Assumption Map, so that the team can identify the next steps needed to address those assumptions.

If you’re interested in using this tool with your team, download our one-pager to get started.

Assumption Map

The Assumption Map is a tool that allows product teams to discuss and align on the most important and the riskiest assumptions. By plotting the list of key assumptions the team has generated during previous ideation workshops (such as working through a Lean Canvas) onto a simple 2x2 matrix, they quickly understand the next steps required to address these assumptions.

The tool’s primary strength is its simplicity — the simple matrix forces teams to collectively assess the key assumptions based on what is known today. This reduces debates based on opinions because the existence of multiple opinions without significant supporting research indicates that the assumption is not well proven. Rather the tool provides teams the space to speak openly about their concerns about key assumptions. Its simplicity is also well-suited to the early lifecycle phase, when making deep investments in a specific direction is not yet worthwhile, and when limited resources need to be laser-focused on experimenting on what matters most.

• The product team is overwhelmed by a long list of key assumptions or unsure of what to prioritize for next steps, or
• The team is struggling to differentiate which assumptions matter the most and truly need experimentation

It’s best used when:

• The team must first align on a lean prioritization framework before mapping
• Risk-averse stakeholders may view the map as lacking enough rigor
• It provides general guidance on the next steps but not the specific methods or techniques to address the assumptions — for example, the “Validate” quadrant guides team to design evaluative experiments for the assumptions but doesn’t tell the team if an assumption would be better addressed with a smoke test, a usability test, a Wizard of Oz experiment, etc.

However, teams should be aware of a few things before using the tool:

Teams will get the most out of the tool when they have already completed an initial pass of an opportunity identification-focused canvas (e.g. Lean Canvas, Customer Journey Map, Market Opportunity Navigator, etc.), and conducted initial user and market research. Once all the key assumptions from the canvas are plotted on the map, the team should transfer them into the initial experiment backlog and initial product backlog, design appropriate experiments, and continue market and user research as needed.

If you’re interested in using this tool with your team, download our one-pager to get started.

In the next piece of our product strategy series, we’ll delve into the fourth phase of the product lifecycle: Product Maturity. This coveted phase requires a very different product strategy because the product’s scope is at its broadest point and has likely grown to a size where multiple product teams must work in concert to support it. Stay tuned for more on what product strategy seeks to achieve in this phase that all organizations hope that their products will reach.

Originally published at https://rangle.io on April 6, 2021.