In my previous article, I shared an improved template for writing problem statements. Knowing a good structure is necessary, but you also need to avoid filling the good template with bad content.
Don’t Describe a Situation
When faced with an empty problem statement template, universally, the first question is “what is the problem we want to solve?” The answer is consistently to describe that which is most apparent, that which is most immediate, and that which is most easily understood.
Unfortunately, these characteristics drive people towards describing a situation, and not the underlying problem. There are two patterns I see with product managers I work with – describing problem manifestations, and falling victim to the curse of knowledge.
Problem Manifestations
Problem manifestations are the last link on a chain of causality. The toddler’s question “why?” is the tool we use to work through things. This makes sense, as the most immediate information is what we share with toddlers.
- “You need to put your left shoe on your left foot, not your right.”
- “Why?”
- “Because each shoe is made to perfectly fit each foot – right for right, and left for left.”
- “Why?”
- “Because having shoes backwards may cause you to lose your balance, fall, and get hurt while playing.”
What is immediate is that the shoes are on the wrong foot, so the conversation starts there. The root of this chain is that there is an unaddressed risk of getting hurt. You could solve it by swapping shoes to the correct foot, or you could solve it by removing shoes entirely.
The challenge, in pulling yourself up this chain of causality is knowing when to stop. Each new link is more abstract and less immediately actionable. I was poking at this issue back in 2008, to encourage people to abstract their problems correctly I provided a few examples, of “correctly” but not really good guidance to help people find the correct level of abstraction.
As a product manager, you can see problem manifestations – at too low a level of abstraction, basically everywhere you look. How might the above conversation unfold for a product manager:
- “People need to be able to complete a purchase transaction with fewer clicks.”
- “Why?”
- “Because too many people are abandoning transactions after starting them.”
- “Why?”
- “Because there are so many configuration decisions to make customers get confused and purchase elsewhere.”
The problem has manifested as “too many clicks” when the real underlying issue is that the purchase flow is confusing for customers. The extra clicks might have been added to allow for customized ordering of a product which can support a breadth of uses. It isn’t obvious to many people that too much of a good thing is in fact a bad thing.
The solution as it exists has too much flexibility for the target customers. The manifestation – “too many clicks” is something you can identify through a heuristic analysis, but genuine research is required to identify what the actual problem is. Too many clicks is the manifestation of the problem of requiring too many decisions. You could solve the underlying problem either by removing choices, redesigning the flow to short-circuit into fewer choices for any given person, or even providing explanations and default selections.
When the problem is framed in terms of the number of clicks, then any solution which reduces the number of clicks could be considered acceptable. Putting all the choices on a single screen (eliminating “next page” clicks) without changing anything would reduce the number of clicks, while doing nothing to address confusion.
Don’t Go Too Far
You can keep walking the links of the chain until you get so abstract that you are no longer providing clarity of purpose. When you get too abstract, your problem statement is not actionable – it may even become crippling to your team, because they are rightly concerned that what and how they choose to address the problem is completely unaligned with the product strategy.
Take the example above – “customers get confused” is a little bit too abstract, “customers get confused because there are too many configuration choices” feels just right.
“Customers purchase elsewhere” is (hopefully) obviously too abstract. This is a real problem, but it could be caused by any number of issues – website too slow or buggy, prices too high, confusing UI, not the right product for the buyer, etc. The list is effectively endless.
I’ve found the act of filling in all four fields of the problem statement template to be helpful in calibrating the proper level of abstraction.
The problem of… customers becoming confused by excess configuration choices
Affects… general purpose customers, first-time customers
The impact of which is… 1/4 of the 80% of customers who abandon the configuration and purchase flow abandon due to confusion (per research)
The benefits of a solution are…25% fewer customers abandoning, thereby more than doubling revenue (because 45% complete a purchase vs. 20% today)
Trying to write the problem statement at a higher level of abstraction is difficult – the template (and any good template) acts to autocorrect your thinking.
The problem of… too many customers purchasing elsewhere
Affects… all prospective customers?
The impact of which is… our market share is lower than we believe it should be, given the quality of our product
The benefits of a solution are… we gain some amount of market share
The inability to crisply define any of the other fields – who is affected, how bad it is, and how much better it would be if the problem is addressed – is your signal that you’ve gone too far. When your problem statement is no longer actionable, you’ve gone too far.
As a communication tool, you also have to calibrate your writing for your audience. If you have a team with deep expertise in user experience and complex-product configuration and purchase flows, you will have to provide less clarity and specificity. It may be enough to indicate that the abandonment rates are higher than the industry norm, and allow the team to develop hypotheses about why.
If you have a team who is new to customer-facing interface design or ecommerce, they won’t know how to begin. You may be able to clarify that the issue is abandonment due to confusion. You may need to provide design-flows and decision-tree models which guide the development team towards implementing an improved choice-architecture. Or you may be able to provide only statistics about the user populations and allow the team to develop their own interaction models.
On the plus side, as the same team works together in the same domain over time they develop this expertise and communication requires less and less clarification to create clarity.
Go Far Enough
The template also provides guidance to tell you when you haven’t gone far enough – when you are describing a problem manifestation and not a problem. The phrase I use when teaching this is to find a level of abstraction which is both actionable and meaningful.
You may be familiar with Bolton’s model of reflection – “What? So What? Now What?” The first two questions are useful for discovering you’ve not gone far enough.
“What? So What?” starts with a situation and asks why we care. “Why does that matter?” is the matured version of the toddler’s query. Anyone who’s explained something they know in detail to someone who does not is familiar with this. The best communicators walk this chain in advance.
I once worked with someone who painted miniatures as a hobby.
- Someone who paints miniature figurines may be excited because the new orange color includes titanium.
- Why does that matter?
- Because the color will pop more strikingly on the figurine.
- Why does that matter?
- Because we want to give the impression of something glowing, generating light when it is not.
- Why does that matter?
- Because we are building a diorama of a battle scene and we want to evoke emotion.
If you were to describe the problem as “the orange paint lacks titanium” you are not going far enough, but “the diorama fails to evoke emotion” puts a fine point on the problem to be solved. As a good communicator, my colleague would say “I’m excited because the new paint will allow me to evoke more emotion with the diorama.” The problem they were solving was evoking emotion, not owning paint with titanium in it.
This helps to navigate up from the obvious, but low-level issues to the reasons why they are issues.
The Curse of Knowledge
As product managers, when we research, explore, and synthesize our understanding of the situation and the opportunities for our product, we are developing insights and gaining knowledge. Which is a blessing for us, but can curse our teams if we aren’t mindful when developing problem statements.
We see situations which for us appear to be self-evidently wrong or bad. That appearance, however, is in the context of everything else we already know. Set aside for a moment the implicit problem that “everything else we already know” is really a pile of assumptions potentially worthy of testing. That’s another topic for another series of articles. This curse is not the arrogance of “knowing” things, but rather of the (temporarily) uneven distribution of knowledge
The curse of knowledge springs into being when you assume whoever you’re working with knows everything you know – but they don’t. We write problem statements not only for ourselves, but for the people shaping a product’s strategy and we write problem statements for the people executing to deliver on the product strategy. None of whom share our perspective or our specific set of knowledge.
Shaping the Product Strategy
People shaping product strategy have responsibilities which require them to consider a domain much broader than ours, but at less depth than we consider. Their perspective is different, and we should not require them to know that something is self-evidently wrong.
One of the leadership responsibilities is to prioritize investment – explicitly making choices to place one bet at the expense of not placing another bet. Choosing to solve one problem, instead of solving a different one. When presenting situations, you are not framing the problem in a way which informs a good decision process. The quality of your decision will be bad as a result.
You need to walk up that ladder of reflective “Why does that matter?” questions to elevate the conversation to one you are both capable of having. If you’re responsible for the product strategy, you want to walk the same ladder until (a) your problems are both meaningful and actionable, and (b) they are all at similar levels. The similarity of level is what allows you to reasonably shape the product strategy and make prioritization decisions.
Executing the Product Strategy
People executing on a product strategy have responsibilities which require them to consider their work with greater depth than we can, even if in a narrower field of view than ours. Their perspective is also different, and we should expect them to address the situation we identify.
When we stop climbing the ladder of abstraction at too low of a rung, we run the risk of being order-givers, reinforcing the patterns of a feature factory – an output-oriented system. When we go too far, we stop on a rung the team cannot reach because they don’t have something clear upon which they can act.
Imagine a mechanic tells you “Your car air conditioner is low on refrigerant.” This is the situation, and to someone familiar with air conditioners this is self-evidently bad. Refrigeration systems are closed loops – which means if the levels are low, there must be a leak. Which must be fixed before the system can be recharged. The situation is “low on refrigerant” the underlying problem is “there’s a leak.”
When a mechanic tells another mechanic there’s an air conditioner which is low on refrigerant, the other mechanic has clarity. They know there’s a leak to be fixed as well as the need to recharge the AC with refrigerant.
The mechanic needs to practice the reflective exercise to communicate the need to fix the leak. If not, a technician in the shop may only add refrigerant, which appears fine when the owner drives away, only to get bad again, because the leak was never fixed. The problem was not solved, but no one knew it at the time.
Properly framing the problem is necessary not only to communicate effectively, but to empower and align teams towards purpose without dictating the specific necessary tasks.
Framing the Right Problems
There are two patterns of thought you need to practice to assure you are creating good problem statements. You need to align on a ‘scale’ of impact to make sure you target problems which are both actionable and meaningful. You also need to assure you are describing the actual problems, and not merely problem manifestations or situations.
