All Gas No Brakes

Compounding goes both ways

Sun, 11 Feb 2024 00:00:00 GMT

The reason compounding is hard to act on isn’t that people doubt the maths. It’s that the daily increment is always below the threshold of noticing.

Nobody chooses to erode user trust. They ship one email that’s slightly more aggressive than the last, and it performs, so the next one is slightly more aggressive than that. Two years later the list is large and dead, and no single decision in the chain looks like the culprit.

The ledgers nobody opens

Three accounts compound in most companies, and typically one is instrumented.

Technical debt is the tracked one — badly, but tracked. It has tickets.

User trust has no ticket. It moves on things that never reach a dashboard: whether the cancel flow is honest, whether the incident post said what actually happened, whether the price changed quietly. It is slow to build, and it doesn’t decay linearly — it holds, then goes.

Culture is the same shape. It is the average of what got tolerated, not what got written down. One person shipping without review, unremarked, is the new standard by the following quarter.

An incident report that names the actual cause is the concrete version. In the moment it costs something real: it hands a competitor a quote, it invites a harder question from a customer, it is strictly worse than the vague version for this week. What it buys is that the next time you say something is fine, someone believes you. There’s no way to buy that quickly, and no way to keep it after one report written to reassure.

Where it breaks

The long view is also the most respectable way to avoid shipping.

“Optimise for ten-year effects” is unfalsifiable in the present tense, which makes it perfect cover. Refactors nobody asked for, a rewrite justified by maintainability, six weeks on a design system for a product with forty users — all defensible as compounding, all indistinguishable from procrastination while you’re inside them.

And compounding assumes survival. A company with nine months of runway does not have a ten-year decision to make; it has a nine-month one. Advice about decades is disproportionately written by people who already cleared the survival filter, which is the same survivorship problem that makes luck advice unreliable.

The honest version is narrower: a small number of things compound, most don’t, and the compounding ones are usually cheap per unit. Writing the incident report honestly costs an hour. Not adding the dark pattern costs a conversion point. Reviewing the pull request costs twenty minutes. None of these are the six-week refactor, and the six-week refactor is the one that gets justified this way.

The test

Ask whether the thing accrues on its own once started, or needs continuous spend. Trust accrues. A design system does not — it decays without staffing.

Then ask what the daily increment costs. If it’s an hour, it is probably real compounding. If it’s a quarter, it is a project wearing compounding as a costume.

Takeaway: optimise for 10+ year effects.

The founder is the thermostat

Sat, 23 Dec 2023 00:00:00 GMT

A team reads its founder’s state continuously and adjusts to it. Not the stated priorities — the tone of the message sent at 11pm, the impatience in a review, the week where every decision got reopened.

Which means your condition isn’t a private matter. It’s an input to everyone else’s work, and it propagates faster than anything you actually say.

Burnout is a leverage problem

The reason to take this seriously isn’t wellbeing language. It’s that a depleted founder makes worse decisions and makes more of them — the two failure modes arrive together, because tiredness both degrades judgement and removes the patience required to delegate, so you end up personally handling more while handling it worse.

The compounding runs the wrong way. Every decision you retain because delegating feels slower today is a decision you’ll retain forever, and the set only grows.

What protects the bandwidth is unglamorous and known: sleep first, movement, some regular block where you’re not reacting. Not optimisation — maintenance. The genuinely hard one is delegation, because it requires accepting outcomes that are worse than yours for a period, and most founders would rather be tired.

What makes handing something over actually stick is transferring the rule rather than the decision. Answering “what would you do here?” each time keeps the work exactly where it was. Writing down what you’re optimising for, what you’d never accept and where the line sits means someone can reach a decision you’d have reached, without asking. The first few will differ from yours. Review them afterwards rather than before — reviewing before is the old arrangement with an extra step.

Where it breaks

The sustainable-pace argument is often made in a way that doesn’t survive contact with an actual startup.

There are periods — a launch, a migration, the month before a raise — where the correct choice is to spend yourself and recover after. Everyone who has built something knows this and the advice literature won’t say it, which is why the advice reads as written by people describing a company rather than starting one. The claim isn’t that intensity is avoidable. It’s that intensity has to be bounded and followed by real recovery, and the failure is the unbounded version that becomes the permanent operating mode.

“Delegate ruthlessly” also assumes there’s someone to delegate to. At four people there frequently isn’t, and the honest answer for that stage is that you carry more than is sustainable and the fix is hiring, not routine.

And the thermostat framing has a cost of its own. Told your emotional state is a company input, some founders start performing calm — which the team reads instantly as inauthenticity and trusts less than visible strain. Managing your state is not the same as concealing it.

Takeaway: sustainable founders build sustainable companies.

Craft compounds

Fri, 08 Dec 2023 00:00:00 GMT

Nobody adopts a product because the error messages are well written. But the person who hits three well-written error messages in a week forms a belief about whether the thing was built by people who were paying attention, and that belief determines how much benefit of the doubt you get on the day something breaks.

That’s the actual mechanism. Craft doesn’t win users. It buys the credit you spend during your worst week.

Care is legible

People read details as evidence of what they can’t see. A form that keeps your input after an error implies someone thought about failure. A changelog written in plain language implies someone respects the reader. An empty state that explains what goes there implies the team used their own product.

None are features. All are signals, and users are good at reading them, because it’s the only information available about the parts of your system they’ll never inspect.

The discipline is boring

Tests you actually maintain. Reviews that catch design problems, not formatting. Refactors sized to fit inside a normal week rather than saved up into a quarter nobody approves. The point of all three is the same: keep the cost of the next change low, because momentum over years is a function of that cost and almost nothing else.

The cancellation flow is the sharpest single test. It’s where a company’s actual attitude to the people paying it becomes legible with no marketing on top — whether the button is findable, whether it takes one click or four screens, whether it asks why in a way that helps or a way that delays. Nobody reads a cancellation flow before signing up. Everybody remembers one, and tells other people about it.

Where it breaks

Craft is the most respectable available reason not to ship.

Every hour on polish is defensible, which is exactly the problem — it means the decision never gets challenged. Startups die with beautifully factored codebases serving no one, and each individual refactor along the way was justified. The work looks like progress from the inside and satisfies the same instincts as real progress, which is what makes it dangerous rather than merely wasteful.

There’s a second version: craft as a proxy for taste in things nobody else values. Deep consistency in an internal admin tool. A perfect design system for forty users. Real skill, correctly applied, to something that will never be noticed. It compounds nothing because nothing was accruing.

And the compounding claim only holds if the thing survives. Code deleted in six months returns nothing on the care invested — which argues for craft concentrated in the parts you’re confident are permanent, and deliberate roughness everywhere else. Most teams apply it uniformly, which means over-investing in what gets thrown away and under-investing in the core they’ll live with for a decade.

Takeaway: respect craft; it compounds credibility.

Scale the right parts

Wed, 06 Dec 2023 00:00:00 GMT

Ten times the load does not mean ten times the system. It means a different system, because somewhere between here and there a constraint that was invisible becomes the only thing that matters.

The work is figuring out which one, early enough to be cheap and late enough to be real.

Fragile on purpose

Not everything needs to be robust, and pretending otherwise is how small teams spend a year building for a scale they never reach.

Decide deliberately which components are allowed to be fragile. The admin tool that three people use can fall over. The nightly job can be manual. What must not fall over is the path that touches customers, and the data you cannot reconstruct.

Stating this out loud matters more than the choice itself. Undeclared fragility is the thing that surprises you at 3am; declared fragility is a known cost with a known blast radius.

Degrade gracefully

The interesting question is never whether a dependency fails. It’s what the system does during the failure.

Serve stale rather than nothing. Queue rather than reject. Fall back to a worse answer that arrives, rather than a better one that doesn’t. For anything real-time this is the difference between a degraded experience and a broken one — a voice agent that says “one moment” is in a different category from a voice agent that says nothing.

