The Product Spec

Episode #6 of the course Product development 101 by Jeff Brunski

 

Today’s lesson is about a critical step in the product development process.

Having selected a product concept, it’s best to begin to define your product in a formal manner. This is accomplished in a document called the product spec.

The product spec establishes boundaries and guidelines for the people designing the product. It orients the team to the objectives of the product. It describes what it will do, as well as what it will not do. I like to say the product spec “draws a box” within which the development team can play. Constraints exist in the real world, and product developers need to know where to draw the line.

Understandably, some developers like to skip this step and begin prototyping and testing as soon as possible; after all, that’s the fun part. Writing a document is objectively less fun. However, writing a clear product spec can save an enormous amount of time and frustration down the road, especially as the number of people involved with product development grows.

Here are the key best practices when it comes to writing a product spec:

Make it collaborative. Multiple people—ideally, someone from every team involved in development—should participate in writing the product spec. This will promote cross-functional alignment from the start, resulting in better teamwork down the road.

Focus on benefits, not features. Product developers can fall into the trap of specifying features because, frankly, it’s easy. The problem with specifying features is that it embeds assumptions into the spec. It presumes that the feature delivers a particular benefit, when in actuality, in may not. Developers should care about the benefits the product delivers, not the features.

Make a “must have” list. Having said that, there are sometimes features or properties that “must be” included in a product. Make these crystal clear with a “must have” list, and differentiate these features from “would like to have” features.

Determine “what,” not “how.” Good product specs should detail WHAT the product should do, not HOW to do it. This is one of Nike founder Phil Knight’s key tenets of management, and it applies very well to product design as well. The “how” will be discovered in testing and prototyping.

Address the “why.” In addition to “what,” a good product spec addresses the “why” of a product. Explaining the why forces the authors of the spec to consider “benefits” and not “features.” It also helps provide context for the team, which can be very useful when it comes to making difficult decisions and trade-offs later in the process.

Include an elevator pitch. Add a very short (30-60 second) summary detailing your product and its value proposition. This will force clarity of purpose and vision for the product.

Don’t forget about, “Unlike our competitors…” This is a useful way to begin a sentence describing the product, since it forces you to clarify the brand or product’s differentiating properties. Include a number of these sentences in your spec.

Explain what it will not do. Itemizing what a product will NOT do provides more clarity than just listing what it should do.

Capture the current knowledge. Perhaps most importantly, the product spec is meant to be a living document. It captures the current knowledge, not eternal, infallible knowledge. As you proceed into the next steps of prototyping and learning, things will change, and the product spec should be updated to reflect those changes.

Speaking of which, it’s time to talk about prototyping…in tomorrow’s lesson.

 

Recommended books

The Product Manager’s Desk Reference by Steven Haines

Inspired: How to Create Products Customers Love by Marty Cagan

 

Share with friends