Writing Design-Free Requirements

big ten

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

Yorick's skull

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.

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

3 thoughts on “Writing Design-Free Requirements

  1. Dear author,
    I ended up on your page from hints on other pages and found myself struggling with all of the acronyms (e.g. MRD, PRD) which are used repeatedly without giving a clear definition. Only accidentally I found in another linked article an explanation that MRD stands for “Market Requirements Document” and by analogy infer that PRD then refers to the “Products Requirements Document”. But in a set of articles about high quality requirements the assumption that any reader is familiar with the writer’s acronyms is an unjustified assumption. Therefore in my personal perception a better practice would be to give at least the corresponding full term for each acronym at first use in the individual articles or otherwise provide a clear pointer to a glossary where all acronyms are listed in alphabetical order and explained once.

    Kind regards,
    Roland

  2. Thank you very much Roland! You’re exactly right. This is even a pretty timely comment, since I’ve just started updating and rewriting the “rules of requirements” series. I really appreciate your point – very well made – and will be sure to avoid the same mistake in the future.

    Thanks,

    Scott

Leave a Reply to Kristina Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.