Stage 1 of 4 — Ground Control

Understand the problem
from three perspectives

A great mission starts with an honest briefing. Three roles — UX, Business, and Engineering — each see the problem differently. All three views must be in the room before you can leave the ground.

⏱ Suggested time: 20 minutes — each role fills their column, then share and align

Set the mission context

Start here — what are you building and who is it for? Everyone fills this in together.

💬 Discussion starter — whole team (3 min) Everyone ›
  • In one sentence — what problem are you trying to solve? Go around the room. Notice where your sentences differ.
  • Who specifically has this problem? Name a real person, not a demographic.
  • Does everyone on the team describe the same product? If not — that's important information. Note where you disagree.
💡 Facilitator: if the team takes more than 5 minutes on this, set a timer. The goal is alignment on the starting point — not perfection.
What are you building?
One sentence — the product or feature in plain language.
Who is the primary user? (specific)
Not "young people" — a real, specific type of person.
Ground Control rule: most teams skip to solutions and build the wrong thing perfectly. You need to understand the problem from all three angles: what the user experiences (pain and unmet need), what the business needs to survive (market, revenue, sustainability), and what engineering can realistically do (constraints and capabilities). One missing perspective and your launch window closes.
💬 How to fill in the three columns — who speaks to what UX lead Business lead Engineering lead ›
  • UX Designer: You own the first column. Explain what the user is trying to do, what stops them, and why existing solutions fail. The rest of the team asks: "How do you know that?"
  • Business Student: You own the second column. Explain the market gap, the business risk, and how this could make money. The rest of the team asks: "Who is already trying to solve this?"
  • Engineer: You own the third column. Explain what is technically hard, what the team doesn't yet know how to build, and what an MVP could realistically do. The rest of the team asks: "What would you cut first?"
  • After each column is filled: spend 2 minutes checking if the three perspectives align. Do they describe the same problem? If not, discuss the gap — it's probably your most important assumption.
💡 The goal is not consensus — it's understanding where the three views create tension. Tension is where the interesting product decisions live.
👤 UX Designer leads
User Problem
What does the user experience today that you want to change?
The job the user is trying to do
The pain — what gets in the way
Why existing alternatives fail this user
💼 Business lead
Business Problem
What does the business need to solve to be sustainable?
The market gap or opportunity
The business risk — what could stop this working?
How it could make money
⚙️ Engineer leads
Technical Problem
What are the real constraints and challenges for building this?
The core technical challenge
Skills or tools the team doesn't yet have
What an MVP could realistically do (no app)
💬 Alignment check — before moving on Everyone ›
  • Read each other's columns. Do the three problems describe the same core issue, or three different problems?
  • Where does the UX perspective and the Business perspective disagree? That gap is your first assumption to test.
  • Does engineering's "what an MVP can do" match what UX needs to test the core user pain? If not — which is more important right now?
💡 You don't need to resolve every disagreement now. Just name the disagreements. They become inputs to Stage 4.
Stage 1 summary — three problem perspectives
✓ Copied
Fill in the three columns above — your problem summary will appear here.
Stage 2 of 4 — Pre-Launch Checks

Translate problems into requirements
— what the product must do

Each problem perspective becomes a requirement: a specific statement about what must be true for the product to work. Requirements define what must be achieved — not how to achieve it.

⏱ Suggested time: 20 minutes — each role fills their track, then discuss where they conflict
↑ Carried from Ground Control — the problems you're solving
User pain
—
Market gap
—
Technical challenge
—
A requirement is not a feature. Mission Control doesn't say "install a red button" — they say "the crew must be able to abort within 3 seconds." Requirements define what must be true; features come later. Confuse them and you'll build the right button for the wrong mission.
💬 How to approach this stage — who explains what UX Business Engineering ›
  • UX Designer: Look at the user pain from Stage 1. Turn it into a requirement: what must the product enable the user to do? Use the format "the product must allow [user] to [action] without [barrier]."
  • Business Student: Look at the market gap from Stage 1. What does the product need to generate — in terms of revenue, growth, or engagement — to be sustainable? What is the single biggest business constraint?
  • Engineer: Look at the technical challenge from Stage 1. What must the system be capable of? What's the non-negotiable technical constraint — the thing that, if you can't do it, the product doesn't exist?
  • After filling in: Check for conflicts. Do the UX requirements and engineering constraints create tension? That tension is probably your riskiest assumption — bring it to Stage 4.
💡 The hardest moment: when the UX requirement says "must be real-time" and engineering says "we can't do real-time cheaply." Don't paper over this — write it both ways and flag the conflict explicitly.
👤 UX Designer owns this
UX Requirement
What must the product enable the user to do?
The product must enable the user to…
Success for the user looks like…
Non-negotiable UX constraint
💼 Business lead owns this
Business Requirement
What must the product generate to be sustainable?
The product must generate…
The growth mechanism (how users 2–100 arrive)
Non-negotiable business constraint
⚙️ Engineer owns this
Engineering Requirement
What must the system be capable of? What's off the table?
The system must be capable of…
MVP technical approach (minimum to test the idea)
Non-negotiable technical constraint
💬 Conflict check — where do the three tracks push against each other? Everyone ›
  • Read across the three tracks horizontally. Does the UX requirement match what engineering says is buildable?
  • Does the business model require a scale of users that engineering thinks is too expensive to reach?
  • Is there a requirement that all three tracks agree on? That's your safest starting point. Is there one that creates conflict? That's your riskiest assumption — write it down for Stage 4.
