Shrink the Box
Building got cheaper. Judgment got more valuable.
About 25 years ago I had a manager who used to joke about having two number-one priorities.
It was funny because, obviously, you can’t have two number-one priorities.
Except I’m no longer sure that’s true. A company can be reducing churn while improving reliability while growing pipeline. You’d be in trouble if it couldn’t. The problem starts when those priorities want the same dollar, the same person, or the same hour. Then somebody has to choose.
We call that choice prioritization. We stack-rank the roadmap, score projects, move cards around in Jira. But by the time you’re having those arguments, bigger decisions should already have happened. What company are we trying to build? Where do we put our money and people to get there? How big a bet before we have evidence? When do we stop and move the resources somewhere else?
That isn’t roadmap management. That’s capital allocation.
For most of my career, the budget did a lot of that thinking for you. Building was expensive, so every real bet had to be argued for and defended. Building is dramatically cheaper and faster now, which means one of the scarcest resources in your company is judgment: knowing what’s actually worth building.
Strategy cuts work before you rank it
Most of the ideas aren’t bad. Sales has a feature they think closes a deal. Product has something customers keep asking about. Engineering has reliability work. Every one of them can make a reasonable argument.
But “this is a good idea” is a low bar for spending money. The better question is whether it fits the company you’re actually trying to build.
One thing I like to do is make a company map its feature requests back to the prospects who asked for them. If ten similar prospects keep asking for variations of the same three things, you have a signal. If ten prospects are asking for twenty different things, you may have an ICP problem hiding inside a roadmap problem.
Sell to everyone and you end up with what I think of as the Microsoft Word Effect: a thousand menu items designed to keep everybody happy. The money you don’t leave on the table turns into complexity, and you carry that forever. Knowing who you’re building for deletes the features that were never yours to build.
Don’t confuse a request with evidence
I worked at a travel SaaS company where we kept hearing a version of “nobody will buy this without AI.”
It sounded plausible. So we invested. We stood up an AI team, built recommendation systems and a pile of other technology. We burned through seven figures. That’s massive for a company that size.
And companies still didn’t buy. Wild.
We’d never established why we were losing those deals in the first place. Sales wasn’t asking the right questions, and leadership had no clean way to separate what prospects asked for from what was actually stopping the purchase. “Customers are asking about this” and “customers aren’t buying because we lack this” point to completely different capital decisions.
So now, when someone tells me “we can’t sell this without X,” I ask a narrower question. Which deals did we lose because X was missing? Which customers were otherwise ready to buy and walked because this one thing wasn’t there?
Buy the information as cheaply as you can
Sometimes you genuinely don’t know whether something will work. The mistake is thinking you have to build the whole thing to find out.
I learned this after a painful year chasing a big customer, a logo that would have looked great on the wall. Endless enterprise sales hours, and we built everything they asked for. They never closed. Which was probably a mercy, because we’d have been screwed: the contract price turned out to be so low it made us wonder what all the fuss had been about.
After that, my team built shells. They looked real and behaved almost like the finished product in a demo. Underneath, they were vapor in parts, and that was the point. We could confirm demand before spending months building.
The question changed from “how much will this cost to build” to “what’s the cheapest way to buy the next piece of information?” Sometimes that’s a mockup. Sometimes you do the thing manually behind the scenes. Increasingly, you put an engineer directly in front of the customer and build with them, and the feedback loop goes from months to days.
If you can answer a million-dollar question for fifty thousand dollars, answer it for fifty thousand. Then make the next investment once you have more evidence.
The cost of having said yes
Here’s where cheap building turns dangerous.
When something took six engineers and six months, somebody had to defend the investment. The cost was the gate. When one engineer can spin up a plausible version in three days, that gate quietly disappears.
So companies accumulate. Experiments, features, agents, integrations, internal tools, each one individually cheap. Collectively they’re expensive. Someone still has to understand them, secure them, support them, and eventually decide whether they even belong in the product.
AI lowered the cost of saying yes. It didn’t lower the cost of having said yes.
And speed cuts the other way too. A customer asks for something Tuesday, it’s in front of them Friday, and two weeks later three competitors have something similar. If a thing takes six months to operationalize and its differentiation has a three-month shelf life, you either shrink the build dramatically or you don’t do it at all.
“Done” is an economic decision
The same logic runs at the end of a project.
I saw this recently with a product that was good enough to start selling. There were still plenty of things we could improve. There always are. But we moved someone onto a new strategic initiative, and eventually killed the old sub-product entirely. Dead and buried. The new one made more money in three months than the old one had made in three years.
“Can we make the old product better” would obviously have been yes. The better question was “where is the next month of this person’s time worth more.” Knowing when to stop is judgment too, and it’s the kind almost nobody thanks you for.
Shrink the box
So I’ve changed my mind about my old manager’s joke. You can have several number-one priorities. You can’t have several number-one claims on the same dollar, the same person, the same hour.
Work expands to fit the box you give it. Give an organization room for ten priorities and you’ll find ten. So when everything looks important, shrink the box.
What happens if this initiative gets half the resources? What has to be true before it earns the other half? If you could only fund three initiatives, which two disappear?
When building was expensive, cost forced companies to choose. Now you have to create the constraint yourself. Make smaller bets. Demand better evidence. Move people and money when the evidence changes.
Prioritization was always capital allocation wearing a smaller word.
Know where this has to go, and not how?
Twenty minutes. Tell me where you want this company to be in two years and I’ll tell you what I’d go look at first.