Can We, or Should We?

Few questions make me grit my teeth like this one: "Can we do X?"

It's software. Short of breaking the laws of physics, software is an infinitely abstractable, infinitely mutable medium. Can we? Yes. Almost always, yes.

In Wisdom Can Be Learned, Not Taught, I argued that the interesting question is a different one: "Should we do X?" That question is where judgment lives. This post is about what's inside it.

The dropdown nobody needed

When we were building Amazon Tote, we were largely hacking our way onto Amazon's commerce platform to make it work for a Seattle-only pilot. We had very few resources, and we were certainly not going to get Mother A to change its core services just to suit us.

One of our hacks reached into the fulfillment system to drop-ship items from other fulfillment centers into our Seattle one. It could only move a quantity of one at a time. We could have built a background process to loop over larger quantities. But with low inventory, and no way to reserve stock ahead of time, by the time you tried to order four or twelve of something for a customer, you might not be able to fulfill it.

So I did the research on how Amazon customers actually behaved. Orders often had many items, but rarely more than one of the same item, unless the customer was a business. Not having a quantity dropdown seemed like something no one would miss. If you wanted two, or twelve, you could add one at a time. Functionally complete. Inarguably poor for usability. But an edge case. So we shipped without it.

The number one complaint to customer support, in spirit if not in so many words: "Where's the @#$% dropdown for multiple quantities?!" And: "Are you stupid? Why do I have to add an item twice?"

So I, the product manager, also moonlighting as one of the pilot's two software engineers, went back to the drawing board. I redid the research. Multi-quantity orders did exist, below the Amazon average, but they existed. I decided to support them, knowing we might hit the corner case where we couldn't fulfill an order.

Launch came. Launch went. Customer support thought we were heroes.

And then? Nothing. Not one metric tracking multi-quantity orders moved. Customers had never been ordering less because the dropdown was missing. They had just been unhappy that it wasn't there.

Did I do the right thing? I honestly wouldn't change what I did, or how we got there. The dropdown started as a "can we?" The research and the systems told us we shouldn't, and that was sound judgment. Then customers showed up, and taught me something no dataset had: sometimes perception matters more than anything else.

That's the thing about "should we?" It's never answered once. It's a thousand little questions through the week, and they pile up. And some of the answers only come from shipping.

Yes is never free

Every yes spends something. Most of the cost is invisible on the day you say it.

Software is cheap to write and expensive to own. A feature you ship today is a feature you support, secure, monitor, migrate, document and explain for as long as it lives. It's a new surface for bugs, a new door for attackers, a new thing a customer can come to depend on, and a new reason a future change gets harder.

AI makes the writing cheaper still. It does nothing for the owning. So the gap between what a feature costs to build and what it costs to keep is wider than it has ever been. As I wrote in Code Was Never the Unit of Value, the code was never where the value lived. It's also not where most of the cost lives.

The long list nobody writes down

"Should we?" is never one question. It's a long Pareto of demands, pulling in different directions:

• Sellability: will anyone pay for it, or pay more because of it?
• Marketability: can we explain it in a sentence?
• Usability: will people find it, understand it and use it without help?
• Perception: how will it feel to the people using it? That isn't always what the metrics say.
• Operability: can we run it at 3 a.m. when it breaks?
• Maintainability: will the next engineer understand it, and will it survive the next change?
• Security and privacy: what does it expose, and to whom?
• Time: what don't we do because we did this?

They're never weighted equally, and the weights change. A product hunting for its first signal should trade almost everything for learning fast. A product at scale should trade almost everything for not breaking. I wrote about those stages in Effective Before Efficient. The same feature can be a clear yes at one stage and a clear no at another.

Time is the one people forget. It hides inside every other item on the list, and it's the one resource you can't buy more of.

One-way doors and two-way doors

Jeff Bezos gave this part of the question its best-known shape. Some decisions are one-way doors: once you walk through, you can't easily come back. Others are two-way doors: if you're wrong, you step back out and try another.

A data model, a public API, a pricing promise, a security boundary: these are one-way doors, or close to it. Go slowly. Ask for a second opinion. Write down why.

A button color, an internal tool, a first draft of a page: these are two-way doors. Don't hold a meeting. Do something, anything, and learn from it.

Most of the damage I've seen came from mixing the two up: agonizing over two-way doors until the window closed, and walking briskly through one-way doors because the demo looked done.

Agents always say yes

Here is what's new. An agent will answer "can we?" in seconds, and the answer will always be yes. It will build the thing, with tests, and a cheerful summary.

It will not ask "should we?" unless someone does. It doesn't know what the feature will cost to own. It doesn't know which of your doors are one-way. It optimizes the happy path, and judgment is mostly about the unhappy ones. I made that case in You Can't Direct What You Can't Interrogate.

So the question hasn't gone away. It has moved. It used to be asked, implicitly, by the engineer at the keyboard, a thousand times a week, in every small decision a spec left open. Now it has to be asked, explicitly, by whoever is directing the agent. If nobody asks, the answer is yes by default.

Questions for the next time someone asks "can we?"

Before you say yes, or before you hand it to an agent:

1. Who is it for, and what will they do differently because it exists? If you can't name them, stop here.
2. What does it cost to own for three years? Not to build. To own.
3. Is this a one-way door? If so, slow down and write down why.
4. What do we stop doing to make room for it? There is always something.
5. What happens if we wait a quarter? Sometimes the honest answer is "nothing."
6. What's the smallest version that tells us whether we're right? Build that first.

None of these questions is hard to ask. Answering them well is the hard part, and that takes years of having answered them badly. That's the point of the last post: you can learn about these questions in an afternoon. Learning to answer them takes a career.

"Can we?" is a question about software. "Should we?" is a question about judgment. Only one of them is the job.