Shrink the Box

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 have several things that are critically important at the same time. You can be reducing churn while improving reliability while growing pipeline. You’d be in trouble if your company couldn’t run a lot of things in parallel.

The problem starts when those priorities want the same dollar, the same person, or the same hour. Then somebody has to choose.

And we usually describe that choice poorly. We call it prioritization. We stack-rank the roadmap, we score projects, we argue about whether Feature A beats Feature B, we move cards around in Jira.

But by the time you’re having those arguments, a few more important 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 should we make before we have evidence we’re right? And when do we stop investing and move those resources somewhere else?

That isn’t roadmap management. That’s capital allocation.

Here’s what’s changed, and why it matters more now than when my old manager was making that joke. For most of my career, the budget did a lot of the thinking for you. Building was expensive, so every real bet had to be argued for and defended. It made you choose whether you wanted to or not.

Building is dramatically cheaper and faster now. Which sounds like good news, and often is. But it means one of the scarcest resources in your company is increasingly judgment: knowing what’s actually worth building.

Strategy cuts work before you rank it

One of the hardest things about ranking anything is that most of the ideas aren’t bad. On any given day you’ll get a fistful of pretty good ones.

Sales has a feature they think closes a deal. Product has something customers keep asking about. Engineering has reliability work. Marketing wants another channel. Somebody saw a thing a competitor is doing. Every one of them can make a reasonable argument.

But “this is a good idea” is a low bar for spending money. The more useful question is whether it’s a better use of your resources than the other things you could do instead. And before even that: does it fit the company you’re actually trying to build?

I’ve watched people get this backwards. They collect requirements from the market and then try to cram them all onto the roadmap.

One thing I like to do is make a company map its feature requests back to the prospects who asked for them. It’s surprisingly revealing. 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 have a different signal. You may not have a roadmap problem at all. You may have an ICP problem.

The broader the audience you’re trying to sell to, the broader the set of problems you have to solve. Different workflows, different integrations, different security requirements, different messaging. Eventually you’re building with what I think of as the Microsoft Word Effect: a thousand menu items designed to keep everybody happy, because you don’t want to leave money on the table. But the money you don’t leave on the table turns into complexity, and you carry that forever.

Knowing who you’re building for cuts an enormous amount of work before any of it needs to be prioritized. That’s the first place judgment pays for itself. Not in choosing between features, but in deleting the ones 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. Some genuinely good work came out of it. We burned through seven figures.

And companies still didn’t buy.

AI was never the reason. The real problem was that 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.

There’s a large difference between “customers are asking about this” and “customers aren’t buying because we lack this.” Those two sentences 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 specifically lose because X was missing, and why exactly did they want it? Not which prospects mentioned it. Not which salesperson thinks it would help. Which customers were otherwise ready to buy and walked because this one thing wasn’t there.

Sometimes you find out fast that you were about to spend a lot of money solving the wrong problem. Better still, you find out before the deal is lost. The judgment call isn’t whether they want it. It’s whether it’s the thing standing between them and the money.

Buy the information as cheaply as you can

There’s a flip side. Sometimes you genuinely don’t know whether something will work. The mistake is thinking you have to build the whole thing to find out.

Earlier in my career I got very good at building polished MVPs. It started after a painful year. We chased a big customer, a logo that would have looked great on the wall. Endless enterprise sales hours, weekly meetings, and we built everything they asked for. They never closed. Which was probably a mercy, because the contract price turned out to be so low it made us wonder what all the fuss had been about.

After that, my team changed how we worked. We built shells. They looked real. They demonstrated the experience we were going for and behaved almost like the finished product in a demo, enough that a customer walked away confident in the approach. Underneath, they often weren’t remotely finished. They were vapor in parts, and that was the point. We could confirm demand before spending months building.

So instead of opening with “how much will this cost to build,” we started asking a better question first: what’s the least we can build to find out if we’re right? Or more precisely, what’s the cheapest way to buy the next piece of information? Sometimes that’s a prototype. Sometimes a mockup. Sometimes you do the thing manually behind the scenes that you’ll eventually automate.

And increasingly, sometimes you put an engineer directly in front of the customer and build with them. There’s a name for one version of this: a forward-deployed engineer (FDE). Instead of requirements crawling from customer to salesperson to product manager to engineering and eventually back to the customer, the engineer works right next to the problem. They understand the problem, build something, watch the customer use it, learn what was wrong about the original assumption, and change it. The feedback loop goes from months to days.

If you don’t work this way yet, it’s worth paying attention to. Not because you necessarily need to stand up an FDE team, but because it changes what’s possible. The important idea isn’t the job title. It’s collapsing the distance between the person who has the problem and the person who can build the solution.

