How to write an effective Product Brief

Try this three-part Product Brief to guide you through the solution-definition and delivery phases of your new feature or product. Template included in this blog.

A while ago, I noticed a pattern occurring in the Product team I worked in. Despite our many years of experience in product development, when deadlines were tight our approach to product validation would suffer. We’d rush to deliver solutions and would often find out after costly hours spent in development that we were carrying big value and usability risks. This drastically reduced the impact of the work we were doing.

My solution to this problem was to create a template for Product Managers to use during the solution-definition and delivery phases, enabling us to validate our solutions at pace rather than rushing into development with assumptions and risks. We’ve now been using this template successfully for a couple of years, and I wanted to share our approach.

What a Product Brief is (and what it isn’t)

The Product Brief is used by Product Managers in the solution-definition and delivery phases. While traditional Product Specifications will help you detail WHAT we will build and HOW we will build it, the Product Brief goes a step further and asks WHY should we do it? It will enable you to:

1. Deliver outcomes at pace, by identifying the right amount of discovery needed for your product (time spent in product discovery has an opportunity-cost associated with it).
2. Reduce time wasted on poorly validated and badly-planned products.
3. Provide clear documentation that can be shared and commented on by your teammates and stakeholders.

The Product Brief will allow you to list all of your assumptions and start validating them. It is the manual for your product discovery.

A Product Brief does not contain all of the answers. It is instead, a plan to get to the answers. It should be written at the start of your solution-definition phase (after you’ve completed your opportunity discovery and definition). At this point, your idea will still be largely made up of assumptions. The Product Brief will allow you to list these assumptions and set about validating them. It is the manual for your product discovery.

A Product Brief is not a technical specification. Technical involvement at this point should be light touch. From a technical perspective, the important point the Product Brief is trying to address is feasibility. By this I mean, do you have the infrastructure, resources and skills to build your idea? While technical involvement is light touch at this point, I highly recommend encouraging your squad to get involved in product discovery.

A Product Brief is not a Business Case, and does not constitute a commitment to build. However, it can be used to generate alignment. In my experience, the Product Brief is a great way to generate early excitement and alignment. We create our Product Briefs in Confluence and tag colleagues so that they can read our Product Briefs. We also have an integration with Slack that notifies us each time a new Product Brief is published. A note that it is important to form the brief in such a way that your stakeholders are clear that it is a discovery plan rather than a firm commitment to build.

Our Confluence integration in Slack allows us to keep up to date with new Product Briefs and Test Plans

The Product Brief Template

The elements I will now describe are the cornerstones of all of my Product Briefs. I’ve honed them over time thanks to guidance from discovery coaches and product thinkers such as Marty Cagan, Teresa Torres, Cindy Alvarez, Steve Blank, Melissa Perri, Alex Osterwalder. I was also lucky enough to attend the Marty Cagan / SVPG Inspired workshop — and I owe a great deal of the shape and form of this Product Brief template to principles he discussed in this workshop.

Now, on to the brief! And if you don’t have time to read, here is the Product Brief template.

Our Product Brief template in Confluence

Section 1: Defining the opportunity

This first section should be done at the inception of your idea, and will form your plan for rapid validation and discovery. Section 1 is as follows:

• Define the objective of the product. Here you should describe how the product will drive forward the company’s strategic goals.This usually comes from a larger business objective. For example, for many companies this might come from an OKR (Objective and Key Results).
• Set the success measures. You’ll need to define what the goal is for this product, and your measures for success. It’s easy for projects to lose their way and become bloated with additional features or technical complexity added by stakeholders. Your success measures will allow you and your team to be ruthless with your efforts, only prioritising activities that will have a tangible impact on the goals you’ve defined. Your success measures will also allow you to retrospectively review the impact of your work.
• Give background on the product. In this section there’s room from some blue-sky thinking. I suggest summarising your idea in one to two paragraphs, as if you were writing a PR doc for an external audience. Set the scene for the product — why should your customers and stakeholders be excited about? Just remember again— don’t fall in love with an idea you haven’t validated.
• Define the problem you are solving, and for who. Here you should describe the specific customer problem you are trying to solve, as well as any evidence you have to support this problem. You should also describe what customer segment you are solving the problem for. If you have personas — use them!

Section 2: Highlighting the risks and assumptions

For me, this is the most important part of the whole brief. The work done in this stage of the product process allows my team to have maximum impact with minimised effort, as we only build products we have strong confidence will hit the market well. Hours spent in the discovery phase can save weeks in development time.

The work done in solution-definition and validation phase of the product process will allow your team to have maximum impact with minimised effort, as you’ll only build products you have strong confidence will hit the market well. Hours spent in the discovery phase can save weeks in development time.

Summarise the risks. In this section, you should summarise the risks and / or assumptions that need to be validated before you spend time and money developing the product. Perhaps you’re concerned that the product might have a negative impact on a particular customer segment, or you’re not sure you have the technical skills to build the product? These should all be flagged as risks and validated as quickly as possible. I categorise my risks into Value, Usability, Feasibility and Business Viability, using the risks framework developed by Marty Cagan. For each risk, I assess the potential impact (High, Medium, Low), based on what I already know about that specific risk. Giving each risk an impact level highlights those that need to be validated first and most rigorously.

The Risks Section of our Product Brief template in Confluence. Using Marty Cagan’s Risks Framework.

Section 3: Defining the solution

Once you’ve adequately validated your risks, you’re ready to start defining your solution.

• Gather your requirements. When writing requirements, we should always be thinking about the minimum requirements needed to mitigate our key risks. This is a useful document on the different forms an MVP (Minimum Viable Product) can take.
• Gather your designs. By this point you should already have low-fi prototypes that have been validated with potential customers from outside of your office. Link these in the brief (for reference) as well as your high-fidelity designs.
• Detail what you need to measure. This is a new section I’ve added recently. This section is for you to detail what product metrics you want to be able to measure, and why. Work with a Product Analyst to ensure that the analytic frameworks you have in place cover these measurement goals. This section is one of the most critical of the Product Brief. It ensures you’ll be able to understand the impact of your product, and understand optimisations that need to make. Don’t get caught in the “we can’t measure it” trap.

Don’t get caught in the “we can’t measure it” trap.

Final Thoughts

The above is a guide based on my own experience over several years of working on technology-enabled products, and the Product Brief I’ve described here will likely evolve over time as I continue to hone my approach. Regardless of this, the principle of the brief is unlikely to change —

• Rapid upfront validation of your solution will save you time, money and pain.
• Formalising your approach to validation will help make it second nature.
• Documenting your approach and findings will help you showcase your work to the rest of your organisation.

Free Product Brief template

View and download the Product Brief template here.