---
title: "Six weeks of working software beats six months of design"
url: "https://vucale.com/blog/six-weeks-of-software-beats-six-months-of-design"
description: "A design document cannot be wrong in any way that hurts yet. That is precisely what makes it a bad instrument for finding out whether an idea is any good."
---

# Six weeks of working software beats six months of design

July 21, 2026·2 min read·VUCALE

The standard shape of a transformation engagement is an assessment, then a target operating model, then a roadmap, then delivery. Months of it before anything runs. The logic is sound — understand before you build — and the outcome is that the first contact with reality happens after the expensive decisions have already been made.

The alternative is not to skip thinking. It is to compress the loop until being wrong is survivable, which usually means something real running in about six weeks.

## What a document cannot tell you

**Whether people will use it.** The only reliable predictor of adoption is watching somebody try to use the thing while doing their actual job.

**What the data is really like.** Every assessment describes the data as documented. Every build discovers the fields that are optional in theory and empty in practice, the codes that mean different things by region, and the system that has been silently failing since March.

**Where the exceptions are.** The workshop covers the standard case. The exceptions surface when somebody tries to process a real week.

**Whether it is worth it.** A business case built on assumptions returns whatever the assumptions said. One built on six weeks of measured reality is a different kind of document.

## What six weeks actually buys

One real problem, solved end to end, for a real group of users, against real data. Not a prototype with mocked inputs and not a demo environment — something a person can use on a Tuesday and complain about on Wednesday.

The complaints are the deliverable. They are worth more than the assessment, because they are specific, they come from people who will have to live with the result, and they arrive while changing course is still cheap.

## Where this approach fails

It is worth being clear, because this method is oversold too.

**When the pilot never scales.** A thing built in six weeks for twelve users is not a thing that runs for two thousand. If nobody plans the path from one to the other, you get a graveyard of successful pilots, which is its own well-documented failure mode.

**When it becomes the plan.** Six weeks of building does not replace knowing where you are going. It replaces pretending you know before you have evidence.

**When it is used to avoid hard decisions.** Building something is more enjoyable than deciding which department owns the outcome, and a pilot can become a way of postponing that.

**In genuinely regulated or safety-critical work.** Where the cost of being wrong is measured in something other than money, the slow, documented approach exists for good reasons.

## The rule we work to

Nothing longer than six weeks without something running that a real user can criticise. If the work cannot be shaped that way, that is itself a finding worth discussing — it usually means the problem is not yet defined well enough to solve, and no amount of design time fixes that.

-   pilots
-   delivery
-   innovation lab
-   method

## Keep reading

-   [The constraint is change capacity, not strategy](https://vucale.com/blog/the-constraint-is-change-capacity)
-   [A consultancy that resells cannot advise you](https://vucale.com/blog/a-consultancy-that-resells-cannot-advise-you)