The real advantage isn’t that the engineer builds faster. It’s that the company learns faster. And when judgment is the constraint, shortening the distance between a decision and the evidence that tells you whether it was right becomes enormously valuable.

That’s the whole discipline. If you can answer a million-dollar question for fifty thousand dollars, answer it for fifty thousand. If you can answer the same question with three days of an engineer’s time, better still. Then make the next investment once you have more evidence.

AI lowered the cost of saying yes, not the cost of having said yes

Here’s where cheap building turns dangerous, and where the whole thing comes to a point.

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. The approval threshold is gone.

So companies accumulate. Experiments, features, agents, integrations, internal tools, each one individually cheap. Collectively they’re not cheap at all. Someone still has to understand them, integrate them, test them, secure them, support them, maintain them, and eventually decide whether they even belong in the product.

Every feature is a standing claim on the company’s attention.

AI lowered the cost of saying yes. It didn’t lower the cost of having said yes.

Cheap software still creates expensive obligations.

The questioning doesn’t disappear when building gets easier. It matters more, because nothing else is forcing you to say no.

“Done” is an economic decision

The same logic runs the other way, at the end of a project instead of the start.

We tend to treat “done” as a fixed state, a finish line every initiative is entitled to. It isn’t.

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 getting it from good to great would have taken people we could use somewhere else. So we moved someone onto a new strategic initiative, and eventually killed the old sub-product entirely. The new one made more money in three months than the old one had made in three years.

If we’d asked “can we make the old product better,” the answer would obviously have been yes. But that was the wrong question. The better one was “where is the next month of this person’s time worth more.”

There’s a point where the next week spent improving something is worth less than the same week spent somewhere else. The CEO’s job isn’t to maximize the completeness of every initiative. It’s to maximize the return on the resources the company has. Knowing when to stop is judgment too, and it’s the kind almost nobody thanks you for.

Value has a shelf life

Time adds another problem, and it’s gotten sharper.

You see a feature somewhere. It’s cool. A competitor has it, or someone internal loves it, and you decide you need it. A few years ago, the gap between deciding to build something and having something convincing in front of a customer was often measured in months. Now it can be measured in days. A customer asks for something Tuesday, someone prototypes it Wednesday, it’s in front of the customer Friday. Two weeks later three competitors have something similar. Speed solved one problem and created another: when building gets this cheap and fast, it gets much easier to build things nobody needed.

And even a three-day build isn’t really done in three days. Getting it into production, integrating it into the business, changing customer behavior, and producing measurable value can take a lot longer. That’s the timeline that actually matters. So potential value isn’t enough. You have to ask whether it’ll still matter by the time you operationalize it.

That’s becoming one of the more important questions a company can ask. Markets move, technology moves, expectations move, and AI in particular has a way of turning yesterday’s differentiator into today’s table stakes. An initiative can make perfect strategic sense now and be economically irrelevant by the time you create real value from it. If something takes six months to operationalize and its differentiation has a three-month shelf life, you don’t have a scheduling problem. You either shrink the build dramatically or you don’t do it at all.

You can have many number-one priorities

This is where I’ve changed my mind about my old manager’s joke.

A company can have many number-one priorities. Marketing can work on acquisition while engineering works on reliability while customer success works on retention. That’s what an organization is for.

The issue was never having several important things going at once. The issue is pretending parallelism is free. Two projects can look completely independent on a roadmap and still need the same senior engineer. Or the same product lead. Or the same data team. Or the same executive attention. Or the same $500,000. The moment that happens, they aren’t parallel anymore. They’re competing, and somebody has to make an economic decision.

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.

Shrink the box

So how do you force the judgment when nothing else will?

Work expands to fit the box you give it. Give an organization room for ten priorities and you’ll find ten. Give it room for twenty and you’ll find twenty. 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? What’s good enough to stop? If you could only fund three initiatives, which two disappear?

None of this is about starving the company for sport. It’s about forcing the economic assumptions underneath the work out into the open, where you can actually look at them. Because the hardest part of prioritization was never spotting the bad ideas. It’s deciding which good ideas aren’t good enough.

For any real initiative you’re funding, there are five questions worth sitting with. What evidence says this actually matters? Which specific customers or prospects does it matter to? What’s the cheapest version we can ship to learn whether we’re right? When is it good enough that the next dollar or person should move on? And will it still matter by the time we finish it? If you can’t answer those, another scoring system isn’t going to save you.

When building was expensive, cost forced companies to choose. Now that building is cheaper, you have to create the constraint yourself. You have to shrink the box.

Make smaller bets. Demand better evidence. Move people and money when the evidence changes.

That isn’t prioritization. It’s capital allocation.