Problems are the reason why we create software. We solve problems. For the business. A “Goal” is an acknowledgment that you are going to try and address the problem. One mistake people commonly make is to describe problem manifestations and not problems. Read on to see the difference.
Problem Manifestation
Someone recently forwarded to a mailing list an article about how to define the impetus for requirements. The article was written by someone at a “product management training and consulting” company. Instead of linking to the article, let me just say that it inspired me to write this article, and not because I agree with it. So, the names are removed to protect the well-intentioned.
That article starts with a statement I really agree with, and one I really don’t agree with:
- The Good: “All great products begin with a well defined need.”
- The Bad: “Starting your requirements with a problem statement is a problem.”
The article goes on to describe a problem manifestation*, labels it as a problem, tells us it is bad, and then goes on to propose an alternative. Don’t Build a Stupid Product Roadmap shows a similar phenomenon – someone well intentioned criticized a really horrible product roadmap, and errantly drew the conclusion that product roadmaps are bad. This is the same thing. Problem statements are not bad – in fact, they can be one of the most effective tools for clearly communicating the vision of a product.
*Problem manifestation [noun] – an example of a way in which a problem is exhibited, without appreciating the true nature of the problem. Ex: The problem manifestation is that the tires on my car are under-inflated. The problem is that my car is too expensive to maintain.
This distinction is relevant. The cost of operating the car is too high. That is the problem. It happens to be that one reason that the cost is too high is under-inflated tires. If you focus your energy on getting properly inflated tires, it will help (by improving fuel economy a little, and by reducing the frequency of tire replacement) with costs anecdotally. But you will not have solved the problem that costs are too high. Unless you get lucky. Costs can be high because the engine is inefficient or damaged, the aerodynamics of the car are bad, or any of a number of reasons. If you solve the problem by addressing a single manifestation of the problem, without understanding the whole problem, it is only because of luck.
Abstract Your Problem Correctly
When you elicit a problem from users, it is usually a description of a problem with their procedure, or the design of their product.
- I can’t keep my tires properly inflated.
- It takes too long to find the information I need about the customer who just called me.
- My price catalog is always out of date.
These are examples of how problems manifest, given a particular process or product design. If you start with a problem manifestation like one of these, it will be impossible to avoid design cues in your requirements. And you should always avoid specifying design in your requirements. The article that started us down this path is correct – these are bad things. The solution is not to abandon problem statements. The solution is to abstract them correctly. This is a skill that great product managers have, and all product managers need.
Properly abstracted, the problem manifestations above could be rewritten as problems.
- The cost of operating my car is too high.
- I lose too many customers because their calls for support take too long.
- We are making unprofitable sales (and losing other sales) because we quote incorrect prices to our customers.
These problem statements can be turned into goals, from which the rest of your requirements can be defined. Goals would be in the form “Reduce the cost of operating my car by 20%.”
You can abstract too far. You know you’ve gone too far when the problem statement does not give you any insight into what problem you are solving. Here are the same three examples, abstracted too far.
- I don’t have enough money.
- We don’t have enough revenue.
- We don’t make enough profit.
This abstraction problem is a common one in product management. It has come up in a handful of discussion threads over the last couple of years here, and is a key point in a couple articles too.
- We see incorrect definitions of problem statements.
- We see incorrect definitions of use cases.
- We see business rules and requirements at the wrong level.
Don’t go too far, or your team won’t know what to do. The goal is to understand the problems that affect multiple customers in your market – not just a single company or user. Make sure you abstract far enough, or you won’t actually solve the valuable problems. And without valuable problems to solve, you can’t write valuable requirements.
Conclusion
Problem statements are awesome. They define the scope and vision of what you intend with your software. They provide a framework for measuring the value your customers see from your product. They provide context for prioritization and design decisions.
Problem manifestations are too low level to achieve any of these goals. They are bad.
Don’t abandon your problem manifestation, just ask “why does that matter?” until you reach the proper level of abstraction. Then you’ll know what the real problem is.
Latest Articles
Comments on all Articles
