Effective Before Efficient

One holiday season at AmazonFresh, we ran out of turkeys.

Customers had ordered frozen turkeys from us, for delivery on a day and at a time they had chosen. So we got in our cars, drove to local grocery stores, bought their frozen turkeys at retail, and delivered them.

It was a terrible way to source a turkey. It was also exactly the right thing to do. We weren't in the turkey business. We were trying to prove something much harder: would people trust someone else to deliver their groceries, to their door, at a time they chose? Every turkey that arrived on time was evidence. How it got into our van was our problem, not theirs.

That's the difference between being effective and being efficient, and knowing which one matters right now is one of the most important calls a builder makes.

A Turing test for customers

At AmazonFresh, we reported up to Doug Herrington, then VP of Consumables. I remember him describing what we were doing as a Turing test, but for customers. It struck me then, and it has stuck with me ever since.

Alan Turing's imitation game, from 1950, is one of the landmark ideas of early AI. Put a person in a room with only a keyboard and a screen. On the other end is either another person or a machine. If the person can't tell which one they're talking to, the machine has, in some meaningful sense, passed for thinking. By 2026 we know it's a deeply flawed test of machine intelligence, let alone sentience. As an idea, though, it's profound.

Every new product faces the same test. Yours is the one on the other side of the wall, trying to pass for the real thing. A grocery business buying its turkeys off other people's shelves and delivering them in its employees' cars: can the customer tell? If they can't, if all they experience is the delivery they were promised, you've found what I call signal. If they can, you haven't.

It's lean thinking's value add (VA) in another form. VA is anything that changes fit, form or function in a way a customer would willingly pay for. Everything else is non-value add (NVA). Period. Full stop. The customer only ever sees their side of the wall.

Or think of Pinocchio, the wooden puppet who only wished to be a real boy. Signal is that story's ending, told from the other side: when Geppetto no longer cares whether you're made of wood, only that he loves you, you're a real boy, whatever your origin story.

Signal, Scale, Sustain

Every product, team and company I've been part of has lived through three stages. I've written about the first two in On Building Scale. The third completes the picture.

Signal is where you find out whether anyone cares. You're searching for product-market fit, for your ideal customer, and for a way to reach them. Nothing is proven, and the customer holds every card.

Scale is where the signal is real and the job is to serve far more people than the idea was born with. You have to stay effective as you open the aperture beyond your ideal customer to more, and more varied, users. And efficiency starts to matter, because growth exposes every shortcut you took to get here.

Sustain is where you've reached altitude. The afterburners are off. The work is refinement, and leaning out what you do through cost optimization. Efficiency reigns here, and effectiveness quietly erodes as tastes shift and competitors climb up from behind.

The three stages of a product, and what each one rewards.

	Signal	Scale	Sustain
The question	Does anyone care?	Can we serve everyone who cares?	Can we do it for less?
What wins	Effective­ness	Effective­ness, then efficiency	Efficiency
Innovation is	The whole game	An asset	A liability, until it's survival

Notice what happens to innovation along the way. In Signal it's the entire game. By Sustain it has become a liability: every new idea disrupts a machine tuned to run lean. And yet a product in Sustain eventually has to reinvent itself, to go back to Signal, or it dies.

Companies, teams and organizations can be great at any one of these stages. Rarely all three.

Did the punch land?

Effectiveness is a binary question: did the punch land on the target, or not? It doesn't ask how hard it was.