💡 The most common conflict: UX needs real-time features, business needs zero infrastructure cost, engineering needs time to build. This tension is exactly what your first experiment should test.
Stage 2 summary — requirements across three tracks
✓ Copied
Fill in the requirements above.
Stage 3 of 4 — Mission Briefing

Converge on the Big Idea —
your mission objective

All three tracks must converge into one clear product direction. The Big Idea is where UX, Business, and Engineering stop being separate — and start building the same thing.

⏱ Suggested time: 20 minutes — DVF check first (10 min), then write the Big Idea together (10 min)
↑ Carried from Pre-Launch Checks — the requirements you must meet
UX must
—
Business model
—
Tech capability
—
The Big Idea is your mission objective, not your vision. "Help people connect" is not a mission objective. "Let a first-year student find someone nearby with 2 shared interests in under 60 seconds, anonymously" is. Your Big Idea should be specific enough that your team could begin an experiment tomorrow. If it's still vague, you haven't cleared the briefing room.

DVF pre-flight check — does the idea hold up on all three lenses?

Before writing the Big Idea, each role confirms their lens. If you can't answer all three, the idea is not ready.

💬 Who fills in which lens — and what to say UX → D Business → V Engineering → F ›
  • UX Designer fills in Desirable: Why will real users want this? Describe a specific person and what they would feel when they first use it. The test: would you personally recommend this to a friend who has the problem?
  • Business Student fills in Viable: Describe the economic logic — how does solving this problem create sustainable value? Don't say "people will pay." Say "users will pay £X for Y because the alternative costs them £Z or Z hours."
  • Engineer fills in Feasible: Can your team actually build this, with the tools and skills you have, in a semester? Name the one thing that's most technically uncertain. If you're not sure — that's your first tech spike.
💡 A "No" on any DVF lens doesn't kill the idea — it identifies what you need to de-risk first. The lens you're least confident about is your first experiment.
👤 UX Designer
Desirable
💼 Business Lead
Viable
⚙️ Engineer
Feasible

Write the Big Idea — together

One unified product direction. Not three separate visions.

