Things get out of hand when working in a fast-moving startup or organization of any scale that believes in fast product iteration cycles or experimental iterations on products. If you are part of such a setup, you must have seen problems such as

1. Miscommunication, misunderstandings, and misalignment among team members that often result in wasted time and effort.

2. Product requirements keep changing or evolving beyond the initial scope, leading to delays, frustration, compromised product quality, etc.

3. Inconsistent or poor quality end-user experience as all the possible edge and corner cases from a product perspective are not explored or solved correctly.

Many other problems arise when there is no method to the madness. At a high level, it all results in an output that neither solves the user's or business problems well.

After building multiple large-scale products and profitable companies over the last decade, I have realized that a structured approach and sufficient planning go a long way in solving these problems. If one product owner is hell-bent on solving it by thinking deeply, they only need a way to structure the solution, and most problems disappear.

This blog post will give you a template for defining your product requirements that has worked well for me. It will help you structure your solution better. I have used it to describe and build several products that solve complex problem statements, so it's battle-tested.

Since I worked mostly with startups, I seldom had access to a "product management team", and I learned the hard way that the best way to avoid problems, as mentioned earlier, in the long run, is to structure the product problem statement and the What, Why and How of the solution well before writing a single line of code.

This template will help you if you are a product manager, engineering manager or developer.

Before I share the template, let me share a few pointers on how to use it. The idea is to avoid ambiguity while using this template.

1. Define a single product requirement document (PRD) for each product. If you are extending or changing the product, make changes in the same document. Don't create a separate doc for new features or modifications to the existing system. It will cause issues in the long run.

2. Most tools where you write the PRDs have a versioning system that enables you to fetch the document's historical version if needed. Please ensure your tool has this functionality, too. If not, do a manual backup, or if you are a developer, you can always use a Git repository to do versioning of the product documents.

3. If your product depends on an existing product or system in your organization, mention the links, constraints and considerations of the older product in the new PRD.

4. Write down the considerations you took into account for a part of your solution, especially if your solution is experimental- a template of such considerations can be - “I took this decision to do <X> like <Y> because of <z> reason. It will help you iterate on the solution better.

5. Be as detailed as possible. The devil is always in the details. The template below describes what you are supposed to write at a high level. But it doesn't dictate what level of detail you can go up to. That's your choice. And trust me when I say this: the depth of your thought would count. The depth of your solution will contribute to the long-term success of your product.

If you follow the points mentioned above religiously, you will end up with a PRD document that efficiently solves 99% of the communication, scoping and product quality problems.

Product requirements template

[Product Title]​

Description: What is it?​

A very high-level description of the product that can be sent to a non-product person or techie to understand quickly. Think of it as a pitch for the product/feature.

Problem: What problem is this solving?​

Specify why we are building this product/feature. Define who is facing this problem. "Who" can be a user or another actor in the system. Define their persona.

Why: How do we know this is a real problem and it's worth solving?​

Add the data or assumption that pointed you in this direction. If this was a requirement from another team/function, write that note here.

Success: How do we know if we've solved this problem?​

How will you measure the success objectively? It can be done using metrics tracked in our analytics tool or data warehouse. Define those metrics in detail.

Audience: Who are we building for?​

Define the persona (in detail if required). It will also help us better target the audience within the product and retention activities (like notifications, etc.)

What: what does this look like in the product?​

1. Key feature - describe the features in as much detail as possible.

2. User journeys - should cover all possible states of the user journey

3. Figma link

4. Product copy for all the places

5. Out of scope

6. Future considerations - Optionally list features you are saving for later. These might inform how you build now.

7. Constraints and dependencies - explore all the limitations and dependencies possible. Examples - can be tech constraints, constraints because of existing features on the product, etc.

8. From a product perspective, list the edge/corner case scenarios and their solutions - for example, the user didn't do X but did Y. It resulted in a Z state in the product journey.

How: What is the experiment plan?​

If this feature/product is an experiment, define how the investigation will occur. How will it be controlled (for example, start/stop using a feature flag)?

When: When does it ship, and what are the milestones?​

Divide the project into phases, each with milestones (or all stages can work towards a single metric/milestone). Add tentative dates next to them.

Open questions (optional)​

Write any questions on top of your mind while writing this doc or any of its versions. Write the questions in the raw form with your thought process or assumptions. The idea is to revisit it later.

Non-visual product requirements (optional)​

Explore all the non-visual production requirements needed to make this a success—examples - Push notifications, emails, WhatsApp messages, etc. Explore the product copy aspect of this as well.

Third-party tools​

Mention if there are any dependencies on third-party tools and services (like Firebase, amplitude, etc.). Ensure they have been explored in depth in PRD.

Is seeding required in this product? (optional)​

Explore whether any manual intervention from growth/content or any other teams is required in this product/feature.

Go to market (optional)​

If this is a new product/feature being shipped and a specific GTM is required, then detail it in this section. Explore the risks and risk mitigation strategies if needed.

Create a launch checklist to ensure that everything is ready before going live.

Glossary​

Define new or specific terminology in this document to remove ambiguity while communicating.

Ending note

I hope this template helps you as much as it has helped me. If you have any questions, doubts or suggestions, please feel free to contact me on Twitter, Linkedin or Instagram. Do share this post with your friends and colleagues.