W4PM_Ayu_Savitri_PRD

PRD: Bobobox Easily Booking Journey

Project Data

Explore

Figma's approach to modern PRDs

A brief intro to our Product Requirements Doc template

Want to get started right away? Start here👇

⁠

PRD: Bobobox Easily Booking Journey Product Requirement Document (PRD)⁠

⁠

Background

Writing a great Product Requirements Doc (aka “PRD”) can be hard. Even if you don’t use PRDs or consider the term outdated, you probably have some sort of product spec. For these types of docs, it’s hard to choose the right “altitude” to describe what your team is intending to build, as different cross-functional stakeholders care about different things and are equipped with varying levels of context. If you try to be exhaustive, you can easily write a 20-page spec that no one has the time to read (I’ve definitely written a couple of these in the past!). If you’re too vague, you’re not able to elicit meaningful feedback from the reader.

Over my time at Microsoft, YouTube, Uber, and now Figma, I’ve come to slowly gravitate towards a template for PRDs that captures just the right amount of information and displays it in a way that is useful to as many different stakeholders as possible.

How it’s structured

We structure our PRDs into 3 sections that align with the types of Product Reviews we have at Figma:

Problem Alignment: Where the PM clearly articulates the key problem we want to solve

Solution Alignment: Where the team shares the proposed solution by embedding Figma design files and scoping features

Launch Readiness: Where the cross-functional team outlines dependencies for launch

Let’s dive into what each of the sections look like.

Problem Alignment

I strongly believe that PMs are uniquely accountable for making sure the “why” of an initiative is well-defined and well-understood. So often I’ve seen a team spend a ton of time designing a solution only to have the very premise of the problem it’s solving challenged at the very end. For this reason, I think just as much time should be spent defining the problem as determining the solution, as this saves everyone time in the long run.

I’m not going to dive into what’s the right way to write a problem statement as there are enough blog posts about that on the Internet. Rather, I want to share some additional color I like to include when defining the problem:

Ask “why” one more time than you think you need. Don’t just explain why you’re proposing this project; ask why the problem is important in the first place. Or why the problem even exists, to ensure you’re not simply describing a symptom of a deeper problem.

Optimize for eliciting a meaningful reaction. Sometimes a reader won’t give great feedback on your problem because it “sounds good in the abstract,” but it’s unclear what core assumptions underlie this problem, or how severe you think the problem really is (since, at some level, everything can be described as a problem). This is why the “High-level Approach” section is important—it can quickly give a sense of scope and lets the reader imagine what a prospective solution might look like, which for many is easier to react to.

State all your goals, even those immeasurable. Sometimes, the insistence on having only perfectly measurable goals and KPIs prevents you from clearly explaining what you’re trying to achieve. Simply describing what you want users to think, feel, and do can be an important first step in defining what success looks like.

Solution Alignment

At Figma, we find presenting solutions via a couple different lenses to be most helpful: key features and user flows.

User flows are the easiest way for readers to understand the project because it shows how the customer will ultimately experience it.

Key features is a quick way for other functions like marketing or product education to understand how we might talk about the initiative with our customers.

One common pain point with this section is keeping the designs up-to-date. Oftentimes you’re sharing this PRD early for feedback, or even as the product starts getting implemented, designs change. This is where Figma embeds save you a lot of time—

now, you can embed private Figma files⁠

, meaning that you can keep your existing sharing permissions (whereas previously you had to set the file to “Anyone with the link can view”). In Coda, it’s as easy as copy-pasting a link, and you’ll get options for how to embed the content.

Embed example:

⁠

Launch Readiness

In this last section, we create a checklist of considerations you want all teams to make before actually launching a feature. Your project may have unintended legal consequences or important marketing implications, and this list is intended to flag the right stakeholders at the right time—and define criteria for launch readiness—so everyone can plan accordingly, well ahead of time.

One additional thing you can do here is to configure this so that certain individuals get notified (maybe via Slack) when the “Yes” checkbox is checked off.

⁠

⁠

A single source of truth

Because this template is written in Coda, I was able to remove any redundant data entry, and to make sure everything about the project is automatically kept up-to-date. At the very top, there’s a section that gives readers extra context about the project (e.g., its current status). Go ahead and try it for yourself—just change the Project listed below and see all of the underlying info update:

Project:

Private embeds

⁠

EDIT INFO

⁠

Team:

@Collaboration

⁠

Contributors:

⁠

TL;DR:

Embed Figma files only accessible to specific individuals or teams

⁠

Status:

@Launched

⁠

Shipping:

May 18, 2020

⁠

This is pulled in automatically from the Figma Project Tracker. As you add more collaborators, or as the status of the project changes, this will automatically be updated so you’re no longer having to keep multiple places up-to-date!

Read about how we've set up the Figma Project Tracker here:

⁠

An inside look at how Figma ships product Designing the fastest way to keep an entire company up-to-date on our roadmap using a Coda doc and a bit of social engineering. coda.io⁠

⁠