Experiment governance to stop ad‑hoc menu changes wasting capacity

Most bakeries don't suffer from a lack of ideas. They suffer from too many running at once, with nobody tracking what actually worked.

The croissant lamination got tweaked three weeks ago, but nobody wrote down the butter percentage. The new seasonal muffin is "doing well" according to the front counter, but you can't tell if it's cannibalizing your banana bread or genuinely adding sales. Someone moved the display case layout and traffic went up—maybe. Was it the layout, or was it the sunny weekend?

This is the quiet tax of running experiments without governance. You burn real production capacity, real ingredient cost, and real staff attention on changes you can't evaluate and won't remember. And because the chaos is invisible on any single day, it rarely gets fixed.

Governance is the boring word for the thing that makes R&D actually compound instead of evaporate. Here's how to build one that fits a small bakery—not a lab.

Why ad‑hoc menu changes quietly drain capacity

The core problem isn't that bakeries experiment too much. They experiment without containers. No intake step, no prioritization, no sample-size discipline, no record of what happened. Every test competes for the same scarce resources—oven slots, proofing space, prep hours—with no referee.

A typical example looks like this. A bakery is running, at any given moment:

1. 1
   A new sourdough hydration test on the main deck oven
2. 2
   A "limited time" pistachio danish the owner wants to push
3. 3
   A reworked pricing sign on the cookie case
4. 4
   A trial of a cheaper vanilla from a backup supplier

None of these are tracked against each other. The pistachio danish eats proofing space the sourdough test needed. The vanilla swap happens the same week as the pricing change, so when cookie sales dip, nobody knows whether it's taste or price. The deck oven is running at capacity, so the sourdough test gets rushed and under‑proofed—producing a result that's basically noise.

What breaks here isn't the ideas. It's the coordination. When you run four uncontrolled experiments on a shared production line, you don't get four learnings. You get zero clean learnings and a week of wasted capacity.

This pattern repeats across almost every bakery that grows past a single baker making every decision in their head. The person with the ideas used to also be the person doing the baking, so the "tracking" lived in their hands. Once you add a second shift, a wholesale line, or a second site, that mental model stops working—and nobody notices until margin starts leaking.

