Wide problems

It was 2012 and I was having a crisis of confidence. I was one of five expensive consultants tasked with reducing the energy consumption of a kilometre-long paper mill. I felt useless. My colleague Patrick was clearly the expert. He’d done this countless times before, knew all the ways you could tweak fluid flow rates, adjust valve pressures, and a hundred other techniques. My main value add? Trying to read his handwritten diagrams and convert them into slides.

This was a deep problem – tightly constrained, with known dimensions, and a well defined model – and Patrick had spent years going deeply into it. And it taught me a very important lesson: if you face this kind of problem, go deep, become the expert – or find one and get out of their way.

Not long after, I found myself at a startup called onefinestay. We took people’s really nice homes and turned them into upscale hotels for our guests. The problems we faced looked nothing like a paper mill.

Here’s one I remember: our cleaning teams were getting through WAY too much expensive microfibre cloth. So what do you do? Give them less? But if they ran out part way through a day, disruption would cascade. Perhaps it was a training problem, then? Or maybe an analytics problem – could we forecast how much each home should need? Incentives? Procurement – buy packets of cloths, instead of a roll? There certainly wasn’t a ‘how do you reduce microfibre usage when you don’t even know how much should be used’ expert on speed-dial. And in a situation like this, handing it to an expert can be disastrous: give it to a training expert and they’ll inevitably give you a training solution.

In a deep problem there is uncertainty within a well defined model. In a wide problem there is uncertainty about the model itself.

Now fast forward to Nous. We’re building a new category of business – AI agents to take on the load of modern life, starting with household bills. Our agents go further than chatting or giving advice. They do things in the real world, things with consequences. And buying insurance isn’t something you want to hallucinate.

The thing about building a new category is, there’s no one to hire who’s done it before. Not because the expertise doesn’t exist – there are brilliant engineers, operators, insurance people, regulatory people, of course. The point is that nobody is an expert in this combination, because the combination has never existed.

Take insurance. You’ve probably got some. And you probably know you’re supposed to shop for a new policy each year so you don’t get ripped off. (Side note: most people still forget). We wanted our agent to sort people’s insurance, the Nous way. That means taking the load off, rather than adding one more bit of admin. You give us your current policy docs, we’ll work out what you need, and in the run-up to your policy expiring, we’ll recommend one and then go and buy it for you.

No-one has built an insurance journey like this. We didn’t need to invent insurance, or APIs, or LLMs – we needed to combine them in ways none of them were built for. Commercial deals for policy access. Regulators comfortable with a journey they’ve never seen. And running through all of it, the product question: what do we ask you, what do we decide on your behalf, when do we step in? All in a couple of months, in an industry where everything normally takes years.

Tim led the build. He’s not an insurance expert. He’s never worked in insurance. He did a Chemical Engineering MEng, then a Computer Science MSc, and has since been an energy analyst, a one-man software agency and a startup cofounder. And Tim is exactly the person you’d want to follow a wide problem across engineering, insurance, regulation, product and commercial.

Standup this morning: insurance has just launched. We celebrate, then get straight to bug bashing. Turns out, lots of people upload very long policy docs that take ~30 seconds to process – a real speed-bump. What kind of problem is it? A sequencing one; redesign the flow so nothing needs to be realtime? An extraction one; process the pages in parallel? Or just paper over it with a loading screen? Tim runs a quick experiment to see if a cheap, fast model can grab the handful of fields the next screens need within a couple of seconds. That worked – so let’s do that while we kick off the full extraction in the background. It’s going into production now.

I’ve made it sound like the Tim show. In actual fact, he was part of a small squad where everyone takes problems from ‘what even is this?’ all the way to something live in production. And it’s not just engineers: operations and growth are wiring up agents too. Jacob owned what the journey should feel like. Jon owned the commercial deals and the regulatory constraints. He wasn’t an expert either. We needed one, so he became one.

There’s a pattern here. You don’t solve wide problems by thinking harder. You run a quick experiment. You do something manually to understand what you’re trying to automate. Step 2 depends on what you learn from Step 1.

So do you want experts, or generalists who’ll figure it out? The archetype we keep coming back to is the smart generalist problem-solver with a superpower. That superpower might be a skill (‘amazing software architect’), a domain (‘knows everything about the mobile industry’), an approach (‘builds the smallest thing that tests the idea’) or a character trait (‘won’t stop until they’ve cracked it’). Why the superpower? Because wide problems have deep problems buried inside them.

Learning enough about a household without hassling them is a wide problem. We believe Open Banking is one strand of the solution. It gives you a raw stream of payments, but turning that into a picture of a household gets arbitrarily deep, fast. What packages have they signed up to? Have they been oversold something they don’t need? How do you benchmark them against similar households?

The reverse is also true: deep problems often have wide ones wrapped around them. Shazam in the early days was about as ‘deep problem’ as it gets: how do you identify a song from a noisy clip a few seconds long? They understood this from day one: they asked a Stanford professor to list the top experts in Digital Signal Processing and brought Avery Wang, #1 on the list, on board as a cofounder. Exactly the right call – he cracked the algorithm. But no-one had cracked the wide problem around it – ‘how do we make this algorithm into a business?’ They were stuck on that for six years until they got lucky and Apple launched the App Store. That’s a long time to wait for someone else to solve your wide problem.

Which brings us back to the paper mill. Maybe I was just the wrong shape for that problem. It suited someone happy to go deep on one thing for years. And as it turned out, almost every problem I’ve worked on since has been the opposite.

So if you want to be an expert, the paper mills are still out there. But if you’d rather spend your days on the breadth of building AI agents to run parts of people’s lives, with the odd unexpected spell of going deep, come and say hi :-)