Problem Statement Impact and Assumptions

Quantifying the impact of your problems puts them in perspective. It also exposes the assumptions you’re making, creating a virtuous cycle helping you to improve your framing of the problems, and making it possible to prioritize among them.

When you first start to describe a problem, you may skip the notion of quantifying entirely, and instead describe an abstract scenario like “repeat customers abandon the new product registration process.” This is the not nearly enough, and most teams will catch it quickly – incorporating the magnitude of the situation, either in absolute or relative terms.

The Problem of… 20% of repeat customers abandon the new product registration process
The Problem of… 200,000 repeat customers abandoned the new product registration process last year

Using relative terms is helpful, as you get a better informed intuition about the situation. When considering 200,000 customers abandoning the process, is that 1% of 20M? or 80% of 250K? Knowing that 20% of people – at whatever scale – are abandoning is a useful hint at significance. However, even adding some numbers to describe the situation is not enough. When shaping what your product will be, you are making a collection of investment decisions – prioritizing some work ahead of other work, discarding some work. Your investment decisions should be framed in terms of which problems you choose to solve. When you are describing situations, you are comparing apples and oranges. You need a lingua franca, a common language or perspective to use when making those decisions. You use the impact section of the problem statement to do that, without losing the character of the problem.

Describing the impact of the problem is where you shift from describing the situation, to assessing the importance of the situation. It is important to identify problems, not their manifestations. The situation – customers abandoning a registration process – is just that, a situation. With the curse of knowledge, you know this is bad because you know why it is bad. For you, this is self-evidently a bad thing. If you’re like me and most of the people I’ve coached, you will describe the situation and move on to the next field – yes, it is bad, but how widespread is it?

The Problem of… 20% of repeat customers abandon the new product registration process
Affects Whom… 200,000 existing customers making additional purchases each year

OK, now you’ve captured a sense of scale – a lot of people are abandoning the process. Still, you’re describing a situation, and now you’re clarifying how widespread the situation is. You still haven’t answered the question “why should we care?” To decide if you should care, your first question should be “how much is this hurting us?” and this is exactly what the impact section of the problem statement declares. This is the information we need to compare the importance of solving this problem with the importance of solving some other problem.

The Problem of… 20% of repeat customers abandon the new product registration process
Affects Whom… 200,000 existing customers making additional purchases each year
The Impact of Which is… We lose $400K – $500K in incremental attached-services revenue per year

Now we understand the magnitude of the problem, using a common language – revenue* – to compare the different things we might do. There’s a bit of an issue here, but I’ve only seen this affect decision-making at two companies – revenue is not a good comparison, because profit is what really matters, and different revenue streams come with different profit margins. Attached-services revenue dollars may come at a very high gross margin, while incremental product sales may come at a much lower margin; $500K in incremental services revenue may be more profitable than $5M in incremental product sales. More commonly, people are making these decisions within an area of the company where margins are similar enough as to be ignorable for ease of analysis. The services team and the product teams are making decisions within their own silos. Yes, this is a problem. But not one you can solve with problem statements. My suggestion – use gross profits when you are comparing choices which have revenue implications.

The economic framework also improves decision making in a more subtle way. As we try to analyze economics, we uncover those assumptions that have the greatest impact on our answers. This permits us to invest more effort on getting these assumptions correct. Thus, the economic view regeneratively improves our understanding of economics. We can create enormous improvements in decision making with surprisingly imperfect answers.

Don Reinertsen, The Principles of Product Development Flow

Problem statements using this template really can help improve both your product thinking and your communications. What you’ve described is a leap – making a connection from the situation of process abandonment to the consequence of lost revenue. You know, but aren’t sharing with anyone why you can make the leap. Selling attached services is a cross-selling activity. Some people who buy the underlying product will also purchase an attachable service. Buying Apple Care for your new iPad, paying in advance for car-servicing (tire rotation, oil changes, etc.) when buying a car, purchasing additional attachments for a tool.

All of the customers who register the product are now qualified leads in your marketing database. Your company can and will target and tailor marketing messages and promotions to those customers. Every customer who abandons the registration process is unreachable (your assumption). You lose out on the opportunity to have a conversation with that customer, and therefore cross-selling opportunities are lost. The customers who abandon the registration are no longer qualified leads because you don’t know how to contact them. The actual problem is that you cannot market to those customers.

The jump in reasoning from your description of the problem to the consequences is too far for someone who doesn’t already know what you know. Without closing that gap somewhat, you undermine your communication of purpose to the teams doing the work.

The Problem of… 20% of repeat customers abandon the new product registration process

Should instead be:

The Problem of… We cannot market to the 20% of repeat customers abandon the new product registration process
Affects Whom… 200,000 existing customers making additional purchases each year
The Impact of Which is… We lose $400K – $500K in incremental attached-services sales per year

Assumption of Causality

Between the problem section and the impact section, you now have the elements of an assumption of causality. What this problem statement is asserting is not only that we cannot market to existing customers who abandon the registration process of their new product, but that we lose money because of this. The implicit assumption is in the reverse – if we could market to those customers, we would capture incremental revenue. These aren’t unreasonable assumptions, but ultimately they do need to be tested.

The first step to testing it is to take what you’ve captured and write it out as an assumption

We assume if we prevent existing customers from abandoning the registration process, then we will cross-sell incremental services to them.

This assumption, however, is anchored in the original situation – abandonment. The following assumption is more powerful because it anchors on the problem and not the situation.

We assume if we could market to existing customers who abandon the registration process, then we will cross-sell incremental services to them.

The first assumption biases teams towards developing a solution which reduces the rate of abandonment. The second version allows the team to consider reducing the abandonment rate – but also leaves open the possibility of solving the problem in a different way. Consider a couple possible solution approaches. For the first version, update the product registration flow with a “use your existing information” checkbox. Arguably this is an improved experience with a better flow for the customer and would reduce the rate of abandonment.

The second assumption does not have the same implicit constraint. The team may consider prepopulating the interface, to reduce abandonment rates. However, the barrier is removed to make it easier to ask the question – if we can prepopulate the UI, why don’t we just automate the product registration and eliminate the flow entirely? At least for existing customers who already have information on file. Registration can be automated using the same contextual information which would have been used to prepopulate a form. Why don’t we bypass the registration pattern entirely, and simply record internally who owns what? For products with an aftermarket, different company-models should be considered.

It is this act of explicitly looking at the implicit assumption in the problem statement – “abandonment causes lost revenue” vs. “inability to market causes lost revenue” – which helps you write a craft a problem statement. It also empowers your team – your collaborators – to make more meaningful contributions to solutioning because they are not unnecessarily constrained with an overly narrow problem framing.

The Problem of… We cannot market to the 20% of repeat customers abandon the new product registration process
Affects Whom… 200,000 existing customers making additional purchases each year
The Impact of Which is… We lose $400K – $500K in incremental attached-services sales per year
The Benefits of a Solution are… We increase revenue by at least $400K per year in incremental attached-services sales

Diving into crafting a non-trivial benefits section is a topic for a future post.

Conclusion

There are two different benefits of quantifying the impact in a problem statement. First – you need a common denomination for making comparisons across problems, when choosing which ones to solve and which ones to solve first. Second – by translating your understanding of a situation into economic terms, you improve your thinking about the underlying problems, and expose the assumptions you are making.

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

One thought on “Problem Statement Impact and Assumptions

  1. Pingback: Problem Statement

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.