Writing Valuable Requirements

One of the ten big rules of writing a good MRD is writing valuable requirements. How do we determine what requirements are valuable? To whom are they valuable? When a requirement represents a continuum how much is enough? What is too fast, what is too scalable? To whom must the requirement be valuable?

The Big Rule of Value

From our previous article, Writing Good Requirements – Big Ten Rules:

Pragmatic uses necessary as a criteria of good requirements. We believe that valuable requirements are good requirements. When prioritizing requirements, we should do the must-have requirements first. But other valuable requirements are critically important – even if they aren’t mandatory. Prioritization and release scheduling should stress necessary requirements first, and then the most valuable requirements next.

Requirements that can differentiate our product from the competition are by definition not necessary – or the competition would have done it already.

Valuable How?

Ultimately, we care about requirements that are valuable to us – they help us sell more software, more profitably.

We might sell more software by selling additional products to the customer. Our customer could become an advocate for our products, helping us sell the software to more customers. We could get a maintenance, subscription, or renewal contract. Or we might offer services that can be sold in conjunction with our software.

When we solve the right problems, we can sell our software for more profit.

Valuable to Whom?

While value to us is our ultimate goal, we sell software because it is valuable to our customers. There are two key groups we need to listen to, and one we need to ignore. We address the needs of the purchasing persona and the key user persona. We don’t let our salespeople have undue influence over our requirements.

Salespeople are correctly focused on a single sale. “Add this feature, and I know we can close this deal!” And a good salesperson is likely to be right about that. This, however, is a slippery slope. When we are writing an MRD we are writing market requirements, not customer X requirements. Salespeople give us input that is overwhelmingly driven by the influence of the current deal. Its possible that the salesperson is tapped into a single example of a market requirement. But it isn’t the salesperson’s priority to vett that requirement as one that applies to multiple customers. We have to do that.

The key user personas are the primary beneficiaries of our software. We are helping them improve existing processes, or we are introducing new capabilities that allow them to introduce new business processes. We help them in a way that helps their employer to make more profit. Since this is a market requirement, we need to validate that this problem is one that applies generally to our potential customers in the market, and not specifically to this customer.

A market requirement may look like the following:

Customers are waiting an average of five minutes for customer support when they call for assistance. We need to reduce the time that people wait on for support to an average of under a minute without adding support staff.

The supporting product requirement might look like the following:

Our best technical people are spending time on easy-to-solve problems, and our new-hires are wasting time trying to solve problems that they can’t solve. We need a way to make sure that our new-hires are not trying to solve problems they can’t solve, and our experts are not spending time solving trivial problems. We need a solution where new-hires solve >90% of all calls they handle, and experts only handle calls passed on by new hires.

In this example, the user persona is the call-center support staff member. The key user would be the new-hire. This requirement is valuable to them. The new-hire might have a personal goal of getting promoted. The ability to process more calls to resolution (by immediately rerouting hard problems) will help them achieve their personal goals.

The corporate goal of increasing the effective capacity of the team is also achieved. Our buying persona cares about this. And our buyer won’t buy if they don’t understand the value. A valuable requirement will be measurable. In this example, reduction of waiting time from over five minutes to under a minute is an easily measured market requirement. We can also easily measure that more than 90% of calls get re-routed, or that all expert-calls are previously vetted by the new hires.

How much value is too much?

Why did we set a goal of moving from over five minutes per call to under one minute? Why not under two minutes, or under ten seconds?

We’re dealing with a measureable goal that operates on a continuum. Most continuum-based goals operate under the law of diminishing returns. A reduction in time from five minutes to three is worth more than a reduction from three minutes to one. In our example, we have data that indicates that most people who will wait ten seconds will wait a minute. After we have asked them to wait a minute, more people become unhappy with the service with each passing moment. We have a data-driven utility curve that we can measure caller-happiness versus wait time. This gives us a good understanding of value versus wait time.

We also have to understand the cost function. Our engineering team, in this example, has studied the previous call logs and believes that we can achieve the one-minute mark by providing a solution that helps new-hires triage a call in ten seconds, and know if they need to forward it to an expert. To get the triage process under ten seconds, our engineering team has told us that they would have to build a system that automatically knows if the problem is easy to solve or hard. And this solution can involve voice recognition, or online-connectivity to the product being supported, or other cutting edge technological solutions. These clever solutions are also dramatically more expensive. This gives us a good understanding of the cost of solution versus predicted wait time.

By combining these two sets of data (benefit versus cost) we can produce a curve that tells us exactly how much is too much.

Making the tradeoff

Our customers will be willing to pay more for more value. However, they will have a target ROI or hurdle rate for making an investment in our solution. The cost axis of the curve becomes the cost to our customer for a particular measurement of the requirement (three minutes, one minute, ten seconds). The customer’s hurdle rate is tangent to the cost-benefit curve (representing customer cost and customer benefit) at the customer’s optimal point.

We should target this point for the requirement.

When Should We Get the Value?

We might not target this point for the earliest releases of our software.

In an incremental delivery process, we may prioritize a partial delivery of the feature in an earlier release. When scheduling requirements across releases, we start with a focus on the must-have requirements, and then introduce the more-is-better requirements.

In our example, we may choose to solve this problem with a database that provides keyword lookups for the new-hires, who can ask two or three simple questions, and then quickly identify the problems that are beyond their capacity to solve. This system might be designed to also log the solutions based upon the answers to the triage questions (allowing new-hires to solve more and more of the problems). In our first release, we might choose to implement the logging features. In the second release, we may include the ability for experts to input post-mortem results (to make the system get smarter over time), and in the third release, we may focus on entering data from the previous call logs, so that the system is sufficiently smart to allow for routing of more than 90% of incoming calls.

Conclusion

• Make sure our requirements are valuable.
• Make sure that the value is expressable to the buyers and ideally directly achievable by the primary users of the system.
• When developing requirements along a continuum, use data (not opinion) to set the target for the requirement.
• Prioritize incremental delivery of the functionality across sequential releases.