“The product shall.”
Market requirements typically define the problems your product will address using a formal, stilted language known to all technology people. For some reason, the verb shall be “shall”—not “should” or “will” or “must” or “it’d be neat if.” Maybe it goes all the way back to the Ten Commandments: You Shall Honor Thy Father and Mother; You Shall Not Murder; You Shall Not Steal. You Shall Not Write Requirements Without the Verb Shall.
I’ve completely given up on formal requirements. We’re just terrible at writing them; and, still, the development group wants more detail—and more and more and more.
Product managers write horrid requirements that are littered with buzzwords, ambivalent language, and non-specific performance parameters. They read like somewhat-technical marketing hype. And developers have to make sense of the requirements. They complain, “I cannot program to these requirements.”
And they’re right.
So product managers try to become more specific by writing what I call ReqSpecs. Part problem, part implementation—and impossible to use. Developers then complain, “Don’t tell me how to do my job,” because the requirement now explains how the feature should be implemented.
And they’re right again.
Developers say they cannot program to Product Management’s requirements. And they’re right. What they need is a functional specification. ReqSpecs don’t solve the problem.
Let’s clarify some terms.
A requirement is a short statement of the problem.
A specification is a detailed description of how to solve the problem.
Alan Cooper, often called “the father of Visual Basic”and an expert in interaction design, argues that most projects fail because they do not have a spec at all. This is because most companies do not have product designers or architects. Product managers create desired feature lists; developers write code. But neither the product managers nor the developers are designing anything. Would you hire a carpenter to design a house? Of course not. You would hire an architect. Yet programmers often write complex software products without a design.
Cooper suggests we add a role that is new to most Development organizations: the product designer. The designer analyzes the problems described in the requirements and then creates a specification, at a functional level, to describe how the problem can be solved with the product. The designer delivers a recommended approach to solving the problem, serving as the bridge between Product Management and Development.
In eXtreme Programming (XP), a requirement fits on an index card and is delivered in the form of a story. This requirement also comes with an implicit “agreement to discuss,” so that developers fully understand the problem.
Rather than being in the requirement, implementation details must be in the specification. A specification is the designer’s intended implementation to solve the problem.
In his excellent series on “Painless Functional Specifications” (www.joelonsoftware.com), Joel Spolsky, CEO of Fog Creek Software, writes:
“…on any non-trivial project (more than about 1 week of coding or more than 1programmer), if you don’t have a spec, you will always spend more time and create lower quality code.
“A functional specification describes how a product will work entirely from the user’s perspective. It doesn’t care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on. A technical specification describes the internal implementation of the program. It talks about data structures, relational database models, choice of programming languages and tools, algorithms, etc.”
So, a requirement states the problem; a specification states the solution. Spolsky defines two kinds of specification: functional, which is the intended approach to solving the problem; and technical, which is a detailed internal implementation.
In the end, we all have a critical role to play:
Every company and every consultant has a laundry list of acronyms for the documents that must be produced: BRD, MRD, PRD, SRS. Enough already! There are only a few documents required: the problems (the basis of the market requirements document) and how we will solve them (a product specifications document).
In the old days, tech companies followed the “waterfall” model: Documents moved downstream one department at a time, from requirement to specification to build to test. But the final result—the product—looked nothing like the requirements. Product managers were always surprised in the end.
The waterfall approach fails. What’s missing from the waterfall is collaboration and iteration.
Imagine going to a college seminar and not being able to ask the professor any questions! No matter whether or not you understand it, you’re being tested on the lecture without being able to clarify any of the professor’s points. How likely are you to do well in that course?
And now imagine that college ends with a single exam—without any tests along the way. In four or five years, you sit through 60 or more courses–ranging from Western Civilization to a foreign language to biology to women’s studies to macro economics to business law to volleyball. Now take a single exam to receive your diploma. No one could pass such an exam!
Isn’t it the same for products? Imagine a software development effort that takes multiple years to deliver—without any opportunity to test your progress along the way.
Years ago, I joined a product team that was entering its third year of programming without a product release. Everyone on the team was despondent. Over the course of two or three years, every role had been filled more than once. Long ago, they had lost any hope of succeeding, and all of them were looking for jobs elsewhere.
I took one look at the requirements and saw the problem: The executives were constantly adding new requirements. Every week brought new features to the list—and features were being added to the list faster than they could be programmed into the product. The solution was simple: Someone—and that someone was me—had to stand up to the executives and tell them to stop! We were no longer accepting requirements for the next release. Here’s how we did it.
Pragmatic Marketing, Inc. has continuously delivered thought leadership in technology product management and marketing since it was founded in 1993. Today, we provide training and present at industry events around the world, conduct the industry’s largest annual survey and produce respected publications that are read by more than 100,000 product management and marketing professionals. Our thought-leadership portfolio includes the Pragmatic Marketing Framework, eBooks, blogs, webinars, podcasts, newsletters, The Pragmatic Marketer magazine and the bestseller “Tuned In.”
To learn more about our courses and join the growing international community of more than 85,000 product management and marketing professionals trained by Pragmatic Marketing, please click here.