There’s a difference between who is exposed to a situation (many people) and who experiences that situation as a meaningful problem they would like to solve (a select few). It is important to not describe a situation as self-evidently bad, but rather to reshape your framing to discuss the problem which attends. Once you start reshaping into a description of a problem, a good problem statement template nudges you towards more in-depth discussion of who is affected.
For Whom are You Solving?
When working to identify a problem to be solved, part of what we want to think about is for whom we are solving. There are usually multiple groups of people who use our products, and who face different problems or different versions of the same problem. Each group of people has a specific goal they are trying to achieve, a specific circumstance in which they are pursuing that goal, and a specific thinking style which reflects how they conceptualize and approach the goal. Each of these aspects affects the definition of what it means to solve the problem. Each of these distinct groups (combinations of people, contexts, and purpose) will experience a distinct level of impact associated with not-solving the problem and each will contribute a distinct aspect of benefit coming from having solved the problem
I saw a post recently where someone said that product managers operate within ambiguity. I don’t think that’s right. Product managers operate within an environment of uncertainty – and embracing uncertainty is critical to creating value, but product managers have a responsibility to eliminate ambiguity. We don’t want our teams to operate with a lack of clarity, we want them to operate comfortably with a lack of certainty.
Many problem statements start with complete ambiguity about who is affected by the problem to be addressed. You will struggle to solve a problem without knowing for whom you’re solving – because you have no way to understand their definition of ‘solved.’ This is the reason the problem statement template distinctly calls out “Affects…” as a field, versus relying on product people to mention who is affected when describing the problem itself.
Imagine road construction on your commute to work in the morning. For you, the problem may be that your commute was unexpectedly longer, and you risk being late for work. For the truck driver next to you the problem is safely navigating the narrowed road with their large vehicle. It is the same situation – but you experience different problems, potentially solved in different ways. Making the rerouted lanes wider would solve the truck driver’s problem without solving yours. You should not be ambiguous about the people affected by the problem you intend to solve – this insight will help you shape the definition of the problem, and avoid delivering a solution to the wrong manifestation of the problem and ultimately failing your target customers.
You want to solve for all of the customers – the commuter and the truck driver, as well as the construction workers, the city planners, dispatch operators, mapping services, civil servants, etc. You probably don’t have the resources to solve for all of the customers. Even if you did, each incremental solution is developed with an opportunity cost of not solving some other problem. Even in the unlikely event that you have the luxury to solve for everyone, and you have nothing better to do, you still need an approach for sequencing the work into incremental deliveries – and a very strong incremental delivery pattern is to do something meaningful for one group prior to another instead of something partial for all groups. Each group faces a different problem, so you need to identify for whom you will solve, and for whom you will solve first.
All of the People All of the Time
A brilliant colleague of mine, Jeff Vogelsang, once shared a version of this 2×2 matrix to help with assigning a priority level to defects.
This intuitively makes a lot of sense – the “showstopper bugs” are the ones which affect all of the people all of the time. Like the mobile app which crashes on the loading screen. Issues which are less pervasive are lower priority. When something affects only a few people, and then only infrequently, it is intuitively something we address far later than the other issues.
We bring this intuition to defining the problems we are considering solving as well. When coaching someone, I will tell them that it is fine for the first draft of the problem statement, but it is ambiguous because not all people experience the same situation in the same way. Removing ambiguity is something which happens through multiple clarifying steps of rewriting and reshaping your view of the problem. A very common challenge I see facing organizations is jumping to the solutioning aspects of product development while their understanding of the problem to be solved is still overly ambiguous.
You will not have a productive ideation session when designing solutions to an ambiguously defined problem. And here’s the catch – you won’t know you were unproductive, because you will produce a lot of solutioning ideas. You may feel productive. But all of your ideas will be valid, because each of them can be interpreted as addressing some aspect of some problem. The odds that you accidentally addressed the problem you needed to address, and not something else are low. Until you add some constraints to the search space – from “doing something” in an abstract way, to “doing something for someone distinct” you will lack the criteria for ideating to find a solution to a clearly defined problem.
The product development process, when operating with ambiguity, has no feedback mechanisms available to help you course correct. There are no signals to tell you that what you are doing is wasting time and money building something which does not matter. There is a solution – to manifest signals through evaluation of the effectiveness of what you are building at solving the problem you are trying to solve. But those signals can only be generated, those evaluations can only be interpreted, within the context of a clearly defined problem. A problem statement to address a problem for all of the people all of the time is too unfocused to establish enough clarity of purpose to support effective development. A problem statement which addresses everyone’s problem is also likely to be too large to incrementally deliver within your cadence of operations, and will need to be split into multiple independently addressable problems.
Solving for Some of the People
I was recently working with a client who has a customer base of nearly 200 million users. The product manager had a particular problem in mind and was working to formulate a problem statement. Their initial point of view was that it was not helpful to identify a subset of users for whom to explicitly solve the particular problem because the problem was being experienced by all of the users. The following example illustrates the process of focusing on a subset of users without revealing the details of the specific problem they were solving.
“The story is true…the names were changed to protect the innocent…” as the old Dragnet TV show narrator would have intoned.
The Problem of… It is hard to configure a color printer for optimal output
Affects Whom… All color printer users
The Impact of Which is… 5% of customers call tech support for help setting up their printer because of dissatisfaction with the default print quality, requiring roughly $20M USD per year in costs to staff sufficient call center capacity.
The Benefits of a Solution are… More than $10M USD savings per year in call center labor costs and a simultaneously improved setup experience for all customers.
Product managers are afflicted with the curse of knowledge – in this example, objectively knowing that configuring color printers for optimal output is hard with the current solution. Application of the problem statement template to describing the problem immediately triggers a reframing of the problem. The template helps to emphasize that while all users interact with the existing product in their experiences, only a subset of people are sufficiently negatively affected by it as to call it a problem. This gives them the first opportunity to apply a constraint to remove some ambiguity.
If 5% of customers are calling tech support, then you can assert that at least 5% of customers are having a problem with configuration. 100% of color printer users experience the current solution but only 5% of those customers reach out to tech support. This clue helps form the hypothesis that only a subset of users – somewhere between 5% and 100% consider their difficult experience to be a problem worth solving, and a subset of those users (exactly 5%) call tech support.
In the first draft above, one mistake in the problem statement is that it describes the situation (it is hard to configure), when a better problem statement would describe the problem (many customers cannot configure without calling tech support). Just like the the road construction example above – not everyone experiences the difficulty of the configuration experience as the same problem.
Rewriting this problem statement less ambiguity results in the following:
The Problem of… 5% of customers cannot configure their color printer without calling tech support.
Affects Whom… More than 5% of color printer users
The Impact of Which is… 5% of customers call tech support for help setting up their printer because of dissatisfaction with the default print quality, requiring roughly $20M USD per year in costs to staff sufficient call center capacity.
The Benefits of a Solution are… More than $10M USD savings in annual call center labor costs and a simultaneously improved setup experience for all customers.
This is clearer and more focused because it no longer is trying to improve things for all 200 million customers. But the draft above still falls short of being unambiguous. Which 5% are failing? Is it a lottery? Does the application randomly just not work? A reasonable assumption is that for the group of affected customers is somehow different from the other groups – you are clearly in the “some of the people” column in Jeff’s diagram above. The next step is to build a mental model identifying a subset of the users as being somehow distinct from the rest of the users – in goal, in identity or thinking style, or in context.
Imagine four populations of users (in this fictional example) as a mental model. Even some lightweight research could be performed to inform a sense of relative sizes of the different populations. You already know the size of one group (the 5% who call tech support)
- 75% of users successfully configure the printer without assistance, even though the experience is hard.
- 10% of users get assistance from someone else, without calling our tech support.
- 5% of users call tech support, and spend 10 minutes on average getting the printer configured.
- 10% of users never configure their printer for optimum output.
With that bit of modeling – and ideally of research (which could be as simple as a survey of people who purchased their color printer between 1 and 2 months earlier), you can now improve the problem statement further to focus on groups 2 & 3 from your model.
The Problem of… 15% of customers cannot configure their color printer without getting assistance.
Affects Whom… 15% of color printer users
The Impact of Which is… 5% of customers call tech support for help setting up their printer because of dissatisfaction with the default print quality, requiring roughly $20M USD per year in costs to staff sufficient call center capacity.
The Benefits of a Solution are… More than $10M USD savings in call center labor costs and a simultaneously improved setup experience for all customers.
Some of you, reading the above, will immediately see that this framing of the problem abandons the 10% of users who had to get assistance somewhere else. Yes, that is exactly the point, and you should be getting excited. This framing of the problem provides clarity of purpose to declare that the goal is to reduce the load on the call center. There is no “credit” with this framing for making things better for those users who needed help and found it elsewhere.
With this problem framing, an acceptable solution could be one which reduces the amount of time it takes for a tech support agent to help the customer. An also acceptable solution is one which eliminates many of the calls in the first place by making it easier to configure. Yet another acceptable solution is to provide improved call-center call routing (to more efficiently route setup-assistance calls to dedicated experts) and improved call-center training materials (to more quickly handle setup-assistance calls). Success is measured in terms of reducing the costs associated with call-center support of color printer configuration. You could solve the problem – as defined – without improving the configuration process. Technically, you’ve improved the experience which includes getting support by improving the efficiency of the support experience.
This is an intentional choice, shaping your product strategy by documenting an unambiguous problem statement. There is a cascade of clarity which results – the outputs of ideation sessions are now measured in terms of their anticipated impact on the problem as defined and not arbitrarily in terms of how they make people feel in terms of their impact on the situation originally observed. You could write a very different problem statement, where you explore the consequences of 15% of customers needing assistance, the impact of which is that for every 20 customers, 3 of them have a bad experience, and when asked, share that their experience was bad.
The research shows (and in particular I found these 2011 findings from Stan Maklan and Phil Klaus to be compelling) that process ease has a correlation of 0.69 on the CXQ (customer experience quality) measure, which then likewise extends to high correlations (over 0.9) on both loyalty and word of mouth behaviors in customers. You could develop a problem statement which clarifies that the bad experience (for at a minimum those 15% who needed help, and the subset of the 75% who eventually succeeded independently, but did not enjoy the experience) has a consequence (“the impact of which”) of degrading customer loyalty or on detrimental word-of-mouth ultimately affecting either repeat sales to existing customers, or respectively affecting market-share of prospective customers choosing a competitor’s color printer because of the reputational impact resulting from bad word of mouth.
This is a big deal. Your product strategy is shaped – are you reducing the cost consequences of providing a safety-net to catch people who are struggling (the 5% who engage the call center), or are you reducing the revenue consequences of existing customers choosing competitors for future purchases, or are you reducing the revenue consequences of reduced acquisition of future prospective customers because they anticipate better configuration experiences when purchasing a competitor’s product.
For Whom You Solve Shapes Your Choice of Problem
Your choice about which problem to solve drives your ideation about possible solutions. Your choice about which problem to solve drives the metrics you will define to measure success. Your choice about which problem to solve has emergent properties in manifesting an implicit product strategy in the absence of direction from leaders. Your choice about which problem to solve can be evaluated in its effectiveness in aligning to an explicit strategy when established by your leadership.
Your choice about which problem to solve results from your choice about the customer for whom you are solving.
One thought on “Problem Statements Solve for Someone”