After we know which problems to address, it’s time to think about solutions.
As a small team, Product Managers, UX, and Engineering explore feasible ways to solve the problems selected during the Problem Definition phase.
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
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.
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.
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
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?
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:
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.