A note for new folks: This post is part of a monthly Sunday series on my notes on technology product management (this is what I do for a living). You might notice that these posts often link to older posts in the series on LinkedIn even though they are all available on this blog. That is intended for folks who only want to follow future product management related posts. Finally, for all those of you who don’t build tech products for a living, I believe many of these notes have broader applicability. This post, however, may be an exception because of its “inside baseball” nature. :)
We’ve covered the following in this “Notes on Product Management” series so far –
—
Today’s post will take us to the one of key pieces of the “Problem Solving” part of Product Management – How to write a good product spec.
In a conversation some time back, a chef explained that baking bread was among the biggest challenges he faced as a chef. He explained that every piece of bread he baked was a summation of many hours of effort and an obsessive focus on detail – all of which showed itself in the final product.
On the face of it, it seems like an easy enough task to bake a good piece of bread. But, getting it to “good” and then to “great” – that takes something else entirely. Japanese sushi chefs are known to speak similarly about rice.
And, I think product managers ought to think about product specs the same way. :-)
A Product Manager’s Bread
The ability to write product specifications is listed as a basic skill in every job posting for a product manager. Despite how commonplace it is as a skill, getting it right consistently is no mean feat.
As in the case of baking good bread, the product spec is less about the document itself and more about the work that precedes it. To understand this, it is worth understanding the costs involved in the product development process.
There are 3 important takeaways from this illustration of costs.
First, problem finding is the cheapest stage of the process. Every good product needs to pass 3 tests – value, usability, and feasibility. Of these, figuring out if the product is valuable is the least expensive part of the product development process. This is the “problem finding” stage and involves getting to a watertight problem statement and list of hypotheses that we want to test. This is typically done by combining user behavior insights and data from existing products or from lightweight tests that generally requires minimal (if any) code.
Second, the product spec is the crucial step that marks the a shift in focus from solving for value to solving for usability and feasibility. The product spec is the moment we say “yes, we have found a valuable problem that is worth building a product for.” This, then, leads to the more expensive stages of the product – designs, tech designs, development and go-to-market.
Third, the product spec, thus, is as much about what precedes it as what lies ahead. A good product spec is as good about providing clarity on the “why” behind the product as it is about the “how” (principles) and “what” (user stories).
Elements of a good product spec:
Building on what I’ve laid out above, I believe the following are the elements of a good product spec –
While I expect to cover topics such as “principles” and “success metrics” in future posts, an article on product specs would be incomplete without covering user stories. There are many good resources on how to write them. My preferred format tends to be a user story followed by a few bullets that lists the acceptance criteria that articulate how the product is meant to work. Each of these bullets would have a priority (which can also be set at a story level) so we know what will get built first. Below is an example –
As a user, I want to be able to take pictures when I’m sending a message to a friend
You will find better resources on how to frame user stories and acceptance criteria on the web. The key takeaway, however, is to make sure you write them. This is a lesson I’ve learnt repeatedly – start with the user story instead of just rushing to describe the feature. Writing out the story always helps provide better clarity on the problem we’re trying to solve.
More crucially, it provides a vehicle for the team to share better ways to solve the problem and suggest better acceptance criteria. That alone makes the exercise well worth the effort.
These elements will help us fix issues and holes in our thought process faster. The sooner we fix these issues, the less expensive they are to the team and organization. That, in turn, means we can transition smoothly to the problem solving and go-to-market phases of the product development process.
3 truths about product specs
All this brings me to the final section of this post – 3 truths about product specs.
(1) A product spec is a communication tool – there is no one way to write a good one: While this post is about writing good product specs, a large portion of the post was dedicated to understanding the importance of writing them and laying out the elements of a good spec. That is because a product spec is a communication tool that ideally brings clarity and alignment within the entire product development team on building a product that is valuable, usable, and feasible.
It is natural, then, that different teams have different communication styles as a result of the personalities involved and the type of products built. For example, a highly technical back-end product will require a different flavor of spec versus the one I’ve laid out above. Similarly, a tech lead and designer who thrive on finding edge cases will need less detail on the acceptance criteria than others who don’t. Find what works for you.
(2) A great use of a product spec is to solve for value before solving for usability and feasibility. If there is one theme from all of the posts in series that you should take away, it is the importance of solving for value. Take the time to get the problem statement and hypotheses right – this is the value in good product management. If your planning process forces you to write specs in a hurry, fix that planning process (more on that in another post).
(3) Shipping a good product spec is like shipping a product – it requires iterations. Involve the entire cross functional team early in the problem finding process, use their feedback to better articulate your problem statement and hypothesis, get feedback from peers and teams who are impacted by your products, and keep iterating on the user stories till you have everyone aligned on the spec.
Good specs and great specs
I’ve repeatedly emphasized the word “good” over the word “great” with respect to product specs in this post. That’s because I’m not sure if we can ever write a great product spec – at least not off the bat.
A product spec is an artifact of the product development process that is in service of solving a valuable user/customer problem. To the extent a good product spec helps create a great product by providing the right level of clarity and alignment within the team, we can call it a great spec.
But, the meta point is that a great product spec shouldn’t be the goal. Building a great product and a great product teams are worthier goals to aspire for. Just don’t let a poor spec get in the way of that.