It is almost never CPU, which is what gets optimised. It’s a connection pool ceiling, a single table every write passes through, a third-party rate limit nobody read the docs for, a queue with no dead-letter path retrying the same poisoned message forever. The pattern holds: the real constraint is usually a limit somebody else set, sitting somewhere with no dashboard, found at the worst available moment.

Where it breaks

Premature scaling is the famous mistake. The less famous one is that scaling advice is written by people who reached scale, and their constraints are not yours — architecture that makes sense at a million users is often actively worse at a thousand, because it trades simplicity for headroom you don’t need and can’t yet operate.

There’s also a limit to foresight. You cannot reliably predict which component breaks first; load has a way of finding the thing nobody modelled. Time spent designing for the wrong constraint isn’t just wasted, it adds structure that makes the real fix harder. Past a certain point, the better investment is not a better prediction but a faster feedback loop — good enough observability that when the real constraint shows up, you find it in an hour.

Which turns “plan for scale” into something narrower and more defensible: keep the blast radius small, keep the data recoverable, keep the system legible enough to change quickly. Then wait to be surprised.

Takeaway: scale the right parts, not everything.

Features need stories

Sat, 18 Nov 2023 00:00:00 GMT

Give someone a list of capabilities and they have to do the assembly themselves — work out which parts apply to them, in what order, to what end. Most won’t. Not from laziness; the assembly requires knowing the product, which is the thing they don’t have yet.

A story does the assembly for them. Someone like you, in a situation like yours, did this, and afterwards this was different.

Three parts, in order

What you can do. Why it matters. What success looks like.

The third is the one that gets dropped, and it’s the one that makes the other two legible. “Set up call routing” is a task. “By Friday, no caller waits more than twenty seconds and you stop checking the queue at night” is an outcome someone can want.

The same structure works internally, which is the underrated half. A team that can state the story — who this is for, what changes for them — makes consistent decisions about a hundred small things nobody will ever spec. A team that has only a backlog makes a hundred locally reasonable choices that don’t add up to anything.

Amazon’s working-backwards memo is the mechanised form: write the press release and the FAQ before any code, and if the release reads as boring then the feature is boring and nobody has to build it to find out. The value isn’t the document. It’s that stating the outcome first makes it obvious when the outcome was never really the point — a discovery that costs an hour on paper and six weeks in a sprint.

Where it breaks

Narrative is a compression, and compression discards.

A good story is coherent, and coherence is not a property of reality. The tidy arc — problem, insight, solution, transformation — is available for almost any set of facts, including a wrong one, and it gets more persuasive as it gets further from the mess. Teams that tell their story well can talk themselves past evidence for years, and the better the storyteller, the longer it runs.

There’s a specific version in product work: the narrative starts driving the roadmap. Something is built because it completes the story rather than because anyone needed it. The feature that “rounds out the vision” is usually this.

And stories are how software gets oversold. The gap between the story and the product is where trust is spent — a customer who bought the narrative and met the software will not extend credit twice. In a category with real limitations, which anything AI currently is, the temptation to narrate past them is constant and expensive.

The check: can you tell the story with the failure modes included and have it still be worth buying? If yes, tell it. If it only works with the caveats removed, the problem isn’t the storytelling.

Takeaway: translate features into user stories.

Small, honest experiments

Mon, 04 Sep 2023 00:00:00 GMT

An experiment without a stated hypothesis isn’t an experiment. It’s a change, followed by a search for a number that improved.

The discipline is entirely in the order. Hypothesis, then metric, then the smallest test that could move it — written down before the work, where they can embarrass you afterwards.

Write the losing condition

The clause people skip is the one that matters: what result would make you revert.

Without it, every outcome gets absorbed. Up means it worked. Flat means the test was underpowered. Down means something else interfered. All three are available after the fact, and all three feel reasonable, which is why they get used.

Deciding in advance costs nothing and is the only thing standing between an experiment and a rationalisation.

Smallest viable test

Most questions don’t need an A/B test. They need a fake door, five user calls, a manually operated version for a week, or a change shipped to one account with the outcome watched by hand.

A/B tests are expensive in traffic and slow at low volume — below a certain scale they cannot resolve anything you’d act on, and running them anyway produces confident conclusions from noise. Small products should be running qualitative tests almost exclusively, and often aren’t, because a significance number looks more serious in a deck.

The cheapest useful test is usually doing the job by hand. Before building routing logic, route it manually for a week and find out whether the outcome anyone promised actually shows up. Before building a dashboard, mail the numbers round and see if a single person reads them. A fake door — a page for a plan that doesn’t exist yet — answers a demand question in a day. None of these produce a p-value, and all of them beat a test you haven’t the traffic to run.

Where it breaks

Experimentation optimises what it can measure over a horizon it can observe, which makes it structurally conservative.

It reliably finds local improvements — the better button, the shorter form — and reliably rejects anything whose value appears after the measurement window. Nothing that takes three months to matter survives a two-week test. Teams that run entirely on experiments drift toward a product that is well-optimised and directionless, and each individual decision along the way was evidence-based.

There’s a quieter version of the problem. Run enough tests and some win by chance; ship those, and you accumulate a product built partly on noise, with no mechanism that ever removes them. Re-testing old wins is unglamorous and almost never done.

So experiments answer “is this version better than that one”, which is a narrow question. They do not answer what to build, which direction to go, or what the product is for. Those come from judgement, and dressing judgement in experimental language doesn’t improve it — it just makes it harder to argue with.

Takeaway: test assumptions before scaling.

Failure is data

Sat, 03 Dec 2022 00:00:00 GMT

“Fail fast” is repeated by people who have not made failing cheap, which is the part that requires actual work.

A failure is only data if you can see what happened, absorb it without losing something that matters, and change something as a result. Without those three, failing fast is just failing at speed.

Cheap requires machinery

Visibility first. A failure nobody noticed teaches nothing, and most systems fail silently for a while before they fail loudly. Instrumentation is what converts an incident into information.

Then containment. The failure has to be survivable — the feature flag, the canary, the backup you have actually restored from rather than merely configured. Every one of these exists to lower the cost of being wrong, which is what makes being wrong affordable often.

Then the loop. Post-mortems that assume systemic causes, because “someone was careless” ends the investigation exactly where it should start. The useful question isn’t who merged it. It’s what made it possible to merge, and what would have caught it.

Backups are the honest test of all this. Nearly every team has them; a much smaller number have ever restored from one. Until you have, you don’t have backups, you have files — and the failure that teaches you this costs whatever the gap between those two things is worth. The mechanism that follows is unglamorous and specific: a scheduled restore into a scratch environment, on a calendar, run by someone who didn’t set it up.

Where it breaks

Not all failure is instructive, and treating it as though it were is how teams normalise being bad at things.

Some failures are just cost. The outage caused by skipping a review you knew you should do teaches nothing you didn’t already know; it converts a known obligation into an expensive reminder. Filing it as “learning” launders it. There’s a real difference between a failed experiment — designed, bounded, informative whichever way it goes — and a preventable mistake dressed up in the same language afterwards.

The blameless framing has a matching failure. Taken absolutely, it removes the possibility of anyone being accountable for anything, and people notice. The version that works separates the two: no blame for the failure, ownership of the fix. The person closest to it drives the change. That’s not punishment, and teams read the difference correctly.

And speed has a floor. In systems where failure reaches someone real — payments, health, a voice agent talking to a customer at 2am — the correct rate of failure is low, and getting there means slower, more boring engineering than the slogan suggests. “Fail fast” is advice for the cheap tier. Knowing which tier you’re in is the whole judgement.

Takeaway: fail fast, learn faster, ship forward.

Hire for judgment

Mon, 19 Sep 2022 00:00:00 GMT

The first several people you hire are not adding capacity. They’re adding decisions — hundreds of small ones you’ll never see, made when you’re not in the room, that collectively become the product.

Which makes judgement the thing you’re buying, and it’s a poor fit for an interview process built to assess skill.

