Skip to main content
IE
Innovate / Engineer
Start Free Sprint
WIKI · STAGE 01 · IDEA

· Set Expectations

ACTIVITY 01.03 · 5 MIN READ

Set expectations, written.

Also called:  Project alignment · Scope agreement · Definition of done · Ground rules

Writing down what success looks like, what the constraints are, and what the project will not do, before any work starts.

— TL;DR

Agree scope, budget, timeline, success criteria and explicit non-goals in writing, before work begins. Unspoken assumptions are the cheapest thing to fix now and the most expensive thing to fix later. One page, signed off by whoever decides, settles arguments before they happen.

• • •

What setting expectations is

Setting expectations is the act of writing down, before work starts, what everyone is agreeing to. Not the warm version everyone nods along to in the kitchen, but the explicit version: what success looks like, what it will cost, when it lands, and just as importantly, what the project is deliberately not going to do. The point is to settle the disagreements now, on paper, while they are cheap, rather than at week ten when they cost a re-tool.

The trap is that expectations always feel shared until someone tests them. Two people say “a proofing box for serious bakers” and walk away certain they agree. One is picturing a £90 fabric proofer; the other a premium ceramic object. Neither said the number out loud, so neither knows they disagree. The unspoken assumption sits quietly until a design decision forces it into the open, and by then there is sunk cost on both sides.

Why unspoken assumptions derail projects

  • They feel obvious. In my experience the assumptions that blow up are never the ones anyone thought worth stating. They feel so self-evident that writing them down feels insulting, right up until two people produce two different documents.
  • Silence reads as agreement. Nobody objecting is not the same as everybody agreeing. It usually means each person assumed their own reading was the shared one.
  • The cost curve is brutal. An expectation corrected on day one costs a conversation. The same correction at tooling stage costs weeks and real money, and now there is pride in the way too.

How you write them down

Five things, on one page, that anyone on the project can hold a later decision against. Success criteria say what “done well” means in observable terms. Budget and timeline name the hard limits. Hard constraints are the non-negotiables. Explicit non-goals are the tempting things you are choosing not to do. And someone is named as the decider, so a tie does not stall the project. Here is what that page looked like for the proofing box we ran it on, so you can see the shape rather than a generic template.

Expectations · the proofing box
Success looks likeA counter box that holds 26°C ±0.5°C overnight in a 14°C kitchen, that a baker sets with a knob and forgets, and that sells at £149 with bakers calling it worth the money.
Budget & timelineBootstrapped plus a small grant. Bill of materials capped at £38–55. First sellable units within twelve months, no slipping into a second winter.
Hard constraintsUnder 30W. UKCA marked, built to BS EN 61010. Ceramic from Stoke-on-Trent, PCB from Manchester. Rotary knob and OLED, no touchscreen.
Explicit non-goalsNo app, no Wi-Fi, no account. No second capacity at launch. Not chasing commercial-bakery buyers. Not the cheapest box on the shelf.
Who decidesDan owns scope and budget. Anna owns the bakers’ experience and the finish. A genuine tie escalates to the pair together, never stalls.

Five rows, one page. Notice how much of the value sits in the non-goals: “no app” written down is what kills a fortnight of firmware argument six months later, before it ever starts.

The gap that does the damage

The same project, expectations set two ways. The vague version feels friendlier and harder to argue with. That is exactly the problem: nothing it says can ever be wrong, so nothing it says can settle a fight.

✕  Vague expectations
  • “Make a great proofing box bakers love.”
  • “Keep it affordable.”
  • “Get it out reasonably soon.”
  • “We’ll figure out the connectivity later.”
  • “We’re all on the same page here.”
✓  Explicit expectations
  • Holds 26°C ±0.5°C overnight, set-and-forget, sells at £149.
  • Bill of materials capped at £38–55, bootstrapped.
  • Sellable units inside twelve months, before next winter.
  • No app, no Wi-Fi, no account. Decided, written, closed.
  • Dan decides scope; Anna decides finish. Ties escalate.

Every vague line is unfalsifiable, so none of them can resolve a disagreement when one arrives. Every explicit line names a number, a limit or a decision, which means it can be checked, defended, and pointed at when someone proposes something that breaks it.

How it fits the bigger picture

Set Expectations is activity 01.03, the third activity of Stage 01 Idea. It builds on the idea and value goals already named, and it feeds straight into the next activity, run viability sprint (01.04), which pressure-tests those expectations against reality before the project commits any real money.

01 02 03 04 05 06 07 08 09 10 Idea Discover Innovate Evaluate Define Design Engineer Develop Manufacture Deliver YOU ARE HERE

What it can do

It gives the team a written reference that settles arguments before they start. When Anna later proposes a companion app, the page already says “no app”, and the conversation is two minutes instead of a half-day standoff. It protects the budget, the timeline and the scope from quiet, well-meaning drift.

What it can’t do

It can’t tell you whether the expectations are realistic. A £149 price on a £38–55 bill of materials might be fantasy, and writing it down with confidence does not make it true. That is what the viability sprint is for: it tests the expectations you have just set, and either confirms them or sends you back to rewrite this page.

See the full 10-stage process →

Try it yourself

Take your idea and write five things on one page: what success looks like (observable, with a number), the budget and timeline limits, the hard constraints, the explicit non-goals, and who decides when there is a tie. Then read it back and ask the cruel question: “if two of us read this separately, would we build the same thing?” If not, it is not explicit enough yet.

Want a guided version? Start the Free Sprint → and the GPT walks you through scope, value and constraints as a structured first pass.

Your expectations checklist

Project notes: the page that pre-settled a fight

  From the notebook · optional reading

Sitting Dan and Anna Hartley down in Stockport to write the proofing-box expectations, and the one non-goal that paid for the whole exercise.

3 min read · click to open

Dan wanted to start sketching the ceramic shell the same afternoon. I asked for one hour first: “Before any of that, we write down what we’re actually agreeing to. One page. Then you can draw.” They thought it was a formality. It was not.

What we put on the page

Success. A box that holds 26°C give or take half a degree, overnight, in their own Stockport kitchen that drops to 14°C. Set with a knob, forgotten about, and sold at £149 with bakers saying it earned its place on the counter.

Limits. Bootstrapped plus a small grant. Bill of materials between £38 and £55. Sellable units inside twelve months, because missing a winter means missing a year of the season the box exists for.

Constraints. Under 30W, UKCA, built to BS EN 61010. Ceramic from Stoke-on-Trent, PCB from Manchester. A rotary knob and an OLED, nothing more.

Non-goals. No app. No Wi-Fi. No account. One capacity at launch. We worked through each one and made Dan say out loud why it was out, so it would stick.

Where the page earned its hour

Months later Anna came back from a kitchen show keen on a companion app: a push alert when the prove is ready, a temperature graph on the phone. Without the page this is a half-day argument with feelings in it. With the page, I just turned to the non-goals line: “No app. We decided this in week one, and here’s why we wrote it down.” The decision was already made. The conversation was over in minutes, and nobody felt overruled, because the rule was theirs, not mine.

The honest part: a couple of expectations turned out wrong. The twelve-month timeline was tight and we renegotiated it openly at the viability sprint. But renegotiating a written expectation is a clean five-minute conversation. Discovering an unwritten one mid-build is a fortnight and a sulk. The page did not need to be perfect. It needed to exist.

— Idea stage, project notes, 2026

— Next in Idea → Run viability sprint