Questionable use of stock photography aside, Colin Lernell’s Is the Product Requirements Document Dead? A Debate. brings up some interesting points. I’ve long argued that if you do it right, a good “product spec” is essential to successful product management and development. We’ve come a long way since the original concept of a 45-page PRD that no one reads (not even the person who wrote it). The format has evolved as we’ve grown accustomed to leaner development processes.

One of Colin’s suggested alternatives to the dreaded PRD is what he calls an MVPRD. I don’t like the term (the overuse of the MVP concept makes it all but useless these days). But the approach is one I agree with:

Write your first MVPRD in a short, limited amount of time (just enough to communicate to your team and start work) to avoid bloat. As you move toward or through development, meet with your team frequently to assess and iterate on what should go into the document and what should be taken out. Remember to keep it lean and that your intent is to figure out what you need in the document and if you need it at all.

Our product specs at Postmark follow a similar journey. At the beginning of a project I start a new spec document from a template in our wiki. I fill out as much of the basics as possible, which in our case consists of the following:

• Basic metadata like who the team is, links to technical specs, etc.
• The job story.
• A stripped down version of Marty Cagan’s Product Opportunity Assessment framework.
• Known dependencies and risks (such as customer support and back-office systems).

We use that information for our team kick-off call, and then we start filling out the rest of the document as we go. We also go back and make changes as we get further down the road and make decisions. We have three main sections for this part of the document:

• The solution overview provides a broad description of how we intend to solve the problem we identified in the Product Opportunity Assessment
• Sketches, Wireframes, and Prototypes links to the the initial design assets we create, in whatever fidelity is right for the size and scope of the project
• Final design has the final assets that are needed for implementation. In our case this is most often a completed front-end.

The important thing to remember about this fluid version of a product spec is that it is not a document you write from front to back at the beginning of a project and then never look at again. It’s also not something that’s every really done. It’s a document that starts small and that you keep working on as you go.

The benefits of doing it this way is that it not only helps you document all the little decisions you make along the way as you build a product, it also builds up organizational knowledge to remind you of why the team made the decisions they made. Because you will forget otherwise. So if you’re developing without a blueprint and feeling some pain and chaos, give this approach a shot. It might just provide the relief you need.