Anatomy of a Problem
Out there in the world there are many different methodologies for converting market insights into products (and features) and services. Here at The Problem Manager our goal is to be simultaneously independent from and complimentary to these methodologies. For example, in software development our content and tools should be equally useful if you are using a Jobs To Be Done approach or Persona Problem Statement approach or others.
Purpose & Goals
Before defining the problem I recommend thinking about your purpose in doing so. For example, the anatomy of a cat would be described differently by Grandma versus our veterinarian, right?
- Why are we defining this Problem?
- What is/are our goal(s)?
- How many different subjects (who’s) do we need to consider for our purposes?
- How much detail is required for the What (obstacle/challenge)?
- Which aspects of impact (How) are of interest and what level of detail is needed here?
The answers to these questions will help you determine if your Problem definition is complete (done) or not. For example, if the goal of this problem statement is to support a software development team for an early concept prototype for a new product idea, then perhaps not much detail is required.
However, if the goal of this problem statement is to support a detailed consulting proposal for a $1 million project, then probably more detail is required.
Here at The Problem Manager, and maybe for you too, our purpose and goals for capturing and managing problems will relate to creating products and services (or features of products and services) to solve these problems.
Who? Whose Problem Is It?
Problems are subjective. If a tree falls in the forest and there is no one for it to land upon then there is no problem, right?
Briefly let’s revisit our definition of a Problem:
A problem is an obstacle or challenge put forward for investigation.
So our first question is: Obstacle or Challenge for whom?
Of course, the answer here could be specific and individual, such as: Jenna Jorgensen, VP of Product Management for Shiny Objects Inc., if this is for a consulting project. Or the answer could be role or category-based, such as: Product Management leaders of technology companies in North America.
Personas can be very helpful here and we will explore these in more detail in future content, but for now I recommend my friend Saeed Khan’s excellent post here -> https://swkhan.medium.com/what-would-karl-do-or-how-to-get-real-value-from-personas-part-1-8be8d65cb9bd.
In addition to our primary persona, it is also useful to ask about other Who’s as well. Who else is affected by the problem? And who benefits from the problem? Capture as much context as you can.
TO DO:
Pick a Problem your current product or project solves or
will solve.
Identify the primary who for your current product(s) or
project(s).Example: Terra and the Tumbleweed
Let’s create an example that we can carry with us through this maze of problem management.
Terra is a product manager for Shiny Objects Inc, a medium-sized B2B (business-to-business) software company based in Lebanon, Kansas. Terra has recently been promoted from Product Owner to Product Manager for Shiny’s flagship software called ShinyEnterprise.
Finally, thinks Terra, I will be able to influence the strategic direction of the product, instead of just grinding away in the feature factory.
As the new Product Manager for ShinyEnterprise, Terra wants to root the product deeply to its target audience and their problems.
But how to to do this? Terra has a problem.
What? What is the Problem?
Now that we know Who we are focusing on, the next question is What is the Problem they are facing? What is the obstacle or challenge?
The critical success factor here is to be as specific as possible and to focus solely on the problem and avoid suggesting causes or solutions.
For example: Product Management leaders of technology companies in North America….
Need to stay up-to-date on the latest advancements and innovations in Product Management but are too busy leading their organizations to find time for this.
Here we can see that the problem (obstacle, challenge) is not keeping up with latest advancements and innovations in Product Management due to their busy schedules, right?
Remember, the art here is ensure we are basing our Problem Statement on what we know and avoiding additional information which could be wrong or misleading. We are including “too busy leading their organizations to find time for this” which could be misleading and dangerous. Do we know this is true? Maybe there are other reasons why they can’t stay up-to-date. Another approach could be…
Unable to keep current with advancements and innovations in Product Management.
See the difference? Our first version suggests a root cause (insufficient time) but the second does not. Which one is correct? Only you will know. But the art here is to only state what you know to be true, nothing more and nothing less.
Our problem statements can and should evolve as we learn more about our subject(s) and their problem(s). These problem statements should be living artifacts which are updating regularly as we learn more and refine our understanding.
To Do
Pick a problem from your current Project or Product Work.
Write it down in a single sentence. Be careful not to suggest
any causes or solutions. Just the problem.Example: Terra’s Problem
So what is Terra’s problem?
Terra: My product plans and priorities are not rooted in clearly defined problems for personas.
Why? Why is this a Problem?
Why do we need to know “why” this is a problem? The short answer (we will go into much greater detail in future content) is that, like a good doctor, to be of help to our patient (persona) we need to understand not just symptoms but also root causes to determine the best cure (solution) to prescribe.
A popular and useful technique for peeling back the layers of a Problem is called “5 Why’s” or “Popping the Why Stack”. We will cover this in detail in future content, but it is important to cover briefly here.
Whether you get your initial problem description from Customers, Sales, Marketing, industry analysts, or even direct observation it is unlikely that you will have a full appreciation of the problem without digging deeper.
The 5 Why’s is a simple but effective way to do this. If you have ever been around a 2 to 5 year old you will notice children use this technique intuitively often to the exasperation of the adults.
Of course, it doesn’t have to be exactly 5 Why’s. Maybe 3 is enough for your needs, maybe 7 are required. Our goal here is to get as much context about the problem as we can.
There is both a science (method) and art (technique) to this and it takes some practice to get it as right as possible.
There are many other techniques as well which we will explore in future content.
To Do
Choose a Problem from your current Project or Product work.
Complete a 5 Why's analysis on it.If you haven’t used this technique before then it may feel awkward and frustrating at first. Be patient. Practice. Practice. Practice.
5 Why’s for Terra and the Tumbleweed
“My product plans and priorities are not rooted in clearly defined problems for personas.” — Terra
- Why 1: Because product priorities are usually determined by balancing specific feature demands of the Sales and Engineering organizations.
- Why: 2: Because Product Management never had the skills to define product priorities from the perspective of Personas and Problems
- Why 3: Because they lacked training on this Problem-based approach.
- Why 4: Because they lacked awareness of this approach.
- Why 5: Because nobody told them that before they can do Product Management they must do Problem Management
We are keeping it simple at this point in our introduction, but in the real world it would not be uncommon for a problem to have many why’s or causes. So multiple “why stacks” might be needed.
Where & When?
As we continue to build out our full context for the problem, two next logical questions are Where and When does the problem occur? Does the problem only occur at month-end, on the drive to and from work, in the shower, annually two weeks before a shareholder meeting?
Why do we care? Context is king. Let’s say the problem is “need to stay properly hydrated while cycling”. What images and possible solutions are coming to mind? Now, let’s add some where and when. Need to stay hydrated while cycling across the desert at high noon. Do the images and possible solutions change? Absolutely. Context.
Terra and the Tumbleweed
“My product plans and priorities are not rooted in clearly defined problems for personas.” — Terra
No important When or Where considerations jump out to me regarding Terra’s problem, but this could change as we dive deeper. For example, we may learn that there are biweekly, monthly, quarterly and annual cycles to Product Management at Shiny Objects Inc.
We might also learn that there are specific times and places where Persona and Problem information is needed at Shiny Objects Inc.
But let’s move on for now. We will circle back to this in future content.
How? How is the problem experienced?
How is the person(a) impacted by the problem? What quantitative and qualitative impacts can you capture? Quantitative impacts commonly involve time and money. Qualitative impacts can involve harder-to-measure things like reputation, relationships, self esteem, and happiness.
Why do we care? Context. Let’s revisit our need to stay hydrated while cycling.
The impact of running out of water is different when cycling across the desert is much different from when cycling around town. Context. Let’s try to list some impacts for Terra.
Impacts of Terra’s Problem
“My product plans and priorities are not rooted in clearly defined problems for personas.” — Terra
- Impact 1: Financial risk that ShinyEnterprise will fail in the marketplace because it does not address the needs of customers and users effectively
- Impact 2: Reputation risk for both Terra and the Product Management team that they are not managing the product properly
- Impact 3: Reputation risk for Shiny Objects Inc that their flagship product is a disappointment in the marketplace
- Impact 4: Time-to-market risk as product planning takes longer and is less focused without being anchored in Personas and Problems
Ideally, as with everything we do, we want to be as specific as possible so we should add dollar figures or time estimates (days, weeks, months) and other quantification to our impacts where possible.
This will help us with problem prioritization in the future as we can compare various problems we have captured and determine which ones are the biggest pain points for our target persona. More on that in future content.
To Do
Pick a problem from your current project or product work.
List out as many impacts as you can for the problem/persona.
Make sure if they are quantifiable that you include your best
guess at numbers.Summary: Anatomy of a Problem
For our purposes as either consultants or Product Managers, Product Owners or Business Analysts working for solution providers we are interested in problems so they can help us create solutions that will be impactful and successful.
This starts with asking Who or Whom (persona) is experiencing the problem.
Next we ask What is the problem they are experiencing.
This is followed by Why are they experiencing this problem. Peel back the layers of the onion. Move from symptoms to root cause if possible.
Where and when do they experience this problem? Is it periodic? Random? Location specific?
How does this problem impact them (the persona)? Time, Money, Reputation.
Anatomy of a Problem
- Who?
- What?
- Why?
- When?
- Where?
- How?
That’s a lot of ground we just covered. If you haven’t yet had the chance to do the To Do’s place make time for them before we get to the next piece.
But what about the Tumbleweed?
Ah yes, Terra and the Tumbleweed.
Here at the Problem Manager we love the analogy of a good Persona and Problem statement system being like a healthy root system for a tree. The stronger the root system the stronger the tree. We are looking for symmetry.
Terra’s product, ShinyEnterprise, is more like a Tumbleweed because it has no root system of Personas and Problems to anchor it in place. So instead, it literally just goes where the wind blows it. The same thing can happen to Projects or Products if they are not anchored in a rich set of Personas and Problems.
So ShinyEnterprise is a Tumbleweed right now. Let’s try to help it grow some roots going forward.
Before managing Projects or Products, first manage problems
