I have to ship something this week and it's not ready.

What to do when you have to ship this week and it isn't ready

Austin, two thousand and thirteen. Inside Calxeda, the engineering team has built a low-power ARM-based server at a time when the idea is genuinely ahead of its era. Microservers using a fraction of the power of conventional data-centre hardware. The technology works.

The problem is the software ecosystem.

The sixty-four-bit ARM software ecosystem that would let customers actually run anything meaningful on this hardware is not ready. The compilers, the operating system support, the hypervisor work, the database porting — all of it is years behind where it would need to be for the early customers to integrate the systems into production workloads.

Calxeda ships anyway.

The early customers cannot integrate the systems without the missing software layer. Sales stall. The pipeline that the technology should have unlocked never opens, because the technology is sitting on top of an ecosystem that hasn't caught up to it. The company runs out of money before the ecosystem catches up. By the end of two thousand and thirteen, Calxeda is winding down.

The painful thing about the Calxeda case is that the technology is not wrong. The sixty-four-bit ARM server market becomes enormous a few years later. Aws Graviton, Ampere Altra, the entire shift to ARM in the data centre arrives, exactly as the original Calxeda thesis predicted.

It is that ready enough to ship and ready enough to be used turn out to be different questions, and Calxeda only answered the first one.

When you have to ship this week and the code isn't ready, the question is not whether you can finish in time. The question is whether finished is even the right word for what you are about to deliver — and whether shipping it before it is finished requires a different mechanism for handling what comes next.

So let's go to the office and work through it.

First tell whether finished is even the right word

"I have to ship something this week and it's not ready."

The feeling is panicked.

The deadline is real. The work isn't done. And the choice you have been postponing — about what finished means in the time available — has now arrived, with the calendar pressing.

Two choices. They look like the same shipping problem. The first move is different.

When the audience will respect an honest rough edge

Choice one: you can tell the truth about what's missing. The product has rough edges or missing pieces. The audience is the kind that will appreciate being told honestly.

If that's the read, ship it and frame the rough edges as deliberate. Not hidden. Not apologised for. Named. We shipped the core because the core is what matters and we wanted you to have it now; the polish is coming in the next update.

Rory Sutherland, working on the psychology of perception, has written about the way deliberate framing can transform what would otherwise read as a defect. The thing customers and users actually resent is not the rough product. It is the pretence that it's finished when it isn't. A rough product shipped plainly is fine; a rough product shipped as if it's finished is the thing that breaks trust.

When you don't yet know if the polish matters

Choice two: you don't actually know whether the polish matters. You're about to spend another week polishing something nobody will use, and what you really need to find out is whether the rough version solves the user's problem at all.

If that's the read, ship the crudest version that still works and call it a prototype out loud. The naming is doing real work.

Eric Ries, formalising the minimum viable product in the early twenty-tens lean-startup writing, made the discriminating point that the label is what changes the response. A prototype failing is information. A product failing is a disaster. Same artefact, different label, completely different response if it bombs. The only question is whether you're honest about what you're doing before you do it.

Truth-telling, or learning-mode. Same not-ready ship. Two different first moves.

How to ship early on purpose, not by accident

Three tools. The discipline is to turn the unready ship into a deliberate experiment.

Maximise information per day of exposure

The first is

Fail-Fast Prototyping.

Fail-Fast Prototyping as a discipline emerged from IDEO and the design-thinking tradition codified through the late nineteen-nineties and two-thousands, with deeper roots in the iterative-design literature of Christopher Alexander and the rapid-prototyping practice that surfaced in industrial design through the nineteen-seventies and nineteen-eighties. The contemporary version is closer to David Kelley and Tim Brown's IDEO writings than to any single canonical source.

The reason Fail-Fast Prototyping matters when you have to ship something not ready is that it inverts the relationship between embarrassment and information. Most teams trying to avoid an embarrassing ship spend their final week minimising visible defects. Fail-Fast Prototyping spends that week maximising the information per day of exposure the unready ship will produce.

The unique insight is that the point of shipping early is not to minimise embarrassment; it is to maximise the information you get per day of exposure. The two goals look similar from a distance and they are different in practice. The team optimising for low embarrassment polishes; the team optimising for information ships and instruments.

What you get when you ship as a Fail-Fast Prototype is information about what users actually do — which is the question every polished version was implicitly betting on. The bet pays off either way: either the prototype validates the bet, or it falsifies it cheaply.

So. How to run it.

Pick. Not the whole user base. A subset who has signed up for early access, who tolerate roughness, who care about being part of the development. Beta channels, early-access groups, friendly customers.

Ship. The framing is the protective layer. This is unfinished. Here are the rough edges. Here is what we are trying to learn.

Specify. What are you trying to find out? Which of the bets in the build is most uncertain? The exposure is expensive only if you don't extract the answer to the question that mattered most.

Watch. Not the praise. Not the complaints about polish. The behaviour. Did users do the thing the product was built to support? Did they get stuck where you predicted? Did they get stuck somewhere you didn't predict?

The discipline is that you ship to learn — and the learning is what justifies the ship.

Decide what answered means before you launch

The second is

Prototype Testing.

