I don’t like requirements documents. There, I said it.  I’ve been thinking about this latently for a number of months now, but all of this thinking really caught up with me this weekend.  We’ve been thinking a lot lately about evolving our product management practices and there are no shortage of opinions around the office and from experts in the community.  As such, I’ve tried to do a lot of listening, reading, learning, and reflecting over the last few weeks.  Here’s what I’ve come up with so far.

There are many flavors of requirements out there.  Depending on the product management practices you use, you are likely to have some of the following: product requirements documents (PRDs), market requirement documents (MRDs), business requirements documents (BRDs), software requirements specifications (SRSs), and feature specifications (FSs).  For the sake of simplicity, I’ll just refer to all of them as PRDs or specs.

There are a number of shortcoming with PRDs. I’ll take the time to just list a few here:

• They take a long time to write.  Also, they aren’t super useful until you are done writing.  (Think of the value curve as a stair-step function)
• They are not enjoyable, engaging, or interesting to read.  Ergo, they aren’t read often.
• Similar to the above, but potentially worse: they are nearly impossible to ‘diff‘ in most typical formats.   Which, for a living document, is bad.
• They give people a false sense of security.  You read through that fifty pages and you think, ‘wow, we got this thing completely specced out.’  Wrong.  See below.
• They don’t cover the most important of the product: the user experience.

Let’s talk about what a good spec should do

To me, a good set of requirements is supposed to describe a product that we are reasonably confident will be successful in front of real users.  But why does it exist in the first place?  Well, it’s core purpose is to facilitate discussion and decision making around the product in question.  Typically, there are a lot of stakeholders (with a lot of different paradigms) around that table: QA, Engineering, Marketing, Merchandising, Operations, Executives, etc.  So a good spec is able to quickly communicate what this product does and how it will do it.  The goal of such a specification is to create more clarity than confusion.  It should be your single source of truth.  Finally, a sustainable spec is one that is built for change.  Your product will no doubt evolve and change as you gain more insight from users.

Delivering on all the expectations of a good specification is much easier said than done.  There are a lot of things that a spec has to do, and it’s only really useful if you can create it in a reasonable amount of time.  Furthermore, in most typical formats, the spec ends up getting thrown in the trash after the product is launched.  So you really don’t want to invest that much time into it.

Also, there is a timing issue here.  How can we have any degree of confidence that our product will be successful without actually having tested the product in front of real users?   If you look at most specification creation processes, you’ll find that people are writing tens or hundreds of pages well-before they’ve actually put anything in front of a user.  What’s worse is that they haven’t even begun to think about the interaction or visual design of the product yet.   That’s counterintuitive to me because it goes against the most important rule I have learned in my time managing products: The user experience is the most important part of any product. It’s not about ‘what it does.’  It’s about ‘how it does it.’

Now don’t get me wrong.  Some really forward-thinking product teams actually pay close attention to interaction design and visual design in their PRDs.  Some of them actually sketch out ideas and test them in front of users while building their requirements documents, which is a huge win.  If you are in that select group of forward-thinkers, you are definitely a step ahead.  But, in this scenario, there is an obvious question that we are left with: if you are actually beginning the process of product discovery (and doing real user testing), why are you using a document as the format to store your findings and insights?

The ‘aha’ moment: prototyping

When we look at all of the things that a specification is supposed to do well, it becomes clear that building a good one is a really tall order.  But when we combine the goals of communicating the needs of the product with actually validating/discovering the solution, an answer emerges: a high-fidelity prototype!

The beauty of a high-fidelity prototype is that it actually provides people with a realistic sense of the user experience of the product.  A good prototype describes the functionality of the application while leaving very little room for imagination.  High-fidelity, to me, means that the interface is clickable, but that the backend is not necessarily functional.  In most cases, it will be ‘stubbed’ or simulated.  While every single corner case need not be designed, the major use cases and features should be fleshed out.  After all, the idea is to capture the proposed user experience.

Imagine the kind of robust dialogue that can be had around a high-fidelity prototype versus a 50-page spec.  All of a sudden, these disparate stakeholders with very different frames of mind, will all (literally) see the same thing.  They will not only have a sense of what the functional requirements are, but they will see the proposed information architecture, user flow, interaction, and visual design.   They can actually understand how this product will come together and will have a much more robust understanding of what it means to them.  Also, they’ll have a single source of truth.  No need to dig through several email chains to find the answer to the question about a certain use case.  Just click through the prototype to find your answer.

If you think a high-fidelity prototype will help facilitate discussion and decision making around a product, just wait until you see what it does for your engineering team.  Beginning engineering without having fleshed out the user experience can be very costly.  Typical specs are so ambiguous that the really tricky product management decisions are faced only after the engineers have begun writing code.  Also, typical written specs leave so much open to interpretation that its very likely engineers will write code that doesn’t do precisely what you intended.  This usually creates time pressure for PMs and engineers.  The pressure generally causes them to make hasty decisions without user input and to re-write code without taking the time to be thoughtful.

But a high-fidelity prototype changes a lot of that.  The experience has been thought through much more significantly by the time the engineers begin writing (back-end) code.  Furthermore, there are few (if any) better ways to communicate the needs to an engineer than to show them precisely how the application is supposed to behave.  They can actually foresee some of the challenges ahead and can be much more thoughtful about the architecture.  That’s not to mention that their velocity is likely to increase because they have more clarity on what they are building.

Last, but certainly not least, is the effect on the user.  The great thing about using a high-fidelity prototype as your ‘source of truth’ is that you can actually put it in front of users to get feedback.  This enables you as a product team to ‘test early and often.’  And instead of taking all that extra time to ‘write up’ your learnings from user testing, you can just work with the interaction team to evolve the prototype.  Which means you can iteratively test it again and again until you’ve gotten the experience right.  You are able to test much more easily at this stage because the cost of change is so much lower than it will be further downstream.  Once you are ready to begin implementation on the prototype, no additional administrative work is needed (in the form of writing pages and pages).  Instead, you can just begin involving engineering in the discussions around the prototype and they can begin turning it into a real product.

Give it a whirl

If you’re a skeptic right now, that’s OK.  It’s likely that your existing process is painful enough that you’ll get open-minded about this sooner or later.   Next time you have the opportunity to create a product spec, you should consider working with your design team on creating a prototype instead of spending weeks or months writing a longer PRD.  Get that prototype in front of real users (and the rest of your product team and stakeholders) and use it as a catalyst for dialogue and decisions.  When it comes time to implement, bring your engineers into the conversation.  I think you’ll be pleasantly surprised at the result.