I turned down a scope change this week.
Not because it was a bad idea. It was a good idea. The client got feedback from a prospect who'd seen the product, and the feedback was sharp. Redesign the main output page. Make it single-view. Add navigation between sections. New status labels. New data points.
Smart direction. But it contradicted the brief we'd already delivered against.
The Pattern
This is a pattern I've seen hundreds of times. At EA Sports, working on FIFA with 200+ people and $100M budgets, the same thing happened every sprint. Playtest feedback would land. Marketing would have new direction. Someone would see a competitor's trailer and want to pivot.
Every piece of feedback was valid. Every suggestion made sense in isolation. But if you chase all of it, you ship nothing.
The build was never the hard part. Protecting the build was.
Production management isn't about saying no. It's about knowing when a piece of feedback changes the product and when it changes the schedule. Those are different conversations that need different answers.
What Actually Happened
We'd just completed a milestone. The client approved it. Then two rounds of feedback came in, back to back.
The first round said: tighten what's there. Sharpen the language. Make the output feel like something a board member would read. Don't add features.
We built exactly that. Locked in the language system, rewrote the executive summary format, added print-ready styling. Polish, not features.
Then the second round landed. Single-page layout per risk. Navigation between sections. New status indicators. Impact timing windows. A fundamentally different page architecture.
Both rounds were good ideas. They just couldn't be the same sprint.
The Conversation That Matters
Most builders would just start building. Inbox gets a message, hands start typing. The client asked for it, so it must be the right thing to do.
That's how products drift. One round of feedback at a time, each one reasonable, until the thing you're building doesn't look like the thing you agreed to ship.
So instead of building, I sent a message. Here's the gist:
Here's what I can refine within the current build. Here's what would be new scope. And here's why you should decide if this is your vision or one person's preference before we touch anything.
That conversation took five minutes. It saved weeks of rework.
The Framework
When client feedback arrives mid-build, I run it through three questions before touching any code:
| Question | What It Tells You |
|---|---|
| Does this change what we already shipped? | If yes, it's rework, not iteration. Price it separately. |
| Does this contradict the last round of feedback? | If yes, the vision isn't settled. Don't build on shifting ground. |
| Is this the client's direction or someone else's preference? | Feedback from one prospect is data. It's not a product decision. |
None of these questions say no. They say: let's make sure we're building the right thing before we build anything.
Why This Matters for the Product
The products that actually ship and actually work have one thing in common. At some point, someone said: this is what it is. We're locking it. We're shipping it. Then we'll iterate.
That discipline is the difference between a product and a prototype that keeps changing shape.
At EA, we had a phrase for it: feature lock. After a certain date, no new features. Only fixes. The game ships on the date it ships, and everything that didn't make the cut goes into the next release.
The same principle applies to client work. Lock the scope. Ship the milestone. Get it in front of real users. Then decide what changes based on actual usage, not hypothetical feedback.
A shipped product you can iterate on is worth more than a perfect product that never lands.
The Offer I Made Instead
I didn't say no to the feedback. I broke it into two categories:
Refinements I could make now — layout adjustments, moving elements around, tightening spacing, adding a status label. All within the existing architecture. Same data, same logic, different presentation.
New scope — single-page view per risk, navigation system, new data points that don't exist yet. A different product shape that needs its own timeline and its own brief.
The client got both options. No drama. No pushback. Just clarity on what each path costs and what it delivers.
That's the job. Not just building the thing — knowing when to say: let's lock this before we lose it.
Frequently Asked Questions
Running on a stack that grew by accident?
Tools added one at a time, never architected together. That's the problem I solve. Book 45 minutes and I'll map what moves, what stays, and what makes sense for your operation.
Book a Discovery Call