All great products start with a well-defined need. But a lot of products miss the mark because they start and end with a business problem definition. When your business requirements consist of the problem statement only, it’s a big problem. Here’s why.
A problem doesn’t occur until someone is doing something and encounters one or more obstacles (problems) that prevent them from getting the outcome they want. A complete business requirement describes what someone is doing, the outcome they ultimately want, why it’s important to their success, the obstacles standing in their way, and the consequences of not getting the desired outcome.
Well-rounded business requirements result in products that are easier to design, build, market, sell and use because the desired outcome is clear from the start.
Here are two contrasting examples.
A Problem-Based Requirement
- Organizations have to manually extract data from multiple systems so they can better understand their customers.
This is an incomplete requirement at best because the business problem definition on its own doesn’t define the true need. What are the scenarios in which organizations need the data, and what do they hope to accomplish with it? Why is it an issue, etc.?
Let’s say you build features to automate the extraction of data from multiple systems. If you don’t understand why and how that data will be used and the desired outcomes, there’s a good chance those features will miss the mark because the value target was never defined as part of the business requirement.
An Outcome-Based Requirement
- Organizations want to better understand customer behavior for two primary reasons:
- To identify up-sell/cross-sell opportunities earlier.
- To identify warning signs that customers are about to defect so they can take preventive action to retain them.
In both cases, they’re losing revenue, customers and ultimately market share because they’re unable to get data from multiple systems in a timely fashion and use it in a way that’s actionable.
Building Features vs. Solutions
If you build features to satisfy the problem-based requirement, there’s no way to quantify the customer value of those features. They’re just features that have potential, making them all the more difficult to market, sell and use.
If you build features to satisfy the outcome-based business requirement, you’ve delivered a high-value business solution that allows customers to quantify the impact on their up-sell/cross-sell revenue and customer retention. Who wouldn’t buy that?
Problem-based business requirements are one of the biggest culprits to scope creep, poor usability, poor quality, late deliveries and budget overruns. And they’re not doing marketing and sales any favors when it comes to differentiation and selling value.
If your business requirements start and end with a problem statement, contact us about an outcome-based product management or product marketing workshop so you can start delivering, marketing and selling solutions with greater strategic value.
by John Mansour on September 1, 2021.