Solution Discovery

After we know which problems to address, it’s 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 Maps 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 product team involved (Product Managers, UX Research, UX Design, and Engineering) has sketched several potential solutions.

  • The involved product team has a shared understanding of every potential solution, for example, by telling the same story about the user journey.

  • Every candidate solution ensures that the intended customer value is delivered.

  • While the design is not yet final, the UX team does not see usability risks.

  • While the implementation is not yet final, 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, this has already happened, but this is the latest stage at which it should happen. Otherwise, you risk alignment and will likely encounter Chinese Whispers due to a lack of shared understanding.

  • Ensure that any solution idea addresses the selected problem. Double-checking the Value Proposition created during the Problem Definition phase is also a good idea.

  • Make the underlying assumptions of solutions explicit. Maybe it relies on a new technology 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, Sales, Consulting, or 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?

Observe the Context of Customers
Observe the Context of Customers

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, the Product Manager, and a BI Analyst made a series of solution discoveries:

  • They found a co-creation customer who agreed to offer one of their vehicles, their selected transport area, and one driver so they could run tests and collect data. After a full day of testing, the team went back to analyze data to find 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 in which wiggle 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. However, the accuracy was barely 50%, which, in this context, was unhelpful for customers. The team decided to explore another approach.

  • 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.