How to Create Effective Requirements Documents
Hint — focus on the problem and not on the solution
Behind every successful product there is a need or a problem the product has managed to solve. The first stage towards a successful product is the problem/need definition. It usually comes in the form of a requirement document written by the business guys, handled then to the product team to push forward, prioritize, and implement. This document is usually called MRD — Market Requirements Document, and sometimes BRD — Business Requirements Document. Either way, its purpose is to describe the problem domain and the rationale behind putting an effort to solve the discussed problem.
The second stage is the solution definition, a discussion involving all stakeholders on how to solve the problem defined in the first stage. In this stage, we map the possible ways to solve the problem, taking into consideration the various constraints, such as technical capabilities, timelines, budget, resources, etc. The result of the second stage is a decision on how to solve the problem. Only then, the third stage can begin, and this is the implementation stage — writing code, designing UX/UI, building test plans, etc.
So back to the first stage, a good MRD should answer a few basic, yet crucial questions:
- What is the need/problem we are trying to solve?
- Why do we want to solve it? What are the benefits of solving it?
- What is the target market for the product? What is the competition in this market?
- What are the goals and objectives? What are the risks?
This set of questions is straightforward, and from my experience, it is the common practice in many organizations, which is good. So, if all is good, what’s the issue?
The issue I see is the tendency to combine stage 1 and stage 2 together.
All too often, if you examine requirements documents, you find there the problem definition, but you also find the required solution to the problem. Sometimes the mix is in the requirement title itself. Take a look at the following example:
“Our need is to integrate Google Analytics into our website, so we can count unique visitors.”
Do you see how the solution sneaked into the problem definition? The real need is to count unique visitors. Google analytics is NOT the need; it is the solution, one solution amongst others. The VP Marketing, seemingly knowing what she wants, prepares a document that says: “I need Google Analytics, please deliver it.” This is wrong of course. What she needs is the ability to count unique visitors.
I think the original sin here is the use of the term “Requirement”, which is ambiguous and confusing. The two requirements I have just described: “We need Google Analytics” vs. “We need to count unique visitors”, fall both nicely into the term “Requirement”. One of them describes the need, while the other describes the solution.
Here is my tip to avoid this confusion— when you write an MRD, neither use the word “Requirement” nor “Need”. Speak about your Problem. I find the following statement very useful: “My problem is…”. When you use it, you are forced to speak in precise language, which leaves outside the solution domain. In our example: “My problem is — I don’t have the ability to count unique visitors.”
One can ask — Ok, I get this, but why is this mix of problem and solution so bad?
First of all, as I said, to have many solutions on the table, is always better than having one solution envisioned by someone whose mindset is locked.
Second, Product Managers never like to be regarded as ‘technicians of features’. It really turns them off to get a requirement with the implied message — “this is what I need, here is the solution, just do it”. This approach is the opposite of collaboration. Product teams want to be part of the creative process, and guess what — they can be pretty good at it.
Here is a lovely story to exemplify the mixing of problem and solution domains, with its potential consequences:
In 1961, NASA launched its Apollo plan after President Kennedy set the ambitious goal of landing a man on the Moon by the end of the decade. On July 20th 1969, they made it.
Of all the millions of problems and challenges they had to solve, there was the challenge of writing in space — a regular ballpoint pen does not work in zero-gravity conditions. So NASA defined a requirement: “We need a pen that works in zero-gravity conditions”. It was expensive and complicated (it cost around $1M), but finally they managed to build a solution which was to pressurize the ink cartridge, and they named it the AG7 pen. Here it is:
(I bought it recently on Amazon for $37, I must say it’s a great pen)
At the same time in the USSR, the Soviets, who had the same problem for their Soyuz plan, defined their requirement: “We need to write in zero-gravity conditions”. Their tech team came with this solution:
A pencil. Works perfectly in zero gravity 😜
So, let’s compare this:
“We need a pen that writes in zero-gravity conditions.”
With this:
“We need to write in zero-gravity conditions.”
The pen is NOT the need. It’s the solution, only one solution amongst others.
Conclusion — If you ask for a pen, you will get a pen. If you ask for something to write with in space, you might get a pencil.
Disclosure: The historical true story about the space pen is a bit more complicated. The option to use pencils was considered by NASA, but was rejected for two reasons. First, pencils are flammable, a quality NASA wanted to avoid in onboard objects after the Apollo 1 cabin fire. And second, the tips of the pencils can flake and break off, drifting in the cabin where they could potentially harm an astronaut or equipment.
(Regardless of the historical facts, one must admit the story is still funny and thought provoking. And like with all myths, even if it’s not necessarily true, it’s great for taking a lesson from.)
Henry Ford’s famous quote fits here perfectly. He once said:
“If I had asked people what they wanted, they would have said faster horses.”
For our purpose, let me rephrase it a bit:
If you ask for a faster horse, you will get a faster horse. If you ask for a faster way to get to work (which is your real problem), you might get a car…
Drive safely!
