Shrink the Box
Building got cheaper. Judgment got more valuable.
About twenty-five years ago, I had a manager who used to joke about having two number-one priorities. It was funny at the time because, obviously, you can’t have two number-one priorities.
Except the longer I’ve done this, the less sure I am that his joke was wrong. A company can be reducing customer churn while improving platform reliability while aggressively expanding pipeline. In fact, you’d be in serious trouble if it couldn’t do all three at once. The real problem only starts when those priorities demand the exact same dollar, the exact same engineer, or the exact same working hour. That’s the moment somebody actually has to choose.
In corporate speak, people call that choice prioritization. Teams stack-rank their backlog, score features with arbitrary matrices, and shuffle cards around in Jira. But by the time you’re having those tactical arguments, the real decisions should have already happened. What kind of business are you actually trying to build? Where are you placing your balance sheet bets to get there? How much evidence do you need before doubling down, and when do you pull the plug to redeploy those resources somewhere else?
That’s capital allocation wearing an engineering hat.
For most of my career, the budget did that hard thinking for you. Building software was brutally expensive, so every major initiative had to be defended in front of people holding the purse strings. Today, writing code is dramatically cheaper and faster, which means the rarest asset in your company isn’t technical capacity. It’s judgment: knowing what’s actually worth building in the first place.
Strategy cuts work before you rank it
Most ideas pitched inside a company aren’t stupid. Sales has a custom feature they swear will close a tier-one deal. Product has a capability prospects keep asking about during demos, and engineering has legitimate technical debt and reliability work. Every single one of them can make a coherent, persuasive argument.
The trouble is that “this sounds like a good idea” is an embarrassingly low bar for spending company capital. The real test is whether the project serves the specific company you’re trying to become.
One exercise I run with executive teams is mapping incoming feature requests directly back to the customer profiles asking for them. If ten similar, high-value accounts keep asking for variations of the same three capabilities, you’re looking at a real commercial signal. On a product roadmap, that’s a banger of an insight. But if ten prospects are asking for twenty completely different things, you don’t have a roadmap problem. You have an ICP problem masquerading as a feature backlog.
When you try to sell to everybody, you end up with what I call the Microsoft Word Effect: a thousand nested menu options designed to keep every conceivable user happy. The short-term revenue you refused to leave on the table turns into permanent operational complexity, and you carry the carrying cost forever. Knowing who you’re building for is what deletes the features that were never yours to touch.
Don’t confuse an inbound request with commercial evidence
Take a travel SaaS company I worked with, where leadership kept hearing a relentless drumbeat: nobody will buy our platform without AI capabilities.
It sounded plausible on an executive slide. So the company poured capital into it. They hired dedicated machine learning talent, built recommendation algorithms, and rolled out a suite of proprietary models. They burned through seven figures of capital, which was a massive chunk of their balance sheet.
And prospects still didn’t buy. Which was wild, but totally predictable in hindsight.
The business had never established why deals were falling through in the first place. The sales team wasn’t asking the right diagnostic questions, and leadership had no way to separate polite prospect curiosity from an actual deal-breaker. “Prospects are asking about AI” and “prospects are walking away because we lack AI” point toward completely different balance sheet allocations.
So these days, when someone tells me we can’t close business without a specific capability, I ask a much narrower question: which specific deals walked away solely because this was missing? Name the accounts that had pens in hand and refused to sign. If the room goes quiet, you have your answer.
Buy the information as cheaply as you can
There will always be times when you genuinely don’t know whether an initiative will succeed. The fatal mistake is assuming you have to build the entire production system just to find out.
I learned that lesson the hard way after spending a grueling year chasing an enterprise logo that would have looked incredible on the company website. The team burned endless sales engineering hours building out every bespoke integration the client demanded. They never signed the contract. Which was probably a mercy, because if they had, we’d have been completely screwed: the eventual contract value was so low it wouldn’t have covered the cloud infrastructure bill.
After that burn, my teams started building shells. They looked completely real on the outside and behaved like finished software in a guided demo. Under the hood, half of it was manual scripts or smoke and mirrors. But that was the entire point. We could confirm real customer demand and willingness to pay before committing months of engineering attention.
The governing question shifted from “how much will this cost to build” to “what’s the cheapest way to buy the next piece of conviction?” Sometimes that’s a clickable prototype. Sometimes you run the workflow manually behind the scenes with humans. Increasingly, you put an engineer directly in front of the buyer and build alongside them in real time.
If you can answer a million-dollar strategic question for fifty thousand dollars of throwaway work, spend the fifty grand. Then make the real bet once the evidence is on the table.
The true cost of having said yes
Here’s where cheap, rapid development turns dangerous.
When building a feature required six engineers and six months of sprint cycles, somebody had to defend the investment. The friction of the budget was the gate. When a single developer can hack together a plausible prototype in three days using modern tools, that gate disappears.
So organizations accumulate clutter. Micro-features, internal dashboards, custom integrations, throwaway agents, each one individually cheap to build, but collectively suffocating to maintain. Somebody still has to support them, patch their vulnerabilities, and answer for them when they break.
AI lowered the cost of saying yes. It didn’t lower the cost of having said yes.
And market velocity cuts both ways. A customer asks for a feature on Tuesday, your team deploys it on Friday, and three weeks later three competitors have launched the identical capability. If a project takes six months to operationalize but its competitive differentiation has a shelf life of ninety days, you either shrink the build to a long weekend or you leave it alone.
Knowing when to declare victory and walk away
The exact same economic logic applies to sunsetting initiatives.
I saw this recently with a product line that was performing adequately. There were plenty of incremental improvements the team could have made. There always are. But leadership made the hard call to reassign the lead engineer to a new strategic bet, and eventually killed the legacy product completely. It was dead and buried. Three months later, the new initiative had generated more margin than the old product had produced in three years.
Asking whether you can make an existing feature better will almost always yield a yes. The better question is where the next month of top-tier attention generates the highest return. Knowing when to stop polishing is pure judgment, and it’s the kind of leadership almost nobody thanks you for in the moment.
Shrink the box
So I’ve changed my mind about my old manager’s joke. You can have multiple strategic priorities. You just can’t have multiple number-one claims on the same dollar, the same person, and the same working hour.
Work expands to fill whatever container you give it. Give an organization room for ten priorities and it will happily find ten things to work on. So when everything in the building looks critical, shrink the box.
What happens if this initiative gets half the headcount? What proof has to land before it earns the other half? If you could only fund three projects this year, which ones get cut today?
When engineering was expensive, the ledger forced those choices for you. Today, you have to engineer the constraints yourself. Make smaller, faster bets. Demand real commercial evidence before building the machine, and move resources the second the data shifts. Because 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.