Getting stakeholders to agree on scope, and keeping it agreed

The Product Leaders work group on writing scope down, putting a cost on every addition and checking that agreement is real.

Updated October 13, 2026

Write the scope decisions where everyone can see them, make every addition a choice with a cost, and check that agreement is real before the team treats scope as settled.

Put a draft in front of people. Kevin Yien suggests a PRD that sets the bounds: the user and their job, the surfaces to support and a real trade-off. He would run a 20-minute silent read where stakeholders comment on the draft, then record the decisions in the PRD.
Make the cut list visible. Ravi Mehta would write down non-goals beside the chosen work and keep committed work and deferred requests in one decision record. At Linktree, Jiaona Zhang asked teams to plan against a fixed staffing limit and list what they couldn't do, and she would question a tiny cut list.
Give every addition a cost. When someone proposes an addition, Ravi would ask which agreed item moves or whether the outcome has changed. Kevin adds one more question: does the date move? He pushed a strict Square launch date three times after decisions about what had to ship.
Draw out disagreement before scope is settled. Lane Shackleton has given stakeholders an imaginary $100 to spread across candidate problems, and at Coda asks for a Pulse score on the write-up. He wants to hear a low scorer's objection before scope counts as settled. Tamar Yehoshua suggests asking each stakeholder to explain the decision back in their own words.
Name who makes each call. At Webflow, Jiaona's engineering counterpart led the 'how' and she led the 'why'. She suggests writing the decision owner beside each open trade-off. Before calling scope settled, Kevin would ask the people who explain the release to customers to write its promise in one sentence and compare it with the PRD.

Group chat with Tamar, Jiaona, Kevin, Ravi, Lane — the Product Leaders work group

Question:

How do product managers keep stakeholders aligned on scope?

Kevin YienHead of Product, Merchant Experiences at Stripe. Former Head of Lifecycle at Square

Put a draft in front of people. At Square, I joined a new product line where the team had designs and a slide deck, but people had different ideas about what the PRD was supposed to settle. My job was to define the bounds of the problem so engineering and design could explore freely inside them. Spell out the user and their job, the surfaces you will support, and a real trade-off, such as speed versus data consistency. Those choices make scope debatable before people build against different assumptions.

Spotify

Then get feedback in a 20-minute silent read. Have stakeholders comment on the draft in the room, respond to the comments, revise the document, and record the decisions in the PRD. A request that changes the agreed bounds should reopen the trade-off explicitly. Otherwise the team can quietly accumulate incompatible promises.

Spotify

Ravi MehtaProduct advisor. Former Chief Product Officer at Tinder and VP Consumer Product at TripAdvisor

Write down the scope choices that people are most likely to reopen. In strategic planning, I recommend documenting "non-goals" alongside the work you chose, so stakeholders can see the specific alternatives the team set aside.

For a project, I'd put the customer problem, the outcome, the committed work, and the deferred requests in one shared decision record. When someone proposes an addition, ask which agreed item should move or whether the outcome has changed. Record the decision and who made it, then use that record in the next stakeholder update. That makes a scope change an explicit choice with a cost.

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

I’d start by making the scope decision visible before anyone debates features. In planning at Linktree, I asked teams to work against a clear staffing constraint and surface what they could not do with that capacity. If the cut list was tiny, I’d question whether we were being realistic. That gives stakeholders a concrete choice: accept the excluded work, change the goal, or change the capacity.

review.firstround

Then explain the work in a few user-centered themes that someone can repeat in 30 seconds. I’ve found that people can debate a theme and its sequence much more usefully than a list of 50 features. As new evidence comes in, revisit the theme and the trade-off with the team, then update the scope and the cut list in the same place.

review.firstround

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

I would make scope a shared decision between product, engineering, and design. At Slack, we used OKRs to state what mattered and how we would measure it, reviewed them regularly, and had engineering and product work toward the same objectives. Cal Henderson and I held the reviews together, so teams heard one set of priorities and could discuss the build cost alongside the customer need. Infrastructure work still had its own roadmap, with product aware of the resources it required.

Apple Podcasts

Then give stakeholders something concrete to react to at each milestone. Our Slack principle was "prototype the path": show a slide deck or prototype to someone outside the team, get feedback, and use that evidence to decide what belongs in the next release. When remote work drove a surge of new Slack sign-ups, we changed our roadmap to redo onboarding. A PM should explain a scope change in the same terms: what changed for customers, which priority moved, and what work the team will pause.

Apple Podcasts

Lane ShackletonHead of Superhuman Docs. Former Chief Product Officer at Coda