What to look for instead

Ask about decisions with incomplete information. Not “tell me about a hard project” — “tell me about a call you made without enough data, and what you’d do differently”. You’re listening for whether they can reconstruct their own reasoning, distinguish a bad outcome from a bad decision, and describe the trade-off they chose to accept.

Curiosity shows up as unprompted depth. People who are actually curious have gone further into something than their job required, and they can’t help revealing it.

Culture-add over culture-fit, because fit is a hiring manager’s comfort dressed as a criterion, and it compounds toward a room where everyone shares your blind spots.

Onboarding is a product

Teach principles rather than procedures. Procedures answer the cases you anticipated; principles let someone handle the ones you didn’t, which is most of them. Someone who knows why the deploy process looks like that can adapt it. Someone who knows only the steps files a ticket and waits.

There’s one tell worth listening for. Ask about a call that turned out badly and most people offer either the defence or the confession. The useful answer separates the decision from the outcome: here’s what I knew, here’s what I’d have needed, here’s why the process was sound even though the result wasn’t — or why it wasn’t sound. Someone who can hold that distinction under mild pressure will make good calls with you nowhere near the room.

Where it breaks

“Hire for judgement” is nearly unfalsifiable at the point of decision, and it licenses a lot of bad practice.

Judgement is assessed through conversation, and conversation rewards people who present like the people already there — articulate in the same register, similar background, comfortable narrating their own competence. Interview processes built around it are measurably less consistent than skills-based ones, and “great judgement, couldn’t articulate it” is a sentence that mostly doesn’t get said about candidates who interview like the panel.

Culture-add has a matching gap. Everyone endorses it; almost nobody has decided what specifically is missing from the room. Undefined, it becomes a slot for whichever difference feels safe, which is how a company hires for diversity of background and none of perspective.

And judgement is domain-bound more than the framing admits. Someone with excellent judgement about enterprise sales cycles may have none about consumer retention, and it takes a year to find out. Skills transfer poorly; judgement transfers worse, and it’s much harder to test for.

Takeaway: hire for leverage and teach autonomy.

Attention is the budget

Fri, 12 Aug 2022 00:00:00 GMT

Software is costed in engineering weeks. It is paid for in user attention, and nobody keeps that ledger.

A notification costs a context switch. A new tab in the navigation costs a scan on every visit, forever, from everyone. A setting costs a decision. These are small individually and they are charged to every user on every session, which makes them the largest recurring expense most products have.

Session shape

Design around how long someone actually has, not how long you’d like them to stay. A tool used in four-minute gaps between calls needs to resume where it left off, hold no state in the user’s head, and complete something in four minutes. The same tool designed for a leisurely half-hour is unusable in the gap, and the gap is where it’s actually opened.

Interruption is the expensive one. Recovering a train of thought after a context switch takes minutes, not seconds, so a notification that saves someone thirty seconds of checking has still cost them more than it gave — unless it’s genuinely urgent, and almost nothing is.

Batching beats immediacy nearly everywhere. Digest over ping. Async over meeting. Nothing over digest, most of the time.

Onboarding tours are the standard removal. They go in during a week, almost nobody finishes one, and every user pays the interruption on their first and most fragile visit. Taking one out usually moves nothing measurable, which gets read as proof it didn’t matter — when it is really proof that the cost was carried by people who never became users, and so never appeared in the numbers anyone was watching.

Where it breaks

“Respect attention” is easy to say and structurally disadvantaged, because attention-respecting choices show up as flat numbers.

Remove the notification and engagement drops. It drops whether or not the product got better, and the dashboard cannot distinguish the two. You’ll be arguing a qualitative case against a quantitative one, quarterly, and mostly losing. That’s the real reason products get noisier — not villainy, just asymmetric evidence.

The principle also gets misread as minimalism. Fewer features is not the same as less attention spent. A product stripped so far that people need three tools and manual copying between them has increased total cost while looking clean. Sometimes the attention-respecting move is a dense, information-heavy interface that lets an expert see everything at once. Airline crews don’t want progressive disclosure.

And it cuts both ways internally. Protecting focus blocks and going async is right for deep work, and it is genuinely worse for the fast, ambiguous conversations where a five-minute call replaces two days of thread. Teams that adopt async as an ideology rather than a default trade interruption for latency and call it discipline.

Takeaway: design for sustained attention, not maximal engagement.

Empathy is discovery, not projection

Tue, 26 Jul 2022 00:00:00 GMT

The word empathy does a lot of damage in product work, because it lets people imagine the user instead of meeting one. Sitting quietly and picturing someone’s frustration is not empathy. It’s fiction with a flattering name.

The version that works is unglamorous: ask people what happened, in order, last time.

Stories, not solutions

“What would you like this to do?” returns a feature request, filtered through what the person believes is buildable and what they think you want to hear. “Walk me through the last time you had to do this” returns a sequence of events, including the parts they’ve stopped noticing.

The interesting material is always in the parts they’ve stopped noticing. The tab they keep open. The colleague they ping to check a number. The step they do twice because once it silently failed and they never trusted it again.

Nobody reports these. They aren’t complaints anymore; they’re just the job.

Edge users carry the constraints

Spend disproportionate time with the people the product fits worst — the highest volume account, the one on a bad connection, the one whose compliance team reads everything. They surface constraints that everyone has and only they have hit hard enough to articulate.

Design for the median and the edge breaks. Design for the edge and the median is usually fine.

The useful remark almost never arrives as feedback. It sounds like “I keep that tab open so I can copy the ID across” — said in passing, as background, because it stopped being a problem years ago and became part of the job. Nobody files a ticket for it. It won’t appear in any survey. And it names a missing thing more precisely than anything in the backlog.

Where it breaks

Two ways, and both are common.

Edge users can capture the roadmap. The one demanding, articulate account is not more representative for being louder. Some constraints they surface are universal; some are theirs alone, and the difference is not visible from inside a single interview. If you can’t find a second customer with the same problem, you have a support relationship, not a product insight.

Empathy is not a decision procedure. Research tells you what people experience. It does not tell you what to build, and it never resolves a trade-off between two groups who both have real needs. Teams that lean hardest on user research often struggle most with prioritisation, because “the users said” feels like it should settle things and doesn’t. Someone still has to decide, and own it.

Also worth saying: people are unreliable narrators of their own behaviour. They under-report effort and over-report intention. The story is the raw material, not the finding — you still have to watch what they do.

Takeaway: observe problems before inventing solutions.

Metrics that change behaviour

Sat, 25 Jun 2022 00:00:00 GMT

The test for a metric is not whether it’s accurate. It’s whether any plausible value of it would cause you to do something different.

Run that test across a typical dashboard and most of it fails. Total users, cumulative revenue, page views — these can only go up, they resolve nothing, and their function is to be shown to someone rather than to inform a choice.

Leading, and therefore uncomfortable

Lagging indicators tell you what happened. Revenue, churn, retention at 90 days. They’re trustworthy and they’re late — by the time churn moves, the cause is a quarter behind you.

Leading indicators are noisier and earlier. Time to first successful action. Share of sessions that hit an error. Whether a new account did the core thing twice in week one. You can act on these while acting is still cheap, and you’ll sometimes act on noise.

That trade is worth taking, and most teams don’t, because a leading indicator can make you wrong in public and a lagging one can only make you late.

Instrument before you need it

The measurement you want always concerns a period that has already passed. There is no retrofit. Adding events costs an hour before launch and is impossible after, so the discipline is to instrument the boring paths early — not the feature you’re excited about, the one you assume works.

The asymmetry is specific. Anything held as state can be reconstructed later — how many accounts existed, what they were worth, when they cancelled. Anything that happened between states cannot. Where someone hesitated, which step they repeated, what they tried before the thing that worked, how long the first success took: none of it exists unless something was emitting at the time. Which is why the instrumentation that matters is always the boring path nobody expected to be interesting.

Where it breaks