What governance actually means here (and what it doesn't)

Governance sounds like bureaucracy. In a bakery it should be the opposite—a small set of rules that let you say no to most ideas and yes, properly to a few.

A working experiment governance system has five parts:

1. 1
   Intake – a single place every idea gets written down before it touches production
2. 2
   Prioritization – a consistent way to rank ideas so the best ones get capacity first
3. 3
   Sample‑size rules – a minimum bar for how much data makes a result trustworthy
4. 4
   Documentation standards – what gets recorded so the test is repeatable
5. 5
   A learning registry – a running log that ties outcomes back to menu, merchandising, and analytics decisions

Most bakeries treat this as paperwork. It's not. It's a capacity allocation system disguised as a notebook. Every experiment you run is a bet with real production cost. Governance just forces you to size the bet and keep the receipt.

Intake: one door for every idea

First rule: no experiment starts without an intake entry. Not "we'll just try it this weekend." Written down, with a name, a reason, and a rough cost.

Intake does two jobs. It creates a backlog so ideas don't get lost, and—more importantly—it creates friction. Most ad‑hoc changes die at intake because the person proposing them can't articulate what success looks like. That's a feature, not a bug.

A minimal intake form captures:

1. 1
   Idea / hypothesis – "Lowering the almond croissant price from $5.50 to $4.75 will lift unit sales enough to grow total margin"
2. 2
   Type – recipe, pricing, merchandising, sourcing, process
3. 3
   Expected benefit – more units, higher margin, less waste, faster prep
4. 4
   Capacity cost – oven time, prep hours, display space, ingredient spend
5. 5
   Proposed by / date

The hypothesis needs a number attached, not just "let's try a cheaper almond croissant." If you can't write the prediction, the idea isn't ready. This single discipline eliminates a surprising share of the noise, because vague ideas can't survive contact with a hypothesis field.

Prioritization: a matrix that respects your oven, not just your enthusiasm

Once ideas are in the backlog, you need a consistent way to rank them. Enthusiasm is a terrible ranking system—the loudest idea wins, which is usually the owner's pet project, not the highest‑return test.

A simple scoring matrix fixes this. Score each idea 1–5 on a few dimensions, then rank by total. The dimensions below are weighted toward what actually matters in a capacity‑constrained kitchen.

The two dimensions people skip are reversibility and measurability, and they're exactly the ones that separate real R&D from guessing. A high‑impact idea you can't measure is a trap—you spend capacity and still argue about the result. A low‑cost, instantly reversible, cleanly measurable test is worth running even if the upside is modest, because it's cheap to learn from.

Score the backlog once a week. The top one or two ideas get capacity. Everything else waits. The discipline is in holding the line—you run few experiments well instead of many badly.

“

One practical rule worth keeping: cap concurrent experiments at the number of independent measurement surfaces you have.

One practical rule worth keeping: cap concurrent experiments at the number of independent measurement surfaces you have. If you only sell cookies through one channel at one price point, you can't cleanly run two cookie pricing tests at once. One surface, one test.

Sample‑size rules: the part everyone fudges

This is where most bakery experiments fall apart. Someone runs a new scone for a weekend, sells "a bunch," declares victory, and puts it on the permanent menu. Then it underperforms for six months and nobody connects the dots.

A single weekend isn't data. It's an anecdote with a receipt.

You don't need statistics training to set a sane bar. You just need a rule that accounts for your actual sales volume. The lower your daily units, the longer you need to run a test to see a real signal through the day‑to‑day noise.

1. 1
   High‑volume SKUs (80+ units/day)

   a clean 2‑week window usually separates signal from noise

2. 2
   Mid‑volume SKUs (20–80 units/day)

   plan for 3–4 weeks, and try to cover at least two full weekends

3. 3
   Low‑volume / special items (under 20/day)

   you often can't get a trustworthy read at all—treat these as judgment calls, not experiments, and label them honestly

Three non‑negotiable sample rules:

1. 1
   Cover representative demand. Never judge a result on a holiday week, a heatwave, or the week a nearby office closed. Include normal days.
2. 2
   Change one thing at a time per measurement surface. Change the recipe and the price simultaneously and you've learned nothing about either.
3. 3
   Pre‑commit the decision. Before you start, write down what result makes you keep, kill, or iterate. Deciding the threshold after you see the numbers is how pet projects survive bad data.

The deeper framework behind matching test length to volume is worth its own read—our repeatable menu‑engineering system walks through sample sizes and seasonal decision rules in more depth, and it pairs directly with the governance layer here.

Documentation standards: write it so your past self isn't a liar

The most expensive failure in bakery R&D is winning an experiment and then being unable to reproduce it. The lamination was perfect that one week. What was the butter block temperature? The proof time? Nobody logged it. Now you're reverse‑engineering your own success.

Documentation standards exist to make every experiment repeatable by someone who wasn't there. Keep them tight—nobody fills out a two‑page form during a 5 a.m. bake.

The minimum record per experiment:

1. 1
   Exact variables – quantities, temperatures, times, supplier/lot if relevant
2. 2
   Conditions – dates run, weather if it matters, any disruptions
3. 3
   Raw numbers – units sold, waste, cost per unit, price point
4. 4
   Decision – keep / kill / iterate, and the reasoning in one sentence
5. 5
   Who ran it

That one sentence of reasoning is the part people drop and later regret. "Killed—lift didn't cover the extra 12 minutes of prep per batch" is worth more in six months than any spreadsheet, because it captures the why that raw numbers can't.

The learning registry: where it all compounds

Intake, prioritization, and documentation are the inputs. The learning registry is the asset you're actually building—a permanent, searchable record of everything you've tried and what you concluded.

This is the piece that ties menu engineering, merchandising, and analytics into one flow instead of three disconnected habits. A pricing result from the cookie case, a recipe change on the deck oven, and a display‑layout test at the counter all live side by side, so you can start seeing patterns across them.

A workable registry is just a running table, one row per concluded experiment:

Why this matters more than any single test: the registry prevents you from re‑running experiments you already ran. Bakeries without one repeat the same vanilla‑swap test every year or two, because the baker who ran it last time left and the knowledge left with them. The registry turns individual learning into institutional memory.

It also connects naturally to your reporting rhythm. If you're already turning sales data into tests—the loop described in turning weekly reports into experiments—the registry is where those tests go to be remembered, not just run. And for the front‑of‑house side, the measurement templates in our guide to merchandising experiments that move the needle feed directly into the registry's merchandising rows.

How the whole flow runs week to week

New ideas land in intake throughout the week—anyone can add, nobody can start. Once a week, spend fifteen minutes scoring the backlog on the matrix and picking the one or two experiments that fit your available measurement surfaces and capacity. Those get a sample‑size plan before a single batch is baked—how long, what days, what decision thresholds. While running, whoever's on the line logs the documentation as they go. When the test hits its pre‑committed window, you read the numbers, make the keep/kill/iterate call, and the whole thing gets one row in the learning registry.

That's the full loop. No single step is heavy. The weekly scoring session is the only recurring meeting, and it's shorter than a shift briefing. Everything else is capture-as-you-go.

The failure mode to watch for: the registry going stale. If experiments get run but never logged, the whole system degrades back into ad‑hoc chaos within a month or two. The fix is making logging the last step of finishing an experiment—a test isn't done until it has a registry row. Think of an unlogged experiment as an incomplete one, because that's exactly what it is.

A real scenario

A two‑location bakery doing roughly $55k–$60k a month across both shops kept refreshing its pastry menu every quarter. Items went on, items came off, mostly on gut feel from the owner and counter staff. Ingredient spend crept up, and two new SKUs required specialty ingredients that sat in the walk‑in and eventually got tossed.

When they looked back, they'd launched around 14 new items over the year and could confidently say why maybe three of them worked. The rest were guesses that ate prep time and shelf space.

They put in a bare‑bones governance flow—a shared intake sheet, a weekly fifteen‑minute scoring session, and a registry tab in the same spreadsheet. The first thing it did was reduce activity: concurrent experiments dropped from "whatever we felt like" to two at a time.

Over the next two quarters, they ran about nine experiments total—fewer than before—but every one had a clean read and a logged decision. Two low‑volume specialty items that had been quietly losing money got killed with evidence instead of debate. Ingredient waste on experimental SKUs dropped noticeably, and prep hours stopped getting swallowed by half‑measured trials. The owner's comment was the tell: "We're trying less stuff but actually learning now."

That's the whole point. Governance isn't about doing more R&D. It's about making the R&D you do count.

When this makes sense—and when it doesn't

This system is worth building once you have more than one person making menu or display decisions, or more than one production surface where tests compete for capacity. The moment your knowledge lives in two heads instead of one, you need a shared record.

When it's probably overkill: a true one‑person bakery where the baker is the only decision‑maker and volume is low. If you make every item and remember every tweak, formal governance adds friction without much payoff. A simple logbook is enough.

When it's a bad idea: if you'll set up the registry and then not maintain it. A half‑used governance system is worse than none, because people stop trusting it and start working around it. Only commit if you'll actually make "log the result" the non‑negotiable last step.

Who should hold the line: one owner. Prioritization by committee drifts back toward whoever's loudest. Someone has to own the weekly scoring and the right to say "that idea waits."

Pulling it together

Ad‑hoc menu changes feel productive because they're visible—new item, new sign, new recipe. The cost is invisible: the capacity burned on uncontrolled tests, the results you can't trust, the wins you can't reproduce.

Experiment governance flips that. Fewer things running, but each one a real learning you keep. The intake door, the prioritization matrix, the sample‑size discipline, the documentation standard, and the registry aren't five chores—they're one capacity‑protection system that compounds over time.

The bakeries that pull ahead aren't the ones with the most ideas. They're the ones whose ideas stack on top of each other because somebody wrote down what happened last time.