Solution Discovery

After we are sure about which problems to address, it’s now time to think about solutions.

Solution Discovery Phase
Solution Discovery Phase

Key Objectives / Key Questions

As a small team, Product Managers, UX, and Engineering explore feasible ways to solve the problems selected during the Problem Definition phase.

Key Activities

  • If not done already, onboard the Engineering team to get them involved
  • Ideate, e.g. during whiteboarding sessions or with other creative tools to develop several diverse ideas
  • Drill deeper into the User Journey Map and JTBD to see where to focus on for improvements
  • Formulate User Stories and align them in User Story Maps to see all related activities in a concise picture
  • Find analogies, either in other parts of the product or in other products where users might solve similar problems
  • Run Discovery Sprints to generate creative ideas

Exit Criteria

  • The involved product team (Product Managers, UX Research, UX Design, and Engineering) have sketched a number of potential solutions.
  • The involved product team has a shared understanding of every potential solution, for example by way of telling the same story about the user journey.
  • Every candidate solution ensures that the intended customer value is delivered.
  • While not yet final about the design, the UX team does not see usability risks.
  • While not yet final about the implementation, the Engineering team does not see feasibility risks.

Involved Team Members

  • Product Managers are in the lead and accountable.
  • UX Design helps to generate sketches and build prototypes.
  • The engineering team lead collaborates closely with Product Management and UX on every finding.
  • The Engineering team chips in their ideas during refinements.

Tools and Techniques

  • Creative techniques, such as Crazy 8 or Fat Marker Sketches to generate diverse ideas
  • User Stories and User Story Maps to describe the intended behavior of solutions in a step-by-step manner
  • Wireframing and prototyping to build tangible assets that can be assessed and tested by users
  • Continue working with Opportunity Solution Trees or Impact Mapping to keep all insights and learnings inside a uniform and consistent framework

Things to Watch out for

  • Involve the Engineering team. Ideally, that happened before already but this is the latest stage this should happen. Otherwise, you risk alignment and will very likely run into Chinese Whispers due to a lack of shared understanding.
  • Ensure that any solution idea is addressing the selected problem. Better double-check the Value Proposition created during the Problem Definition phase.
  • Make the underlying assumptions of solutions explicit. Maybe it relies on a new technology that the Engineering team needs to learn? Maybe it requires a new tech stack that implies a change in operations? Maybe it requires some 3rd party component which the Legal team needs to check? Whatever it is, make it explicit for later decision-making.
  • Have open ears but avoid having solutions prescribed to you, whether by customers, by Sales, by Consulting, or by whomever. It’s the responsibility of the product team to come up with solutions.
  • Keep an eye on the target users. Would the solutions really work for them? Did you consider their context, circumstances, and skills?
Some Users are Hard to Reach

Example

A B2B fleet management software is exploring a solution where the software could indicate whether a vehicle is driving with load or without, in order for customers to optimize transport routes. The Engineering representative, here the team lead, Product Manager, and a BI Analyst did a series of solution discovery:

  • Found a co-creation customer, who agreed to offer one of their vehicles, their selected transport area, and one driver for them to run tests and collect data. After a full day of testing, the team went back to analyze data, aimed at finding a data pattern that could clearly indicate that the vehicle is carrying any load. It wasn’t successful. The team decided to work on data handling.
  • The team sat together and discussed a data model, where wriggle rooms and principles are determined to “clean up the noise” in the data. The team rolled in previously collected road data and was able to draw rough conclusions. The accuracy was barely 50%, which in this context was unhelpful for customers. The team decided to explore another way.
  • The Product Manager learned that some vehicles have OEM built-in readings that indicate the carrying load. The team decided to find such vehicles and benchmark the data model toward the OEM reading. This time, the team found a promising direction to explore a solid solution.
Previous Chapter
Chapter 13:
Problem Definition
Chapter 15:
Solution Validation
Next Chapter

Table of Contents

Part I: Introduction
Chapter 1:
Preface
Chapter 2:
The Four Key Risks
Chapter 3:
Focus on B2B
Chapter 4:
StartUp vs. ScaleUp
Part II: From Vision to Roadmap
Chapter 5:
Purpose & Vision
Chapter 6:
From Vision to Product Mission
Chapter 7:
From Mission to Product Strategy
Chapter 8:
From Strategy to Product Roadmap
Chapter 9:
From Roadmap to Product Backlog
Part III: The PM Process
Chapter 10:
Process Overview
Chapter 11:
Idea Collection
Chapter 12:
Problem Discovery
Chapter 13:
Problem Definition
Chapter 14:
Solution Discovery
Chapter 15:
Solution Validation
Chapter 16:
Delivery
Chapter 17:
Distribution
Chapter 18:
Optimization
Part IV: Life as a Product Manager
Chapter 19:
Archetypes of Product Managers
Chapter 20:
Traits of a Great Product Manager
Chapter 21:
Competency Assessment
Chapter 22:
Transitioning into Product Management
Chapter 23:
Business Acumen for Product Managers
Chapter 24:
Communication as a Product Manager
Chapter 25:
Implementing Customer Discovery – A Case Study
Part V: Product Leadership
Chapter 26:
From Individual Contributor to Product Leader
Chapter 27:
Onboarding New Product Managers