Writing a product brief the team can build from

The Product Leaders work group on what a brief should carry, how short to keep it and how to mark which constraints are open.

Updated October 13, 2026

A useful brief lets engineers and designers make good decisions without the PM in the room. It says who has the problem, the outcome wanted, the trade-offs already made and what is still open.

Write it for decisions made without you. Ami Vora would put the customer's problem, the audience, the evidence behind that choice and what success looks like up front, then the hypotheses, constraints and choices set aside. She wants customer detail concrete enough to judge a design against a real person's day.
Keep it short and near the design. Jiaona Zhang suggests roughly two pages: who has the problem, the outcome, the trade-offs and what remains open. At Linktree, the team put the key problems beside the designs in Figma. Her test is whether the engineer and designer can explain why a flow exists.
Name the first test. Tamar Yehoshua wants the brief to name the first thing the team can show someone outside it and what it needs to learn. At Slack, the team prototyped a major UI revision daily. She also wants the technical work visible, so product sees infrastructure needs and engineering hears what customers say.
Show why a design changed. Beside the design, Yuhki Yamashita would put the user situation behind it, the assumption the prototype tests and the constraint shaping this version. After each test he would update them, so an engineer can see why the flow changed.
Label each constraint and who decides. Noah Desai Weiss would label each constraint with its reason and status. A legal or security requirement names its owner; a date or scope choice says what keeping it gains and what evidence would reopen it. For a hard-to-reverse call, the brief names the decision maker, and the PM structures the trade-off.

Group chat with Tamar, Yuhki, Jiaona, Noah, Ami — the Product Leaders work group

Question:

What makes a product brief useful to the people building from it?

Jiaona Zhang (jz)Chief Product Officer at Laurel. Former SVP of Product at Webflow and CPO at Linktree

I think about a useful brief as a decision aid for the people doing the work. At Linktree, we found that long documents left people with different pictures of the product. We put the key problems beside the designs in Figma, then worked through low-fidelity and high-fidelity flows. A lightweight scorecard carried what success looked like, progress, blockers, and asks. That gave builders the context where they were already making choices.

YouTube

I would keep the written brief short, roughly two pages as a rule of thumb: who has the problem, what outcome we want, the tradeoffs we've made, and what remains open. Then I would check it with the engineer and designer building from it. If they can explain why a flow exists and identify the decision they need from me, the brief is doing its job.

Ami VoraCPO of Anthropic. Former CPO of Faire and VP of Product and Design at WhatsApp

A useful brief lets the engineer or designer make a good decision when the PM is out of the room. I’d put the customer’s problem, the audience we’re solving for now, the evidence behind that choice, and what success would look like up front. Then I’d name the main hypotheses, the constraints, and the choices we’re deliberately setting aside. That gives the team room to find a better solution while keeping the reason for the work clear.

Substack+1

At Faire, a conversation with a hospital gift-shop owner gave me a concrete test for simplicity: could she understand what we built in the few minutes she had between helping new families? I’d want a brief to carry that kind of customer detail, so the team can judge a design choice against a person’s actual day.

Substack

Jiaona Zhang (jz)Chief Product Officer at Laurel. Former SVP of Product at Webflow and CPO at Linktree

The brief also needs to change when the team learns something. A team can start with a clear problem and still lose time building against a decision that changed after a prototype test. I’d keep the current flow, success measure, open questions, and the reason for each changed decision together, so engineering and design can see what is settled before they build the next version. In my AI product leadership material, I use prototypes to expose risk earlier and call for requirements and metrics to trace back to research or data.

Tamar YehoshuaChief Product and AI Officer at Atlassian. Former CPO of Slack and President of Product and Technology at Glean

I want a brief to give engineers and designers the customer’s job, the priority, and a way to tell whether we helped. The team should also see the technical work needed to deliver it: product needs to understand infrastructure and scaling needs, and engineering needs to understand what we hear from customers. Shared objectives and a measure of progress make those trade-offs visible.

Apple Podcasts

The brief should identify the first thing we can put in front of someone outside the team and what we need to learn from it. At Slack, we prototyped a major UI revision daily and used the feedback to change the design before building the final version. That gave the builders a way to test the brief’s assumptions as they worked.

saastr

Question:

Yuhki, Tamar wants the brief to name the first thing to test outside the team, and Ami wants the customer evidence behind the choice. What would you put beside a design so builders can use both when a prototype changes?

