Scripts for the conversations that stop feature bloat
The answer is always “yes, but later” or “yes, if this.” Never a flat no. A flat no is an argument about your authority. A reframe is an argument about the evidence. The scripts below are ways to say no that sound like yes, because they redirect the conversation from the feature to the problem, and problems are where the good work happens.
These scripts are literal. They are wording you can use in a Slack message, a 1:1, a roadmap review, or a sprint planning meeting. They are not diplomatic formulas or soft-leadership principles. They are sentences that work in the moment.
Each script comes with: the context it applies to, what to have ready before you use it, the reframing move, and when to lose gracefully.
Script 01. The CEO pet feature
The CEO pet feature
Context
The founder or CEO mentions, at an all-hands, in a one-on-one, or in a Slack message, a feature they want built. It may be something they personally use the product for, an idea from the weekend, or something a friend of theirs mentioned. The feature does not appear in your user research. It is not on the roadmap.
Have ready
- Usage data on the problem the feature addresses, if any
- The three things currently on the roadmap and why they are prioritised
- A question about what specific outcome the CEO is trying to drive
The script
“I was using the product over the weekend and I think we really need [feature X]. Can we get this on the roadmap?”
“I've been looking at [related data area]. What outcome are you hoping this moves? I want to make sure I'm solving the right problem, not just shipping a feature.”
“I just think it would be useful. I know I'd use it.”
“Your instinct is worth taking seriously. What I want to do is bring it to the team as a problem statement rather than a solution, so we can test whether your use case is representative and whether [feature X] is the best way to address it. Can I come back to you next week with what we find?”
The reframing move
You are not refusing to build the feature. You are refusing to build it without data. The CEO cannot reasonably object to that. You are also giving yourself a week to gather evidence that might support or challenge the feature, without committing.
When to lose gracefully
If the CEO has positional authority and insists after the data conversation, the feature gets built. Choose your battles. The data conversation is worth having regardless of the outcome, because it establishes a norm: features need evidence. That norm pays off over time even when it does not win the immediate argument.
Script 02. The sales-led customisation
The sales-led customisation
Context
A salesperson or account executive tells you that a prospect or customer needs a specific feature to close or retain a deal. The feature is not on the roadmap. It may be something that one customer needs, not something that generalises to the product.
Have ready
- The size of the deal and the customer segment
- Whether this is a one-time request or representative of a market
- An estimate of the engineering cost and the ongoing maintenance cost
The script
“We're about to lose [customer] because we don't have [feature Y]. Can we just build it? It's a $80k account.”
“I want to help you close this. Here's my concern: building [feature Y] for one customer costs us about three weeks of engineering time and then ongoing maintenance forever. Before I escalate this as a roadmap request, can you find out whether [feature Y] is a blocker because of a specific workflow they have, or because they've seen it in a competitor? I want to know if there's a lighter-weight solution to their actual problem.”
“They've already told me they need it. There's no alternative.”
“Then let me present it to the team as an enterprise-tier feature, not a general product feature. We can scope a version that meets their requirement without affecting the experience for our other customers. I'll need two weeks to assess feasibility. Can we hold the deal that long?”
The reframing move
The reframe is: this is an enterprise-tier feature, not a general product feature. It may get built, but it gets built in the right tier with the right pricing to cover its maintenance cost. You are not saying no to the revenue. You are saying no to architecture debt.
When to lose gracefully
If the deal is large enough and the feature is scoped narrowly enough, build it. The important thing is that it is documented as an enterprise customisation, not as a roadmap commitment to all customers.
Script 03. The loud customer
The loud customer
Context
A customer, often a power user or an early adopter with a large following in the community, is publicly or privately requesting a feature. They may be vocal in your community forum, on Twitter, or in support tickets. Their request is louder than most, but it may not be representative.
Have ready
- Usage data showing how many other users have the same problem
- The forum or support ticket history to understand how long the request has been active
- An honest assessment of whether the customer is an outlier or a lead indicator
The script
“[feature Z] is missing and I've been asking for it for 18 months. I'm starting to look at alternatives.”
“I appreciate you staying with us long enough to keep asking. I want to be honest with you: [feature Z] is not on our current roadmap, and here is why. [Explain the real reason: either it does not match the usage data, or it is on the list but other things are ahead of it, or it conflicts with the product direction.] What I can tell you is [what is on the roadmap and when]. Does that address any part of what you are trying to do?”
The reframing move
The acknowledge-then-reframe technique. You are not dismissing the request. You are acknowledging it, explaining the real reason it is not prioritised (not diplomatic hedging), and redirecting to what is available. Customers respect honesty more than vague commitments to 'keep it in mind.'
When to lose gracefully
If the customer leaves, they were not the right fit for where the product is going. That is a painful but correct outcome. The alternative is building features to retain one vocal customer, which is the enterprise-exception anti-pattern.
Script 04. The engineer who wants to refactor
The engineer who wants to refactor
Context
An engineer, or the engineering lead, proposes a significant refactor or infrastructure change that would delay user-facing work. They may frame it as technical debt, a performance improvement, or a prerequisite for future features. The refactor may be genuinely necessary or may be engineering desire for a cleaner codebase.
Have ready
- An honest assessment of whether the technical debt is currently causing user-visible problems
- The estimated cost (time) of the refactor
- A proposal for sequencing the refactor with a product milestone that gives it a user-facing justification
The script
“We really need to refactor the data pipeline. It's slowing us down and going to cause bigger problems later.”
“I hear that. Help me understand the current user impact. Are there features we can't build, or are there bugs users are hitting, because of the current pipeline? I want to make the case for this work internally, and 'it'll cause problems later' is harder to resource than 'users are hitting X today.'”
“It's not causing problems now, but it will.”
“Then let's plan it properly. What's the project that would give us a user-visible win while also delivering the pipeline refactor? I'd rather ship this as 'we rebuilt the pipeline and as a result users now have [feature or improvement]' than as pure infrastructure spend. Can you sketch that? I'll make sure it has space in the next planning cycle.”
The reframing move
You are not refusing the refactor. You are asking it to justify itself in user-visible terms. This is not unreasonable and it is not anti-engineering. It is a request for the refactor to be framed as a product decision, not a purely technical one. This also protects the engineering team: refactors framed as business outcomes are easier to resource and less likely to be cancelled mid-sprint.
When to lose gracefully
If the technical debt is causing real velocity problems that are delaying features with user impact, approve the refactor without a user-facing justification. The sequencing argument only applies when the debt is preventive rather than currently active.
05. The meeting template
A 30-minute feature-triage meeting agenda
State the agenda and the decision to be made. One sentence: 'We are here to decide whether [feature request] goes on the roadmap, gets parked, or gets killed.'
Present the evidence: usage data, user research, revenue data, competitive landscape. No opinions until the evidence is shared.
Run the 10-question checklist. Go through each question. Anyone in the room can answer. The PM records the answers.
Identify the decision: build now, park for 90 days with a specific re-evaluation trigger, or kill.
Assign actions. If building: who shapes it, what appetite, what milestone. If parking: who owns the trigger. If killing: who communicates and when.
06. Anti-scripts
Things not to say
"We just don't have the bandwidth."
This frames the problem as a resourcing problem. The stakeholder's next response will be to ask for more resources. The real reason is not bandwidth; it is priority. Say: 'This is not where we are investing our time because [reason].' Own the prioritisation decision.
"Our team already agreed against it."
This sounds like politics. The stakeholder will want to talk to the team, or to whoever overrides the team. If the decision was made by the team, explain the reasoning, not the outcome.
"We'll keep it in mind."
This means nothing and both parties know it. If you are not going to build it, say so. If you might build it under specific conditions, name the conditions. 'We'll keep it in mind' erodes trust because it is a social non-answer.
"It's on the backlog."
A backlog is not a commitment. Saying something is on the backlog signals it might happen without committing to it, which frustrates stakeholders more than a clear no. If it is in the backlog as a genuine candidate, say when it will be evaluated. If it is in the backlog as a parking lot, say that.
Digital Signet
Need help running these conversations with your team?
Digital Signet facilitates product strategy workshops where we run these conversations in a structured way, with your actual roadmap and stakeholders.
Email OliverRelated reading