Re-designing the Product Briefing Document from the Ground Up 👷🏼‍♂️

At ucreate we constantly challenge and re-evaluate our processes for building great products for our founders. As a result of scaling our organisation over the last year, our communication overhead has increased.

Due to this increased communication overhead, we needed to re-think how we could improve communication, product workflows and handover documentation across our ever expanding teams. We also had to factor in the challenges of multiple, distributed offices, which adds its own unique set of challenges.

In the early stage of your company, you don’t need that many processes because people can simply talk to one another. As a company scales and starts adding multiple teams, you need more formal ways of communicating across teams and to do that you need to start building repeatable processes — Hiten Shah

Whilst researching how other early-stage startups communicate their product vision and proposed features, I found a great podcast episode from Drift discussing their “one-pager” document.

Side note:💡Drift call it a One-pager — AKA Scope of Work (SoW), Product Spec, Product Requirements Document (PRD) or in Intercom’s case ‘The Intermission’.

After listening to the podcast, I thought I would have a shot at creating my own document. Taking onboard our product principles, I created a template that would work for our Product Managers and our remote development teams.

In this post, I have put together an explanation of our Product Brief and also provided a free template for you to download.

So what is a Product Briefing Document?

What it’s not, is a description of what you’re building, a list of requirements or a list of features. Too many people make the mistake of quickly assigning easy work items to their teams without involving them from the outset, listening to their suggestions, points of view or giving them the full product vision.

It’s extremely important everyone involved in each product team has a voice at the planning stage. Too many people are reluctant to speak up about their reservations during the all-important planning phase. By making it safe for objectors who are knowledgeable about the undertaking but worried about its weaknesses to speak up, you can improve a project’s chances of success.

As a Product Manager, this Product Brief helps frame, scope and communicate the customer problem to the team.

The goal of the Product Brief is to have a shared understanding of what we are building and why.

6 sections of the Product Brief

  1. Background and context
  2. Goals
  3. Risks and constraints
  4. Timebox
  5. Concepts and references
  6. Retrospective

Side note:💡The audience, and the reader, aren’t necessarily you, it’s your team (engineers, designers, stakeholders, CEO’s, founders etc).

1. Story 📝

Use the Jobs to be Done (JTBD) framework so you don’t just think about how it would be easier for somebody to achieve x in the product — but instead think about it in terms of what their ultimate goal is.

When _____ , I want to _____ , so I can _____ .

For example: When a new customer signs up to my platform, I want to be notified via email, so I can reach out to them.

2. Background & Context 👩‍🏫

Provide some insight about your users (persona types) and the requirements that lead to the JTBD.

Include direct quotes from customers, visuals, the current experience right now and why it’s difficult or needs improving. This will help you demonstrate to the reader the context around the story that you’re telling.

3. Goal(s) 🏆

For us and our individual teams, we pull out the particular product objectives and relevant key results to ensure we aren’t straying from our company and product OKR’s.

4. Risks and constraints 🚧

Research conducted in 1989 by Deborah J. Mitchell, of the Wharton School; Jay Russo, of Cornell; and Nancy Pennington, of the University of Colorado, found that prospective hindsight — imagining that an event has already occurred — increases the ability to correctly identify reasons for future outcomes by 30%.

Flesh out any constraints you might have. Do you have particular legal or technical parameters to work within? Are there any risks that you can foresee?

Be mindful of the 3 main product risks — desirability (do our users want it), feasibility (can our team actually make it) & viability (does this make business sense).

You might not know all of the above at the time of writing your doc, but this is a live doc so keep adding to this section after the engineering and design team have fed back.

5. Timebox ⏰

We typically work in 1–2 week sprint cycles depending on the complexity of the work. If we feel the element of work is going to take longer than 2 weeks we try to reduce the scope or break the work down into subsequent phases.

Again this may change after you have discussed it with your wider team. Keep updating it as you get more info/ feedback.

6. Concepts and references 📎

  • Examples of similar features or products that you learnt from
  • Teardowns
  • User context
  • Persona types & research
  • Quotes, pictures, Slack messages, emails, articles, diagrams etc.

Basically, any detail that you have that could help provide more context for your team. Keep this as concise as possible with some bullet points and hyperlinks — you don’t want to overwhelm your team.

7. Retrospective (AKA Post-mortem) 👨‍👧‍👦

⚠️ This section should be complete once the solution/ feature has been shipped and in the hands of users.

This is where we capture our learnings, review section 3 (Goals), and discuss how we can do better next time. It’s also a good opportunity to review your premortem risk and constraints in section 4 to see which elements you didn’t foresee.

For this section, I would recommend arranging a meeting/ video call with your team. It’s important you get feedback from everyone involved. Ask yourselves:

  • Where our assumptions correct?
  • Did we reach our proposed goals?
  • What went wrong and why?
  • What did we learn?
  • What can we do better next time?

It’s also worth noting I don’t intend to use this approach for each feature we intend on building (e.g. contact form or login) — but for larger problems, new products/features, flows and integrations I would suggest producing one.


This will most likely evolve as we use it more within each of our respective teams and projects at ucreate — so I'll be updating this post regularly with any new changes and improvements.

Got some feedback or questions on the Product Briefing document? Drop me a message in the comments below.

👉 Check out some of my other writing on my personal site 👈

Thanks to Joe Dempsey, Victoria Davies, and Michael Christofides.

Sam Dickie 👨🏼‍💻

Written by

Senior Product Manager @ucreate_ & Founder @nocodetech (acquired) + http://betatesta.xyz — www.samdickie.me