When building gets cheap, prioritization becomes strategy

Delivery speed is no longer the hard part. For most teams using AI-assisted development, the constraint has moved upstream: not how fast you can build, but whether you're building the right thing at all.

James Shore makes this argument clearly in Modeling Software's Business Impact, the fourth part of his series on assessing AI's effect on software development. His core observation is worth sitting with: when code was expensive to write, cost itself acted as a forcing function for prioritization. Pet projects got deferred. Only the highest-value work could justify the spend. That filter is weakening fast.

The replacement Shore proposes is a financial model—a spreadsheet forecasting net present value over five years, broken into categories like new sales, upsell, retention, cost savings, and development expenditures. Each major initiative has to clear this hurdle before it gets resources. Small features and bugs don't need the treatment. Substantial initiatives do.

We think this is right, and most teams are nowhere near it.

The gut-feel problem

In practice, prioritization at most software companies is a negotiation between the loudest stakeholders. Someone wants a feature because a big prospect asked for it. Someone else wants a refactor because the codebase is painful. A third person wants an integration because it looks good in a demo. These aren't wrong instincts, but none of them are strategy.

Shore's financial model forces the hidden assumptions into the open. When you have to write down why a feature will drive retention, and by how much, and over what time horizon, you find out quickly whether the reasoning holds. More importantly, it gives you something to critique. Shore recommends a somewhat adversarial prioritization process where proponents of different initiatives critique each other's models. That's uncomfortable, but it's far better than HIPPO-driven roadmaps.

The attribution problem is real, but not fatal

The obvious objection is that you can't reliably attribute revenue changes to individual features. Shore acknowledges this directly. A 10% lift in purchases could be your new release—or the VP of Sales running a quota-retirement promotion and marketing landing a key influencer mention. Attribution is messy.

His answer is to model rather than measure directly, using proxy metrics—he borrows Dave McClure's AARRR framework (Acquisition, Activation, Retention, Referral, Revenue)—as faster-feedback signals that are less contaminated by other departments' activities. The model won't be correct. George Box's line applies: all models are wrong, but some are useful. The value isn't precision; it's the discipline of articulating why you expect an initiative to work and what you'll watch to find out.

Customer attention is the scarce resource now

One point Shore raises that doesn't get enough attention: customers have a limited capacity to absorb new features. When building was expensive, that scarcity handled prioritization for us. Now that we can ship more, we risk shipping things customers simply ignore. The invisible backlog isn't features waiting to be built—it's features that got built and weren't noticed.

That reframing matters for how small teams think about their roadmaps. Fewer, better-chosen initiatives beat a high-velocity feature factory. The financial model is one mechanism for enforcing that discipline. Proxy metrics give you the feedback loop to know whether you were right.

Shore is honest that the organizational work is harder than the spreadsheet. Getting sales, customer success, marketing, and finance to engage with a model takes time and relationship-building. But the alternative—prioritizing by feel while AI steadily lowers the cost of building the wrong thing faster—is worse.

Sources

• James Shore: Modeling Software’s Business Impact (original)
• Found via the TLDR newsletter