Design for the Ideal, Then Negotiate Reality

You're three days into designing an onboarding flow. You haven't decided what great looks like for the customer yet, but you already know three things: operations needs a manual review, the integration runs overnight, and changing either would put the launch date at risk.

Those concerns deserve attention. The problem is timing. You're already designing around a queue and a delay before you've decided whether either belongs in the experience you're building. And you've skipped a question that matters more now than it did two years ago: whether the queue and the delay still need to exist at all.

Every other function in the room has a legitimate claim to protect. Operations is accountable for the review. Engineering is accountable for the integration. Legal is accountable for the risk. The customer isn't in the room, and nobody else at the table is there to represent them.

If you don't champion the idealized customer experience, nobody else will. You'll cede to every stakeholder except the one who matters most.

So describe it first. Give yourself enough room to imagine it before reducing it to fit the systems, policies, and processes you have today. Then work with the people responsible for those constraints to figure out what you can change and what you have to accommodate.

That sequence matters for two reasons. You'll make plenty of compromises on the way to shipping, so you don't need a head start. And the list of real constraints is shorter than it was, because a lot of them assumed a human in the loop who no longer has to be there.

Nobody holds the sum

In a negotiation, you establish what you want before making concessions, and you judge each concession against the whole deal. Five individually acceptable concessions can add up to an agreement you'd never have accepted at the outset. The reason you catch it is that one person is keeping score.

Product development has the same math and no scorekeeper. Operations takes a concession in a Tuesday meeting. Legal takes another the following week. Engineering takes a third in a sprint review. Each is reasonable on its own terms, each is made by a different person, and nobody is holding the running total.

In that onboarding flow, you add a field because operations needs information. You introduce a separate verification step to address a risk. You send the customer to another screen because the integration won't be ready, then cut the status updates to hit the date.

The customer experiences all of it together: more work, more waiting, and less certainty about what happens next.

If you start with a diminished experience, you're compromising an already compromised vision. And if you put the ideal away once delivery begins, you lose the reference point that would tell you how far you've drifted.

The PM and designer are the scorekeepers. Keep the original experience visible throughout development, and after a significant tradeoff, walk the whole journey again; the cost to the customer is usually larger than the cost you discussed in that one meeting.

Make constraints earn their place

There's a second problem with negotiating reality: we mistake the current way of doing things for something we're obliged to preserve.

"We can't do that" might mean the law prohibits it. It might mean our architecture doesn't support it. Or it might mean someone considered it three years ago and decided it wasn't worth the effort.

Those require different conversations. Yet teams treat them as equally final, especially when the constraint comes from someone with more history or authority. I'd call this pre-conceding: giving something up before anyone asked you to, in exchange for nothing.

Take the manual review. We may need to verify the customer's information, and we may have built a review queue to satisfy that requirement. We should be able to explain why a person needs to review every submission before we carry that queue into the next version of the product.

Ask what the constraint protects, why the current approach was chosen, and what has changed since. Some constraints will hold up under scrutiny. Others will turn out to be decisions we can revisit, or problems we can solve differently.

Do that work with engineering, legal, and operations. They know why the process exists and what could go wrong if you remove it; they're also the people who can help you find a better approach.

What has changed since

That last question, what has changed since, has a new default answer. Most of the constraints a product carries were set when a person had to read the document, make the judgment call, or reconcile the two systems. "We need a review" usually started as "someone has to do this, and they can't do it instantly." If the second half moved, the first half is up for discussion.

Felix Rieseberg has a useful word for this in How to be more ambitious: A tutorial for humans with models: altitude, moving up from the task in front of you to the outcome you actually want. His example starts with asking a model for QBR slides and ends with asking it to design a better way for leadership to catch problems early.

For our onboarding flow, the altitude question is: how do we verify the customer's information without making them wait? That leaves room to reconsider the review itself, not just the screen that tells the customer it's happening.

A person might have needed to read a document, interpret its contents, and reconcile it with information in another system. Depending on the task, AI may now handle enough of that to change the process. Perhaps a person only reviews the uncertain cases, instead of every customer waiting in the same queue.

We still need to test whether the new approach meets the accuracy, legal, and accountability requirements. "AI can do it" needs evidence, just like "we can't do it."

But the design opportunity is worth investigating. If the review no longer needs to happen the same way, the customer may complete onboarding in one sitting, which is a different experience from a nicer screen telling them to wait.

In The Supercomputer in the Corner, I argued that running yesterday's company faster is an incomplete ambition for AI. This is where that argument becomes a design decision: are we improving the existing process, or removing the reason the customer had to endure it?

Protect the ambition through delivery

Starting with the ideal doesn't commit you to shipping all of it in the first release. It gives you something concrete to work toward and a way to judge what you give up.

The ideal should describe a customer outcome, not a maximal feature list. "The customer can get started in one sitting, with confidence that everything is complete" is an ideal. A list of screens is a spec. The difference matters under negotiation: a feature list loses a feature at a time and nobody notices the experience going with it, while an outcome either survives the tradeoff or visibly doesn't. An outcome also gives the team room to find different ways of delivering it.

I had this conversation with a PM on my team recently, and they played it back better than I'd said it: "Define the idealized customer experience, then challenge existing processes before designing around them. Rather than accepting them at face value, ask what they're actually trying to achieve and whether there's a better way to get there."

When a tradeoff comes up, I'd ask:

• What does the customer lose? Describe the extra effort, delay, uncertainty, or risk.
• Does the constraint still require this compromise? Explain what you've tested, which alternatives you've considered, and whether the constraint still assumes work a person has to do.
• What do our tradeoffs add up to? Walk through the complete experience, including the compromises you've already made.

You'll still ship something short of the ideal. Sometimes the extra step is necessary; sometimes the integration has to wait. Make those decisions with a clear understanding of their cost, and keep the ambition past that release.

You can't fight for an experience you never imagined.