Empower your team and product through detailed PRD (Product Requirement Document)

How to build great products with right context and execution while leaving enough room for creativity from the team.

The most crucial way to empower the team to make the right decisions and build the right product is by writing the perfect PRD (Product Requirement Document) , also called One Pager /Product Template /Product Specs .

Photo by David Travis on Unsplash

Fareed Mosavat, former Director of Product at Slack and former Technical Director at Pixar, says, “Great PMs direct their product, not manage it. They empower their team to make decisions, instead of dictating each decision.”

What is a PRD/Product Spec?

At its most fundamental level, PRDs are written by Product Managers that communicates what, why, and how a feature should be built. Typically , it has 2 parts , one for building the right context and other for execution details. A great PRD also comes with a third section i.e. FAQ section at the end to document all the decisions taken so far and the reasoning behind it.

Section 1 of PRD : Building the right context

A great Product Manager spends time to heavily communicate the critical background information the team needs to understand the problem space and make decisions through the life cycle of building the feature. A PRD should include the following :

• Define the Opportunity/Problem Statement — Describe the problem we are trying to solve in a few sentences along with reasons for prioritizing this feature right now. Sometimes solving for a particular problem could be more strategic than revenue generating. Any one in the team should be able to read this alone and communicate the value/opportunity of the product/feature.
• Support the Problem statement with the right Evidence — Leverage clear data to pinpoint the problem. The product KPIs and intent tracking helps support the problem statement. Knowing industry standards and metrics evolution can also help shed light on the evidence. Do not use descriptive language like adjectives. Cite your sources from any primary/secondary research.
• Build possible solutions and Goal through right Hypothesis — Build your case with a series of bullets that outline what would change in the world your idea was brought to life. Frame it as a bet or hypothesis and seek truth to falsify. Try to answer : “ We believe that [building this feature], [for these people] will achieve [this benefit]. We will know we are successful when [outcome from the market]”
• Build right feature set by focusing on right Target Audience — List the most critical customer for who you’re building the feature for. Try to find if specific segments of the audience needs different ability. The challenge with leaving your target audience generalized is that specific sub-audience attributes greatly change how you need to implement the feature. For example, a power user target audience likely wants a lot of customizability. In contrast, a casual user target audience generally doesn’t want to do any customization at all.
• Build empathy through Customer Insights — The primary purpose of this section is to create user empathy. The empowering way to write your customer insights section is to take the time to summarize the most relevant parts of your user research, feedbacks, surveys etc. into key themes, making sure to support each theme with direct customer quotes.
• Inspire and differentiate through Competitive Insights — This is a very important step to both understanding what market provides and leverage it as inspiration and using the same to create differentiation in the market. Read through competitor marketing manuals, try the product, read app reviews etc to understand how the best in class competitors solve for the customers and how should the team emphasize to differentiate on. The great PMs will also look beyond just their direct competitors for inspiration, at cutting edge companies outside their industry.
• Build focused outcomes through Success metrics — Setting success metrics up front helps you evaluate later on whether your feature really succeeded at its ultimate goal — improving some sort of product or business outcome. Define priority metrics (Metrics that you want to move with this feature), Deprioritized metrics (Metrics metrics you don’t care about affecting) and Guardrail metrics (Metrics that you specifically do not want to worsen as a result of feature implementation) to help the team with a smart trade off .

Section 2 of PRD : Building the right execution steps.

In this section, PM explains the solution space i.e. what exactly you’re building, and documents feature’s functional requirements, user experience, technical implementation, and other key details. The PRD should include the following :

• Outline feature functions and timelines Scope — Outline the list of functional requirements needed for the feature. The typical product practice is to write scope in full user story format, i.e. in the ‘as a [user], I want [functionality], because [reason]’. Make a note to state the obvious as well , else it can lead to engineering rework as well . However, for a great PM, the right balance between too prescriptive and too much detail is important. One other thing is to build vision during this process wrt to scope by being clear what is needed now, what is needed next and what is planned for later. This gives the engineering team the line of sight and will help build the right architecture for the product.
• Define and chart out what is a good customer Experience and flow : the user experience flow for the feature. Co-own this process with the design team. This has a significant on the customer experience by ensuring the information hierarchy and frictionless flow for the customer along with standing out with respect to the competitors. The most important part here is to define clearly what is the right customer experience for your product — is it more information, better performance or anything else.
• Outline the Implementation details — This is a big loop hole in the PRD for a PM. This is best left to the engineering team to decide on the BIG stuff like what technology to be used along with low level details like error codes. The part where PM needs to empower the team is by providing the most important clarifications which involves user actions and expected results. Rest details can be worked out closely with engineering team .
• Call out the Dependencies — Sometimes a feature rollout is supported by multiple teams or has external dependencies . In such cases it is important to call out the dependencies and timelines to ensure the correct timeline can be built and correct expectations can be set up.
• Chalk the Release Plan — The feature go-live schedule for users should ideally not be a big bang. Depending on the feature, you can either use A/B testing or Beta testing or even a soft Launch to avoid
• Track the right success and improvement 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. Future answers that you are seeking through metrics are primarily in 3 categories. 1- Feature Usage Improvements — How often is the feature being used? This helps you appropriately gauge how much user benefit you’d create by further improving the feature. 2 -Functionality Additions — Measure metrics that show customers intent to do something in the product. 3- User Experience improvements — Measure metrics that are key part of experience.

Section 3 of PRD : Documenting all decisions in a FAQ

In this section, the PM documents the major decisions that have been made over the course of the product spec’s development, and the rationale behind those decisions. You can also add a status in there against each decision incase something is work in progress. This section helps a great deal wrt avoiding additional ad-hoc meetings and bringing alignment without multiple repetitions.

Pro tip : The Do’s and Don’ts for a PRD

1. PRD writing is a non-linear process and keeps evolving over time, meaning you write first drafts for each section as soon as you have enough information, and then update each section as your knowledge evolves. The PRD evolution happens in phases from discovery to research to design and then implementation
2. At all stages maintain a balance between being too prescriptive (which is very time consuming ) and being too high level or open ended.
3. Be your own devil’s advocate at all stages and try to find three reasons why solving this problem is not the right thing to do.

For more smart ways of acing product management , follow me on medium ,LinkedIn or twitter