Using AI without pretending to be an AI expert

The most reliable value I get is in the messy early parts of work. Sorting a large pile of qualitative feedback into rough themes, producing a first draft of something I intend to rewrite, or getting to a testable prototype in an afternoon rather than a week.

That last one matters more than it sounds. A lot of good decisions get delayed because building something real enough to react to is expensive. When that cost drops, you can put more options in front of people and be less attached to any single one.

It's also quite good at the parts of leadership work that are essentially formatting. Restructuring a document, checking whether a case holds together, drafting the version of an argument that a finance audience would recognise. None of that replaces the thinking, but it removes a fair amount of the friction around it.

I founded The Concierge, an AI enabled luxury services venture, which has been the most direct way of learning what this technology does and doesn't do.

Building something yourself removes a lot of the comfortable abstraction. You quickly find out how often the model is confidently wrong, how much of the experience is actually the fallback behaviour, and how much design work sits in the moments when the system can't help.

The honest lesson has been that the interesting problems were rarely about the model. They were about trust, expectations and what happens when something goes wrong, which are the same problems I've been working on for years in other contexts.

I'm wary of teams adopting AI as a way of producing more work rather than better work. Generating forty concepts isn't obviously an improvement on generating four if nobody has time to evaluate any of them properly.

I'm also cautious about it in research. Synthetic responses and automated analysis look convincing, and convincing is exactly the wrong quality when you're trying to find out something you don't already believe.

And there's a skills question I don't have a good answer to yet. A lot of how I learned came from doing the slow, unglamorous version of the work and getting it wrong. I'm genuinely unsure what replaces that for people starting now.

In teams, I have found it works better to start from an existing frustration than from the technology. Ask where the tedious parts of the week are, then see whether any of them can be reduced.

That produces smaller results than a big programme but they tend to stick, because the person using the tool wanted the outcome in the first place.

I also try to keep judgement clearly with people. The model can produce the material, but somebody still has to decide whether it's right, and in my experience that responsibility gets blurry faster than anyone expects.