Every metric becomes a target, and every target gets gamed — including by sincere people with no intention of gaming anything.

Measure response time and answers get shorter. Measure engagement and the product gets stickier in ways nobody would defend out loud. The team isn’t cheating; they’re optimising what you told them mattered, and the parts of the job that weren’t measured quietly stop being done. Choosing a metric is choosing what to neglect, and that half is rarely stated.

The engagement case deserves singling out. “Design for sustained attention, not maximal engagement” and “instrument everything” pull in opposite directions, because engagement is the easiest thing to measure and the easiest to grow. A number that goes up while the product gets worse is not a vanity metric — vanity metrics are merely useless. This kind is actively hostile, and it looks like success for several quarters.

Two guards, both cheap. Pair every metric with the one it would degrade — speed with quality, engagement with weekly-active-and-satisfied, conversion with refund rate. And review whether a metric still deserves the dashboard, because the ones that stay longest are the ones nobody argues about, which usually means nobody uses them.

Takeaway: metrics should inform action, not justify past choices.

Stewardship in AI

Thu, 17 Feb 2022 00:00:00 GMT

Everyone building with AI right now is making decisions whose consequences land on people who did not choose to be part of them. That’s not a reason to stop. It’s a reason to hold the decisions differently from ordinary product calls.

I build voice agents, so the version I live with is concrete: a synthetic voice on a phone call with someone who may not know, may not be technical, and may be calling about something that matters to them.

What that implies in practice

Disclosure isn’t a compliance checkbox. A person on a call should know what they’re talking to, early, in the first turn. Every argument for burying this is an argument that the interaction works better when the person is mistaken, which answers the question.

Escalation must be real. “Talk to a human” has to reach one, within the same call where possible. A system that recognises the request and routes it into a queue that ends nowhere is worse than one that never offered.

Auditability before scale. Logs, transcripts, retention limits set on purpose, and the ability to answer what happened on a specific call at a specific time. This is unglamorous and it is what lets you tell the truth after an incident rather than reconstruct a story.

Humans on the consequential branch. Not on everything — that’s theatre and it doesn’t survive volume. On the branch where the system commits to something irreversible on someone’s behalf.

The cost runs in the direction you’d expect. Telling a caller in the first turn that they’re speaking to an AI lowers completion, at least initially — some people hang up who would otherwise have carried on. That’s the trade, stated plainly. It’s also decreasingly optional: bot-disclosure rules already exist in several jurisdictions, which makes the real choice between doing it now on purpose and doing it later badly, because someone made you.

Where it breaks

Two failure modes, and the second is the one that gets less attention.

The first is obvious: ethics as positioning. A page about responsible AI, a paragraph in the deck, no mechanism behind either. Everyone can spot this from outside, eventually.

The second is safety theatre that shifts risk rather than reducing it. Consent language nobody reads. A human-in-the-loop who approves four hundred items an hour and is therefore approving nothing. Both create a record of diligence and a person to blame, which is a legal artefact, not a safety one. It’s possible to add these in good faith and end up with a system that is less safe and better defended.

And the trade is real. Disclosure lowers conversion. Escalation costs headcount. Retention limits lose you training data. Anyone claiming these are all free is selling something. The argument for them isn’t that they’re costless — it’s that the alternative is a category that gets regulated into a shape nobody chose, after an incident that was preventable and predictable.

Takeaway: ethical design is product-market fit for the future.

Decisions are experiments

Thu, 03 Feb 2022 00:00:00 GMT

Every decision worth agonising over is one you cannot resolve with more research. If the data settled it, it wouldn’t feel like a decision — it would feel like arithmetic.

So the question is never “what is true here”. It’s “what do I believe, how strongly, and what would change my mind”.

Priors, out loud

Write the number down. Not because the number is right, but because writing it converts a mood into something falsifiable. “This will work” cannot be wrong. “I think there’s a 60% chance ten of these customers renew” can be, and in three months it will be.

The second half is the condition. Before committing, say what you would have to see to reverse. If you cannot name it, you have not made a decision — you have made an identity, and identities do not update.

Reversible beats correct

Most of the value here isn’t in better prediction. Prediction under real uncertainty is bad, and stays bad. The value is in choosing shapes you can back out of.

A schema change you can roll back, a vendor you can leave in 30 days, a feature behind a flag — these cost more upfront and let you be wrong cheaply. A rewrite, a two-year contract, a hire made to fix a strategy problem: those are wrong expensively.

A public API is the sharpest example of the irreversible class. You can add to one forever and remove from one almost never, because removal is a promise broken on someone else’s schedule. Ship a field with the wrong name and you keep it for a decade. The same afternoon’s work behind a feature flag costs an hour more and can be withdrawn at any point. The two look identical while you’re making them and are nothing alike afterwards.

Where it breaks

Optionality has a price, and the people who love this framing rarely pay it out loud.

Everything reversible is also everything uncommitted. You cannot build a hard technical asset, a brand, or a team on a foundation you have explicitly reserved the right to abandon in 30 days. Some things only pay out if you refuse to reconsider them — most compounding is exactly that. A founder who treats every decision as an experiment ends up with a portfolio of half-tested bets and nothing that anyone else could not also have.

There’s a second failure. Probabilistic language is unusually good at laundering indecision. “I’m 60/40 on it” can mean you’ve reasoned carefully, or that you would rather not be on the hook. A team can tell the difference; the calibration habit does not protect you from it.

The line I use: reversibility is the default, and a small number of decisions get deliberately promoted out of it — named as irreversible, argued once, then closed. The mistake is not having irreversible bets. It’s having them by accident.

In practice

State the hypothesis before the work, not after. Set the review date at the same time as the decision, because a decision with no review date is never wrong. Keep a short list of the calls you have deliberately closed, so you stop relitigating them in the shower.

Takeaway: treat decisions as experiments; optimise for optionality.

Design as philosophy

Mon, 24 Jan 2022 00:00:00 GMT

Everything in this series has been a version of one claim: the arrangement of a thing determines what people do with it, and doing shapes what people become.

That’s what makes design a philosophical activity rather than a decorative one. Not because designers are important — because artefacts carry decisions, and the decisions outlive the argument that produced them.

Three levels

Achieving intent. The floor. Someone came to do something; the design either gets out of the way or doesn’t. Most craft lives here and most products fail here.

Shaping behaviour. The design makes some actions easy and others hard, and over time that becomes what people do. Defaults are the sharpest instrument anyone in software holds, and they’re usually set by whoever wrote the code first.

Shifting what’s imaginable. The rarest. The spreadsheet didn’t make accounting faster; it made a kind of thinking available that wasn’t before. Version control didn’t speed up programming; it made a way of collaborating conceivable. These are not usability improvements. They change the set of thoughts people can have.

Which means the responsibility is real

If your artefact shapes behaviour, then “we just built the tool” is not a position. The defaults you set are a claim about how people should act, made at scale, mostly by accident, and left in place because nobody revisited them.

Defaults are where this stops being abstract. Organ donation rates differ by tens of percentage points between countries with opt-in and opt-out registers, across populations with near-identical stated attitudes. Nobody’s values changed; the form did. Software gets the same lever for free — private-by-default repositories, encryption on rather than available, telemetry off unless asked. Each is a line of code and a claim about how people should be treated, usually made in an afternoon by whoever got there first.

Where it breaks

The elevated framing is available to anyone, which drains it.

Most design is not philosophy. It’s a form that needs fewer fields and a page that loads faster, and the people doing that work well produce more value than anyone theorising about artefacts and behaviour. Grand framings are most attractive to those furthest from the actual making, and there’s a whole genre of design writing that is philosophy of design by people who have not recently shipped one.

The claim also flatters our sense of causation. Products change behaviour at the margin, inside constraints set by economics, culture and law — most of which are not yours. The design of a hiring tool matters much less to hiring outcomes than the labour market does. Overstating the leverage is pleasant and leads to building products aimed at problems that were never product-shaped.

