Communication has changed significantly in the past several years. Twitter, Facebook and other social media have driven personal interaction to short, succinct statements that force us to be brief and to the point. One of my colleagues on the engineering team recently told me “if you can’t write your spec in 140 characters, I can’t implement it.” Though I’m sure he said it in jest, he got me to thinking about effective communication. Effective communication is the key to creating great products (and services).

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:

1. 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.
2. 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.
3. 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.
4. 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.