Valuable Requirements

Writing valuable requirements is important. It doesn’t matter how well your teams execute if they are off building the wrong products / capabilities / features. The right products and capabilities are the ones that have relevant value.

• Valuable requirements solve problems in your market.
• Valuable requirements support your business strategy.
• Valuable requirements solve problems for your users.
• Valuable requirements meet your buyers’ criteria.
• Valuable requirements don’t over-solve the problems.

Valuable Requirements – Revisiting

A little over three years ago, I compiled the Big Ten Rules of Writing Good Requirements, which ended up with an even dozen “rules.” The first rule was writing valuable requirements. Three years is a long time. Our environment has changed. Many great insights have come into our neck of the software development woods from many inspired voices. I’ve personally learned a lot. My focus has changed from being more focused on product specification (back then) to being more engaged in business strategy (today). Our audience here has grown ~ 10x since the original rules were published. My dog has tripled in size. Perhaps my writing has even improved.

Given that, it makes sense to revisit the topic now.

Valuable Requirements Solve Problems in your Market

I struggled a little about starting with “strategy” or starting with “the market.” Pragmatic Marketing’s Framework (recently updated) starts with the market. When I first watched the great video, where Jim Foxworthy introduces the updates to the grid, I was a little concerned about that. Market first, strategy second. Why not strategy first and market second? I decided that I was happy with their presentation, since the framework is a tool for product managers. Product managers usually have responsibility for a market, as a component of their company’s strategy – so the sequencing makes sense for a product manager audience. Jim also puts it in perspective – their framework is focused on the company’s strategy for attacking a particular market. I’ll stick with that here too.

To understand what problems are valuable for a particular market (or market segment) you have to approach it from your customer’s perspective. What are the problems they are trying to solve?

Your customers might be distributors of retail products, who’s business it is to acquire, store, and redistribute small products. They are in a business where their customers value accuracy, timeliness, and low cost of delivery. Your customers may value solutions that allow them to more accurately redistribute products (they receive pallets full of items, and then redistribute them a case at a time). They may value solutions that allow them to adapt to changes in orders with minimal turn-around time. Or they may get the most value out of cost reductions. Talk with your customers, listen to them talk about their problems. When I was working for an enterprise software company years ago, our CEO stressed that he wanted to be solving the problems that keep our customer CEOs up at night. Find out what those problems are.

The next challenge is in breaking those problems down into something actionable. If your customers’ biggest problem is cost reduction, how do you solve it? The first step is to understand where the costs are. One way to visualize and decompose the problems your customers face is with an Ishikawa diagram (check this out to learn how to use an Ishikawa).

The following diagram shows a decomposition of “The cost of driving is too high” problem:

[larger image]

Now you’ve identified a set of problems that are valuable to your customers. The Ishikawa can help you make sure you’re identifying problems, not the manifestations of problems.

You also have to understand what solutions are already available to your customers. If you have a competitor that already offers a very good solution to one of the identified problems, your customers will find less value in a solution from you.

Valuable Requirements Support Your Business Strategy

With a set of problems in hand that are worth solving, you have to figure out which ones are aligned with your company’s strategy.

In the Ishikawa above, one of the problems that car owners face is excessively high payments (on their car loan). Another problem is that the cost of maintenance is too high. If your company provides financing products (loans and leases), trying to solve the cost of maintenance problem for your customers is probably out of alignment with your strategy. Making the financing of a vehicle more affordable (while still profitable for your company) is probably a well-aligned problem.

Your company will also have a strategy for engaging the market – target market share levels, target market segments to penetrate, etc. You may be trying to become a visionary company with your finger on the pulse of your market – or you may be trying to get mass adoption of your product by solving a very common problem, but solving it better than your competitors. Your strategy for winning in this market may be to differentiate your offerings by solving different problems than your competitors, or defining a unique market.

Another way to think about alignment with your business strategy is to think about the owners of your company’s strategic goals – your internal stakeholders. Most projects will fail (or be killed) without internal champions who believe in the ideas.

