A few of the problems I've helped untangle.

These are real pieces of work, named where I have permission and anonymised otherwise. They share one thing: the most valuable change was rarely the one anyone expected.

Voyage Manager

The situation

A founder I'd known for years runs Voyage Manager, a company whose software does something quietly difficult: it tracks business travellers as they move around the world, pulling together signals from booking systems, phones and dozens of other touchpoints. His biggest customer, a travel-assistance company, relies on it to reach people fast when something goes wrong abroad.

The technology was strong. What he wanted was better results from the business around it. The commercial relationship with that main customer had grown steadily over years, billed on a simple per-trip basis.

The work

We started by getting a clear picture of that relationship. The information existed, but it lived in three places that had never been looked at side by side: how the software was used, what the contract committed to, and what had been invoiced. I joined those up and reconstructed the full commercial story of the past three years in a single view.

Seeing it all in one place changed the conversation. Instead of talking about the product, we could talk about the shape of the deal itself.

The software was never the problem.

What changed

From that picture, I designed a new commercial model, moving away from charging purely per trip towards a sliding scale with agreed minimum spends.

It worked for both sides. His customer could extend the service to more of their own clients, including the marginal ones the per-trip cost had previously made uneconomical. And the business got more volume on a steadier footing, on a relationship now built to grow.

A company with two app teams

The situation

A company had two versions of the same product, one for iPhone, one for Android, and they refused to stay in step. Features arrived on one before the other. Even when both had a feature, it behaved differently. To everyone involved, it looked like a technical problem with the apps.

The work

I came in with a colleague to find out why. We worked at two levels at once: the two of us with the leadership, and a couple of senior developers alongside the teams doing the work.

Over five weeks we talked to people up and down the organisation, from the CTO to the testers, and met every day to compare what we were learning. Slowly a picture formed.

The design team couldn't fully specify a feature without input from the developers, and the developers were always too busy to give it. So features landed in the backlog half-defined. From there the two app teams worked separately: each picked its own priorities, and each had to guess at what a half-defined feature really meant. They guessed differently. That was the drift.

It had nothing to do with the code.

What changed

For the first time, the leadership could see the real shape of the problem. Not two underperforming teams, but a structure that quietly guaranteed they'd pull apart.

We proposed a fix: second some developers into the design team, so features were properly worked out before they reached the backlog. On paper it slows development slightly; in practice we were confident it would raise quality and bring the two apps back into line.

They were genuinely receptive. Whether they restructured in the end, I can't say, but they left with a clear, shared understanding of what had really been going wrong.

An adviser to top football clubs

The situation

A specialist had built a rare reputation with some of the biggest football clubs in the world, names every fan would know. He specialised in an aspect of how those clubs are run off the pitch. Demand for his hands-on help had outgrown what one person could deliver, and he was having to turn major clubs away.

The work

The idea was to capture a slice of his experience in a software system: a self-guided tool that could give a club some of what they could otherwise only get with his hands-on presence. It would help them find their biggest weakness and start on the easiest fixes themselves.

I brought in a designer, and together we interviewed the people responsible for this work inside several clubs, to understand what they really needed. The answer was a self-diagnostic built on his method. From there, I led a small team of developers to build it, and we ran a pilot with real clubs.

Real expertise, turned into software that actually worked.

What changed

The tool performed exactly as it was meant to, and delivered just what the clubs wanted. In the pilot, they could sit down with it, see clearly where they were falling short, and act on it, drawing on expertise that until then had lived in one person's head.

If you recognise your own situation in any of these, I'd love to talk it through.

Let's talk