Staircase or flywheel?

Almost everyone in business has seen Maslow’s hierarchy of needs drawn as a pyramid. Food and shelter at the bottom, self-actualisation at the top.

Maslow never drew it.

When Todd Bridgman, Stephen Cummings and John Ballard went looking in 2019, they searched his books, articles, diaries and archive and found no trace of Maslow framing his ideas as a pyramid. The first drawing of his theory, in a 1957 textbook by Keith Davis, was a staircase. The pyramid came in 1960, from a consultant called Charles McDermid, in an article on getting “maximum motivation at the lowest cost”.

So what has Maslow’s pyramid got to do with your revenue engine?

Diagrams make ideas tidier than they are. A staircase says you finish one step before you start the next. Real life rarely works like that, for people or for marketing teams.

I drew a staircase too

I’ve described my revenue engine as three layers built in order: foundation, then predictability, then optimisation and scale. Crawl, walk, run.

I still believe the order matters. But I’ve drawn it as a staircase, and it isn’t really one. Once it’s running, it behaves much more like a flywheel - each layer feeding the others, none of them ever finished.

So my answer to “staircase or flywheel?” is both, in a particular way: a flywheel with prerequisites. I’ve broken it into three parts: why the order still matters, why it’s really a loop, and how to run it as one.

1. Why the order still matters

You can’t test what you can’t measure, and you can’t scale what you haven’t tested.

That’s the case for the staircase, and it’s a strong one. Run experiments on numbers nobody trusts and you’ll learn the wrong lessons with great confidence. Scale a tactic nobody has tested and you’ll spend more, faster, on something that may not work. And bolt AI onto either and you’ll do both at machine speed.

The software world worked this out a long time ago. The Capability Maturity Model, developed at Carnegie Mellon’s Software Engineering Institute, describes organisations moving through levels from ad hoc to optimising, and its 1993 report has a whole section on skipping maturity levels. The lesson that’s been taught ever since is simple: you can’t.

That matches my experience. At Rescale, the first thing we did wasn’t a campaign. It was agreeing goals, budget, metrics and reporting. The prerequisites came first.

2. Why it’s really a loop

But here’s where the staircase breaks down. The layers don’t stay finished.

Amazon is the famous example of the other shape. In 2001, in the middle of the dot-com bust, Jeff Bezos and his team mapped their business as a virtuous cycle after time with Jim Collins: lower prices brought more customer visits, which attracted more third-party sellers, which spread fixed costs further and allowed lower prices still. Each part pushed the next. None of them was ever “done”.

A revenue engine works the same way. What you learn by optimising feeds back into the model, and sometimes all the way down into the foundation. When we tested removing the phone number field from critical forms, it wasn’t just a conversion question. It immediately raised a foundation question: how would SDRs follow up without a phone number?

And the model in the middle never gets thrown away. Markets shift, buyers change, and the tests that underpin your plan need running again. Predictability isn’t a step you climb past. It’s the hub the whole wheel turns on.

3. Run it as a flywheel with prerequisites

So how do you run it?

Build the minimum foundation first - trustworthy numbers, shared definitions, follow-up that works. Don’t wait for perfect. Then start the loop: hypotheses, tests, and scaling what works. And decide in advance what sends you back down a layer.

For me, there are a few clear triggers:

• The numbers stop matching. If the CRM, the board deck and finance drift apart again, the foundation needs work before anything else.
• A test result surprises you. That’s often a sign the model is out of date, not that the test was wrong.
• You change something big. A new channel, a new segment or a new way of selling usually needs new definitions as well as new tactics.
• Results flatten. If optimisation stops paying, check whether you’re only harvesting the demand you can see.

That’s the difference between a staircase and a flywheel with prerequisites. On a staircase you only go up. On a flywheel you keep coming back round, and each pass is easier because the last one left something behind.

What good looks like

A few golden rules I use to check whether the flywheel is really turning:

• A minimum foundation, agreed. Everyone knows what “good enough to decide” means for your data.
• The model is a living document. Assumptions are revisited on a schedule, not once a year.
• Learning flows down as well as up. Test results can change definitions and processes, not just tactics.
• Triggers are written down. You know what sends you back to fix the foundation or the model.
• Each pass leaves something behind. A clearer definition, a retested assumption, a documented result.
• Nobody calls a layer finished. Foundation, predictability and scale each have an owner, permanently.

For me, yes and no

There’s a fair challenge to the prerequisites, and it usually comes from fast-growing startups. If you wait for clean foundations before you start, a competitor who’s comfortable with messy data will take the market while you’re tidying your CRM.

There’s truth in that. Speed matters, and perfection is a trap. Anyone who’s worked in a seed-stage start-up knows you don’t get to build the ideal foundation before you sell anything.

But that’s an argument for a smaller foundation, not for none. The minimum is lower than people fear - a few signed definitions, follow-up you can rely on, numbers good enough to decide with. Skip even that and the flywheel doesn’t spin faster. It just wobbles.

Where to start on Monday

1. Write your minimum foundation. List the three or four things that must be true before you trust a test result.
2. Write your triggers. Agree what would send you back down a layer, and who would call it.
3. Pick one assumption to re-test. Choose something your plan relies on that hasn’t been tested in over a year.

Do you run your engine as a staircase or a flywheel? I’d love to hear where other people draw the line.

Next, I’ll step back from the engine to the people running it, starting with how leaders make decisions when the outcome can’t be known.