On this page
In short
- Define answers one question: what exactly are we building, for whom, and what are we not building?
- It's the stage most stalled products are really at, often while they spend as if they were at Market.
- Every idea is sorted into build first, later, cut or don't build. The cut list is written down, not implied.
- The stop line is set here, before the build, so the result can't be argued with afterwards.
Ideate ends with a problem worth solving. Define turns it into something a team can build without arguing about it every week. It's where we make the decisions that are cheap now and expensive later: who the product is for, what the first release does, what it leaves out, and what result would make us stop.
01What is the Define stage for?
Define is the second stage of Stuck-to-Scale. Its question has three parts, and each one is a decision rather than a description.
- What exactly are we building? The first release, specific enough that everyone agrees when it's done.
- For whom? The buyer, with the people it isn't for named just as clearly.
- What are we not building? The cut list, written down with a reason for each line.
Define is where most stalled products actually are. The misdiagnosis we see most often is a team at Define behaving as if it's at Market: spending on reach for a product whose buyer and scope aren't settled. Reach can't fix a definition problem. It just shows the problem to more people, at a higher cost per person.
02What does being stuck at Define look like?
| Signal | What it looks like | What it usually means |
|---|---|---|
| The roadmap grows every meeting | New ideas join; nothing ever leaves | Nobody has the authority, or the list, to cut |
| "It's for everyone" | The buyer is described as a market, not a person | The positioning will be vague, and so will the product |
| Features justified by competitors | "They have it, so we need it" | The product is being defined by someone else's buyer |
| Spending on reach too early | Ads, launches or a sales hire before the scope settles | A team at Define behaving as if it's at Market |
| The scope still moves mid-build | "Just one more thing" | The first release was never fixed, so it can't end |
03What do we decide at Define, and in what order?
The order matters. Each decision narrows the next one, so we don't move on until the one before it is written down.
- The buyer, with exclusions. Who it's for, and who it isn't. Exclusions do more work than descriptions: "not for enterprises with their own IT team" rules out a whole category of features in one line.
- The job and the success metric. What the buyer is trying to get done, and the one result that will show the product works. We agree the metric before any architecture, because the architecture should serve it.
- The scope. Every idea on the table goes through the Scope Cut: build first, later, cut, or don't build. Nothing stays unsorted, and "later" is a real category, not a polite way of saying no.
- The stop line. The kill criteria: the result that would make us stop, written before the build and shared with everyone who'll judge it.
- The position in one sentence. What it is, who it's for, and why it's different. It's the first layer of a brand, and every later layer rests on it, which is why Brand OS Layers starts at Define.
Before any of that, we name the cell. The Foundation Matrix crosses strategy, creativity and technology with judgement, craft and distribution, and every problem sits in one cell. A team that thinks it has a technology problem often has a strategy one: the product works, for the wrong buyer. Fixing the wrong cell is the most expensive mistake Define can make.
A scope without a cut list is a wish list.
04How did Define go on our own ventures?
apprn. Define gave apprn its spine: one verified event. An artist can only start a service by entering a one-time code sent to the customer with that booking. That single event feeds everything downstream: honest commission and salary, feedback that reaches the right artist, and a clear answer when owner and artist disagree. Around the spine, we defined what each person gets. Customers stay on WhatsApp, where booking and promotions run with nothing to install. Artists have their own app. Owners get one system for the rest.
Decision · apprn's customers install nothing
- What we chose: customers book and hear from the salon on WhatsApp. There's no customer app.
- What we gave up: a direct channel we'd control, and everything a customer app would let us collect.
- Why: salon owners and their customers don't think of themselves as software users. Every install is a place adoption can fail, so the product has to fit how they already work.
- What it protected: the one event everything depends on. The customer only has to receive a code and read it out.
otlo. otlo was defined as one arc, not a single point: people find a community, gather, keep coming back, and the builder can see what's working and do it again in the next city. We defined the whole arc, then built the first two surfaces: members management, and community pages with upcoming gatherings and the people who lead them. Defining the arc first told us what "later" meant, so later could wait without being lost.
05What does a Define document contain?
One short document, and five decisions in it. Each one protects the build from a specific failure.
| Decision | The question it answers | What it protects against |
|---|---|---|
| Buyer and exclusions | Who is it for, and who isn't it for? | A product that tries to please everyone |
| Success metric | What result shows it works? | A launch judged on how it feels |
| Scope Cut | What's in the first release, what's later, what's cut, what's never? | A first release that can't end |
| Stop line | What result would make us stop? | Moving the goalposts after the result is in |
| Position | What is it, who is it for, and why is it different? | Copy that could belong to anyone |
The test of a good one: a new engineer and a new salesperson read it separately, and describe the same product.
06Why write down what you won't build?
Because every idea that didn't make the first release will come back, usually from a good customer or a senior colleague, and usually at the worst moment in the build. Written down with its reason, "later" and "cut" are decisions, and a decision can be pointed to. Unwritten, they're ideas waiting for a meeting.
The cut list is also what makes a fixed scope possible. We work to a fixed scope and a fixed end date, and changes after Define are priced, never silently absorbed. That only works if everyone agreed, in writing, what the scope left out.
Insight
Scope is a promise, not a guideline. The cut list is how you keep it.
With the definition written, the question changes again: does the thing exist, and does it work? That's Build.
07Questions founders ask about Define
Is Define the same as writing a requirements document?
A requirements document lists what to build. Define also decides who the product isn't for, what's cut, and what result would stop it. Those three decisions are what keep a requirements document short.
Who needs to be in the room?
The person who decides, and the people who'll build and sell the product. We force decisions in working sessions, so a definition that still needs a committee to approve it isn't finished.
We've already started building. Is it too late to define?
No, and it's often the most valuable moment to do it. If the scope still moves, you're at Define whatever the plan says. Naming that is cheaper than building the wrong thing for longer.
How detailed should the first release be?
Detailed enough that everyone agrees when it's done, and small enough to prove the success metric. If it can't prove the metric, it's too small. If it tries to prove three things at once, it's too big.
Where this fits