Most teams like the idea of “appetites over estimates” until you try to run an actual planning cycle.

Let’s say you’re planning a 4-week cycle: 3 weeks of development and 1 week cooldown. You’ve got a set of pitches on the table. The business sees the list and asks the most natural question in the world:

“How long will each pitch take?”

This is where the engineering lead has to push back and reframe. Not because the business is being unreasonable — they’re asking the question they need answered to make trade-offs. But “how long?” forces you into estimation mode, and estimation mode usually creates a false sense of precision.

The reframe is:

“How much is this worth?”

That’s not easy for the business either. It’s a different muscle. They’re being asked to decide value and priority explicitly instead of hiding behind dates.

What works best in practice is making the choice concrete in terms of the cycle.

For example: “This pitch is worth 10% of the cycle.”

If you have 60 engineering days across the cycle, 10% is 6 days. You’re not asking engineering to predict the future. You’re asking the business to decide whether the outcome is worth spending six days of the team’s time.

That’s the bet.

Then the execution side matters just as much as the planning side.

Because what tends to happen in reality is:
If you have good engineers who make progress visible as early as possible, you get a workable V1 surprisingly fast.

By around day 2, you can often have something shipable that covers the core functionality.
Shape Up calls this the epicentre: the part that must exist or the whole thing can’t launch. It’s the “if we don’t build this, nothing else matters” component.
In an e-commerce marketplace, a good example is payments. If you’re building a new checkout flow or subscription model, starting with payments is often the right move because it’s the hardest constraint and the highest leverage. Without payments working, the whole feature is dead.

So you build the epicentre first.

By day 4, that V1 is usually much more robust. It covers a lot of what was in the pitch, and in many cases it’s what actually ships as the final product. Then you hit an important moment:
The last couple of days are usually polish and nice-to-haves.

And here’s the key: once the business can see the “day 4 version”, they often choose not to spend the remaining time. They’d rather allocate those days to something else.

That’s appetites over estimates in practice. You’re not trying to predict exactly how long everything will take. You’re making the work visible early so the business can decide when to stop spending.
This is also why tight feedback loops matter so much. Making progress visible early isn’t just demos. It’s confidence.
Test coverage and TDD-style validation are what make “shipping early” safe, because you can move fast without relying on manual UAT for every small change.

And AI has accelerated this dynamic. It increases iteration speed, especially for getting the V1 in place, wiring the happy path, and tightening up the implementation but it doesn’t change the core Shape Up idea:

The business still decides the appetite.

Engineering still prioritises the epicentre.
And the team still makes progress visible early so trade-offs happen before the time is gone.

The most important shift is cultural:
Instead of “how long will this take?”, the question becomes:
“How much is this worth and what do we get if we spend that amount?”