How To Write Empowering Product Specs
Building great products is like creating a great movie.
In each case, there are many specialized people, each serving distinct roles, being orchestrated towards a unified delivery of a final end product.
For example, in movies, some cinematographers create the visual look and feel, editors that assemble shots into a finished film, and directors that oversee the production.
During the product development process, there are the designers who help create the specifics of the user experience, the engineers who bring the features to life, and the Product Managers who oversee it all.
And similarly, it turns out that the same principles for creating great movies are the same for creating great products.
The most obvious illustration of this is the product spec.
Product specs are written documents that communicate what, why, and how a feature should be built.
That is a lot of information in one document. While our complete program on Mastering Product Management helps product managers master the full suite of tools at their disposal, we’re sharing a slice of it here.
With that, let’s break down exactly how to write an effective product spec.
What we will cover:
What Is A Product Spec?
At its most basic, product specs are the written documents that communicate what, why, and how a product feature should be built based on the overall product strategy.
Product specs typically have two major parts to them, Context and Implementation, with a FAQ section at the end.
Context provides background information for why you’re building a product feature, who you’re building it for, and what principles everyone should follow while building the feature.
Implementation explains what exactly you’re building, and documents your feature’s functional requirements, user experience, technical implementation, and other key details.
The last section of the product spec, the FAQ, tracks the major decisions you’ve made on the product feature over the course of development, and the rationale for each of those decisions.
Great Product Managers write their product specs in the same way that the best movie directors direct their movies.
They outline the key product decisions but encourage creativity and decision-making from their team regarding everything else.
Fareed Mosavat, former Director of Product at Slack and former Technical Director at Pixar, says, “Great Product Managers direct their product, not manage it. They empower their team to make decisions, instead of dictating each decision.”
How To Write An Empowering Product Spec
Great Product Managers write their product specs at a level of detail that is neither too prescriptive, nor too high-level; it is empowering.
They are empowering by effectively conveying Context and keeping Implementation ownership to just the most important details.
Empowering Context
First, let’s talk about how to write empowering detail for each section in the Context part of the product specs, namely:
Opportunity
Target audience
Customer insights
Competitive Insights
Success metrics
Effectively writing these product spec sections will create leverage by giving your team the critical background information they need to make great product decisions.
Your specific product specs template might have slightly different names for each section or group the information in another way, but the information you need to convey and what empowering detail looks like will remain the same.
In Opportunity, you should explain not just what the problem you’re solving is, but also why you are prioritizing solving this feature.
We suggest explaining your prioritization reasons using your 4D roadmap’s four lenses since that empowers your team to understand what goal they are primarily solving.
Target Audience is next, which explains who you’re building the product feature for. Here, you should be naming the specific sub-audience your feature serves.
Specifically, in your product spec call out the key ways in which the target audience differs from your other audience sub-segments to better empower your team.
For example, knowing whether you serve power or casual users will help the team figure out whether to add high-feature customizability or not.
Then, there are Customer Insights, where you synthesize themes across user research and support those themes with direct quotes where possible.
An effective customer insight on your product spec is often two things:
Counterintuitive, meaning the insight differs from your default assumption, and
Material, meaning it significantly changes the user problem you’re solving or how you build the feature to solve it.
Next, there are Competitive Insights, where you summarize your key learnings from competitive research.
Writing this in an empowering way means identifying how to differentiate their product in implementation.
This can be helped by looking beyond just direct competitors, but also at cutting-edge companies outside their industry.
Then there’s Success Metrics, which clarifies what the primary outcome metrics you are trying to improve are.
To empower your team to make smart trade-offs, explicitly define a very narrow subset of metrics to optimize for.
Then, to make trade-offs even easier, call out deprioritized metrics, or metrics you don’t care about affecting, as well as guardrail metrics, or metrics you specifically do not want to worsen as a result of feature implementation.
Empowering Implementation
The Implementation section of your product spec should include:
Scope: the list of functional requirements needed for the feature.
Experience: the user experience flow for the feature.
Implementation details: the technical details behind the feature.
Launch plan: the feature go-live schedule for users.
Investigative metrics: the list of metrics that need to be instrumented as part of the feature to help you answer questions you might have in the future about it.
First in Implementation is Scope, which details the individual functional requirements needed to create the full feature experience.
To create an empowering product spec , write only the functionality needed and don’t micromanage exactly how the functionality needs to work.
Additionally, make sure to call out future functionality you may want to be implemented as part of the feature, so engineering can properly plan for it.
Then, for Experience, which communicates what the user experience should look and feel like, and have the design team fully own writing the Experience section.
Still be closely involved, giving input and stating key design goals, but empower the designer by having them ultimately own the wireframes and specific micro-decisions.
Still be closely involved, giving input and stating key design goals, but empower the designer by having them ultimately own the wireframes and specific micro-decisions.
Next, let’s move on to the Implementation Details. These are the technical details that impact the feature’s implementation.
Define technical details only to the extent that they significantly alter the user experience, so that engineering managers have the space to make smart decisions on the rest.
For Launch Plan, explain the roll-out process and rough timeline for the feature’s release to allow engineering to plan for appropriate amounts of server load.
Some examples of common launch plans outlined on a product spec include:
A/B testing
Beta testing
Soft launch
Lastly, there’s Investigative Metrics, where you detail what metrics need to be instrumented as part of the initiative’s implementation.
This ensures that engineering can properly plan for capturing certain data to help you answer future questions as they arise.
Most people don’t think about this section at all, so simply planning ahead and thinking about what questions you might want to answer, and the metrics you need to answer them is already empowering.
Empowering FAQs
As a refresher, FAQ is the closer section to the product spec, which covers a list of key decisions you’ve made over the course of the feature development and the rationale for the final decision.
Typically, Product Managers might not think to include this at all. Instead, as questions are raised about certain feature decisions, they simply address them in ad hoc meetings.
The problem with this is that at a certain point, they end up spending more time repeatedly defending decisions ad hoc than they would save by simply documenting their decision rationale.
So to avoid repeating yourself, or to at least limit how often you need to, create a FAQs section where you document contentious decisions with rationale on why you’ve made a specific choice.
Your rationale doesn’t have to be an extensive essay to conclude your product spec sheet, but it should convey the key data points that led you towards one decision or another.
Remember, Product Specs Are Iterative
Writing these sections is iterative, meaning you write first drafts for each section as soon as you have enough information, and then update each section as your knowledge evolves.
Specifically, you typically start writing your product spec and iterating on Scope, Experience, and Implementation as your research phase tails off, and as you enter your design and implementation iteration phase.
Towards the end of this phase, when you’re more certain about the product feature and start doing Reviews, you’ll start writing and iterating on the Metrics and Launch Plan.
Finally, after each major decision you make, you’ll be updating your FAQ to document what decisions were made and why.
To summarize, Great Product Managers write their product specs in a way that empowers their team to make decisions, giving them both sufficient implementation space and contextual information.
In other words, like a great movie director, they direct the creation of their product, setting only overall direction and creating space for creativity, instead of trying to control all the details.
P.S. This content came directly from our Mastering Product Management program built by Sachin Rekhi. Apply today to unlock the full program, including a product spec template!