💬 How to write this together — whole team exercise Everyone contributes ›
  • Start with the name. Each person suggests one. Vote. Pick the one that feels most like what you're actually building.
  • For the full description: UX writes the first sentence (what it is, who it's for). Business writes the second (how it makes money or grows). Engineering writes the third (what the first version can actually do). Stitch them together.
  • Read the final Big Idea out loud. Does it sound like the same product all three of you are building? If not — find the sentence where you diverge and fix it.
💡 The test of a good Big Idea: explain it to someone who wasn't in the room. If they ask questions that reveal gaps — those gaps are your assumptions.
Product / feature name
Specifically who it's for
One-sentence plain language description
Explain it to a parent in 20 words. No jargon.
The full Big Idea (3–4 sentences — all three voices)
Cover: what it is, who it's for, what problem it solves, how the business works, what version 1 looks like.
Stage 3 — Big Idea summary
✓ Copied
Fill in the Big Idea fields above.
Stage 4 of 4 — Launch Sequence

From idea to first test flight —
the design hypothesis

Your Big Idea rests on assumptions you haven't proved. Find the one that, if wrong, would end the mission. Then design the simplest possible test to find out.

⏱ Suggested time: 30 minutes — hypothesis (10), assumptions (10), experiment brief (10)
↑ Carried from Mission Briefing — the idea you're testing
Product
—
Big Idea
—

Design Hypothesis — the testable cause-and-effect claim

A hypothesis is a bet you're willing to be proved wrong on. If you can't be wrong about it, it's not a hypothesis.

💬 Building the hypothesis — who fills in what UX → user + benefit Business → outcome Engineering → feature ›
  • UX Designer fills in "the user" and "the benefit": Who specifically will use this feature? What will they be able to do as a result — stated as something observable and measurable?
  • Business Student fills in "the business outcome": What metric improves if the user gets the benefit? State it as a number: "30% of users upgrade to premium" not "more revenue."
  • Engineer fills in "the feature": The specific thing the product does that enables the benefit. Be precise — not "a matching algorithm" but "a proximity-based interest tag filter with a 1km radius."
  • After completing the hypothesis: Read it out loud. Ask everyone: "On a scale of 1–5, how confident are you this is true?" Record each person's score before anyone discusses. The range of scores is more important than the average.
💡 If all three team members give a 5 — you haven't thought about it hard enough. A genuine hypothesis should generate some doubt.
The feature
The user
The user benefit (observable, measurable)
The business outcome (as a number)
Your hypothesis — live preview
We believe that will be achieved if attains with .
Team confidence scores — submitted independently, before discussion
💬 Discussing the confidence scores — where does the team disagree? Everyone ›
  • Who gave the lowest score? Ask them to explain — without interruption — what they're uncertain about.
  • Who gave the highest score? Ask them: "What would need to happen for your score to drop to a 2?"
  • The gap between the highest and lowest score is the assumption you understand least as a team. That's your first thing to test.
💡 A team where everyone scores 5 is a team that isn't listening to each other. Productive disagreement now is better than discovering the disagreement after you've built something.

Riskiest Assumption — what if we're wrong about this?

List what your hypothesis assumes. Rank them by uncertainty × importance. Find the one that, if false, ends the idea.

💬 How to identify assumptions — the "but do we actually know that?" technique Everyone contributes ›
  • Read your hypothesis out loud. After every clause, ask: "But do we actually know that?" Write down every "we're not sure."
  • Each person adds at least one assumption. UX adds user behaviour assumptions. Business adds market and economic assumptions. Engineering adds technical assumptions.
  • Rate each assumption on uncertainty (how sure are you it's true) and importance (if wrong, does the idea survive?). The top-right quadrant — high uncertainty + high importance — is where you start.
  • The riskiest assumption: ask "if this is false, what exactly happens to our product?" The answer must be specific. "We would have no way to acquire users" is specific. "The product wouldn't work" is not.
💡 The riskiest assumption is usually the most uncomfortable one — the one the team is least willing to test because they're afraid of the result.
Every hypothesis is a stack of hidden assumptions. The riskiest one is the assumption that, if wrong, causes a mission abort — not the one you're curious about. The one that would end everything.
Assumptions (things you believe but haven't proved)
The assumptionUncertainty 1–5Importance 1–5
← Low importance · High importance →
📋 Know — just act
High importance, low uncertainty
TL
🚨 Test first
High importance + high uncertainty = riskiest
TR
💤 Low priority
Low importance, low uncertainty
BL
⚡ Quick win
High uncertainty, lower importance
BR
← Low uncertainty · High uncertainty →
Riskiest assumption (from Test First quadrant)
If this is wrong — what exactly happens?

Experiment Brief — design the simplest possible test

Three questions, not a test card. The experiment brief asks: what are you trying to find out, how will you find out, and what would change your mind?

💬 Designing the experiment — the three questions your test must answer Everyone contributes ›
  • Question 1 — What are you actually trying to find out? One specific question, not "does our product work." Something answerable in 48 hours by talking to 5 real people. UX frames this question — it should connect directly to the riskiest assumption.
  • Question 2 — What is the simplest human interaction that gives you evidence? Not a prototype. Not a survey. A conversation, a text message, a sketch shown to one person. Engineer: push back if anyone says "let's build an app." Business: push back if it costs money. UX: push back if it takes more than a day.
  • Question 3 — What would change your mind? This is the part teams skip. You must name BOTH what a positive result looks like AND what a negative result looks like — in specific, observable terms. "Seemed interested" is not a result. "4 of 5 people said yes and asked when they could use it" is a result.
💡 The "what would change your mind" question reveals whether you've designed an experiment or a confirmation exercise. If the team can't name a specific negative result — they are afraid of being wrong. That fear is exactly why the experiment is necessary.
💬 5 user interviews
📋 Online survey
🎭 Wizard of Oz
📦 Concierge test
🖼 Fake landing page
📱 Paper prototype
🛠 Clickable mockup
📣 Social post / poll
🪙 Pre-sale / waitlist
Plan 3–5 test flights in order — cheapest first
Start with what you can do today with nothing. Only run the next test if the previous one gave a positive signal. Don't build the rocket first — fly a paper plane.

First Experiment — full brief

Structure your first test flight. Set your pass/fail threshold before you run it — not after.

We believe that… (the assumption being tested)
To find out, we will… (the experiment — as simple as possible)
We will measure…
We expect… (your prediction — set before you run)
⚖️ Set your go/no-go threshold now — before you run the test
✓ Validated — keep going if…
✗ Invalidated — reconsider if…
🚀 You're in Orbit

Mission Overview

Your idea has cleared the launchpad. Review, print, or email your summary.

✓ Copied!
① The Problem & The Idea
🔭
Ground Control
Three problem perspectives
User pain
—
Market gap
—
Technical challenge
—
📋
Pre-Launch Checks
What the product must do
UX requirement
—
Business model
—
Engineering approach
—
💡
The Big Idea
Where all three tracks converge
—
—
D V F
② The Design Hypothesis
🎯
—
Design Hypothesis
⚠️ Riskiest Assumption
—
🔬 If this is wrong…
—
Team confidence scores
—
③ Test Flight Sequence — 3 to 5 experiments in order
Run these experiments in order. Only advance to the next test flight when the previous one gives a positive signal. Each one gets you closer to evidence — or tells you to change course.
④ First Experiment — full test brief
We believe that…
—
To find out, we will…
—
We will measure…
—
We expect…
—
✓ Validated — keep going if…
—
✗ Invalidated — reconsider if…
—
⑤ Next Steps — what the team does after this session

Commitments before the next session

Assign a name and a deadline to each action. No item should take more than 2 days.