Find. Strip. Try. Prove.

By this point you may reasonably be wondering whether there is actually a method hiding underneath all of this. I resisted giving it a grand name for quite a while, partly because the quickest way to ruin a simple idea is usually to put it in a hexagon, add some arrows and start behaving as though nobody has ever had a sensible thought before.

There is, though, a repeatable shape to the work, and four words seem to do the job perfectly well. Find. Strip. Try. Prove.

Find the friction by watching the work and listening to the person doing it.

Strip the problem back to the outcome that matters, removing, simplifying, reusing or connecting before adding anything new.

Try the smallest sensible intervention with real people doing real work.

Prove what changed, then decide what the evidence has earned. Kill it, keep it small, harden it, scale it, productise it or buy the mature answer.

There are much more sophisticated ways to describe all of that, I know because I have spent a career in meetings where somebody inevitably has, usually with a diagram. But if I cannot explain the basic idea to Neil over a pint without reaching for PowerPoint, I am not sure it deserves to survive at all.

The four words arrived late because I did not begin with a method. I began with a collection of experiences that kept behaving in similar ways. That is probably why I trust the words now. They describe what I had already learned to do rather than prescribing a process invented in order to make the book look organised.

Finding is more demanding than spotting something annoying. Good friction is repeated, consequential enough to matter and close enough to real work that you can watch it happen. A complaint from one person may be useful. A workaround repeated by twenty people every week is evidence. The job is to stay curious long enough to tell the difference.

Stripping is where I think most projects could save themselves a fortune. People arrive with solutions already attached to their problems. They need a new system, a dashboard, an app, an integration. Strip asks what outcome sits underneath the request and what can disappear before anything new is introduced. This is the stage where doing nothing, changing a process or using something already available can beat a build before the build has begun.

Trying is deliberately practical. I do not mean producing a beautiful demonstration that behaves perfectly while the person who made it is standing beside it. Put enough of the idea into real work that it can be contradicted. Let a sceptical manager touch it. Let Friday night happen to it. A prototype that cannot be proven wrong is usually a presentation wearing a login screen.

Proving is the discipline that stops enthusiasm doing the accounting. Look for changed behaviour, removed effort, earlier decisions, requests from people who were not asked to be enthusiastic and evidence strong enough to justify whatever comes next. Sometimes the proof earns another store. Sometimes it earns proper engineering. Sometimes it earns a purchase order. Sometimes it earns the delete key.

That last possibility is why I like the method. It has no predetermined winner. Find, Strip, Try and Prove can end with software, a supplier, a simpler process or nothing at all. If the answer is already decided before those four things happen, the method is not really being followed. It is just being used to decorate a decision that was made earlier.