If you’re familiar with the rocks, pebbles, sand framework, you can think of this as an approach to PRDs that’s better suited for smaller pebbles and sand. There’s a lot of work that simply doesn’t need the level of depth and upfront research that doing a full-scale PRD requires. When you’re doing something quick and scrappy—say, iterating on a feature post-launch—that sort of friction is just going to get in the way without adding much value to the work.

If you’re working on a larger project, you can check out the 

I think the word “requirements” is misleading in a lot of ways. What’s important in a PRD is that it’s clearly communicating what the job is in the simplest terms possible, along with the problem that it’s solving and the evidence that you to support this as the right solution. Beyond these key points, there’s a wide range of detail that it can get to on the shape of the solution. I’ve been on teams before where we essentially stopped at drawing the perimeter of the solution space: that was all the detail that we needed to move on with the project.

When you’re working on a PRD, it’s easy to feel like you have to get down every piece of evidence and analysis to support it, but the reality is that, on a small project like this version is suited to, you really shouldn’t be spending more than 3 hours on getting a draft together.

Kevin Yien

I use this template for projects that are less than six weeks. Teams often go wrong by using a PRD template that’s too heavy for what they need to move fast!

: What is it? A customer should be able to understand this.

: What problem is this solving? Frame around customers or the business.

: What evidence or insights do you have to support this?

 How do we know if we’ve solved this problem? Include primary success metrics (drivers), secondary success metrics (checks), and softer measures (e.g. customer sentiment).

: What are we explicitly not solving for (i.e. non-goals)? These are logical and tempting, not obviously bad. Include the why.

Think through all the different permutations a user might experience. Make sure to write stories to account for all relevant scenarios (including edge cases). The following “job story” format can be helpful in being really clear on logic. 

 Given [some relevant context] When [something is true or happens] Then [something should happen] So that [a user can accomplish something] 

 Given a customer has Salesforce integrated And Salesforce Campaigns are being synced to Mutiny When a new Account is added to a Salesforce Campaign Then it will appear the relevant Mutiny List And the customer will be notified via Slack So they can update any live campaigns

Then [something should happen] So that [a user can accomplish something]

Given a customer has Salesforce integrated 

And Salesforce Campaigns are being synced to Mutiny 

When a new Account is added to a Salesforce Campaign 

Then it will appear the relevant Mutiny List 

And the customer will be notified via Slack 

🛑 Do not begin engineering without aligning with relevant teams (e.g. Design, Engineering, CX, Sales, Marketing).

Track open questions here. When a decision is made, track it in the Changelog below.

Be sure to test your feature as you build it. You’ll want to:   

Select a group of Mutineers to help you test

Create a location in Linear for test fest tickets to be filed

Arrange a meeting for live testing where users step through your test fest and file tickets

Prioritize tickets based on how severely they impact the experience and fix all experience-breaking tickets before launching

Did you write integration tests for every story? Yes / No

Did you add event tracking in Amplitude? Yes / No

Understand how they would want this to work in the demo environment 

 Understand how the dummy data needs to look for the demo feature to be sellable

Do this before engineering work has been done on the project, but after designs are available. Engineering needs to know early how sales wants a feature to be demoed. 

Some features won’t need special work to work in demo (e.g. nested and/or). Some features need seed data to reflect a realistic scenario (e.g. Revenue Dash). Some features need even more considerations (e.g. headline gen would work better if the headlines were for the target account rather than a placeholder)

Did you check for client version dependencies before enabling for any customers? Yes / No

Did you resolve all major issues from beta feedback? Yes / No

Did you write / update support docs? Yes / No

Did you gate the feature in the right tiers? Yes / No 

Product and Marketing and Eng form a POV about what pricing tier something should be in and then align with Henry and Brian Chaliff

Make the necessary code changes to gate a feature [code changes document link]

If possible, design a gated experience that people in lower tiers will see when they encounter your feature

Did you check on success metrics and report out to the rest of the PM team?   

Make sure that the product behaves as expected

Talk to users and non-users who have seen the feature

Report on product usage and potential improvements in PM Jam

Remove feature flags if feature is rolled out 100% and stable (~2 weeks).

Did you gather / incorporate feedback from GTM teams for improvements?

Light PRD Template at Mutiny

Overview

Sign up to see more