Strategy & Prioritization · Method
Design Principles
Pre-committed tradeoffs that decide, in advance, how a team will choose when a hard choice arrives, and what it has agreed to say no to.
Time required
2–3 hours to derive; revisited when strategy or product stage changes
Group size
The team that faces the recurring choices — not representatives, the decision-makers themselves
The visual
A principle is a fork with one branch closed
A design principle is not a value. It is a pre-committed decision about a specific recurring tradeoff — made before the hard choice arrives, by the people who will be held to it, with the sacrifice explicitly named.
Visualised as a fork, the principle sits on the incoming path. At the junction, one branch is taken and one branch is closed. The closed branch — the thing the team has agreed to say no to — is the point. Without a closed branch, you have not written a principle. You have written a platitude.
The tests
Two tests: arguability and closure
A valid design principle must pass two tests. It must close a branch, and it must be arguable. Together, they filter out everything that sounds good but decides nothing.
Test 1: closure
Bring a real choice to the fork. Does the principle close one branch?
Take the last real disagreement your team had. Apply the principle. Did it decide the question unambiguously, or did both routes through the fork remain open? If both remain open, the principle is not doing work. It is decoration.
Test 2: arguability
Can a reasonable person argue the opposite and be taken seriously?
“Be user-centred” fails this test: no reasonable person advocates user-hostility. “We favour speed over configurability, even when power users ask for options” passes it: many excellent products chose configurability over speed and won. If the opposite cannot be defended, the principle is not describing a real choice — it is describing a preference so universal it constrains nothing.
The combined test
If it passes arguability but fails closure: you have identified the right territory but not yet committed to a side. Keep working. If it passes closure but fails arguability: the choice it makes is trivially obvious and nobody was going to make the other choice anyway. If it passes both: you have a principle.
The failure mode
Why platitudes proliferate
Platitudes proliferate because they are easy to agree with. A platitude has no enemies. It survives every review, because nobody can argue against “be user-centred” or “delight our customers” without sounding cynical. That is precisely what makes them useless.
The mechanism of failure is social. In a workshop, a principle that names a real sacrifice will be challenged immediately by everyone whose interests are on the wrong side of the fork. A principle that closes nothing faces no such challenge. It gets unanimous agreement, goes on the wall, and decides nothing when the next hard choice arrives.
The warning sign is unanimous agreement at the moment of writing. If everyone in the room agrees with the principle without discussion, check whether it names a sacrifice. If it does not, you have written something that costs nothing to agree with — and will give nothing back when you need it.
A useful test in the room
Before the session ends, read each candidate principle aloud and ask: “Who in this room would argue the opposite?” If nobody raises their hand — not because everyone agrees, but because the opposite is impossible to defend — you have written a platitude. Try again.
Derivation
Start from the recurring argument
The best source for a design principle is a decision your team keeps making badly, slowly, or inconsistently. Not a hypothetical tradeoff someone invents in a workshop — a real argument that surfaced three times in the last quarter and never stayed decided.
The derivation question is: what is the real tension underneath the repeating argument? Two people disagree about a feature. Why, specifically? One believes the product should serve power users. One believes it should serve new users. That tension is the principle waiting to be named. The feature debate is just the surface.
Once the tension is named, the next question is: which side does this team commit to? Not in theory — in the next version of the product, given what we know about our users and our strategy. That commitment, written with the sacrifice explicitly stated, is the principle.
Step 1
Collect the last 3–5 decisions your team found difficult, slow, or where the answer kept changing. These are the candidates. Do not invent hypothetical tensions.
Step 2
For each one, ask: what is the underlying tension? Not the surface feature, the competing value underneath it. Speed vs. quality. Expert vs. new user. Breadth vs. depth. Name it as a pair.
Step 3
Commit to a side. Write the principle in the form: “We [do A], even when [the pressure to do B arrives].” The second clause names what you are giving up. Without it, you have not committed.
Step 4
Run both tests. Bring a real scenario to the fork — does it close a branch? Ask the room to argue the opposite — does someone genuinely believe the other side? If both pass, you have a principle.
Language
“Even when” is the whole principle
The most important words in a design principle are the ones after the comma. “We optimise for the first-time user” is a preference. “We optimise for the first-time user, even at the expense of the expert” is a principle. The sacrifice clause is what makes the commitment real.
A good formulation names the highest-pressure exception the principle will face — the case that will most tempt the team to abandon it — and commits in advance. If the principle would not hold under that pressure, it is not a principle. It is a preference that bends.
Aim for a single sentence that contains the commitment and the sacrifice. Principles that require two sentences to state often contain an unresolved tension in the middle — they are two competing principles sharing one slot.
The anatomy
“We favour speed over configurability, even when power users ask for options.”
Commitment
The branch you take — stated in terms of what you are optimising for
Sacrifice
The branch you close — named explicitly, including the pressure that will test it
Pressure
A principle is tested when the pressure arrives
A principle that has never been tested is a hypothesis. You do not know yet whether it is a principle or a preference. The test arrives the first time someone influential asks for something that is on the wrong side of the fork — and it is compelling.
If the principle holds, two things happen: the decision is made faster, because the reasoning was done in advance. And the team learns that the principle is real — that they are actually committed to what it says, not just to the words on a wall.
If the principle does not hold — if the team votes to make an exception, or silently drifts to the closed branch — that is also information. It does not mean the principle was wrong. It means either the strategy has shifted (update the principle) or the team was not genuinely committed to it in the first place (do the harder derivation work again).
The exception question
Every team eventually faces someone who argues “this case is different.” It usually is, in some specific way. The principle does not have to be applied robotically — but it does have to be the starting position, and overriding it requires a conscious decision, not just the loudest voice in the room. If you find yourself regularly making exceptions, the principle no longer reflects your actual commitments. Revisit it.
Maintenance
Principles have a shelf life
A principle written for an early product may be wrong for the same product at scale. “Optimise for the first-time user” is an excellent principle when you are in acquisition mode. It may be the wrong principle when your growth is driven by expansion within existing accounts, and experts are the ones with the budget.
The trigger for revisiting a principle is not elapsed time but changed conditions: a shift in business model, a shift in who the primary user is, a shift in competitive position. Revisiting does not mean abandoning — it means running the derivation process again and asking whether this is still the right side of the fork to commit to.
Principles that are never revisited eventually become dogma. The team applies them past the point where they are right, because nobody questions what has been on the wall for three years. Schedule a deliberate review when major strategy decisions are made, not on a calendar cadence.
Try it
Bring a candidate principle to the fork
Select one of the five candidates below. Real principles close a branch and pass the arguability test. Platitudes close nothing — the fork stays undecided.
When to use
When the same argument keeps coming back
Design principles are worth deriving when a team is making the same type of decision repeatedly and reaching inconsistent conclusions — or when decisions that should be fast are consuming hours of senior time in every planning cycle.
Right moment
- —The same tradeoff keeps surfacing in planning sessions
- —Different people are making similar decisions differently
- —The team is scaling and making decisions without the founders
- —A major product direction is being set and commitments need to be documented
Wrong moment
- —You have not yet made enough product decisions to know what the real tensions are
- —Strategy is changing so fast that commitments would be outdated in weeks
- —The team wants to feel aligned without doing the work of actual alignment
- —It is used as a substitute for a specific decision that is being avoided
On quantity
Most teams need three to five principles, not twenty. Each principle should cover a distinct, recurring decision type. If you have ten principles, check whether they are all distinct — teams often generate many statements that collapse onto the same underlying tension, restated in different language.
AI & this method
When AI helps and when it misleads
AI produces polished, balanced principles by design. At the fork, that means both branches remain open — the fork is always undecided. Here is where the boundary runs.
Example
A product team and a power-user problem
A team faces a recurring argument about configurability. The traditional tab shows the derivation method working. The AI tab shows what happens when the process is shortcut — and where AI genuinely earns its place.
Shared scenario
A product team has built an early product for first-time users. It is working: adoption is healthy, users complete their tasks, the feedback is mostly positive. Then come the power users. Their requests are consistent and reasonable-sounding: more configurability, more options, the ability to adapt the tool to advanced workflows. The team must decide whether to build it. The decision keeps coming up, consuming the same hour in every planning session, landing in the same unresolved place. They need a principle.
Both tabs start from the same recurring argument. Only the derivation method differs.
Derive from the recurring argument
The team mapped the recurring argument. Every time the power-user requests came in, the same sub-discussion surfaced underneath them: should the product be primarily for the new user or for the expert? Nobody had ever decided. They had built a product for new users, but nobody had actually committed to it in writing, in a form that could hold when someone arrived with a compelling counter-case.
Name the sacrifice explicitly
After two sessions, they had a candidate principle: “We optimise for the first-time user, even at the expense of the expert.” The second clause — “even at the expense of the expert” — was the hard part, and it was the whole point. Without it, the principle was just “be good for users” and it closed nothing. With it, it named what they were giving up.
The principle working under pressure
The next time a large customer asked for a power-user feature, a customer who was vocal and important, the team ran the principle. The feature would improve expert efficiency at the cost of first-time clarity. The principle had already decided: the answer was no. There was no hour-long debate. The customer was disappointed. The principle held. The product did not drift.
The arguability test as a check
They checked it: could a reasonable team argue the opposite? Yes — many products had been built the other way and had succeeded. Bloomberg Terminal, Adobe Photoshop, Microsoft Excel all chose the expert over the first-time user and won. The opposite was defensible. That confirmed it was a principle, not a platitude. It described a real, contested choice that the team had now committed to explicitly.
What this taught
The principle did not change the answer — it made the answer pre-computable. The same situation had come up eight times in the previous six months. It had consumed the same hour each time and reached no durable conclusion. After the principle, the same situation took four minutes.
Connections
Where this sits in the wider work
Frameworks
Principles derived in the Define phase anchor the Develop phase against feature drift — they are the boundary conditions that govern what the team builds next.
In Design Thinking, the Define phase closes in on a problem statement. Design Principles extend that closure into the solution space — they constrain what counts as a valid answer.
Sprints start by agreeing a long-term goal and then mapping the critical path. If design principles already exist, Monday’s goal-setting is faster. If they do not, the sprint often surfaces the recurring tensions that become them.
Principles give the team something stable to plan against and review decisions against — without them, each sprint carries the cost of redeciding the same tradeoffs.
Related methods
The closest sibling. The Cascade answers “what will we win at” and “where will we play.” Design Principles answer “how will we choose when the choice arrives.” Together they form a complete strategic pre-commitment system.
A design principle can govern which lens gets prioritised when desirability, feasibility, and viability pull against each other. The principle makes explicit which tradeoff the team makes when two lenses conflict.
Concept testing surfaces what users actually respond to — which often conflicts with the team’s existing commitments. Design principles help the team decide whether to update the principle or resist the pull of a local user preference.
Orthodoxies surfaces the assumptions the industry treats as given. Design principles can be built by questioning them — a principle that commits against the orthodoxy is often the most powerful and the most contested.
Different innovation horizons require different principles. What is the right principle for a core product may be the wrong one for a new venture. Mapping your portfolio across the matrix surfaces where the same principle needs to hold — and where it does not.
Strategy & Prioritization — Method 8 of 9
40 methods across 6 stage groups