When you’re aligned with a part of your company strategy, you’re aligned with whoever is the owner of that component of the strategy, and you’re providing value to that stakeholder. Sometimes there are many components and stakeholders. You can adapt some process-improvement prioritization techniques that Roger Burlton teaches to get an understanding of which goals are important to whom.

Valuable Requirements Solve Problems for Your Users

Products are used by people. People use those products to accomplish goals. They may be using your product for their employers, in which case they have “practical goals” (finish quickly) that represent how their company’s goals (lowered costs) are realized. And those people usually interact with other people. You can quickly build a visualization of who are the users (and indirect users).

[larger image]

You can think of this as an ecosystem of users of your product. Develop personas and their goals to represent these users. You can apply the same Ishikawa-based problem-decomposition technique when needed to make sure you’re uncovering the real problems (too many people abandon the sign-up process) and not the manifestations of those problems (users have to click too much).

When your users are not your customers, your users have personal and practical goals that represent their individual contributions to achieving your customer’s goals. And your users achieve those goals by doing stuff. You can represent that stuff with user stories or use cases. The key element is to make sure that you’ve identified the valuable activities, the ones that are required to achieve goals.

[larger version]

The above diagram is used when assessing the completeness of requirements, which is an element of assuring valuable requirements. If a goal has value, you have to identify the set of user stories required to achieve the goal. Those user stories therefore have value. User stories that don’t support a goal don’t have value.

Valuable Requirements Meet Your Buyer’s Criteria

The people who buy your products are sometimes not the people who use your products. Even when the same person is both buyer and user, that person’s mental model for buying is different from their model for using a product. If you can’t convince someone to buy your product, it doesn’t matter how great it would have been had they bought it.

Here are the opening soundbites from an earlier article on buyer personas.

• Buyer Persona: If you build what he thinks he wants, he’ll come.
• User Persona: If you build what he actually needs, he’ll come back.

And the closing summary points (it’s a long article):

• Buyer personas make purchases when products appear to address their internal view of what the problems are.
• User personas love products when those products solve the real problems.
• Don’t confuse buyers (who need to buy products to solve user problems) with users (who need to solve their own problems).
• When buyers and users are the same people, acknowledge the buyer-goals distinctly from the user-goals.

There are also several really great insights in the discussion thread – including great comments from Shaun Connolly, Edele Revella, and David Meerman Scott!

Valuable Requirements Don’t Over-Solve the Problems

More is better, right? Not always. Sometimes, “more” is a waste. There are really two ways to think about how much is too much.

The ROI of Incremental Improvements

Because of the law of diminishing returns, the next “more” is always worth less than the previous “more.” Think of it in terms of improving fuel-economy. If you have a car that gets 10 mpg, and you drive 100 miles a day, you have to buy 10 gallons of gas a day. If you improve the mpg by 10 mpg (to 20 mpg), you’ll save 5 gallons of gas per day. Huge value. If you improve the mpg by another 10 mpg (to 30 mpg), you’ll save an additional 1.3 gallons of gas per day. Some value. Another 10 mpg buys you 0.8 gallons per day. Diminishing returns.

The cost of achieving “more” is also a factor. The simplified diagram above shows a linear representation of cost as a black line. The diminishing returns of value are represented as the red curve. The optimal investment point is where the two curves are tangent (have the same slope) – marked with the blue circle. Less investment leaves money on the table – additional investment is done at a loss.

Good Enough is Enough

You don’t need to super-solve the problem. How much more would you pay for a car that got 10,000 mpg than one that got 1,000 mpg? If you drove 100 miles a day, the difference between the two (from a value standpoint) is trivial. Over the course of 100 days, you would save 9 gallons total with the car that had ten times the fuel efficiency.

Why haven’t microwave ovens been getting faster every year? Because the move from a 1-hr baked potato to a 5-minute baked potato is good enough. You don’t need to get it under 4 minutes.

This is known as satisficing – stopping when something is good, not trying to make it “perfect.” Additional “goodness” will not result in enough additional sales to justify the investment.

Conclusion

The tagline for Tyner Blain is Software Product Success. On an elevator, I explain that you have to not only “build stuff right” but you have to “build the right stuff.” And the right stuff is the valuable stuff.

Define valuable requirements to make sure you’re building the right stuff.