Writing Design-Free Requirements

One of the ten big rules of writing a good MRD is writing requirements that do not specify design. How do we specify enough detail to be actionable without constraining the engineering team? How do we trust our developers to do the right thing?

The Big Rule of Avoiding Design-Agnosticism

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

Generally, a requirement should not specifiy any of the implementation choices. From a product manager’s perspective the requirement is the ‘what’ and the spec is the ‘how’. To a system designer or architect or lead developer, the requirement serves as a ‘why’.

Reviewing the Flow of Requirements from the Market to the PRD

Product managers begin by identifying a need in the market. The need can either be a problem that needs solving, or an opportunity that awaits a solution. Pragmatic Marketing teaches (and we agree) that people will pay more to solve problems than they will to address opportunities. Our previous article on innovation touches on the demands to reduce costs (address pain) that overshadow the attempts to seize new markets (opportunities).

Once a problem has been identified in the market, the product manager will capture it in an MRD. The MRD provides context for the entire project, and may include a vision statement and a product roadmap as well. This vision is built upon the identified market needs.

A PRD identifies those market problems that are to be solved within the scope of a product. The transition from MRD to PRD is an ideation process. The product manager must determine which problems are worth solving (high enough ROI) and which problems should be solved earlier or later. The PRD captures a definition of the problems to be solved with this product.

The software requirements specification, or SRS, is created from the PRD. This article is focused on the MRD, so covering the flow through the PRD is where we will stop.

To Act or Not To Act

Alas poor Product Manager. [Ed: silly idea]
Actionable Requirements

The MRD identifies the market problems with enough information for someone to ask “How should we solve this?” The creation of the PRD is the step where we say “We solve this one with our software, but not that one. And do this one first.”

For an MRD to be actionable it needs to provide insight into the problem, without assuming a particular solution approach. Software solutions are specified in the PRD. Here are a couple examples.

Bad

• Our premium skateboards are losing market share.

Good

• Our premium skateboards are losing market share to Tony Hawk’s new high-end board. We advertise in the same places, and have similar prices. Tony introduces a new limited edition board every month, which quickly sells out. His boards stay on the cutting edge of truck and bearing design, but his boards have half the life in tests that ours do.

Why is Good Good?

With the comparative information, we know that our competitor has differentiated technology, and we have better quality. This market research data (not opinion) allows us to make decisions about how we want to characterize and address the solution. We have not specified a solution.

Bad

• We need to update our social-networking website. Furl allows people to give ratings not just of linked pages, but also of other people. Furl is doubling in traffic every quarter while we have no growth. We need to add people-rating to meet our goal of doubling traffic every six months.

Good

• Our social-networking site is not growing as fast as we want. Furl is doubling in traffic every quarter. They allow people to ratings to other people, not just to linked pages like our site. We need to at least double our traffic every six months.

Why is Bad Bad?

There is an implicit assumption in the bad example – that adding people-rating capabilities will improve our traffic. The MRD should not include solutions, only identification of the problems. We might decide that we think people-rating is irrelevant, and that we will solve this problem with a marketing program. The research data is important, but the conclusions should not be drawn in the MRD.

Conclusion

Don’t draw conclusions in the MRD. Provide the data only. Conclusions represent design.