The demo is going well. The stakeholder can see the product working for the first time, the screens make sense, and the room relaxes. Then someone leans in and says, "This is great. Can it also do this?" The request is reasonable, the person asking matters, and it feels small. Before anyone has thought it through, someone on your side says, "Yes, we can add that." In that moment the release you were about to ship quietly became a different release.
I see this pattern on almost every product I work on, and I saw it again recently. A demo is the moment a product becomes real for people who have only seen slides, so it is also the moment the new ideas arrive. That is useful. A request tells you people are engaging with the product and thinking about their own work, but it is a signal to investigate, not proof that the product is right. The problem is not the request. The problem is answering it in the room, before anyone knows what it costs or whether it belongs in this release at all.
Why the yes happens in the room
The yes is rarely a decision. It is usually a social reflex. The stakeholder is senior, or is the client, or is the person whose support the project needs next quarter. Saying "not now" feels like friction at the exact moment everyone is finally happy. And the request almost always sounds small: one more field, one more filter, one more screen, a mobile version.
Product people know better, and we still do it. Des Traynor wrote about this at Intercom back in 2013, in a post whose title says it all: "There are no small changes." A new field needs validation, storage, reporting, permissions, testing, support and documentation. A new screen needs a place in the navigation and a reason to exist next to the screens around it. With AI tools, building the first version of that change is often a matter of hours, which makes the yes even more tempting. But a cheap build can still become an expensive obligation. You pay for a feature once when you build it, and then again every day after you ship it, in support, maintenance and the attention of whoever owns it.
What a mid-release yes really costs
A yes given during a release has a cost that a yes given during planning does not. The team was close to done. The scope was agreed, tested and in some cases already in front of users. Now part of that work has to be reopened, retested and explained again. The release date moves, or the team squeezes the new item in and something else gets less attention. Sometimes the change makes the release better. More often, in my experience, the thing everyone agreed to ship gets weaker so that something nobody has examined can be added.
There is also a cost you cannot see on the plan. Every promise made in a meeting becomes a commitment someone has to keep, and it travels. The stakeholder tells their team. Their team tells the people they report to. A week later, the feature you mentioned in passing is "coming in the next release" in a document you have never seen. Walking that back is far harder than not making the promise in the first place, and it costs you trust you will need later.
Ship what was agreed
Recently I worked through exactly this situation with a high profile client. We showed the new version to a senior stakeholder who will rely on it. They liked what they saw, and they asked for more. Both requests were sensible. Neither was in the milestone that was about to ship.
My advice was simple. Launch the milestone as planned and scope the new needs as part of the next phase. The client agreed, and we also agreed not to promise new features to outside stakeholders until they had been vetted. We made a similar call on reporting. Instead of forcing several different views into the current design, we chose to release the first set and give the others their own requirements. In both cases the decision was the same: keep the release focused on what it was designed for, and give the new needs a proper place to be decided.
That is the core of the method. The agreed scope is a promise to the people who will use the product, and by default it should ship on the terms it was planned on. A safety, legal or usability problem found late can still justify changing it, and that is a judgment call, not a rule. A new idea is different. It deserves a real decision, but not in the middle of the room and not inside a release that is almost done.
Park the ask properly
Parking a request does not mean ignoring it. A parked ask that nobody writes down tends to come back later as a complaint: "We asked for this months ago." So when a request arrives mid-release, record who asked, what job they were trying to do, why it matters to them now, and what would make it urgent enough to revisit. The request is rarely the real need. "We need a mobile app" often means "our people work where there is no connection," and that need may have a very different answer.
Then sort what came in. Some of what people raise in a demo is not a feature at all. It is a bug, or a gap in the agreed scope, and that should go through support and be fixed according to how badly it hurts users. Real feature requests go to the next planning round, where they compete with everything else on demand, impact and complexity, and where someone has to say who will own, support and maintain them. On this project we used exactly that split: user-reported bugs became support tickets, and new feature requests were prioritized on those three factors.
Before you design anything, check whether the need is already served somewhere. Sometimes another system the client uses already does the job, and connecting to it is better than rebuilding it. In this case, one of the new requests overlapped with an existing tool, so the right question for the next phase is whether to integrate rather than build. That question gets asked when the request is parked and examined. It rarely gets asked once the answer was already "yes" in the meeting.
Writing the decision down is not only for your own team. A short note of what is out of scope for this release, why, and what would reopen it, gives everyone the same answer when the same request comes back from a different person. Some teams call this a scope exclusion record or a list of non-goals. Whatever you call it, the reason is practical: the same debate is cheaper to settle once than to have five times.
What to say in the room
Pushing back is part of the job, and you can be warm and clear at the same time. Thank the person for the request, because it is useful. Restate the need in your own words, so they know you understood the job and not just the feature. Then say plainly where it goes: "This is not in the release we are shipping now. We will look at it in the next planning round and come back to you with a decision by a date we agree." Notice what that does not promise. The answer may be yes, no, or a different solution that needs no new build at all.
If the stakeholder pushes, ask one question back: would they delay the current release to get this? In my experience the answer is usually no, and the conversation settles itself. When the answer is yes, you have learned something important about their priorities. Then the product person's job is to bring a clear recommendation, with the cost and the trade-off spelled out, to the people who decide on the release and the budget, rather than settle it on the spot.
A quick test before you say yes
When a new ask arrives during a release, I run through a short set of questions before anything is promised. First, is this fixing something broken in the scope we already agreed, or is it new scope? Broken things get fixed on their severity. New scope waits for planning. Second, which users is this milestone for, and does the request serve them, or a different group with a different job? Third, would the person asking accept a later release date to get it? Fourth, how many people have asked for this, and is it the same need underneath? And fifth, does something already exist that we could connect to instead of building?
These questions are not a pass or fail score. They reduce the uncertainty enough to make a call, and I am comfortable making it at around 80% confidence, then correcting course if the evidence changes. Some requests will move up. Many will wait with their reason attached, and some will be dropped, which is often the most useful call of all. Either way, the decision happens on purpose, with the cost in view, and not as a reflex in the middle of a good demo.
A product does not get better because it says yes to every good idea. It gets better because the team finishes what it promised and chooses the next thing carefully. Ship the milestone, park the new ask, and decide it on purpose.
Sources
- There are no small changes, Des Traynor, Intercom, 2013. Why even a minor addition carries hidden cost.
- Product strategy means saying no, Des Traynor, Intercom, 2013. On feature requests and why optional features still weaken a product.
- Document Product Scope Exclusions So Teams Can Evaluate Later Feature Requests Consistently, ONES, October 2026. A practical format for recording what is out of scope.
- Product Vision Needs Boundaries: Write Non-Goals That Help Decisions, Rizwan Zafar, October 2026. How to write non-goals that guide scope decisions.