Do you write Requirements or Specifications? Or do you combine them into ReqSpecs? Each has a place but combining them just causes confusion.
Can you believe the angst between product managers and developers? Many product managers think their developers are incompetent. The feeling is mutual: developers don't think product managers bring any value to the process. Yet we all want to get products to market but our understanding of roles keeps getting in the way. Who writes requirements? Who writes specifications? And what's the difference between a req and a spec? The requirement is the problem.
Product managers write terrible requirements, littered with buzz words, 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 we call ReqSpecs. Part problem, part implementation--and impossible to use. Developers 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.
The primary role of the product manager is to be the "messenger of the market," and we must not take on additional tasks until that primary one is completed. Yet product managers frequently attend design meetings. Why? What value do they add? If product managers have time for design meetings, it had better be after they have completed their on-site visits with their market segment.
Besides, product management attending design meetings is not about getting better designed products; it's about sharing blame for poor design. "What do you mean you don't like it? You were there when we designed it!?!?!" If product managers are creating the design, what value is development providing? Coding? If that's all, perhaps we should just fire all the developers and outsource to India or Ireland or someplace where at least they will code to our design. That is, we'll get exactly what we asked for without the developer's editorial license.
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.
In Pragmatic Marketing's course Build, we teach product managers how to log market problems, distill them into the unique set of problems, and write requirements based on the market problems. A Market Requirements Document (MRD) is a master list of all problems and the number of customer and prospect sites reporting the problem. Developers value the class as much as the product managers because eliminating dysfunction by teaching product management to deliver what developers so desperately want to know: What are the problems in the market? The problem is the requirement.
By definition, a requirement is implementation-free; that is, absent design. When developers request more specific implementation details, they're asking for a specification instead of a requirement. In Extreme Programming (XP), a requirement fits on an index card and is delivered in the form of a story. The requirement is also an explicit "agreement to discuss" so that developers fully understand the problem.
Instead of being in the requirement, implementation details must be in the specification. A specification is the architect's intended implementation to solve the problem. It is not an architectural blueprint of the final product.
Joel Spolsky has already written much on specs (Joel on Software). We defy you to find an article that doesn't have at least one tip on creating better products.
"On any non-trivial project (more than about 1 week of coding or more than 1 programmer), if you don't have a spec, you will always spend more time and create lower quality code."
And also says:
"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. Joel 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:
Think developers are incompetent? Maybe they're working in a dysfunctional environment and are frustrated themselves. Focus on market problems and you're halfway to a reasonable solution. Design a reasonable solution to the problem and you'll deliver a product that people want to buy.
We’ve completely abandoned the traditional “the product shall” approach to writing requirements. Instead, we encourage product management to focus on the problems and let development focus on how to solve the problems. Many of the requirements that we read are in fact thinly veiled feature descriptions.
Do you write requirements in the form of "the product shall"? If so, then you are probably limiting the creativity of your development team and writing specifications. However, depending on the requirements writing legacy that you inherited (probably from a extremely project- or program-oriented waterfall environment), you will need to transition your teams to understand that the product management role does not include writing specs, but rather that the value they add is through customer interaction and understanding market problems.
Do you write "as a 'role,' I want to 'perform an activity,' so that I can 'achieve a goal'?" If so, then you are probably an agile shop, using a variation of Scrum or XP development techniques. We have found this method seems to work the best in software companies, with co-located teams, that have a fairly high degree of domain expertise. However, there are numerous examples of multi-national projects building hardware or electrical components that have also been successful with this approach – it just requires different skills and techniques to be successful.
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.
John Milburn is a Pragmatic Marketing instructor who has “walked the walk” in technology product management. Throughout his 20-plus-year career, he has managed or delivered more than 40 hardware and software products and implemented the Pragmatic Marketing Framework at many companies. A CSPO, his perspective and experiences from companies such as Lane 15 Software, Dell, IBM, Texas Instruments, Exxon, and Vtel add insight and real-world examples to his teaching. This perspective allows John to connect with product managers and executives from companies of all sizes in a broad range of markets. Contact him at firstname.lastname@example.org.