Sandwiches to aeroplanes – reframing discovery for the age of AI

A summary of a talk I gave at NUX Leeds, 6 May 2026. Watch the talk.

Sandwich

You're making a sandwich for someone.

Discovery on a sandwich is straightforward. You might ask, 'What would you like in your sandwich?'. After delivery of the sandwich, you might measure its success by enquiring 'How was your sandwich?'.

The next day you go to work – you're helping design a revolutionary new aeroplane. A huge passenger airliner.

You're collaborating with teams across the world, wading through endless regulations and technicalities. And the risk is as high as it gets – a poor design choice could lead to loss of human life.

If we were to place the discoveries for the sandwich and aeroplane on a chart with 'Risks' and 'Unknowns' on the axes, fairly intuitively I think we'd do this…

I think we can and should apply the same approach to product design discovery, something which is particularly helpful and important in the age of AI.

The goal of discovery

For me, 'discovery' means everything before delivery – from exploring the problem to solution design and testing. (For others, discovery just means the initial problem stage – that's valid too.)

We can add the two broad stages of discovery – 'Problem' and 'Solution' – to the chart. And we can go a step further – I'd define discovery as reducing risks and unknowns, or moving from problem to solution.

'Risks and unknowns' in discovery is not a new concept. Jeanette Fuccella wrote about it in 2021 (their framework for prioritising user research is something I've found super helpful).

And Teresa Torres and Marty Cagan both say that the goal of discovery is to reduce risk.

I'm just reframing in a way that works for me. And adding a sandwich.

Breaking down risks and unknowns

'Risks' and 'Unknowns' stand as intuitive terms. But we could also break them down.

Risks – what could go wrong:

• User: adoption, retention

• Technical: feasibility, reliability

• Business: revenue, profit, reputation, trust

• Market: demand, timing, competitive position

• Operational: support, maintenance, scale

Unknowns – what we haven't figured out yet:

• User: needs, behaviours, journeys

• Technical: unfamiliar tech, complexity, dependencies

• Business: model, pricing, viability

• Market: fit, sizing, competitive landscape

• Operational: resourcing, processes, ownership

Low risks and unknowns (launch and learn)

In the bottom-left of the chart – the zone of low risks and low unknowns – the focus is generally on the solution. Discovery is short, the goal is to ship and measure.

Example

My colleague Dei spotted something in the data on one of our health and safety products. Part of the UI showed users the status of a document (draft, in progress, under review, complete). 27,000 users had clicked it about 110,000 times in 90 days. Trouble was, it wasn't interactive and never had been. It didn't do anything.

If we'd thought through the risks and unknowns, we'd probably have ruled out a few of those categories. But there were some user risks: restyling or moving the element could remove something useful and make it worse. Some technical risks, given it's legacy software that's complex to change. And maybe some user unknowns about how people wanted to move through document states. But realistically, this sat firmly in launch and learn territory.

Discovery took 30 minutes in Figma. I restyled the element, moved it somewhere more sensible, we shipped it, measured again. Clicks went down.

Framing this segment of the chart as "launch and learn" helps me, because it's very common to hear "always launch and learn" or "always ship and measure" framed as universal advice. For some designers and projects, that genuinely is the zone they're always in. But for me, a lot of discovery starts in a different kind of place.

Medium risks and unknowns

In the middle of the chart, the focus is on a balance of problem and solution. Some discovery upfront, then moving into prototyping and testing.

Example

At a legal tech company I used to work for, we built a product that supported families when somebody had died. Part of the experience involved an ops team member spending an hour or so on the phone with a family, collecting important information into a spreadsheet. A spreadsheet is not a great tool for a sensitive call. Data got lost, families had to be called back, and it didn't scale.

If we'd thought through the risks and unknowns at that point, we'd probably have ruled out a few categories. But there were potential user risks: a chance we'd build something no better than the spreadsheet and not really suitable for an emotionally charged call. Technical risks, but not super high; the company was a startup with a modern tech stack, and it was a greenfield project. Business risks: a chance we'd spend a lot of time and not really unlock any scale. And a potential trust and brand risk given the sensitivity of the moment for the family. Plenty of user nknowns too: we didn't really know what the call experience was like, or the flows and value proposition we needed, and there were technical unknowns about what we were even building.

The problem bit of discovery meant rounds of interviews with the ops team, listening in on customer calls, understanding what we needed to do with the data. Then fairly quickly we got into the solution: prototyping, testing internally, designing the thing.

Discovery lasted maybe 6 weeks. It was a balance of problem and solution.

(And by the way it went really well – it's a project I look back on very fondly.)

High risks and unknowns

In the top-right of the chart, the focus of discovery should be on the problem. Interviews, analysis, doing the work to reduce the risks and unknowns before committing to a solution.

Example

A company sold a product on a more or less one-off basis. One of the co-founders had thought for years it should be a subscription model instead. The call was made: we're moving everyone over.

If we'd thought through the risks and unknowns, maybe we'd have ruled out operational. But pretty much everything else applied. There were user risks: people may not have wanted to pay the subscription. Technical risks, given this would involve all three product squads at the company for around three months, with a huge opportunity cost and complex transitions across web and app. Business risks were probably the easiest to spot: totally change your pricing and on day one there's the risk of a drop in revenue, a hit to profit, and churn. Market risks: maybe the market wasn't ready for this and it wasn't how people wanted to pay for this kind of product. And unknowns everywhere. User unknowns: we didn't really know how users felt about buying our product, or their mental models and experiences of paying for comparable products. We didn't know what the flows and experience would have to be. Technical unknowns: how we'd implement complex changes across the product. Business and market unknowns: we weren't super clear on the competition and how they were charging.

How many weeks of problem discovery feels reasonable for this project? Tricky question. Maybe 6? 8? 4?

We did 0 (zero) weeks of problem discovery. That was the decision, and we argued against that unsuccessfully. So we worked hard on making the solution as good as we could.

The goal was 1,000 subscribers within a month or two. We got 6.

The company lost a lot of money, and within a few months, a significant proportion of the workforce had been laid off, including me.

This was a pattern at this company: taking aeroplanes and treating them like sandwiches. In other words, making big bets without appropriate discovery. And more often than not, they didn't work out.

But this stuff is hard. There are plenty of examples beyond my career too. Airbnb Plus is well worth looking up: a known problem, the wrong solution, a lot of money and time lost before they went back and changed it. Here's the story in a Lenny's Podcast with Jiaona Zhang.

AI

AI is impacting all aspects of discovery.

If there's one area of the chart where it's truly re-writing the rules for product designers, it's the bottom left – the low risk, low unknowns, solution part.

And if there's one word I'd assign to that segment, it would be code. Designers are increasingly expected to work in the codebase, prototype in code and generally blur the lines between design and dev.

And if there's a word I'd associate with the top right of the chart, it would be human.

The area of high risk and unknowns is where projects benefit from leaning heavily on human qualities – strategic thinking, collaboration, problem solving, listening to users, working with experts, empathy, organisational awareness, organisational politics.

The top right I associate with complex B2B SaaS, public sector, healthcare, complex systems – though it's more about the project than the domain.

That's not to say there's no role for AI in the top-right; it can certainly help with problem discovery.

And it's not to say there's no role for the human in the bottom-left – taste, judgement, and direction are crucial. But the role of a designer there is changing. It's becoming less about producing many Figma screens, more about how we direct an AI and imbue it with our taste and expertise.

An active discovery – how things are changing

I'm working on a discovery at the moment that leans heavily on AI. It's sustainability product at my current company, helping companies track greenhouse gas emissions across their supply chains.

I'd put it in the middle of the chart. Medium risks, medium unknowns, a balance of problem and solution.

It started in a familiar way. A Miro board, Figma, user interviews, collaborating closely with product manager Neil and with experts in the team.

But even then, AI played a big role. ChatGPT as a mentor to help me understand the subject area, and to help with summarising transcripts and research synthesis. UX Pilot for early design ideas.

Even more interesting is now we're properly into the solution phase. Rather than refining the designs in Figma – which is what I would have done previously – I've built a coded prototype. I took the context from discovery, all the designs, everything we'd learned, and worked with ChatGPT, Claude and VSCode (using Opus as the agent) to build it.

The prototype is now our source of truth. When we're in the room with engineers, we're not looking at Figma, we're looking at the prototype. My main tool for this project, believe it or not, is now VS Code. It's very different from Figma, but in many ways it's liberating, and I can move really quickly.

I've run a round of usability tests with this prototype. Rather than clicking through screens, users can add data, delete it, leave comments, upload things, work through proper workflows. It's a much richer interaction than I could have got from Figma, and easier to change.

There are downsides, and my workflow is shifting every week, but it's exciting.

Sandwich ≠ aeroplane – and that's more important than ever

An aeroplane does not equal a sandwich. With AI rewriting the rules for product designers, that's a more important concept than ever. For two reasons...

(1) it's easier than ever to vibe code something. Anybody in an organisation can vibe code a solution that looks great. And it's very tempting to just build it. But if we take a step back and ask what the risks and unknowns actually are, and whether we're in aeroplane territory, then having a way of thinking about that, and a language for it, helps us advocate for discovery.

(2) if we are in low risk, low unknown territory, as designers we should be moving with the times. Working with AI, moving quickly, not being too afraid to adapt.

But the top-right bit – the aeroplane – is a zone you can't vibe code your way out of. You can't vibe code an aeroplane.

My talk at NUX Leeds

With apologies for the over-exposed camera and microphone failure – both of which can be blamed on user error (by me) – here's a video of my talk.