Constraints & Cost

We cannot build everything, so the real question is never “is this good?” It’s “is this the best possible use of the little capacity we have right now?” Almost everything on any feedback list is good to someone. That’s exactly why “it’s a real problem” is not enough to justify building it. Product sense under constraints means being ruthless about what clears the bar, because the resources are genuinely scarce and every one you spend is one you can’t spend on something better.

This is the doc that makes prioritization matter. Without constraints, you’d just build the whole list eventually. With them, choosing wrong has a real cost, and being “damn sure” before you commit becomes the job.

The Constraints Are Real#

What’s expected: Before you propose building anything, you know roughly what capacity the team actually has, and you treat it as a hard ceiling, not a suggestion.

Three constraints bound everything we do. They’re not obstacles to work around; they’re the frame the work happens inside:

A product person who ignores these produces roadmaps that can’t happen: everything ranked “important,” nothing sequenced, no acknowledgement that the team can carry maybe two or three real things this cycle. That’s not a plan; it’s a wish list. Knowing the ceiling is what turns a wish list into a plan.

Every Yes Is a No: Opportunity Cost#

What’s expected: When you argue for building something, you can name what the team won’t do because of it.

This is the single most important idea in the doc. Because capacity is fixed, the true cost of building something is not the hours it takes. It’s the best thing you didn’t build instead. Economists call this opportunity cost, and it’s the reason “but it’s a real problem” never settles anything. Of course it’s real. So are the ten things it would displace.

• The image-size fix isn’t free because it’s small. It costs whatever the engineer would have done with that day, and if that day could have gone to recovering shoppers who abandon at checkout, the image tweak just cost you orders.
• A quarter spent on a nice-to-have feature isn’t a quarter of progress. It’s a quarter you didn’t spend on the bet that would have made you the best in the world at something.

So the question is never “is this worth doing in a vacuum?” Everything is, in a vacuum. The question is always “is this worth more than the best alternative use of the same capacity?” If you can’t answer that, you haven’t finished thinking. Every serious proposal names its opportunity cost out loud: “building this means we don’t get to X this cycle, and I think that trade is worth it because…”

The Cost of Building Is Bigger Than the Build#

What’s expected: You account for the full lifetime cost of a feature, not just the effort to ship it.

The effort to build is the down payment. The real price is paid over the whole life of the feature, and beginners consistently underestimate it:

• Maintenance forever. Every feature is a thing that can break, needs updating, and must keep working as everything around it changes. A product with a hundred features nobody uses isn’t rich; it’s expensive and fragile.
• Complexity tax. Each addition makes the product a little harder to understand, to change, and to onboard new people into. Complexity compounds silently until the team slows to a crawl and nobody can say exactly why.
• The support and confusion cost. Features that don’t earn their place still generate questions, bugs, and edge cases that drain the team long after the person who wanted it forgot they asked.

This is why “it’s easy to add” is a trap. Easy to add is not the same as cheap to own. The right instinct is the opposite of accumulation: the best products are ruthlessly small, doing a few things superbly rather than many things adequately. Ask not “can we add this?” but “is this worth carrying forever?”

Buy, Borrow, or Reshape Before You Build#

What’s expected: Before proposing to build, you’ve checked whether the problem can be solved without building, or with far less.

Building from scratch is the most expensive option, so it’s the last resort, not the first. The same discipline from How Systeric Works applies: if a solution looks like it’ll take a month, stop and reconsider.

• Can we not build it? A process change, a piece of documentation, or a configuration fix sometimes solves the problem with no code at all (see Discover). Free is cheaper than cheap.
• Can we borrow it? A well-maintained open-source library or an existing tool often solves 80% of the problem for a fraction of the cost. Our default is to reach for these before writing our own.
• Can we reshape it? A smaller version of the feature frequently captures most of the value at a quarter of the cost. Find the version that fits the ceiling instead of fighting the ceiling.

The month-long build you avoided is capacity returned to the things that actually need us.

Being Damn Sure: The Bar for Spending Scarce Capacity#

What’s expected: The size of the commitment you’re asking for matches the strength of the evidence you bring.

Because capacity is scarce, the bigger the ask, the more certain you need to be before you spend it. “Being damn sure” isn’t a personality; it’s a standard that scales with cost and reversibility. (We size work as sand (hours), pebble (a few days), or rock (weeks or more), the same scale used across how we build.)

The mistake in both directions is real: agonizing over a reversible one-day fix wastes more than the fix costs, and committing a quarter to a rock on a hunch bets the team on a guess. Match the rigor to the stakes. For the small stuff, decide fast and learn. For the big stuff, bring impact and evidence, and be able to say why you’re sure.

Applied: The Storefront Under a Real Ceiling#

Say the team has capacity for two, maybe three real things this cycle. Suddenly the six-item feedback list isn’t a to-do list; it’s a competition for two slots. The image sizes and the stale footer links don’t lose because they’re fake, they’re real. They lose because a slot spent on them is a slot not spent on the slow pages or the checkout re-typing that are actually costing orders, and that trade is obviously bad. The constraint did the deciding. It turned “all six are valid” into “two of these are worth our capacity and the rest wait,” which is the only honest answer when you can’t build everything.

That’s the whole point. Constraints aren’t the thing stopping you from doing good work. They’re the thing that forces you to find the most good per unit of scarce capacity, which is what product sense is for.

Next: Prioritization