Every word and structure we ship is a small promise. Call something a “workstream” today and thousands of people learn to think in that word; rename it next year and you’ve broken their map, retrained their teams, and turned entering the next industry into a rebuild. So we’re deliberate to the point of stubbornness about what we introduce — and slow, on purpose, to add.
Start with the least that works#
The temptation is to ship the most you can imagine — every concept, every setting, the whole grand vision in the first release. We do the opposite. We start with a small, plain, universal set of ideas: the least that works everywhere, not the most we can picture. Fewer concepts, chosen carefully, cover more ground and confuse fewer people — and they leave room to grow without contradicting what came before.
Stability is treated as a feature, not a lack of ambition. Core names and structure change rarely and deliberately — a versioned decision, never a casual one — because every change taxes the people who already rely on us. One idea gets one word; we don’t introduce synonyms for a concept just because a new team prefers a different name. A project lane is a workstream, full stop. Less vocabulary, less confusion, cheaper to keep stable.
What a rename actually costs#
It is easy to underrate, because the visible cost is a find-and-replace and the real cost is somewhere else entirely.
A name that has been in use for a year exists in places the vendor does not control. It is in the customer’s internal training deck, their onboarding checklist, the standard operating procedure someone wrote and had approved, the ticket titles their support team searches, and the shorthand two people use in a corridor. Changing it in the product does not change any of those; it desynchronises them. For a while afterwards, every one of those artefacts is quietly wrong, and the people relying on them do not know which of the two words is current.
In regulated settings the cost compounds, because some of those artefacts are controlled documents. A term that appears in an approved procedure cannot be updated on a whim — it goes through the same review as anything else. So a rename that took an afternoon in the codebase can take a quarter on the customer’s side, and they did not ask for it.
This is why we treat naming as a versioned decision with an owner rather than a design preference. Not because names are sacred, but because the bill goes to someone else.
Grow on evidence, not imagination#
New capability earns its way in. We add when real users show us a gap — and the sharpest signal is the moment they have to leave the product to get something done. “What made you leave?” is our priority list for what to build next, and it beats any roadmap drawn from imagination. It also keeps us honest about the unglamorous part: we build for the durable middle — the everyday, repeated use — not just the exciting first screen or the far-off end state. The demo is easy to polish; the daily grind is what actually earns and keeps trust.
The leaving signal is useful precisely because it is behavioural rather than stated. Asked what they want, people describe features they have seen elsewhere. Observed leaving, they show you the seam — the point where the product stopped being sufficient for the job they were actually doing. The first produces a roadmap that resembles a competitor’s marketing site. The second produces one that resembles the work.
The objection worth taking seriously#
The fair criticism is that this is a philosophy that rewards being slow, and that a company can hide behind it for years. Every feature not built has an explanation ready-made: no evidence yet.
It is a real risk and the honest answer is that the discipline has to cut both ways. Evidence-led means we are obliged to build the thing when the evidence arrives, not merely permitted to wait until it does. A gap that several users have hit, and left the product to solve, is not a candidate for further observation. If “grow on evidence” only ever produces reasons to defer, it has stopped being a method and become a temperament.
The second objection is commercial, and sharper: a small vocabulary and a short feature list lose comparisons. A buyer with a requirements matrix is counting rows, and a product built on the least that works everywhere will have fewer rows than one built on the most that can be imagined. We lose some of those, and we know why we lose them.
The trade is deliberate. A row on a matrix is won once. A vocabulary that did not change under someone’s feet is won every day for years, and it is the reason the second and third deployment inside the same organisation cost a fraction of the first. We would rather be chosen slightly less often and be re-chosen without a conversation.
How to check this#
Ask a vendor what they have renamed in the last two years and what it cost their existing customers. Ask what they declined to build recently and why. Ask which of their concepts has more than one name in the product today — the answer is rarely zero, and how readily they know it tells you whether anyone is watching.
None of this is caution for its own sake. A small, stable core that grows on evidence is what lets the same product serve a lab, a factory, and a marketing team without fracturing — and lets a small company enter a new sector cheaply instead of rebuilding each time. Start conservative. Grow on evidence. It’s slower to look impressive, and far faster to become something people can trust for years.