They key to writing a great spec is knowing how to specify software that mets our customers’ needs.
It can be a daunting task. First, we have to define what our customer needs. High level requirements are just requirements that are too vague or high-level to be directly actionable. “We must reduce our cost of fullfilling orders by 20%” is a high level requirement. We can’t start writing code with only that information. In an early post, we talked about functional requirements being written at the right level – don’t confuse the level of clarity required for writing a functional spec with that required to define goals.
A market requirements document (MRD), as we discussed earlier, discusses the problems (to be solved) or the needs of the market. When working with a customer, that customer will identify one or more strategic objectives.
As an aside – this case study demonstrates use of the OST (objectives, strategy and tactics) approach to initiating and managing projects. Check it out for context. You can just skim the bold parts in the OST sections if you want to stay on topic with this post.
The question is – How do we get from an MRD to a great PRD?
A product requirements document (PRD) captures the capabilities of the software in order to address the market needs. From these key capabilities comes the design of the software. How do we get from needs to ideas?
This is an ideation task. A product manager must apply high level design skills when writing the specification. Haven’t we said repeatedly that requirements should not describe the implementation or design? Yes. Previously, we talked about the importance of asking why, this is the same issue, approached in the other direction – starting with the why and asking how.
We’re not talking about specifying implementation details – just articulating capabilities. Here is a list of “market need : product capability” that demonstrate the transition from MRD to PRD.
- Customers are cancelling 5% of their orders because of shipping delays : Software will enable shipping within 24 hours of order
- Our competitor is gaining market share by offering free plugins : Software will support a plug-in architecture
- 80% of potential customers (visitors) leave our website without ordering : Navigation must be simple on the website
- Our software keeps crashing and we don’t know why : Software will send error information from client to server
One of the things that makes this requirements design activity so difficult is that we have to have good ideas about how to solve the problems we are tasked with solving. Look at example number three – there are many different ways to attempt to solve the problem – the challenge is in picking the right one. Requirements elicitation will unearth the required capabilities.
Organizing, validating, and prioritizing these capabilities is the hard part. The output of this effort is a PRD. A product roadmap (a vision of what a product will be capable of doing, over time) is another potential output.
A lot of this terminology – MRD, PRD, market needs, product capabilities, requirements, design – is subject to debates about semantics. I personally don’t see much need to have two separate requirements documents, but I do accept the distinctions between strategic objectives and product requirements.
Just to try to bring some clarity to some of the terms: I would not portray things in terms of market need and product capability. Instead, I would go from:
problem -> requirement -> design
Example:
problem – 20% of customers quit using the product after trying it the first time, expressing frustration about how difficult it is to use.
requirement – 95% of customers with skills a, b, and c should be able to accomplish goal x in y amount of time using the product the first time.
design – present an optional wizard-based user interface for first-time users.
Ideally, the requirement does nothing more than state a pass-fail measurement expressing whether the product has solved the problem to a sufficient degree. Any specification of “product capability” beyond this measurement is, as you state, design. I don’t see any reason to call such a further specification a “requirement”.
Furthermore, I don’t see design (whether high or low level) or “product capability” as the purview of the product manager. Architects and user interface designers are by definition the experts on such matters. A single person can be well qualified to play all these roles, but the roles are distinct.
I completely agree that the flow is from problem -> requirement -> design.
There is ideation at each stage.
Prioritizing the right problems to solve, selecting the articulation of the requirement (sometimes the solution isn’t even in the software), and designing the software are ALL ideation activities.
To focus on “requirements design” – there are several different ways to address any particular problem. Using your example of first time users failing to use the software effectively, there are multiple ways to address the problem:
Each of these “requirement designs” would drive different software design decisions.
On another point – I would be careful of using “95% of users”, as that either introduces a burdensome cost or a sense of false precision. There is significant effort in actually assuring that X% of users can do anything – and you would actually have to state “with Y% degree of confidence” for the requirement to be unambiguous. This is an expensive process, and misleading to anyone who hasn’t studied statistics. It would be better as a general rule, IMHO, to simply say “customers with skills a,b,c…” – and then evaluate subjectively based on anecdotal data. For critical usability concerns (can the guy in the silo enter the launch codes) – spend the money, but clarify the requirement first.
Thanks again for your comments – they are frequent, provoking and helpful, and very appreciated!
I would be hesitant to put these all in the same bucket:
> 1. Specify that goal X is achievable in Y time.
> 2. Eliminate goal X and replace it with goal Y.
> 3. Market the product to a different user group.
> 4. Users must be trained to use the application.
(1) is most likely a requirement, (3) is a strategic decision that impacts requirements, and (4) is almost certainly a design choice. (2) depends a lot on the context.
You’re right – my examples don’t work well as a group. The point I was striving to make is that there isn’t a thought-free conversion from a market requirement to a product requirement.
The best way to articulate what part of the problem the software needs to address is not self-evident. I think keeping seperate notions of “this is what is wrong” and “this is what we’re going to solve with the software” is valuable.
Scott with your last line “I think keeping seperate notions of “this is what is wrong†and “this is what we’re going to solve with the software†is valuable.” seems be be converging with the author’s notion of “market need : product capability(solution)” instead of the 3 step process of “problem -> requirement -> design”
Not sure how much standards have changed till now…