I think scope starts slipping when a PM settles priorities before engineering, design, and adjacent teams have weighed in. I’ve been in the meeting where a carefully worked-out priority list gets blown up by someone who had a different view. At Coda, I’ve used a shared table of candidate problems or features and given each stakeholder an imaginary $100 to allocate across them. The gaps in spending show us exactly where to have the scope conversation together, instead of making the PM relay 20 separate conversations.

coda

Kevin YienHead of Product, Merchant Experiences at Stripe. Former Head of Lifecycle at Square

Ravi's decision record needs one more field: what would make the team move the date. At Square, we had a strict launch deadline and I pushed it three times after a series of decisions about what we believed had to ship. The team chose the customer experience over an artificial GA date.

Spotify

So if a stakeholder wants to add work, ask whether the launch promise changes, what gets removed, or whether the date moves. Put that choice next to the scope decision. A date that everyone treats as fixed can make a seemingly agreed scope impossible to deliver.

Ravi MehtaProduct advisor. Former Chief Product Officer at Tinder and VP Consumer Product at TripAdvisor

The goal behind the scope needs to match how much the team knows. Early in a product's life, a fixed business outcome can create false certainty. I've argued that teams should set goals at the edge of what they understand, then change the type of goal as they learn.

LinkedIn+1

Kevin's agreed bounds and Jiaona's cut list become more useful if the PM also states what evidence could change the plan. For an early product, I would agree on the customer question to answer, the smallest work needed to answer it, and a date to review what we learned. Then a stakeholder request has a clear test: does it help answer that question within the agreed capacity? If the evidence changes the question, bring the scope decision back to the group.

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

One useful check after the scope review is to ask each stakeholder to explain the decision back in their own words: which customer outcome matters, which work comes first, and what their team will do differently. I've found in organization surveys that people often still cannot name the strategy after leaders think they have repeated it many times. Asking people to apply the priorities to their own work exposes different interpretations while there is still time to resolve them.

Apple Podcasts

Keep the top objectives few enough to remember. I've argued for three to five at the company level, even though that means some important work appears only in team-level plans. When every request becomes a top objective, the team loses the basis for saying which scope change takes precedence.

Apple Podcasts

Kevin YienHead of Product, Merchant Experiences at Stripe. Former Head of Lifecycle at Square

The customer question can expire before the next planning review. I've found it tempting to rely on the hundred interviews I've already done and write the next PRD from memory. Customers' lives keep changing, so I keep talking to them even after I feel I know the segment.

Spotify

For Ravi's early-product review, I'd bring a recent customer conversation alongside the cut list. If the request solves a newly observed problem, we can change scope deliberately. If it reflects an old assumption, we have a specific reason to leave the plan alone.

Lane ShackletonHead of Superhuman Docs. Former Chief Product Officer at Coda

A read receipt on a scope doc tells me who has seen it; it doesn't tell me whether they support the proposal. At Coda, we ask people to give a Pulse score on the whole write-up, then put their questions in a shared table and upvote the ones we should discuss first. If the scores cluster high, we can handle minor comments async. If one stakeholder scores it low, I want to hear the objection before the team treats the scope as settled.

Spotify

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

Once everyone has surfaced their priorities, name who makes each scope call. At Webflow, my engineering counterpart led the "how" and feasibility decisions, while I led the "why" and intended outcome. We also made the moment of commitment explicit after airing differences, because a decision can look settled in a meeting while each function walks away with a different plan.

review.firstround

For a PM, I’d write the decision owner beside each open scope trade-off in the shared document. If a new request changes the customer goal, bring product and stakeholders back to the outcome. If it changes effort or delivery risk, ask engineering to assess it before promising a date, including whether the date itself should move. Close the loop by recording the call and telling each team what it should build or pause.

Kevin YienHead of Product, Merchant Experiences at Stripe. Former Head of Lifecycle at Square

Lane's low Pulse score deserves a live conversation when the objection changes the customer promise. I see writing as clarity at scale, both inside the team and with customers. A PM can get everyone to agree on a PRD and still leave sales or support describing a different product.

Spotify

Before calling scope settled, ask the people who will explain the release to customers to write the promise in one sentence. Compare that sentence with the PRD's user, job, and exclusions. Resolve any gap while the work can still change.

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 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.
What makes a product brief useful?
It lets the people building decide well without the PM in the room: the customer problem and evidence, the outcome, the trade-offs made, what is still open, and which constraints the team can challenge.

All product management questions →

Frequently Asked Questions

Getting stakeholders to agree on scope, and keeping it agreed

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 you forecast delivery for a project full of unknowns?

How is AI changing the way product teams are organized?

What makes a product brief useful?

Your ideas, super powered.

Getting stakeholders to agree on scope, and keeping it agreed

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 you forecast delivery for a project full of unknowns?

How is AI changing the way product teams are organized?

What makes a product brief useful?

Your ideas, super powered.