When a team pushes back on a product decision, the sentence that arrives is usually shaped like “we shouldn’t do that.” In my experience it more often means “I don’t know how to do that yet.”
Those are different problems with different answers, and the cost of confusing them compounds quietly.
Here’s the shape it usually takes. I ask for a feature that arrives already working. Every page has a sensible default the day it ships, populated from what the customer already has, so nobody logs in to a setup screen. What comes back is that this departs from how the other configuration screens work, and that we don’t know how many accounts would need it, and could the administrator set it up on first use instead.
Read literally, that sounds like a product decision. Read generously, it’s a description of the path somebody can see from where they’re standing. Backfilling every existing account is genuinely more work than showing an empty state and a button. If nobody on the team has done that kind of migration before, the empty state is often the only door they can find.
The trouble is what happens if I say yes.
Say yes a few times and the product becomes a series of screens that ask people to configure something before it does anything. Each one was a reasonable local decision. Together they’re the reason a customer says the software is hard, and no single conversation is where it went wrong.
So I’ve stopped hearing it as a verdict and started hearing it as information. The useful question is which part they don’t know how to do yet.
Sometimes it’s the migration. Sometimes it’s that nobody wants to write the script that walks every account, because the last one that ran unsupervised did something memorable. Sometimes it’s genuinely a schedule problem and saying “we shouldn’t” is easier than saying “not this month,” which I’d rather they just say.
Once I know which one it is, the answer is usually available, and often it’s already in the codebase. Most mature products have solved this shape before. Menus that materialize from a shared default the first time somebody looks. Settings created quietly on first save so the prerequisite never appears as a task. A script that walks every active account and creates a default, wrapped so it can run twice without harm. When I can point at the thing we already do somewhere else, the conversation stops being about whether and starts being about where to copy from.
That reframe matters more than it sounds. Asking a team to apply a pattern they already built is a completely different conversation from asking them to learn something new to satisfy me.
Two things I try to keep separate while doing this.
The first is that technical uncertainty and the product decision are different discussions. If we’re unsure something is feasible, I want to know immediately, and I want to know it as its own question. What I don’t want is feasibility doubt arriving dressed as a design opinion, because then I’m negotiating with a position nobody actually holds.
The second is tense. Every version of this conversation I’ve had that went badly was one where I said some form of “you didn’t.” Every version that went well was forward-looking: here’s the standard going forward, here’s where we’ve done it before, what would you need to make it work. People tend to rise to an expectation, and to protect themselves from an accusation. I only get one of those two per conversation.
Some teams already have this instinct. Filling in the gap on somebody’s behalf, making a first day frictionless, doing invisible work so a customer never meets a decision they don’t care about. It gets practiced into a team over time. Where it’s missing, it’s usually because nobody has asked for it and then shown them what it looks like.
Which is the part I have some control over.