Prototype Testing as a structured discipline runs through Jakob Nielsen's usability writing in the nineteen-nineties, the Stanford d.school's design-thinking curriculum from the early two-thousands, and the contemporary user-research practice formalised in tools like Maze, UserTesting, and Lookback through the twenty-tens. The discipline is about extracting structured signal from low-fidelity material.

The reason Prototype Testing matters when you've shipped something not ready is that the launch teaches you nothing if you haven't named what you're testing. A noisy launch is just noise. A noisy launch with a specific question and a specific definition of answered is a structured test.

The unique insight is that the test exists before the launch. The launch is the data collection. The interpretation has to be designed in advance, because the team's reading of post-launch data is otherwise too easily bent by the team's hopes for the launch.

What you get when you specify before you launch is signal you can act on. You know, on day three, whether the bet worked. The team isn't arguing about what the data means; the test was designed to answer a specific question, and the data either supports the answer or doesn't.

So. How to run it.

Write. Before launch, in plain language. We believe users in segment X will do Y when we ship the rough version of Z. Specific enough to be wrong.

Define. What number, on what dashboard, will tell you whether the hypothesis held? More than thirty per cent of segment X completing the core flow in the first session is a metric. Users seem to like it is not.

Set. When will you read the result? Day three after launch, against the rolling weekly metric. The time window protects against premature reading and against indefinitely deferred reading.

Read. Held against the metric you defined before launch — not the one that looks best in retrospect.

The discipline of Prototype Testing is the discipline of pre-committing to interpretation. The launch is data collection; the interpretation has been designed in advance.

Watch five users find the real friction

The third is

Usability Testing.

Usability Testing as a practice was formalised by Jakob Nielsen at Sun Microsystems and later at the Nielsen Norman Group in the late nineteen-eighties and nineteen-nineties, with the canonical five-user heuristic — that five users will surface roughly eighty-five per cent of the usability problems on a system — published in two thousand. The deeper lineage runs through the Xerox PARC human-factors work of the nineteen-seventies and the Human Factors Engineering tradition that emerged from post-war military and aviation research.

The reason Usability Testing matters when you've shipped something rough is that the answers to where does it actually fail? are sitting in the heads of users you have not yet watched. The team can guess. The team is usually wrong. Watching five users for an hour each will give you the top three problems painfully clearly within an hour.

The unique insight is the five-user heuristic. Most teams default to assuming usability research needs large samples to be meaningful. For finding usability problems specifically — the friction points in an interface — five is enough. The sixth user surfaces variations on what the first five found; the eleventh user is largely redundant. The marginal information per additional user falls off sharply.

What you get is rapid, concentrated information about where the live build is failing. Not what users say about it — they will be polite, or vague, or wrong about their own experience. What they do with it under direct observation. The behaviour is the data.

So. How to run it.

Recruit. From the segment you're shipping to. Compensate them. Schedule them inside a week.

Pick. Concrete things you want users to attempt. Not use the product; complete this signup flow, find this piece of information, complete this purchase.

Watch. Each user works through the tasks alone, with you observing silently. The instinct to help is the instinct to corrupt the data — let them get stuck. Where they get stuck is the diagnostic.

Aggregate. After five sessions, the same problems will keep surfacing. Those are the ones to fix. Idiosyncratic single-user issues drop out of the aggregate.

The tool is what turns the rough launch from a loss of face into a structured friction inventory.

That's the toolkit. One more story before we close.

A precedent: why ready to ship and ready to use differ

The Calxeda story we opened with showed the cost of conflating ready to ship and ready to be used. The story we close with is the structural argument for why those are not the same question — and why the gap between them, in modern engineering, can be designed for rather than absorbed.

San Francisco, two thousand and sixteen onwards. Charity Majors, co-founder and CTO of Honeycomb, has been writing and speaking about a specific argument that runs against the grain of how most engineering organisations have grown up.

The argument is about two operations most teams conflate: deploying code and releasing a feature.

In the conflated form, putting a new capability in front of users requires pushing code to production. Pulling the capability back requires rolling code back. The deploy and the user-facing change are the same event. That is the shape most engineering organisations have grown up inside.

Majors's argument, written across her charity.wtf blog and repeated in conference talks at QCon, LeadDev, and SREcon, is that this shape is structurally backwards. Deploys are slow, flaky, and untestable in their user impact. Forcing every user-facing change to travel through the deploy cycle loads the riskiest operation in the build with the least-reviewable change at the least-controllable moment.

Feature flags decouple the two.

When you have to ship something you are not sure about, you ship it dark and release it gradually to a slice of users. If the release breaks, you flip the flag rather than rolling back the deploy. Friday-afternoon shipping becomes defensible, because the risky operation is now the flag flip — which is cheap, reversible, and independent of the build.

When you have to ship this week and the code isn't ready, the honest question is usually not whether you can finish in time. It's whether the gap between ready and released has been compressed into a single decision that it does not need to be.

Majors's rule, given as a slogan in conference talks but earned through years of post-mortems: if you must freeze anything, freeze merges, not deploys. The Friday-afternoon-deploy anxiety is real, but it is anxiety about the wrong operation. The useful move isn't to work faster so the unready code gets ready. It is to build a release mechanism that does not require the code to be entirely ready in the first place.

So. Your Next Move from this playbook.

How polished is the prototype you're currently building — and how much harder will it be to throw away precisely because of how much work you've put into making it look real?