And “great design shifts what people imagine possible” is only ever said retrospectively, about the small number of things that did. Nobody sets out and succeeds on purpose. Treated as an aim, it produces overreach; treated as an occasional outcome of doing the first level extremely well, it’s accurate.

So the honest order is: get someone through the task. Notice what your defaults are teaching. And accept that the third level, if it happens at all, will look like an accident from the inside.

Takeaway: design is practice and persuasion.

Process is a tool

Mon, 29 Nov 2021 00:00:00 GMT

Every framework worth anything was extracted from a specific team solving a specific problem under specific constraints. It worked. Then it got written down, and the constraints didn’t travel with it.

That’s the whole story of why process adoption disappoints. You imported the answer without the question.

Diverge, then converge

Under the naming, most methods are doing the same two things in alternation: open the space, then close it. Generate options without judging them, then commit without generating more.

The failures are usually a failure to switch. Teams stuck in divergence explore forever and call it discovery. Teams stuck in convergence execute the first idea anyone had and call it bias for action. The framework matters far less than whether someone is watching which mode you’re in and saying so.

Blend deliberately

Take the standup and drop the sprint. Keep the design critique and skip the personas. This looks like indiscipline and is usually just fit — the useful question about any ceremony is what it would cost you to remove it, and if nobody can answer, that’s the answer.

Story points are the usual first casualty, and rarely missed. The ritual produces a number that then gets used as though it measured time, by people who have agreed out loud that it doesn’t. Drop it and what’s left is the conversation the estimate was smuggling in — what’s unclear, what’s risky, what nobody has looked at yet — which was the part doing the work, and can be had directly.

Where it breaks

Pragmatism has a predictable failure mode, and it is more common than dogmatism.

“Use what suits the context” is indistinguishable, from inside, from having no process at all. Every skipped step is justified in the moment — that retro wouldn’t have helped, this week is unusual — and the accumulation is a team where nothing is reliable and everything is a judgement call, which is exhausting for everyone who isn’t the founder.

Process exists mostly for the cases where judgement is unavailable: someone new, someone tired, a Friday deploy, a decision made when the person with context is asleep. Those are precisely the cases the pragmatic argument doesn’t consider, because it’s made by someone with full context on a good day.

Adherence also has an underrated benefit: it’s legible. A team that follows a known method can be joined. A bespoke blend that lives in the founder’s head takes six months to learn and cannot be handed over — you’ve optimised for current fit at the cost of every future member.

So: process is a tool, and tools have maintenance. Pick the smallest set you’d defend, write down why each exists, and re-examine it when the team changes size rather than whenever it’s inconvenient.

Takeaway: process is a tool, not a value.

Rigour and resonance

Thu, 11 Nov 2021 00:00:00 GMT

UX gets described as a science by people defending a budget and as an art by people defending a decision. Both descriptions are self-serving and both are partly right, which is what makes the argument permanent.

The honest position is that they answer different questions and neither answers the other’s.

What each is good for

Research is good at falsification. It tells you people can’t find the button, that the form loses them at step three, that the word you chose means something else to half your users. These are facts, they’re cheap to establish, and ignoring them is just expensive.

What research cannot do is generate the option. No amount of study produces the idea; it only evaluates the ideas you brought. Teams that over-index on evidence end up refining a mediocre concept with great discipline.

Craft is what produces the candidate — the leap, the arrangement, the thing that feels obvious once seen and wasn’t derivable from any interview. It’s also what makes a correct solution feel worth using, which is not a decorative concern. Two products that test identically can differ entirely in whether anyone chooses them.

Sequence, not blend

The pairing works as alternation, not average. Diverge with craft — generate more than you need, unjustified. Converge with evidence — kill what doesn’t survive contact. Averaging the two produces a design nobody argued for and research nobody acted on.

Email cadence is the standard collision. Tests reliably show that sending more lifts opens and clicks inside the measurement window, because people who will unsubscribe do it slowly and people who quietly stop reading never register at all. The data is real. It answers a two-week question, and the decision is a two-year one — which makes it a judgement call wearing the clothes of an experiment.

Where it breaks

The framing is used, most often, to protect whichever half is failing.

“Data can’t capture everything” is true and is also the standard defence of a designer overriding a clear result. “Let’s test it” is true and is the standard way to defer a decision nobody wants to own. Both sentences are correct in general and usually deployed instrumentally, and the harmony framing gives cover to both.

There’s also a resourcing reality that the balanced version ignores. Real rigour is expensive — recruiting, sessions, analysis, enough participants to mean anything. Most teams don’t have it and never will, which means most “research” is four conversations and a survey, presented with a confidence the sample can’t support. That is often still worth doing. It is not evidence in the sense the word implies, and pretending otherwise is worse than admitting you’re operating on informed taste.

Takeaway: use evidence to inform aesthetics.

Systems are not their parts

Wed, 16 Jun 2021 00:00:00 GMT

You can improve every stage of a pipeline and end up with a slower pipeline. It happens often enough that it should be the default expectation rather than a surprise.

A voice agent is the clean example. Faster transcription that emits partial results more eagerly makes the language model start on incomplete input, which makes it revise, which makes the speech synthesis restart. Three components got better. The conversation got worse. Nothing in any single component’s metrics shows this.

Interactions are where the behaviour lives

The properties people actually care about — feels fast, feels reliable, feels trustworthy — are not owned by any component. They emerge from timing between components, from what happens under load, from what each part does when its neighbour misbehaves.

Which is why component-level dashboards can all be green during an outage everyone can feel. Each part is meeting its contract. The contract was the wrong thing to specify.

The useful move is to instrument the path, not the pieces. One trace that follows a single request end to end tells you more than nine healthy services.

Leverage points

Not all interventions are equal. Changing a parameter is weak. Changing a feedback loop is strong. Changing the goal the system optimises for is stronger still, and usually the one nobody has authority to touch.

The corollary is that most of the effort in a system goes into the weakest tier, because that’s the tier with tickets.

Retry storms have the same shape without the timing subtlety. A service slows; every client retries three times on timeout; the service now takes triple the load precisely when it has least capacity, and a slowdown becomes an outage. Every client is behaving exactly as specified, and the retry policy was added as a reliability feature. What failed is a property of the whole — no component owns it, and no component’s dashboard shows it.

Where it breaks

Systems thinking has a failure mode that is arguably worse than naive component-optimising: it produces people who can explain everything and fix nothing.

Once you’re fluent in feedback loops and emergence, every problem can be framed as systemic, which means no specific change is ever obviously correct — there might be a second-order effect. This is genuinely true and completely paralysing. Meanwhile the person who just made the slow query fast has shipped.

There’s also a diagnostic version of the same trap. “It’s an emergent property of the system” is unfalsifiable and blame-free, which makes it the most comfortable possible conclusion for a post-mortem. Sometimes the system is fine and a specific person merged a specific bad change.

The split I’d draw: use systems thinking to choose where to intervene, then be completely reductionist about the intervention itself. Map the interactions, find the loop, then go fix one thing and measure. The map is not the work.

Takeaway: map interactions before optimising parts.

Usability is an ethical position

Fri, 16 Oct 2020 00:00:00 GMT

Usability is usually argued on business grounds — conversion, support cost, retention. Those arguments are true and they’re not the real one.

The real one is that a difficult interface takes something from people that they cannot get back. Not money, which they agreed to spend. Time, attention, and a small amount of self-regard, since most people blame themselves when software defeats them.

The transfer

Every unclear label is work moved from the team that built it to everyone who uses it. The economics are brutally one-sided: an hour of clarification during design, against ten seconds of confusion multiplied by every user, every session, indefinitely.

That’s why “we’ll document it” is rarely an answer. Documentation moves the cost rather than removing it, and it moves it toward the person with the least context.

The measures are old and still right: effectiveness (can they complete it), efficiency (at what cost), satisfaction (how did it feel) — measured in real conditions, not the demo. Real conditions means interruptions, a bad connection, a partly filled form, someone who last used this six weeks ago.