Yuhki YamashitaChief Product Officer at Figma. Former Head of Design for New Mobility at Uber

Beside the design, I’d put the specific user situation that led us here, the assumption the prototype is testing, and the constraint shaping this version. For example: what was the user trying to do, where did they get stuck, and what would we need to see in a test to believe the new flow helped? After the test, I’d update the assumption and the constraint beside the flow, so an engineer can see why the design changed.

I’ve encouraged PMs to speak in the language of the user’s experience and to question the constraints producing a design. Sometimes a design looks wrong because the team assumed it had to keep an existing pattern or stay inside a feasibility limit. The brief should make that assumption available for the whole team to challenge.

YouTube

Question:

Noah, Yuhki says builders should be able to challenge a brief's constraints. How should the brief show which constraints are open to challenge and who makes the call when the team disagrees?

Noah Desai WeissFormer Chief Product Officer at Slack and SVP Product Management at Foursquare

I’d label each constraint with its reason and its decision status. A legal or security requirement needs its owner and a clear path for checking an alternative. A launch-date or scope choice should say what we gain by keeping it, what we give up, and what evidence would cause us to revisit it. That lets an engineer challenge an assumption with a concrete proposal rather than guess whether the brief is fixed.

Medium

For a reversible choice, I’d set a short deadline, let the team try the option, and name the signal that will tell us whether to keep it. For a hard-to-reverse choice, the brief should name the accountable decision maker and the people whose input they need. The PM structures the tradeoff and keeps the decision moving; the PM rarely needs to be the person who makes the call.

Medium

Ask a follow-up

Product Leaders

220

Product Leaders

3M+ insights

Product leaders from Google, Airbnb, Stripe & 7 more

by Lenny Rachitsky

Frequently Asked Questions

What goes into a good product strategy?
A customer problem the team can describe, one clear choice about the value to deliver first, the work set aside, and the evidence that would show the bet is working. It should let the team explain a specific 'no' to an important customer.
How do you tell a product strategy from a roadmap?
A strategy changes decisions: who the team builds for, where people are staffed and which requests get declined. Noam Lovinsky's test is which staffed project the team would stop to make room for its top bet.
How do you run customer interviews that change what you build?
Tie them to a decision someone owns, ask why the customer has the problem, watch them use a working prototype with realistic data, and check which segment each finding came from before it reaches the roadmap.
How do you scope an MVP?
Set the bar for viable, then cut breadth to one segment, one job and one surface. Keep the core interaction at full quality, leave operations rough, and write down the result that would make you stop before launch.
How should a product team handle feature requests?
Route them by source, write down the problem behind each one, rank only near-term work, and protect capacity for bigger bets and reliability so the request queue can't fill the whole roadmap.
How do you tell whether a new feature worked?
Write down what a win looks like and when you'll read the metric before launch. Read adoption, then sentiment, then behavior change, and check that the whole product gained rather than usage moving from one feature to another.
How do product managers keep stakeholders aligned on scope?
Put the scope decisions and the cut list in one shared record, ask what moves whenever someone adds work, name who owns each call, and check that agreement is real, for example by asking stakeholders to explain the decision back.
How do you forecast delivery for a project full of unknowns?
Give a range and the decisions that set it rather than one date, resolve the unknowns on the path to customer value first, and re-forecast at milestones that get feedback from outside the team.
How is AI changing the way product teams are organized?
New bets increasingly go to small pods with wide roles, while large companies keep specialists and find code review and judgment becoming the bottleneck. Either way, someone on the team still has to push for the user.

All product management questions →

Frequently Asked Questions

Writing a product brief the team can build from

Product Leaders

Frequently Asked Questions

What goes into a good product strategy?

How do you tell a product strategy from a roadmap?

How do you run customer interviews that change what you build?

How do you scope an MVP?

How should a product team handle feature requests?

How do you tell whether a new feature worked?

How do product managers keep stakeholders aligned on scope?

How do you forecast delivery for a project full of unknowns?

How is AI changing the way product teams are organized?

Your ideas, super powered.

Writing a product brief the team can build from

Product Leaders

Frequently Asked Questions

What goes into a good product strategy?

How do you tell a product strategy from a roadmap?

How do you run customer interviews that change what you build?

How do you scope an MVP?

How should a product team handle feature requests?

How do you tell whether a new feature worked?

How do product managers keep stakeholders aligned on scope?

How do you forecast delivery for a project full of unknowns?

How is AI changing the way product teams are organized?

Your ideas, super powered.