How to write a compelling product brief

Job Story Template by Intercom
  1. Try to minimise the amount of technical detail. Assume non-technical people will be reading it. Use of simple imagery or diagrams can work wonders.
  2. Avoid describing (or even implying) particular solutions whenever possible. We were fortunate to have at least one designer on every team, and they would work much better when afforded the freedom to develop solutions holistically.
  3. Assume it will change over time.

Summary ✨

Condense everything we are trying to accomplish with the work into a single paragraph (or ideally, sentence). I tend to phrase these in the form or a “How might we…?” question, to stimulate engagement from the get-go.

Problem 😣

This should similarly be a single paragraph. I tend to write it in the form “It’s hard to … because …”. This is probably the hardest section to write, and one that I revise over and over again before I consider the brief ready to share with anyone else. Being unable to succinctly describe the problem to solve means that you don’t yet know enough(as a PM) about what it is you’re trying to accomplish. Often I’d try and work a bit more on the following sections to try and clarify for myself, and then come back and try and express the problem as clearly as possible. It’s of course possible to come to the conclusion that maybe this isn’t a problem worth solving– which points to the need to do more research.

Why 🔍

Here’s where I would go into the detail, kind of like the sales pitch to whomever will be reading the brief. This section tends to be the longest (at least in the first draft), but needs to be edited, edited, and edited some more so that it’s a compelling read. I’ll sometimes break it down with subheadings to make it easier to read. This is also the section that can (and should) inspire the most discussion with the team.

Risks 😟

Identifying risks early on I feel helps create direction around what we need to do first, in terms of research and testing. This can take a lot of thinking about, and requires a different mindset than other parts of the document. Essentially you have to apply a critical eye to everything else in the brief, poke it for holes and then make a list of what those holes are. This is not easy to do when you are (hopefully) enthused about solving the problem you just identified and trying to get the reader excited about it too.

Job Stories 💼

In this section I’ll list out job stories in the form of “When I’m…, I want to …, so that I can…”. These can help focus designers and developers on specific aspects of the problem space.

Success 📊

Part of being a PM means being accountable. Although the work might lead us in a different direction than we might originally anticipate, it’s important to have a lens on the problem space that tells everyone when we’re done, and whether we can call it a successful endeavour. This section can have a clear “definition of done”, but should also include things like which metrics we want to monitor, whether those are qualitative or quantitative.

Audience 🍿

Here I’ll list out the personas we might be focusing on, and also any particular customers we might want to engage with for research and feedback over the course of the project.

What 💡

This section tries to capture the more practical aspects of the project. I’ll often need to revise this once designers have read through it, as inevitably I’ll have strayed too far into implying a solution, but it’s usually easy to find a good balance with some back and forth. What’s extremely important is to include anything that should be considered “out of scope”, a list that I will generally add to as I discuss the brief with the team.

Plan 🗺️

I previously used this section to capture details related to the resourcing and timeline of the project, but I found it just made the document too lengthy. So more recently I have just linked out to a dedicated document, which can be owned by a development manager or scrum master.

Guiding Principles 🧭

Something I have found useful to help people on the team be more autonomous is to describe the work in terms of principles. Often designers and developers need to make choices between two or more seemingly good options, and then we’d need to discuss and think about each of those. Having principles in place instead gives them a framework to try and make those decisions directly. My favourite way of writing principles comes from this comment by Dustin Senos: “list two positive words in opposition”.

Decisions 👍🏻

A lot of decisions get made during the lifetime of a project, and these can be easily forgotten, particularly years later when someone is trying to understand why things are the way they are. Sometimes those decisions are to make for the best possible user experience, and sometimes they are more pragmatic compromises. Either way it’s good to capture them for posterity. Because there tend to be a lot of them, and because they have utility beyond the expected lifetime of the product brief, we usually just link out to a dedicated wiki page.

References 📚

This is just a catch-all list of links to any resources for further reading.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jack James

Jack James

Product Manager for Shotgun at Autodesk. Author of books on technology in film production. Software enthusiast.