Forms make the transfer visible. A field that rejects a valid address, a phone number with a space in it, a name with an apostrophe — people don’t abandon, they lie. They type something that gets them through, and the cost lands twice: once on them, once on whoever later depends on that data being real. The validation was written in an hour to save a downstream check that no longer works anyway.

Where it breaks

Ethical framing raises the stakes, and raised stakes produce their own distortions.

Once usability is a moral matter, disagreements about it become accusations, which is a bad way to run a design review and a worse way to make trade-offs. And there are real trade-offs. Confirmation dialogs make things slower and prevent disasters. Security controls are friction by design. Accessibility work sometimes costs the visual language a team spent months on. Framing usability as a virtue makes it hard to say “this friction stays” without sounding like you’re defending harm.

The framing also flatters. Usability is a floor, not a purpose. A product can be beautifully usable and pointless, or usable and quietly extractive — the smoothest interfaces in the world belong to products optimising for engagement in ways nobody involved would defend. Ease is orthogonal to whether the thing should exist.

So: respect for people’s time is a real obligation, and it’s the smaller of two questions. The first is whether the thing you’re making them fluent in is worth being fluent in.

Takeaway: usability is a moral stance.

Designing for mood

Wed, 06 May 2020 00:00:00 GMT

Experience comes out of three things meeting: what the person brings (disposition), what they have to process (cognition), and what you put in front of them (design). You control one.

That ratio is worth sitting with, because most design conversation proceeds as if the screen were the whole experience.

Context arrives before you do

The same error message reads as helpful at 10am and hostile at 11pm on a deadline. The same onboarding is charming when someone chose to be there and insulting when their employer mandated it. Nothing about the interface changed.

You can’t fix the mood. You can avoid making it worse, and you can notice when the context is predictable. Someone arriving at a cancellation flow is not neutral. Someone hitting a payment failure is not neutral. Someone opening a support chat has already tried something else. The design that ignores this is technically fine and emotionally deaf.

Subtraction beats delight

Removing frustration reliably outperforms adding pleasure, and it’s less fun to work on, which is roughly why it’s underdone.

Nobody remembers the animation. Everybody remembers losing a form. The compounding asset is the absence of bad moments — the state that survived a refresh, the error that said what to do next, the operation that was undoable. Delight is a surface treatment on top of that; applied without it, it reads as contempt.

Failed-payment email is where this shows most reliably. It usually arrives in the same cheerful register as onboarding — exclamation mark, friendly subject line — to someone who has just learned their card declined and may have a reason for that they’d rather not think about. The information is correct and the tone belongs to a different conversation. Neutral would be better, and neutral is rarely what the template library offers.

Where it breaks

Emotional design has a short path to manipulation, and the vocabulary doesn’t distinguish them.

“Nudge toward positive states” describes both reducing anxiety in a checkout and manufacturing urgency to close it. Both are designing for mood. Both work. The difference is entirely whether the state you’re inducing serves the person’s goal or yours, and that question is not answerable from inside the craft — it’s a decision made before the design starts, or not at all.

The second issue is that mood is largely unmeasurable at product scale. You get proxies — completion rates, support tone, session length — and each is compatible with several emotional stories. Which leaves teams making confident claims about how users feel on evidence that would embarrass them in any other context. Better to hold it as a design sensibility than an analytics category.

Takeaway: design for mood as much as mechanism.

Users invent the product

Fri, 17 Apr 2020 00:00:00 GMT

Ship anything and people will use it wrong. Not wrong as in broken — wrong as in for something you never wrote down.

The instinct is to correct them. Better onboarding, clearer empty states, a tooltip explaining what the feature is for. Sometimes that’s right. Often you are arguing with a customer about what your product does, and losing on the merits.

Misuse is a signal with a direction

A workaround is a request that has already been prototyped. Someone wanted an outcome badly enough to build it out of the wrong parts, on their own time, without asking. That’s stronger evidence than anything a survey returns, because it cost them something.

The spreadsheet exported and re-imported daily. The field used as a status because there is no status field. The API called at ten times the intended rate because it’s the only endpoint that returns what they need. Each is a spec, written in the only language available.

Design for affordances

You cannot enumerate use-cases faster than users invent them, so stop trying. What you can do is build parts that combine: stable primitives, real export, webhooks that fire on the events people care about, names that describe capability rather than intent. A product built as a set of affordances gets extended by its users. One built as a set of flows gets abandoned at the edge of the flow.

The hashtag is the canonical case. It wasn’t a feature — someone used a # because Twitter had no way to group a conversation, other people copied it, and years later it was built into the product and then into every product like it. No roadmap would have produced it. What made it worth institutionalising wasn’t that one person did it; it was that thousands independently arrived at the same workaround.

Where it breaks

Emergent use is not automatically valuable, and “listen to how people really use it” is how products lose their shape.

Most appropriation is one customer, once, for a reason that will not generalise. Institutionalise it and you have added a permanent maintenance burden to serve a single account — and you will do it again next quarter, and the quarter after, until the product is a pile of accommodations with no opinion. The teams that followed emergent behaviour most faithfully are not the ones with the clearest products.

There’s also a category that genuinely is misuse: people routing around a constraint that exists for a reason — a rate limit, a consent step, an audit boundary. In a voice product especially, a clever workaround is sometimes a customer quietly moving the compliance risk onto you.

The test I’d apply: does the workaround point at a job several customers have, or at one customer’s process? Enable the first. Support the second without building for it. And when the workaround exists to skip a safeguard, the answer is to fix the friction that made skipping attractive — not to pave the path.

Takeaway: design for affordances, not just use-cases.

The invisible tool

Thu, 16 Apr 2020 00:00:00 GMT

You don’t think about a hammer while using one. You think about the nail. That transfer — from operating the tool to pursuing the outcome — is the whole design target, and almost nothing achieves it.

What breaks it is not complexity. It’s unpredictability.

Predictability beats simplicity

A tool with forty commands that always do the same thing is easier to internalise than a tool with six that behave differently depending on context. The first can become automatic. The second requires you to keep a model of the tool in working memory at all times, which is exactly the attention you wanted to spend on the task.

This is why “smart” behaviour so often makes tools worse. Autocorrect that usually helps costs more than autocorrect that never fires, because now every output needs checking. Variable behaviour taxes every interaction, including the ones where it was right.

Three things carry most of the weight: the same input produces the same result; defaults are forgiving enough that the common path needs no configuration; the outcome of an action is visible before you commit to it.

Undo is the real feature

Confidence comes from reversibility. People move fast in tools where mistakes are cheap and slowly in tools where they aren’t — regardless of how good the interface looks. A reliable undo does more for perceived speed than any amount of latency work, because it removes the pause before each action rather than the milliseconds inside it.

Gmail’s undo-send is the shape worth copying. It is dumb — a fixed delay before the message actually leaves — and because it is dumb it is entirely predictable, so the pause before hitting send disappears. Autocorrect is the counter-example: far cleverer, right most of the time, and therefore requiring you to check every output it touches. The clever one takes attention on every interaction. The dumb one hands attention back.

Where it breaks

Invisibility is the goal for tools people use every day. It is the wrong goal for tools people use twice.

For occasional use, discoverability beats fluency, and those trade against each other directly. The interface that rewards a daily user with speed — dense, keyboard-driven, unlabelled — abandons the person who came back after six weeks. Optimising for invisibility when your usage is monthly produces something that feels expert and gets used once.

There’s a harder version. Tools that vanish into intention also stop being examined. A calculation you no longer check, a suggestion you accept without reading, an agent that acts on your behalf — the friction you removed was sometimes the review step. That’s fine for a hammer, where the consequences are local and immediate. It’s a different proposition for anything that acts at scale or on your behalf, where the right design keeps one deliberate pause in the loop and defends it against every usability instinct you have.

Takeaway: make the tool invisible.

