phase 1
define the problem
The goal of the initial phase is to clearly define the problem and create the necessary common language + understanding to gain alignment. In this phase,, participants learn, explore, and question the problem space before crafting 1 or 2 single problem statements.
Outputs + Deliverables:
Current State + Market Analysis
User Interviews + Insights
Defining + Framing the Problem
To set the foundation for successful outcomes, you will have pre-defined the problem area, key presentations, and homework for participants. With this foundation, you will review user insights and Interviews as needed to fill in any larger holes in the problem space necessary to reduce risk and sharpen your solution. I won’t go into detail about user interviews here; however, I will recommend Dovetails’ guidance as a great resource for quick and dirty user research that has a big impact.
Definitioning:
To frame problems well, we likely need to define terms and metrics. This step is crucial for alignment across the participants. Given they are coming from different departments in the organization, they may have a different perspective or definition of a commonly used term, like ‘quality.’
In the deck, you will find an activity focused on defining terms. Please note that you may have stakeholders and participants who disagree on definitions. This is OK as long as we agree to disagree, ensuring the psychological safety of the group.
I break out definitions by the meaning, assumptions, and hypotheses we have around these definitions. In my humble opinion, language is fluid and ever-evolving in organizations. The best way to get on the same page is to call out the similarities and differences in our definitions. I like to do this by placing a confidence level on each definition. When a term feels extremely important, we also outline the risk of defining the term wrong, allowing us to document our rationale and communicate most effectively.
Problem Framing
The biggest mistake I see in workshops is not having a well-defined problem. Without a well-defined problem, you’ll spend most of the Spike crafting and defining the bounds of the problem space and not generating solution ideas.
I recommend using a proven framework to support the teams in pre-defining the problem space. You can even have multiple problem statements. The more statements, the more time is necessary.
To prioritize the problems, consider what decisions need to be made. The more important decision space will be front-loaded in the Spike. Make tradeoffs wisely.
I’m a big fan of Jobs To Be Done (JTBD )by Anthony Ulwick, which describes the problem to be solved in a human-centered format. I also like defining the bounds of the problem with Critical User Journeys by Google. However, there are many different frameworks you can use. ProductPlan has an excellent guide for choosing the right problem-framing. Ensure that the problem-framing approach works well with your team's planning process and agile practice.
For this kit, we will be using the JTBD framework:
When…
I want/need…
In order to…
So that…
The most important aspect here is defining the problem well, which means you have outlined the bounds of the problem that a specific user/customer/human is experiencing with an idea of the expected value created when the problem is solved. You have to know SOME parts of the problem and solution before jumping into this Spike. Specifically, you will need to have:
Known business mission + vision
Known business model
Known Users groups
Known intentions or the value they are seeking
Known technically constraints
Known resources for solving the problem
If you don’t have these outlined, you will already know that your team is not ready for the PSS and will need to define their problem space before the Spike.