On Scope Cuts, Deadlines, and Advocating for the User

I was talking with a designer on my team recently about the necessity of being the advocate for the user in the room. We were specifically discussing scope cuts, and how to shape work to fit within the somewhat arbitrary deadline of a tradeshow or industry event.

I’ve always disliked this kind of deadline because it rarely aligns with delivering real value or anything meaningful within the software lifecycle. And yet, a deadline can also be an opportunity. It can create the conditions to really finish something—to deliver something of significance, something people can see and feel—rather than endlessly chipping away at incremental features and fixes that are hard to notice.

One thing that came up in the conversation was how important it is to push for clarity about what is important, especially when the picture in the designer’s head and the one in the engineer’s are quietly diverging. The engineer may be imagining the worst-case, high-scale, real-time, fully robust version of a feature—and pushing back because that version doesn’t fit the timeline. I’ve seen this firsthand.

I had a situation where I included a timestamp on a mockup. To me it was clear that I just wanted the user to know when the data was refreshed. Engineering assumed this meant the data needed to be refreshed every minute. Their estimate came back: six months. In reality there was no reason a user would visit the screen more than once a day. I just wanted a clear visual cue to help users bracket their expectations about the data’s freshness—a simple “last updated” date was more than enough. But no one questioned the assumption. I accepted the estimate, even as I kept complaining. Only after weeks of frustration did we finally dig into the details. I explained what I really meant; they explained what they thought I meant. We realized we could ship it in two weeks.

These kinds of mismatches aren’t rare. Sometimes PRDs catch them. Sometimes they don’t. When they don’t, they can lead to sandbagging, missed opportunities, and unnecessary engineering work.

There’s an old adage that work expands to fill the time available. I’ve seen this play out across roles—product managers, designers, researchers, engineers. I’ve also worked with engineers who reflexively respond to any scope discussion with, “What can we cut?” or “We don’t have time.” That kind of sandbagging stance doesn’t reflect a builder mindset.

A builder should start from an ambitious, enthusiastic yes. It’s completely fine—essential, even—for that yes to come with trade-offs, constraints, and implementation notes. But the core energy should be “yes, and.” Yes, and we’ll need to simplify this part. Yes, and we’ll need to delay these aspects. Yes, and it won’t yet be robust or performant or general-purpose. That’s fine.

There are always valid reasons for engineering to push back. Designers and PMs often underestimate complexity, and engineering provides the much-needed grounding to those conversations. But even then, the best responses focus on how to move forward—what is the clearest, leanest path to make the thing real.

Advocating for users means holding a bar for the delivered value and the quality of experience. Because if we don’t, who will? Product managers are often focused on velocity and getting something into the market quickly. That’s a valid and necessary orientation, one I philosophically agree with. But not if it comes at the cost of delivering something that actually helps someone.

So one of the questions I use to evaluate scope cuts is this: If we ship this narrower version, will I learn anything from users? When we cut scope too deep the answer is no. The result isn’t learning—it’s feedback that the feature is incomplete, hard to use, or clearly missing critical functionality — things we already knew when we cut scope, and which happened because we cut scope. It’s requests for things we already knew were important. That kind of feedback is confirmation of known gaps, not insight.

Of course, waiting too long can create a different kind of problem—too much surface area, too many pieces launched at once to understand what’s really working. So there’s a balance. You want to ship enough that the user can meaningfully respond to it, but not so much that you drown in complexity. That balance isn’t static—it’s shaped by intent, context, and clarity.

But the core, the core is shipping enough of something that we can learn things we couldn’t anticipate. We learn that we didn’t understand the need, or didn’t think through the edge cases, or that there’s work we didn’t consider beyond the initial task. These are worth shipping for. They respect the user’s time and investment. They are collaborative and create more value with every launch. But someone in the room needs to hold the line, to limit cuts so that we can deliver something we are proud of, that users can tell us something new about

.