Exploring the Need: What the Two Ronnies Can Teach Us About Business Agility

In business agility and product thinking, one of the most valuable habits we can build is learning to look beyond the request in front of us and understand the underlying need. So how does a 1970’s British Comedy sketch help? 

There are some things you learn at work. And there are some things you learn from watching a man in a hardware shop repeatedly misunderstand what someone is asking for. For me, both have been surprisingly important. 

I grew up in a small, tight-knit, multi-generational family. My childhood education included Are You Being Served?, Fawlty Towers, Morecambe and Wise and, of course, The Two Ronnies. 

So, when I was asked once in an All Hands session, to talk about something I thought mattered in product and problem solving, I didn’t reach for a complicated framework, I reached for a sketch about four candles. Or, more accurately, fork handles. 

If you’ve never seen the sketch, Ronnie Barker walks into a hardware shop and asks Ronnie Corbett for “fork ‘andles”. Corbett hears “four candles” and promptly produces four candles. What follows is several glorious minutes of two people having a perfectly understandable conversation in which neither of them understands what the other actually needs. It’s very funny and may be the most entertaining introduction to requirements discovery you’ll ever have.  

It’s also an excellent lesson in business agility. 

Because the problem isn’t really communication. The problem is that they’re responding to the request rather than exploring the need behind it. 

And I think that distinction is one of the most useful habits we can develop, wherever we sit in an organization. 

Behind every request is a need 

A customer asks for a feature. A colleague asks for a report. Someone raises a user story. A stakeholder asks for a deadline to be moved. A team says it needs another person. A customer complains that something is broken. A crisis lands in your inbox with the words “URGENT” in capitals.  

The temptation is to respond to the thing in front of us. The request. The ticket. The story. The problem. The crisis. 

But what if we pause for a moment and ask: What is the need behind this? 

That question can change everything: 

• A request for a feature might be a need to reduce manual work. 

• A request for a report might be a need for confidence in a decision. 

• A user story might describe a proposed solution rather than the outcome someone is trying to achieve. 

• A demand for something “by Friday” might be driven by a regulatory deadline, a customer commitment or simply somebody’s assumption that Friday sounded reasonable. 

• And a crisis can sometimes be the visible symptom of a much bigger systemic problem. 

If we take the request at face value, we can become brilliantly efficient at delivering four candles when somebody needed fork handles. 

The danger of solving the wrong problem really well

This is where I think product thinking and business agility have a lot in common. 

Good product practice asks us to understand the problem before jumping to the solution. Business agility asks us to continually sense what is happening around us, learn from it and adapt how we respond. Neither is about having the perfect answer in advance. Both are about creating the conditions for better decisions. 

The Framework for Business Agility suggests a set of lenses for understanding where an organization is agile, where friction exists and where improvement might be valuable. It deliberately isn’t a model to implement. 

That idea resonates with me because sometimes the most valuable thing we can do isn’t to move faster – it’s to stop, look again and make sure we’re moving in the right direction. 

The framework places People, Customer & Ecosystem at the heart of value delivery, alongside the organizational conditions that enable agility: culture, leadership, governance, strategy, operations, change and support. For me, “explore the need” is a small habit that cuts across all those things: 

• It’s about customers because we need to understand the value they need, rather than simply building what they ask for 

• It’s about people because the person closest to a problem often has important context that isn’t visible in the request 

• It’s about strategy because understanding the underlying need helps us distinguish between activity and meaningful outcomes 

• It’s about governance because effective governance is not just about approving work, it’s about ensuring decisions are based on evidence, value, accountability and a clear understanding of the need behind the request. 

• And it’s about change because the need itself can change as we learn 

Ask one more question that helps teams understand the real need

One of the things I love about working in and around product is the detective work. 

You get a request. You pull at the thread. You discover an assumption. That reveals a constraint. That leads to another question. And suddenly the thing you thought you were solving isn’t the thing you need to solve at all. 

Sometimes the answer is still the original request. Sometimes it is something completely different. And sometimes the most valuable outcome is realising that you don’t need to do anything. 

That last one is surprisingly powerful. 

So when I talk about “exploring the need”, I’m not suggesting that we interrogate every request until the person making it wishes they’d never spoken to us. It is simply about developing enough curiosity to ask one more question: 

• What are we actually trying to achieve? 

• What would success look like? 

• Why does this matter? 

• Who has the need? 

• What happens if we don’t do it? 

• What do we know, and what are we assuming? 

Those questions are deceptively simple, but they can stop us spending enormous amounts of time solving the wrong problem. 

From four candles to business agility 

I suspect this is one of the reasons I’ve always been drawn to agile ways of working. 

Not because of ceremonies or terminology, but because, at its best, agility is fundamentally about curiosity – noticing, learning, making sense of what is happening rather than pretending we already know, and about having the confidence to change direction when the evidence tells us that we should. 

The world has become considerably more complicated since Ronnie Barker walked into that hardware shop. 

We have AI, shifting customer expectations, geopolitical uncertainty, new business models, changing regulation and technologies arriving faster than most organizations can work out what to do with them.  

The requests are coming faster too. 

Which makes the ability to distinguish between the thing someone is asking for, and the thing they need, increasingly important because we don’t have unlimited time, money or attention. We need to spend those things on what creates genuine value. And that starts with understanding what the value is.  

So, in the early stages of my journey with the Agile Business Consortium, exploring the need is a useful place to begin. 

I’m fascinated by the questions behind the questions. By the messy bit between strategy and execution, how people, technology, culture and systems interact. By what helps organizations become more adaptable without losing sight of why they exist in the first place. And by bringing people together to work things out. Exploring the need is easier when we don’t do it alone (unlike the shopkeeper) because different perspectives often reveal assumptions that we can’t see ourselves, which is one reason communities of practice and professional networks remain so valuable 

I also remain firmly convinced that there are few better ways to explain all of this than a 1970s comedy sketch about a hardware shop. After all, if there is one thing I hope we can avoid as a community, it is becoming exceptionally good at delivering four candles when everyone really needs fork handles.