One of the best books on creating great products is Inspired: How to Create Products Customers Love by Marty Cagan. He covers pretty much every aspect of product management with compelling stories and examples. One of my favorite chapters is Reinventing the Product Spec; the subtitle is R.I.P. PRD (product requirements document). Cagan points out that “most specs take too long to write, they are seldom read, and they don’t provide the necessary detail, don’t address the difficult questions, nor contain the critical information they need to.” He further states that a product spec (specification) can serve as a false indicator to management and the product team that everything is proceeding to plan.
Cagan states (and I agree) that “the central responsibility of the product manager is to make sure that you deliver to the engineering team a product spec that describes a product that will be successful.” The spec must not only communicate the product vision but also the details of how to build the successful product. Cagan asserts that the only form of ‘spec’ that can deliver everything required is a high-fidelity prototype. While I agree that a high-fidelity prototype is the preferred method to communicate the product vision, most product teams do not have the time or resources to create complete, high-fidelity prototypes for every product.
Recognizing that the old-style PRD is largely ineffective in today’s agile world, but that a prototype is also out of reach for most product teams, here are four attributes that will help you communicate product vision in your specs:
- Visual: In the absence of a high-fidelity prototype, at a minimum your product spec must have high-resolution images (mock-ups or screen shots) of how the pages in the product will look. These images need to be written in a way that UI developers can create “pixel perfect” pages in the product that identically match the spec images. The ideal scenario is to have a user experience (UX) designer (or team of designers) that creates these images.
- Clear: Your product spec should link the visual representations to descriptions that detail what needs to happen. The spec needs to tell a story. I’ve started using a simple HTML template that shows the descriptions on the left pane with an indicator that points to the high-res images on the right. I attach the spec(s) to the applicable story in the dev sprint.
- Simple: Keep to the main points. Never add elements in your product spec that are not necessary to creating your product. Be clear and concise in your descriptions and visuals.
- Complete: Your spec needs to completely describe the new product (or version) the engineering team will build. It needs to describe the full user experience. It needs to represent the behavior of the software your engineering team will build. Keep it clear and simple, but make sure it’s complete.
Creating effective product specs requires a lot of work. You will have to iterate frequently and keep an open line of communication with the team. If you keep your specs visual, clear, simple and complete, you can communicate your product vision effectively and create great products.
The Product Management Perspective: Cagan makes the following statement: “The central responsibility of the product manager is to make sure that you deliver to the engineering team a product spec that describes the product that will be successful.” Take a look at your current processes and determine what you can do to improve the way you communicate your successful product to the engineering team.