Almost every prioritization framework we use (RICE, weighted shortest job first, the humble value-versus-effort quadrant) was built to protect what was once the scarcest resource of all, engineering time. It’s consistent across all of these models. The effort to build the work sits in the denominator of all of them. Divide the expected impact (read: guess) of a feature by what it costs to build (read: also a guess), rank the results, and the roadmap almost writes itself.

AI, however, has changed the equation, specifically what goes in the denominator. When a capable engineer can build a working version of a feature in an afternoon, effort stops being the constraint. The models that were designed to protect the engineering effort stop making nearly as much sense and everything starts to seem like it’s worth doing. In other words, we quickly get to a point where nothing is actually prioritized. The hard trade-offs we have to make to build a roadmap, a product plan and frequent backlogs don’t get made in this scenario which makes all of these deliverables nothing more than glorified to-do lists. 

So what do we do? How do we take the work that was going to be prioritized by effort (regardless of process or framework) and build a meaningful, customer-centric and business-forward product roadmap? I’m going to show you how to build this AI product roadmap using the two inputs that still mean something, learning value and reversibility, and what to do with each of the four boxes they create. Let’s dive in.

Why effort estimates stopped working as a prioritization input

To be fair, not everything is an afternoon build. Integration work, compliance reviews, and anything touching your production data still cost real time, and I suspect they will for a while. But the direction is unmistakable, and the planning rituals built on protecting engineering capacity are already on shaky ground when a fully-functioning prototype shows up before the estimate does.

The reflex is to celebrate this, and for the most part we should. Being able to build almost anything is a real gift. The trouble is that “can we build it?” was never actually the bottleneck. Deciding what’s worth building, and living with the consequences when we get it wrong (and right!), still is. Cheap building doesn’t answer that question. It potentially makes the question more dangerous because the cost of building something pointless used to slow us down and now nothing slows us down except our own judgment.

Learning value and reversibility: the two inputs that replace effort

Learning value is how much building the thing teaches you about whether it was worth building in the first place. A feature that settles a real argument your team keeps having, or tests an assumption your whole strategy rests on, has high learning value. A feature you’re already confident about and are mostly just shipping has low learning value, even if customers end up liking it. This is the same discipline behind writing outcome-based OKRs. We’re asking what will change in our customers’ behavior, not what we’ll have shipped.

Reversibility is how easily you can walk the decision back if you’re wrong. Some decisions are a feature toggle you can flip on or off at a moment’s notice. Others are more consequential. They can reshape your data model, retrain your users, or make a promise to the market you can’t quietly retract. Jeff Bezos called these two-way and one-way doors years ago. Reframing that idea in the AI era is particularly relevant because cheap building tempts us to walk through expensive doors quickly just because we can.

How to run the learning-value and reversibility matrix on your product roadmap

Here’s the exercise. It takes about an hour with your team, which is conveniently about what one of the old estimation meetings used to take.

1. Pull the list. Take this quarter’s roadmap, or the top 15 to 20 items in your backlog. Last quarter’s ideas will work too if you want to run a calibration round first.
2. Score learning value. For each item, ask “what will building this teach us that we don’t already know?” If the honest answer is “not much, we’re confident, we’re just shipping it,” that’s low learning value. If it would settle a live argument or test a strategic assumption, that’s high.
3. Score reversibility. For each item, ask “if we’re wrong, what does it take to undo this?” A config change is one thing. A migrated data model, a retrained user base, or a broadly-publicized public commitment is another.
4. Place each item in one of four boxes and apply the directive labeled in each quadrant.

High learning value, easy to reverse: build it now, for real. These items teach you the most and cost almost nothing to undo, so cheap building is a gift here. Ship it, then measure what your users actually do with it rather than declaring victory at launch.

High learning value, hard to reverse: prototype first. The insight is worth chasing but the door only swings one way, so spend a little of that cheap building capacity de-risking the decision before you commit. The classic Lean Startup moves like Wizard-of-Oz tests, a fake door, shipping to ten users instead of ten thousand, all still make sense here. The goal is to capture the learning without locking in the consequences.

Low learning value, easy to reverse: make a small bet and move on. Don’t hold a meeting about it. Ship a version, put a date on the calendar to check whether it made a meaningful difference, and get back to the work that teaches you something. The danger in the AI era isn’t under-building these items, it’s over-investing in them precisely because they’re so easy to produce.

Low learning value, hard to reverse: stay out of this box. It teaches you little and you can’t take it back, which is about the worst possible use of your newly found suddenly-cheap building capacity. When something lands here, wait, gather more evidence, or find a reversible path to the same goal before committing a single sprint.

What this changes in your next product planning meeting

If effort no longer makes sense as a weight in our prioritization work, let’s change it. Replace the effort column in your scoring spreadsheet with two new ones: “what will this teach us?” and “how hard is it to undo?” You don’t need to announce a new framework or rename the meeting. In fact, please don’t. Just run the roadmap (or backlog) through those two questions and watch where the discussions happen. These discussions are where the real prioritization work needs to happen.

None of this is exotic. For the most part it’s the same outcomes-over-outputs discipline we’ve been practicing for years, re-sorted for a world where output is nearly free and judgment is the only expensive thing left. Run the exercise once and count how many of your “quick wins” land in the small-bet box. That number is likely to be a good approximation of how much of your roadmap was being prioritized by cheapness rather than by learning.

Give this framework a shot and let me know how it goes.