Value before polish

Wed, 26 Feb 2020 00:00:00 GMT

Heckel’s observation is that a user’s tolerance for a bad interface scales with how much they want the outcome. People learned vi. People filed taxes through government portals. Nobody does either for the joy of the interaction.

Which means the first question is never “is this beautiful”. It’s “does anyone need this enough to push through it”.

Why the order matters

Polish applied to something nobody wants produces a product that fails more slowly and more expensively. You lose the signal, because a beautiful thing that nobody uses is ambiguous — was it the value or the execution? — and you lose the weeks.

Ugly and valuable is an unambiguous result. Someone tolerated the rough edges to get the outcome. That is the only evidence that matters early, and it arrives faster when you haven’t spent a month on the empty state.

Value first also changes what polish means later. Once you know which two screens people live in, refinement is a targeted act rather than a uniform coat of paint across forty views, thirty-six of which nobody opens.

Barge-in is the clean case in a voice product. Letting a caller interrupt the agent mid-sentence looks like refinement, a nicety on top of a working system. It isn’t. A caller who can’t interrupt learns within two turns that they’re talking to a recording and behaves accordingly: no detail, no patience, straight to “operator”. The thing that sounds like polish is carrying whether the conversation happens at all.

Where it breaks

This law has been used to justify an enormous amount of bad software, and the limits are sharper than the slogan suggests.

Perceived value, not real value. The tolerance comes from what the user believes they’ll get. In a crowded category, the interface is the evidence — if three products claim the same outcome, polish is how a buyer estimates which one works. Ugly-but-valuable only survives where the value is already legible or the alternative is nothing.

Tolerance is spent, not renewed. A user pushes through friction while the outcome is novel. When a competitor arrives with the same outcome and less friction, the accumulated irritation cashes out at once. Retention curves fall off a cliff rather than sloping.

Some interfaces are the product. For anything real-time — a voice agent, a live dashboard, an editor — latency and feedback aren’t polish. A half-second of dead air is not an aesthetic problem; it’s the feature failing. Calling that “UI” and deferring it is a category error I’ve watched teams make repeatedly.

The practical line

Ship rough until someone is annoyed that it’s rough — that annoyance is the signal you were waiting for, and it means the value landed. Then fix the two screens they’re annoyed about, not the forty.

Takeaway: solve the core job-to-be-done before you optimise aesthetics.

Designing for foragers

Mon, 23 Dec 2019 00:00:00 GMT

Information foraging says people navigate the way animals forage — following cues that suggest food is near, abandoning a patch when the return drops below the cost of moving. It isn’t a metaphor so much as the same machinery pointed at a screen.

Which means most navigation problems are scent problems.

Scent is a prediction

A link doesn’t have to describe its destination. It has to let someone predict it well enough to commit. “Settings” carries scent. “More” does not. “Advanced” carries scent for exactly the people who shouldn’t click it.

Scent has to survive the whole path. A label that promises one thing and leads to a page that says something different doesn’t just cost that click — it teaches the user that your labels are unreliable, and after that they stop reading and start guessing. Recovering from that is much harder than getting it right, because the damage is to the whole interface at once.

The cost of exploration matters as much as the cue. If going back is instant and lossless, people probe cheaply and find things. If a wrong click loses their place, their form state, or thirty seconds, they stop probing and start asking a colleague — which reads to you as low engagement and to them as a working strategy.

Labels carry measurably different amounts of scent. “Settings” predicts its destination; “More” predicts nothing and defers the cost to a click; “Advanced” reliably attracts exactly the people who shouldn’t be there, because it reads as a promise of capability rather than a warning. Renaming is the cheapest change available in an interface and routinely outperforms the redesign proposed instead — because the problem was never the layout.

Where it breaks

Foraging describes searching. A good deal of product use isn’t searching.

Someone executing a known workflow for the four-hundredth time isn’t following scent; they’re running a motor program, and the design that serves them — stable positions, no reflow, no helpful reordering — is close to the opposite of what a forager needs. Optimising a daily-use tool for legibility to newcomers degrades it for everyone who stayed.

The model also predicts what people do, not what serves them. Strong scent attracts clicks regardless of whether the destination is worth it, which is precisely the mechanic behind every headline written to be clicked rather than read. “Align with human instincts” and “exploit human instincts” are the same technique with different intent, and the interface cannot tell them apart. Only you can, and only before you build it.

Foraging heuristics evolved for patchy, honest environments. They are badly calibrated for one where the cues are authored by someone with an interest in where you go.

Takeaway: align product flows with human instincts.

Authority without permission

Wed, 18 Sep 2019 00:00:00 GMT

The cost of a permission culture is not the delay. It’s what people stop proposing once they’ve learned that everything routes through one person.

Holacracy’s answer is to make authority explicit: roles with defined accountabilities, decisions that belong to a role rather than a rank, and a process for changing the roles. Do that properly and people act without asking, because asking is no longer the mechanism.

What has to be real

Three things, and skipping any one produces theatre.

The role has to actually hold the decision. If someone with a defined accountability makes a call and it gets quietly reversed, the whole structure is now decorative and everyone learns that in one incident.

The process for changing roles has to be light. Structure that can’t be amended in a meeting hardens into the bureaucracy it was meant to replace.

Ambiguity has to have an owner. Most real problems fall between roles, and distributed authority is silent about those unless you name who decides when nobody’s remit covers it.

The recognisable version is a decision sitting between two teams and belonging to neither — pricing page copy, error message wording, who owns a migration. Nobody is blocked, exactly. It gets raised, discussed and left, three times, across five weeks. The tell is that nobody can say what would have to happen for it to be settled. That isn’t a hard problem, it’s an unowned one, and the fix is one sentence naming who decides.

Where it breaks

Distributed authority is a coordination technology with a real cost, and the literature is quiet about it.

It is heavy. Explicit roles, governance meetings, and a process for changing the process is a lot of overhead for eight people who could just talk. Below a certain size it slows you down while feeling sophisticated — and above a certain speed, in a crisis, you want one person deciding fast and being wrong sometimes, not a process.

It also doesn’t remove power; it relocates it. Informal influence, tenure and who founded the company all still operate, now without an org chart making them visible. A flat structure with unacknowledged hierarchy is harder to challenge than an explicit one, because there’s no name on the thing you’d be challenging.

And it assumes uniformly high judgement. Autonomy given to someone without the context to use it isn’t empowerment; it’s abandonment with extra steps. New people especially need more direction than the model wants to admit, and “process-backed autonomy” is a poor substitute for someone senior saying: do it this way for now, here’s why.

The version I’d defend is narrow — push decisions to whoever has the context, say out loud who that is, keep the reversal rule explicit, and accept that some calls stay central.

Takeaway: structure + autonomy = agility.

Products are relationships

Sat, 07 Sep 2019 00:00:00 GMT

Launch is treated as the event. It isn’t one — it’s the first day of a relationship that has a predictable arc, and the arc ends unless something intervenes.

Five stages, and each fails differently.

Adoption. The product has to be findable, credible and usable in the same sitting. Most losses here aren’t about value; they’re about someone not getting far enough to see it.

Habit. The product attaches to a trigger — a time, an event, another tool. Without a trigger it stays a thing people remember to use, and remembering decays.

Personalisation. The user invests. Settings, data, workflows, muscle memory. This is where switching cost is built, and it is entirely on your side of the ledger.

Plateau. Usage stabilises. Nothing is wrong. This is the dangerous one, because plateau and health look identical on a chart.

Abandonment. Rarely a decision. Usually a gap that got longer.

Intervening

Each stage has its own lever, and applying the wrong one is the common error. Adoption problems are messaging and onboarding. Habit problems are triggers and timing. Plateau needs new capability — a reason to return with a different intent, not a redesign.

Redesigning at plateau is the most reliably wasted quarter in product work. The relationship didn’t get stale because the buttons looked old.

