How I work

Every one of these cost me something to learn. What they share is an instinct to make a question cheap to answer before it becomes expensive to get wrong.


Find the cheapest question that settles the argument

Most disagreements about product direction are not really disagreements about evidence, they are disagreements about which question is being asked. Reframing it so a small test can answer it is usually faster than winning the argument on its merits.

At Intruder the question was whether to keep onboarding or go self-service, and nobody could settle it. I reframed it as whether removing the flow would cost more than 1% of conversion, which a redirect test could answer in an afternoon. Building it took thirty minutes. Getting agreement to build it took twelve months.


Agree the approach before opening Figma

Designing against a logic nobody has agreed to produces work that looks finished and settles nothing. I would rather spend the time up front, even when it feels like delay, because a screen is an expensive way to discover that the thinking underneath it does not hold.

With Paideia I refused to design the screens until the extraction layer behind them worked. The interface was only ever going to be a thin wrapper around whether a photograph of a handwritten planner could become structured lessons, and if that failed no amount of screen design would have rescued it.


Automate the rule, keep the judgement

When a process is slow, the useful question is which parts of it are rule-checkable and which need a person. Automating the first and protecting the second scales output without flattening the thing that made the work good in the first place.

At Newsflare the journalists, led by David Hickey, corroborated filmers' accounts with witnesses before a video went out. Rights and safety were checkable against rules, so we automated them. Whether a video was compelling was not, so it stayed with them. Output went from 20 videos a day to more than 80, with a smaller team.


When adoption is stuck, look for the fear before the missing feature

A feature people can use but do not is rarely an interface problem. Something about using it feels costly or risky, and that cost is usually invisible in the product itself.

Intruder customers were not importing their cloud estates, and the obvious reading was that bulk import was awkward. It wasn't. They were afraid of what appearing in the platform would do to their licence bill, so what unlocked adoption was granular sync controls and a clearer licence flow, not a better import screen.


Check whether the thing you are growing can survive its own success

Growth work tends to concentrate on the lever that is moving, which is not always the one holding everything up. It is worth asking periodically which part of the system would break first if the current plan worked.

Intruder's churn was running above benchmark while the attention was on enterprise. The customers actually leaving were the smaller ones, and between them they carried around 80% of monthly recurring revenue. Close to four in five said a version of what Kevin told us, that the value was good but he had no need for continuous scanning at that point. Intruder weighed it against the enterprise push and backed the push, which was a defensible call. I would have spent the year on the base.


Where these show up

Most of these show up somewhere in the case studies. The clearest two are the Intruder onboarding project, which is the first practice from start to finish, and Paideia, where the middle three were worked out.