Picture a boxer. (Forgive the analogy; it's the cleanest one I have.) Say a punch costs them 1,000 kilojoules, and it lands squarely on the nose. Effective. Now say they get efficient, and throw a punch for 10 kilojoules that grazes an ear, or the air beside the head. Who cares how cheap it was?

The first order of business is to land the punch. The second is to land it efficiently. Once you can land it reliably for 100 kilojoules, and then get that down to 10, the same energy budget throws ten jabs instead of one. That's a winning strategy in any ring.

The order is the whole point. Efficiency compounds what already works. Applied to a punch that misses, it just helps you miss more cheaply. Done in reverse, it has a less polite name: polishing a turd, with gusto.

Nobody cares how you made the burger

You want a juicy hamburger for $5: cooked to order, hot, delicious and on time. Do you care how they made it?

Suppose they secretly ran down the street and bought it from another shop. You probably wouldn't care. You didn't want to walk to that other shop. You got a great burger, as ordered, for $5.

The only people who care how the burger is made are the ones sitting at the chef's table, watching it happen in front of them, and they pay a premium for the privilege. The chef's table is its own product.

The people who do care are us, the ones building it. We know whether we're running 5 meters or 500 meters for each burger. We know the other kitchen charges us a premium. But early on we can't afford a professional kitchen. Maybe ours turns out 20 burgers an hour, so when the crowd arrives after the game, we pay another kitchen to cover the overflow and keep those customers coming to us.

That proof of demand is what takes us to a bank or an investor (in the end, they're the same thing) for the money to build a state-of-the-art kitchen that turns out 200 burgers an hour.

Now we're in Scale mode, baby.

Inefficient on purpose

At Amazon, Tote was the same kind of bet. Every customer in a zip code got their Amazon orders on one fixed day a week, say every Tuesday, at their door, in a very handy and very cute reusable tote bag. You could keep adding to it until the evening before.

At first we could only source from our Seattle fulfillment center, which limited what fit in a tote. So we overnighted everything else into Seattle to guarantee next-day delivery. It was a gross simplification, and wildly inefficient.

It was also exactly right. We were working backwards from the customer, and the promise was the thing we were testing: do people value one or two dependable deliveries a week more than packages trickling in all week long? Breaking the promise to save on freight would have destroyed the very signal we were paying to learn.

Hugely inefficient. Hugely effective. In Signal, that's the right trade every time.

A revenue problem, then a cost problem

Jeff Bezos is said to have put it this way: "I'd rather have a cost problem than a revenue problem."

There's a lot packed into that line. Product-market fit is brutally hard because you don't control it. Customers decide whether they love what you've made, and they vote by buying it or by ignoring it. That's a revenue problem, and no amount of operational excellence fixes it.

Once you've established signal, even if every punch cost 1,000 kilojoules, and assuming you have the reserves to keep throwing them, you have a cost problem instead. A cost problem is operational. It's entirely in your control. That's what Scale and Sustain are for.

Lift before weight

I've argued before that code was never the unit of value. Customers don't buy code. They buy what it does, and they care about the exchange of their money for that value, not about how it was produced.

That's the Turing test again, from the operator's side of the wall: customers pay for VA, and only VA.

Think of a plane. Customers give you lift. Their willingness to pay is what keeps you aloft, and they control your destiny. Whether you can stay aloft for the long run depends on how light you can make the airplane: how efficient the engines are, how clean the wings. That's efficiency, and as the operator you care about every gram.

Passengers don't. They care about the service on the flight, the price of the ticket, and whether it gets them where they're going. In Signal, you're still finding out whether anyone wants to fly the route at all. Shaving weight off a plane nobody boards is wasted effort.

Agents compress the distance, not the physics

This is where the AI revolution in engineering is making us relearn all of this at once.

We've all had an idea. The distance between the idea and a working implementation used to be too many miles for most people to make the journey. With this new crop of tools, almost anyone can get an idea working in an afternoon.

That's genuinely great for Signal. As I wrote in You Can't Direct What You Can't Interrogate, a vibe-coded prototype is a sketch: cheap, valid, and a fine way to get signal. Our agents can now help us run a thousand experiments where we used to run one.

But no agent answers the one question no company has ever owned: do customers even care? Product-market fit is still decided by the customer. The distance has been compressed. The physics hasn't changed.

And the sketch carries the same trap it always did: the throwaway that never gets thrown away. Which brings me to the inheritance.

Forgive the previous stage

As technologists, we usually inherit the sins of the stage before us. I'm regularly brought in as CTO at Scale, or even Sustain, after a mountain of technical debt has piled up. The monolith needs to become services. The services are under-documented and built on click-ops instead of DevOps. And it's tempting to think: if only I'd been here from day one, I'd have done it right.

But you weren't. And you probably wouldn't have. Hindsight is famously 20/20, even when it isn't. In Signal, building for a 100-engineer organization is not the priority. Build that architecture and process before your first paying customer, and you'll either be fired, deserve to be fired, or run out of money before anyone pays you.

That isn't a license to be careless. Start with a monolith, but draw its seams from day one, so the next stage has somewhere to cut. Then extend to the people who came before you the same grace I ask us to extend to ourselves in Works in Progress Told in Three Truths: be forgiving of your former self. They were busy landing punches.

Be effective. Then be efficient.

For Monster Orange, for solopreneurs, and for every company now being built from whole cloth with agents at its side, Signal is the same question it has always been: can you reach the customer, land it on the nose, and have them come back asking for more?

None of them care how you delivered it. You only need to know they felt it.

Be effective. Then worry about being efficient.

---

Den & Den Hub

A shameless plug

This thinking is the heart of Den, the open-source tool we build and use every day at Monster Orange. Den is meant to help you hunt for signal: to work effectively with your agents, at whatever stage you're in, so that every punch has the best chance of landing.

Den Hub, our premium product for teams, is still coming, and it's too soon to share much. But the idea is simple. Help any team or solopreneur, from seasoned engineering gurus to non-technical founders, find signal while lowering the cost of the bridge to Scale. Hub builds best practices into the decisions you make early, so you pay down technical debt as you go, without breaking the bank or slowing the hunt for signal.

If that sounds like your kind of ring, step in.

Join the Den Hub waitlist See Den →