Evernote is the arc in public. Adoption on a genuinely better clipping tool, habit through being on every device, deep personalisation as people moved years of notes in — then a long plateau met with redesigns and pricing changes rather than new capability. The switching cost was enormous and it still lost people, which is the part worth sitting with: personalisation buys time, not loyalty. It delays abandonment rather than preventing it.

Where it breaks

The framing suggests every product should be defended through all five stages. Plenty shouldn’t.

Some products are correctly finished. A tool that does one job well, that people use for two years and then stop needing, has succeeded. Renewing relevance in that case means bolting on jobs it wasn’t built for — the standard path from a sharp product to a suite nobody can describe. Abandonment is sometimes the customer graduating, and treating it as failure produces retention features that serve the vendor.

The lifecycle language also imports an asymmetry worth noticing. Relationships are mutual; this one is measured entirely from your side. Personalisation is described as investment when the user does it and switching cost when they’d like to leave. Those are the same fact, and which word you use tells you what you’re building. The honest version of “design for lifespan” includes designing a clean exit — export that works, cancellation that isn’t a maze — which statistically loses you some retention and is still correct.

Takeaway: design for lifespan, not launch.

Everything starts as a fragment

Wed, 10 Jul 2019 00:00:00 GMT

Nothing starts finished. It starts as a fragment — a half-idea, a file with two functions, a sentence you wrote down because it wouldn’t leave. The gap between that and the thing in your head is where most projects die, and it dies from comparison rather than difficulty.

The comparison is always unfair. You’re holding a fragment against someone else’s shipped work, which is their fragment plus two years you didn’t watch.

Friction is information

The parts that resist tell you where the actual problem is. A section that won’t come out right is usually one you don’t understand yet. A feature that keeps growing in scope is usually two features. An architecture that fights every change is telling you the model is wrong.

None of that arrives as insight. It arrives as annoyance, which is why it gets treated as an obstacle to push through rather than a reading to take.

The practical version: when something is unusually hard, stop and ask what it’s telling you before applying more force. Half the time the answer is that you’re building the wrong shape, and force makes it worse in a way that takes months to undo.

Endpoints are illusions

Shipping is not an ending. It’s the point where the thing stops being yours alone and starts being shaped by contact — which is the beginning of the interesting part, not the conclusion.

Abandonment gets misread too. A project shelved because it was impossible often becomes possible later without anyone touching it: a dependency matures, a price falls, a platform ships the missing primitive. The file you closed in frustration wasn’t a failure, it was a correct assessment of that month. Reopening it a year later isn’t sentimentality — it’s the cheapest research available, because the hard thinking is already done and only the blocked part changed.

Where it breaks

“Value is in the motion” is a lovely sentiment and it is also how people accumulate forty unfinished projects and call it a practice.

Continuous becoming, taken seriously, removes any obligation to finish. Finishing is where most of the learning actually is — the last ten percent is where you find out whether the thing works, and it’s the part every fragment-lover skips. A person with twenty starts has usually learned one thing twenty times.

And not all friction is information. Some is just difficulty. The tedious data migration isn’t telling you anything; it’s tedious, and the answer is to do it. Treating every struggle as a signal to reconsider is a very sophisticated way of avoiding boring work, and it’s especially available to people who enjoy thinking about systems.

The distinction I’d use: friction that recurs in different forms is a signal. Friction that’s just heavy is a task. The first means stop and re-model; the second means put the hours in.

Takeaway: treat struggle as fuel.

Intentional incompetence

Fri, 07 Jun 2019 00:00:00 GMT

The trap in getting good at something is that being good feels like progress while you’re standing still. Execution improves. Learning stops. From the inside, both feel like momentum.

Growth needs friction, and friction means being bad at something on purpose.

The band

There’s a narrow range where learning actually happens. Too easy and you’re performing. Too hard and you have no scaffolding to attach the new thing to, so you quit — not from weakness, but because nothing is sticking.

The band is roughly: you can tell your output is bad, and you can tell why. If you can’t see why, drop a level. If you can’t see that it’s bad, go up.

Cycling across domains is what keeps this available. Ten years in one field gives you a decade of the last two years, because the field stops offering you anything you’re bad at. Move sideways — from backend to interface, from building to selling, from writing code to writing prose — and the discomfort comes back.

The cheapest version of this is a rotation into support. An engineer who spends a month on tickets is bad at it for the first week — wrong tone, wrong level of detail, escalating things that didn’t need escalating — and comes out knowing which parts of the product generate the most human cost. Neither the discomfort nor the knowledge is available from reading the ticket queue, because reading it is something you are already good at.

Where it breaks

The obvious problem: taken seriously, this is a recipe for never being good at anything.

Depth is where the non-obvious value is. The person who has done one thing for fifteen years knows the failure modes that don’t appear in any documentation, and no amount of sideways movement substitutes. Novelty-seeking dressed as growth is one of the more expensive habits available, and it’s especially seductive to founders, because switching domains is indistinguishable from strategy.

The second problem: transfer is weaker than it feels. Learning a new domain sharpens general judgement much less than the people doing it claim. It mostly just teaches you that domain. The “learning how to learn” benefit is real but small, and it’s routinely used to justify a fourth abandoned side project.

Third: you can’t run this at work indefinitely. Deliberate incompetence has a cost, and someone pays it. Doing it inside a team means shipping worse output for a while on someone else’s timeline.

The shape that survives all three: one domain where you go deep and stay, compounding — and a rotating second slot where you are openly, cheaply bad. Small stakes, real feedback, no obligation to become good. The rotation keeps the plasticity. The depth keeps the value.

Takeaway: growth = intentional incompetence.

Luck is biased

Sun, 28 Apr 2019 00:00:00 GMT

Luck is not evenly distributed. That is true, and it is a much weaker claim than the people repeating it believe.

Both halves matter. Skip the first and you sit still waiting to be noticed. Skip the second and you explain your outcomes as the inevitable result of your preparation — which is mostly a way of not looking at how close the whole thing came to not happening.

Windows are short

Luck arrives as a window. Someone mentions a problem in passing. A customer describes their workaround instead of their requirement. A platform ships an API on a Tuesday. The opportunity was available to a few hundred people, and it went to whoever could act inside the window.

Acting inside the window is not speed. It is having already built the thing you would need. The demo that wins the meeting is the demo that existed before the meeting was scheduled.

Three levers, none of them mystical. Position: be where the information moves, because most useful signal about a market is never written down. Perception: notice the weak version of the signal — by the time a category has a name, the window has closed. Primed capability: keep the ability to build the obvious next thing inside a week.

The shape recurs. When a platform ships a capability — an API, a model, a protocol — the teams that ship on top of it within the week are never the ones who started that week. They had a product with a hole in exactly that shape, and the new thing filled it. Everyone else spent the window building the surrounding product, and by the time they had one the advantage was gone. The window rewarded work done months earlier, and from outside it looked like speed.

Where it breaks

“Fortune favours the prepared” is a statement about a base rate, not about you.

Preparation shifts the distribution. It does not determine the draw. There are people who did all three of those things well for years and got nothing, and they are invisible, because nobody interviews them about their process. Every account of luck you have read was written by someone who got the outcome.

That is not a philosophical point. If you believe preparation causes outcomes, a bad outcome means you weren’t prepared enough — so you prepare harder. More optionality, more surface area, more irons. That is how a person ends up busy in nine directions with depth in none, which lowers the base rate they were trying to raise.

Treat it like a bet with good odds and high variance: take it repeatedly, size it so a bad run doesn’t end you, and don’t read a single result as a verdict on the decision.

What that leaves

Ship in public more than is comfortable — not for an audience, for the replies. Answer strangers; the hit rate is terrible and the cost per attempt is four minutes. Keep one capability warm enough to demonstrate inside a week, so that when a window opens the question isn’t whether you can learn the thing.

None of it guarantees anything. It moves you from a bad draw to a slightly better one, over enough draws to matter.

Takeaway: position + perceive + act.