Appetite Before Architecture | Bristena Oprisanu

At my current company we have been working using a shape-up methodology. This means that instead of thinking about "How long will this take?" we focus more on "How much time is this worth?". These are a few of my thoughts after working with Shape-up for the past couple of years.

Where This Comes From

This idea comes from Shape Up, a product development methodology created by Ryan Singer at Basecamp (formerly 37signals).

Basecamp built Hey, Basecamp, and a string of profitable products with a small team. No sprints. No story points. No endless backlog grooming. Instead: six-week cycles, shaped pitches, and fixed timelines with variable scope.

The core insight: most software projects fail not because teams can't build things, but because they build the wrong things, or the right things at the wrong fidelity.

Shape Up addresses this by flipping the planning process. Instead of estimating work and negotiating timelines, you set a time budget (appetite) and shape the work to fit.

The concept that changed how I think most: appetite.

The Traditional Planning Trap

Here's how most teams plan features:

Someone describes what they want
Engineers estimate how long it will take
Everyone negotiates until the timeline feels "realistic"
Work begins
Scope creeps
Deadline slips
Everyone's frustrated

The problem isn't bad estimates. The problem is that estimates drive scope instead of the other way around.

When you ask "how long will this take?", you're treating the solution as fixed and the timeline as variable. But timelines aren't variable—they're constrained by business reality. Budgets, roadmaps, customer commitments, team capacity.

What's actually variable is scope.

Appetite: A Constraint, Not a Forecast

Shape Up introduces a concept called appetite—the amount of time you're willing to spend on a problem.

Notice: willing to spend, not expected to spend.

Appetite is a business decision, not a technical estimate. Before anyone designs a solution, leadership decides: "This problem is worth two weeks of effort. No more."

That constraint then shapes everything downstream:

If a solution fits the appetite: Build it
If a solution exceeds the appetite: Shrink the scope or don't build it
If no solution fits the appetite: Defer until the business can afford more time

This is backwards from traditional planning. Instead of:

"Here's what we want → How long will it take? → Can we afford that?"

You do:

"Here's how much time this is worth → What can we build in that time? → Is that enough value?"

Why Appetite Works

Three reasons:

1. It forces prioritization upfront

When you set appetite first, you're making a statement about value. "This is a 2-week problem, not a 6-week problem." That judgment happens before anyone gets attached to a particular solution.

Without appetite, every problem expands to fill the imagination. "While we're at it, we could also..." The solution grows until it's perfect—and perfectly unbuildable.

2. It prevents the "just one more week" death spiral

We've all been there. The project was supposed to take 4 weeks. It's week 6. "We're so close, just one more week." Week 7. Week 8. The sunk cost fallacy kicks in.

With appetite, week 4 is the hard stop. If you're not done, you cut scope—not extend timeline. The deadline is fixed. The question is always: "What can we ship by Friday?"

3. It makes "no" easier

When someone proposes a feature that would take 12 weeks, and your appetite is 4 weeks, the conversation isn't "can we do it faster?" It's "is this problem worth 12 weeks?"

Often, the answer is no. And that's fine. Appetite gives you permission to defer or descope without it feeling like failure.

Appetite in Practice

Here's how it plays out:

Scenario: Product wants a feature. Engineering explores options.

Without appetite:

Engineering spends two weeks designing a comprehensive solution
Estimate comes back: 8 weeks
Product says "that's too long"
Engineering tries to cut corners
Quality suffers
Everyone's unhappy

With appetite:

Product says "this is worth 4 weeks, max"
Engineering explores what's achievable in 4 weeks
Options presented:
- Option A: Core functionality only (3 weeks)
- Option B: Core + nice-to-have X (4 weeks)
- Option C: Full vision (8 weeks, exceeds appetite)
Product chooses Option B
Team ships in 4 weeks
If demand validates the feature, Option C goes on the backlog for a future cycle

The appetite frame prevents engineering from over-designing and prevents product from over-asking.

Setting Appetite: The Hard Part

Where does appetite come from? It's a judgment call, informed by:

Business value: How much is this problem costing us? What's the opportunity size?
Strategic importance: Does this unlock other things? Is it blocking revenue?
Team capacity: What else is competing for time this cycle?
Risk tolerance: Is this exploratory or mission-critical?

Appetite isn't scientific. It's "this feels like a 2-week problem" based on experience and priorities.

Scope Reduction Options: Your Escape Hatch

Appetite only works if you're willing to cut scope. Which means you need to know what you'd cut.

Before starting a project, write down your scope reduction options—pre-planned cuts ordered by pain level:

Option	What Gets Cut	Trade-off
A	Feature variants (keep 2 of 7)	Core value preserved, less flexibility
B	Edge case handling	Less polish, handles 80% of cases
C	Documentation	Slower adoption, more support burden

Order matters. Cut A before B before C. Protect core value, sacrifice periphery.

Why write this down before you need it? Because decisions made under deadline stress are bad decisions. When it's week 3 of a 4-week project and you're behind, you don't have time for calm prioritization. You need a pre-agreed triage plan.

The Decision Framework

When something new comes up mid-project, run it through:

1. Does it fit the shaped problem?

Yes → Might be an implementation detail, proceed
No → It's scope creep, cut it

2. Can it fit the appetite without slipping?

Yes and it's small → Include it
No, it stretches timeline → Cut and defer

3. Does it unlock essential value?

Yes → Consider swapping something out
It's polish/extra → Defer

This framework prevents both under-delivering (cutting things that matter) and over-committing (adding things that don't).

"Done" Means Value Delivered

Traditional projects define "done" as "all tasks completed." This incentivizes padding the task list and declaring victory when checkboxes are ticked.

Appetite reframes "done" as value delivered.

Did we solve the problem? Can users do the thing? Does the business benefit?

If yes, you're done—even if some tasks got cut. If no, you're not done—even if you completed every task.

This sounds obvious. It's not how most teams operate. Most teams celebrate finishing the sprint backlog regardless of whether the feature actually shipped.

Defer, Don't Kill

Appetite will force you to cut things. That's the point. But "cut" doesn't mean "forget."

Ideas that don't fit the current appetite go into a backlog for future cycles. They're not rejected—they're deferred.

This matters psychologically. "We're not building this now" feels different from "we're never building this." Deferral acknowledges the value while respecting the constraint.

Some deferred ideas come back. Most don't. That's fine—it means you only build things that survive multiple prioritization cycles.

The Uncomfortable Truth

Appetite forces uncomfortable conversations early:

"This isn't worth more than 2 weeks"
"We can't afford to build the full vision"
"If it doesn't fit in 4 weeks, we're not doing it"

These conversations feel harsh. They're also honest.

Traditional planning defers the pain. You start the project, discover the true complexity, and then have the uncomfortable conversation at week 6 instead of week 0. Except now you've spent 6 weeks.

Appetite front-loads the hard decisions. It's more uncomfortable upfront, but it prevents the worse outcome of discovering constraints after you've invested.

Closing

There's no absolute definition of "the best" solution. The best is relative to your constraints.

Without a time limit, there's always a better version. More features. More polish. More edge cases handled. The perfect solution is infinitely expensive.

Appetite gives you permission to ship the good-enough solution—the one that fits the time you have and delivers the value you need.

Ask "how much is this worth?" before "how would we build this?"

The architecture follows the appetite. Not the other way around.

How does your team handle the tension between ambition and timeline? I'd love to hear what's working—or spectacularly failing—for you.