A few of the problems I've helped untangle.

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.

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.

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 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.

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.

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.