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.
Couldn’t agree more with the importance of problem statements. (After all, I believe the requirements are little more than problem statements.) However, every problem statement is a manifestation of a larger problem, so selecting the “proper level of abstraction” is not always easy. But just thinking in terms of problems, rather than in terms of features or solutions, is already a huge amount of progress beyond what most product managers do.
Thanks Roger! 100% with you here.
The organisation I have recently started to work for has a real problem with this. Every project seems to be intiated on the back of a solution, often a piece of software, with no understanding of the problem.
Just by introducing overarching problem statements to the initiation phase has been a quick win and is making stakeholders, product managers and sponsors think “requirements” rather than “solutions”.
It’s a challenge getting them to that right level of abstraction as you said and I often feel like I’m being a real pain in the @ss constantly asking “so what?” and “why is that a problem” but it’s worth it to get to that “eureeka” moment.
Keep up the good work, loving the articles.
The Demon – Sunny Scotland
Thanks, Demon!
I’ve seen the same thing start to propagate through a very “inside out” organization. In some of the meetings, after starting to focus on the problem statements, when people asked “do we need to worry about…” with a very solution-centric perspective, I was able to say “if we decide to solve problem X” and have people nod their heads.
The PITA factor can be a very real one with people who are focused on controlling “what do I have to do?” instead of “what needs to be done?” I’ve had some success with embedding a cause and effect diagram directly into the problem-statement section of the BRD. That gives those solution-focused people the opportunity to absorb the eureka! perspective offline, save face, and bring a changed perspective back into the team dynamics.
Relatively new to this field compared with author and many who post.
But, if we are getting picky about the example you reference, Scott….
“The article goes on to describe a problem manifestation*, labels it as a problem ”
Then couldn’t you get abstract on your oft-cited tyre example and say that “my car is too expensive to maintain” is a problem manifestation of the problem “the job I do ain’t paying enough money to cover all my bills (including my expensive car maintenance”.
Defining “expensive” in appendix?
I’ve abstracted too far, haven’t I? How does one know how not to abstract too far?
Hey James,
Thanks for the great question, and tangible example!
“Too far” can be defined a couple ways, depending on if you’re thinking about it “as a business” or “for a user.”
As a business, if your strategy / vision / positioning (in the market) is that you offer solutions to make the cost of vehicle ownership lower, then that’s where you would stop. Imagine if a rental-car company outsourced “car maintenance” to your company, so that they could focus on distribution, marketing, and rental-services. Yes, tire-inflation is part of it, but everything that makes it cheaper to operate the vehicles is “fair game.” Things like “we (as a rental car company) don’t have enough revenue” would be outside of your (self-defined) scope.
When focusing on “for a user” – picking the right abstraction level becomes a focus on “can I make a difference?” If your (scope of) product development does not include helping users get higher-paying jobs, then that is an abstraction level that is “too high.”
Really, it is the same analysis as the business-version.
However, when you’re thinking about longer-term strategy, it is useful to think “too abstractly” about the current problem on which you are focusing. When you’re ready to grow beyond your current product, one direction for growth is to solve “other problems” for your current customers. The abstraction may help you find those “other problems.”
Does that help?
Gotcha, Scott, thanks.
In simpler terms, it’s a case of defining scope for the business at the beginning. External variables that cannot realistically be influenced by the business (like getting this guy a better paid job) are outta scope. Lowering the expense of the car maintenance could very well be in scope.
Does that sound about right?
Yes, James – you’ve got it! Thanks again, and welcome to Tyner Blain!