How to Write a Feature – Tips and Guidelines for a Product Requirements Document

07/05/2023 – As a product manager, you are often tasked with creating features that will add value to your product and meet the needs of your customers. This usually involves creating some form of requirements document. However, creating a feature that is both user friendly and effective can be a challenging process.

In this article, we will discuss the key elements that make up a good feature description, and provide guidelines for creating a feature that meets your customers' needs.

In today's fast-paced business world, creating any type of product usually requires meticulous planning and documentation. This is where a Product Requirements Document (PRD) comes in. In many companies and engineering organisations, a PRD is considered an essential document that must be created before any feature is built. It serves as a blueprint for implementation. The best product managers are masters at creating such documents. But as with most parts of the PM's job, there's no one way to do it. And yet there are general principles that, if applied correctly, will improve your requirements game.

First things first: No good PRD without clear writing

Clear and concise language ensures that the development team understands the requirements and specifications for the product. A well-written PRD can help streamline the development process and avoid costly mistakes or delays. Consider cleanly written text as important as clean code.

A good place to start is with what is known as classical writing. This involves organising ideas logically, putting the most important information at the beginning of sentences and using transitions to link ideas.

A compelling title and product overview

The first step in writing a good feature is to come up with a compelling title that clearly describes what the feature does. Avoid using abbreviations or jargon that only subject matter experts would understand. Instead, use simple, concise language.

Once you have a title, write a description that tells a good story. The best descriptions are user-centric, meaning they focus on the user's needs and how the feature will benefit them. It should always provide an overview and context for the issue at hand.

Consider using a user story format such as "As [user], I want [feature] so that [benefit]". For example, let's say you're building a mobile app for tracking fitness goals. A good user story for a new feature might be: "As a user, I want to be able to track my daily water intake so that I can stay hydrated and meet my overall fitness goals."

Outcome-driven thinking

A good requirements document should always be outcome-driven. Just because you can build it doesn't mean you should build it. Therefore, the PDR must always include the context and the reason why we need to implement this feature. What business value will it bring? What value will it bring to our customers?

To know whether a feature is effective, you need to define how you will measure its success - ideally working backwards from the outcome you want it to achieve. This could involve tracking metrics such as user engagement, retention or revenue. By setting clear metrics for success, you can monitor the impact of the feature and adjust if necessary. This is often done using a 'benefit hypothesis'.

Using outcomes rather than outputs is one of the most important components of effective feature development. It ensures that your features are aligned with your overall product goals and customer needs. By defining clear outcomes for each feature, you can ensure that they add value to your product and help you achieve your business goals.

For example, let's say you're developing a mobile food delivery app. One of your key business goals might be to increase revenue by attracting new customers and increasing order frequency. To achieve this outcome, you might create features such as personalised recommendations, a loyalty programme or a referral system that incentivises users to share the app with their friends.

By defining clear outcomes for each of these features, you can ensure that they are aligned with your business goals and customer needs. For the personalised recommendations feature, your outcome might be to increase the frequency of orders from existing customers by 10%. Based on this, you can measure the impact of each feature and adjust your development plans accordingly.

Outcome-driven development also helps you prioritise features based on their impact and feasibility. By identifying the outcomes you want to achieve, you can prioritise features based on their potential to help you achieve those outcomes. For example, if your goal is to increase customer retention, you might prioritise features that improve the customer experience, such as a streamlined checkout process or faster delivery times.

Prioritising and roadmapping

When creating features, it is important to prioritise them based on their impact and feasibility. By prioritising features based on their business value and customer impact, you can ensure that your resources are focused on the most important areas. Common methods for prioritising what's next are Cost of Delay or Weighted Shortest Job First (WSJF). Whatever your organisation uses, be sure to include all relevant context and input for the prioritisation method used.

Technical documentation and dependencies

If your feature includes technical specifications or requirements, you should include detailed documentation. This should be accessible to everyone working on the feature. This could include information about APIs, databases, security protocols, or other technical details that are essential to the development and implementation of the feature. A very important aspect here is dependencies. You should identify any external dependencies, such as APIs or third-party software, that are required for the feature to work properly. Otherwise, unknown dependencies can cause huge problems down the line. There are few things more annoying to a team than having to wait for an external party to deliver.

Finally, it's important to identify any stakeholders or third parties that will be involved in the development and implementation of the feature. Typical questions to be answered include who needs to be informed, or who is a subject matter expert for additional input.

The Importance of Structure

A well-structured PRD helps to ensure that all necessary information is included and presented in a logical and organized way. The KISS and DRY principles commonly known in programming are applicable here as well: Don’t Repeat Yourself plus Keep It Simple & Stupid. And it’s good practice to start with why. Bringing it all together, the structure of a feature description or product requirements document could look like the following.

Product Overview - This section provides an overview of the product and its objectives. Always give context why this feature shall be implemented. It should include a brief description of the product, its target audience and the business objectives it is intended to achieve.

User Requirements - This section outlines the needs and requirements of the target users. It should include information on user demographics, behaviour and goals. Many teams like to use the "user story" approach here: As [type of user], I want to [do something] so that [some kind of need or want] is met.

Functionality - This section outlines the functionality of the feature. Based on how your team works, add wireframes or mockups of the product interface and it's limitations to this section.

Technical Requirements - This section outlines the technical requirements of the product. It should include information on hardware and software requirements. It should also include any issues that may affect the development of the product. Name all known dependencies here.

Schedule and Budget - This section outlines the schedule and budget for the development of the product. It should include information on the expected launch date and the resources required to complete the development process.