Scribble It Down or Throw It Out: The One-Coaster Rule for British Founders

There's a particular kind of founder meeting that happens in every accelerator, every co-working space, and every slightly-too-warm WeWork in Britain. Someone opens a laptop. A deck appears. Forty-seven slides later, you still aren't entirely sure what problem the company is solving, but you've seen a lot of gradients and the word 'ecosystem' used as a verb.

Contrast that with the conversation that apparently launched a fairly successful logistics startup in Sheffield. Two blokes in a Wetherspoons. One beermat. The scrawled words: "drivers don't know when loading bays are free." That was it. That was the whole thing.

They shipped a working prototype in six weeks.

The beermat, it turns out, is not just a charming metaphor. It is a brutally effective filter.

Why Complexity Is Usually a Symptom, Not a Feature

British founders — and, frankly, founders everywhere — have a tendency to fall in love with the complexity of their own problems. It's understandable. You've spent months, sometimes years, living inside an industry, watching the inefficiencies stack up like unread Jira tickets. By the time you sit down to articulate the problem, you've got seventeen layers of nuance, three regulatory caveats, and a firm belief that nobody who hasn't worked in your sector for a decade could possibly understand.

This is almost always wrong.

The nuance is real. The complexity is real. But the core problem — the thing that, if you solved it, would make someone genuinely grateful and willing to pay — is almost never complex. It is, in fact, usually embarrassingly simple. The complexity lives in the solution, not the problem.

A useful test: can you write the problem on a beermat? Not the solution. Not the market opportunity. Not the TAM/SAM/SOM breakdown your investor deck insists upon. Just the problem. One sentence. Legible after two pints.

If you can't, you're probably not solving one problem. You're solving several, or none.

The Diagnostic in Practice

Let's be specific about what this actually looks like, because 'simplify your problem statement' is advice that sounds obvious and gets ignored constantly.

Start by writing your current problem statement down in full. Don't edit it. Give yourself five minutes and write everything you'd normally say in a pitch. Now, take a beermat — or, if you're doing this in an office, a Post-it, a napkin, the back of a business card from 2019 you found in your jacket pocket — and try to reduce it to a single sentence.

Not a sentence with seventeen subclauses. A sentence a reasonably intelligent person with no industry knowledge could read and immediately understand.

If you can't do it, that's the finding. That's the diagnostic result. You don't have a problem statement; you have a problem cloud. And building a product inside a problem cloud is how you end up with a 'platform' that does fourteen things adequately and none of them brilliantly.

Case Studies in Painful Simplicity

A small Edinburgh-based SaaS company spent the better part of a year building a comprehensive workforce management suite for care homes. Scheduling, compliance tracking, incident reporting, staff communications — the works. It was technically impressive. It was also, as their lead developer later admitted to us with the resigned expression of someone who has been there, 'a bit of a nightmare to explain.'

Their sales cycle was brutal. Demos ran long. Prospects kept asking which bit they actually needed.

Eventually, almost by accident, one of the founders sat down with a care home manager and asked a very simple question: what's the thing that keeps you up at night? The answer, delivered without hesitation: "Getting the rota sorted when someone calls in sick on a Sunday."

That's a beermat problem. They stripped the product back to that single workflow, relaunched it at a lower price point, and signed thirty new customers in four months.

The elaborate suite still exists. But they sell the Sunday rota problem first.

The Counterargument (and Why It Doesn't Hold)

Some founders push back on this. Real problems, they argue, are genuinely complicated. Healthcare. Financial services. Supply chains. You can't reduce thirty years of regulatory sediment to a single sentence without losing something important.

Fair enough. But here's the thing: the beermat test isn't asking you to solve the problem on the beermat. It's asking you to identify it there. The solution can be as complex as it needs to be. The problem, however, should be simple enough to state clearly.

If your problem statement requires a glossary, that's not complexity — that's obfuscation. Usually self-inflicted, usually well-intentioned, and almost always fatal to early sales conversations.

A Practical Framework (That Fits on a Beermat)

Here's what the actual exercise looks like, distilled:

Step one: Write your problem statement in full. No limits.

Step two: Identify the single group of people who feel this problem most acutely. Not 'SMEs'. An actual type of person, with a job title, who swears quietly at their screen because of this specific thing.

Step three: Write one sentence describing what they can't do, or what goes wrong, because this problem exists.

Step four: If that sentence fits on a beermat, you have a problem statement. If it doesn't, go back to step two.

This is not a silver bullet. Plenty of companies with crystal-clear problem statements have still failed spectacularly for other reasons. But the ones that succeed almost always have this clarity early, even if they acquired it accidentally.

The Real Point

The beermat isn't a gimmick. It's a constraint, and constraints are extraordinarily useful when you're building something new. They force prioritisation. They force honesty. They prevent you from hiding behind complexity when what you actually need is clarity.

British founders, in particular, have a cultural tendency to understate and over-engineer simultaneously — to be modest about the ambition while being wildly elaborate about the execution. The beermat test is a corrective to that. It asks you to be direct about the single most important thing, which is usually the thing you've been slightly embarrassed to say out loud because it sounds too simple.

It probably isn't too simple. It's probably just right.

Get the beermat out.