The duration of a project is inversely proportional to how deeply the problem is understood. Or, more simply: when your thinking still fits in a paragraph, you are a long way from launch.

The idea was simple. CVs fail to deliver on their promise in recruitment: conceived in the 1950s and barely changed since, they describe what you have done, not who you are. We set out to build an alternative with Higher, a product venture we founded: a way for candidates to explain their profile, demonstrate their strengths and grow their self-awareness.

It did not sound difficult. Our first instinct was that a working product was a few months away. Having delivered enough innovation projects to know better, we stretched the estimate to twelve months. Eighteen months later, Higher launched.

How hard can it be?

During that project we noticed something worth naming: the duration of a project is inversely proportional to the depth of understanding of the problem. In simple terms, when your thinking can still be captured in a paragraph, you are a long way from launch. We call this Clarkson’s law, in homage to Jeremy Clarkson’s battle cry of “how hard can it be?”, a question that is inevitably followed by a failed contraption.

Naming the law was the easy part. The useful question is why it holds. Looking back at Higher, and at the client projects since, four lessons explain the gap between the paragraph and the product.

You don’t know what you don’t know

At the start of a project you have not, by definition, thought through every part of it. Your assessment of the work is distorted by the simplicity of the idea and your enthusiasm for it. As the project develops, your understanding of the requirements develops with it. Anyone who has been near a software project knows the label for this: scope creep. But in our experience it is rarely that the solution must deliver more outcomes than were asked for. It is that the solution has to do more than anyone realised to deliver the outcomes that were.

Scope doesn’t creep. Understanding grows.

Jeff Patton

You can’t tell if you’re right until you see it

Learning what actually needs to be built requires seeing the solution in action. A written description, however well argued, is not enough: your brain is far better at judging something in front of it than something imagined. Only when you see what does not work can you define what does.

On Higher we were convinced it would be powerful to generate a personal coat of arms capturing each user’s personality: historically resonant, an instant shortcut to understanding someone. After several design iterations we admitted it was simplistic and distracting, and dropped it. No amount of discussion would have killed that idea. Seeing it did.

Design is not a child of the idea. It is a sibling.

There is a traditional mindset that says get the thinking straight, then find a design that executes it well. The idea is the parent; the design is the child. But good design is as much problem solving as visual creativity, and we regularly find that the act of designing grows the idea itself.

The best feature in Higher arrived exactly that way. While designing the personality feedback we realised that once people understood their profile, they needed a way to prove it: a personal portfolio, a bank of stories and evidence for explaining themselves in career conversations. That thinking came out of the design work, not the other way round.

Iterations are how understanding grows

You will need more iterations than you plan for. Each one deepens your understanding of how the problem actually gets solved for the user. The first version of anything is a view from five thousand feet. Every iteration brings the ground closer, and it is only as the ground comes into view that you learn how the solution has to land.

What we do about it

  • Expect the idea to mature. Innovative ideas need time under load. We plan on the basis that much of the real learning happens during the build, not before it.
  • Practise the shimmy. Take the idea, sketch it, see it working, revise it. We call this the shimmy: an iteration whose explicit purpose is to let the tangible version improve the idea. Knowing you will shimmy several times stops you polishing details before you are ready.
  • Ask how, five times. Lean thinking asks why five times to find a root cause. For new projects we ask how instead: how will that work, then how will that work, until you hit the ground. It is the fastest gauge of project complexity we know, and it shows you where the real effort will go.

AI has made Clarkson’s law more dangerous

Generative AI looks, at first, like the end of Clarkson’s law: you can now produce a working-looking prototype in a day. In fact the law has become more dangerous, because the prototype now arrives before the understanding does. It demonstrates beautifully, everyone in the room quietly concludes the project is nearly finished, and the thinking is still at the paragraph stage.

We saw this from the inside recently. A founder came to us with a product they had built themselves with AI tools. It worked, and it proved the idea. But selling it commercially meant crossing a real gap: proper security and access control, keeping each client’s data separate, storage and scalability, a back end fit for paying customers. The distance between looks done and is done had not shrunk. It had become harder to see.

None of this is an argument against AI, which we use daily and which took that founder further, faster, than they could have gone before. It is an argument for treating every impressive demo as the beginning of the work rather than the end of it.

The point

Innovative projects do something new, and most organisations are configured to be good at what they already do. Teams overestimate how well they can describe an idea at the start, then pay for it downstream in milestones and budgets. So expect understanding to grow. Get the solution in front of your eyes early and often. Give design a full seat at the table. And whenever you hear “how hard can it be?”, remember that the honest answer is: harder than the paragraph suggests.