Last week we talked about closing open loops - those "maybe we should..." decisions that drain your team's energy.

‍

This week, I want to talk about what happens after you've closed a loop: the overwhelming urge to do everything at once.

‍

Because once you've decided what to focus on, the next question is always: how fast should we go?

‍

THE SPEED PARADOX

I was speaking with a founder recently who perfectly captured this dilemma:

‍

"Part of me would like to run loads of experiments in parallel because it means we could learn faster. And then the sensibility kicks in, and I realise we're going to waste a lot of time and money by doing too much at once."

‍

Their startup had a £80k monthly burn rate. They'd just closed a major loop - they knew they needed to find one to two channels with a positive lifetime value (LTV) to customer acquisition cost ratio before scaling anything else.

‍

But knowing what to focus on didn't solve the harder question: what's the right speed to go at?

‍

This is the speed paradox. Everyone knows they need to move fast. But moving fast doesn't mean doing everything simultaneously.

‍

WHY PARALLEL TESTING FEELS RIGHT (BUT RARELY IS)

When you're under pressure to grow, the logic of parallel testing seems obvious:

‍

More experiments = more learning = faster progress

‍

If we test 5 channels at once, we'll find our winner 5x faster

‍

While competitors are testing one thing, we're testing ten

‍

The problem? This logic only works if you have unlimited attention, unlimited resources, and unlimited ability to interpret conflicting signals.

‍

Most startups have none of these things.

‍

WHAT ACTUALLY HAPPENS WHEN YOU TEST TOO MUCH AT ONCE

Your team's focus fractures

Instead of getting really good at one approach, everyone becomes mediocre at many. The developer is context-switching between five landing pages. The marketer is splitting time across multiple channels, never quite optimising any of them properly.

‍

Your learning gets muddy

When you run five experiments simultaneously and one works, you don't actually know why. Was it the channel? The message? The audience? The timing? You've got a result, but not understanding.

‍

Your budget spreads too thin

That client I mentioned was getting 50 downloads per day spending £1,000 per month on ads. If they'd split that across five channels instead of focusing on one, they'd have been spending £200 per channel - not enough to get statistical significance on any of them.

‍

You mistake activity for progress

Having ten experiments running feels productive. But if none of them are getting enough attention to succeed, you're just staying busy while standing still.

‍

THE ALTERNATIVE: SEQUENTIAL LEARNING WITH CLEAR MILESTONES

The most successful startups we work with don't test everything at once. They follow a simple principle:

‍

Find one thing that works. Make it work really well. Then find the next thing.

‍

This isn't slower. It's actually faster because:

‍

• You get real learning from each experiment
• You build confidence in your approach before moving on
• You don't waste budget on tests that never reach significance
• Your team gets good at execution instead of staying in setup mode

‍

Here's how to do it:

‍

1. Stack your experiments by priority

‍

Instead of asking "what can we test in parallel?", ask "what do we need to learn first?"

‍

Create a simple experiment stack:

‍

First: Does our messaging resonate? (Five-second tests, customer interviews)

‍

Then: Which channel can reach our audience? (Small budget tests on 2-3 channels)

‍

Then: Can we convert them? (Landing page optimisation, onboarding flow)

‍

Then: Will they stay? (Retention tests, feature validation)

‍

Each level builds on the one before. You can't optimise retention until you know you can acquire users. You can't scale acquisition until you know your messaging works.

‍

Top tip: Write your experiments on cards and literally stack them. The visual act of putting one on top of another forces you to decide what comes first.

‍

2. Set clear "move on" criteria for each experiment

‍

This is where most teams get stuck. They run an experiment, get some data, then debate endlessly whether it's "good enough" to build on.

‍

Close that loop before you start.

‍

For each experiment, decide upfront:

‍

• What result would make us double down on this?
• What result would make us try a variation?
• What result would make us move on entirely?

‍

Example: "If our Meta ad test gets below £5 cost per download and 20% conversion to signup, we double down. If it's £5-£10, we test three more headline variations. If it's above £10, we try organic LinkedIn instead."

‍

3. Run one primary experiment with one or two fast learning tests on the side

‍

You don't have to be completely sequential. But you need one primary experiment that gets 80% of your attention and budget.

‍

The other 20%? Use it for quick validation tests that inform your primary experiment:

‍

Primary: Testing whether LinkedIn content drives qualified demo requests

‍

Fast validation: Five-second test of your landing page messaging (takes one afternoon)

‍

Fast validation: Survey your email list about their biggest challenge (takes one week)

‍

These fast tests don't compete with your primary experiment - they help you do it better.

‍

Top tip: If your "side" experiment is taking more than a week and £200, it's not a fast validation test - it's a distraction from your primary experiment.

‍

4. Build a learning log, not just a results tracker

‍

After each experiment, spend 30 minutes documenting:

‍

• What you tested and why
• What happened
• What you learned (not just whether it "worked")
• What it means for the next experiment

‍

This compounds over time. Six months of sequential experiments with clear learning beats two years of parallel experiments with muddy results.

‍

One of our clients recently told us: "We've almost got too much data. What we don't have is the ability to turn that into something very actionable that we can learn from very fast."

‍

That's the symptom of testing too much at once. The learning log fixes it.

‍

5. Know when to slow down to speed up

‍

Sometimes the fastest way forward is to pause and get your foundation right.

‍

If you're not sure your messaging is clear? Stop running ads and run five-second tests until it is.

If you're not confident who your ideal customer is? Stop optimising conversion rates and do ten customer interviews.

‍

If you're drowning in data but not making decisions? Stop gathering more and spend a week turning what you have into clear next steps.

‍

These feel like they'll slow you down. They actually accelerate everything that comes after.

A FRAMEWORK FOR FINDING YOUR RIGHT SPEED

Here's the simple test we use with clients:

‍

If you're pre-product/market fit: Run one experiment at a time until you find something that clearly works. You're looking for signal, not optimisation.

‍

If you've found one thing that works: Put 80% of effort into making it work really well. Use the other 20% for quick tests that might become your next primary channel.

‍

If you've got 2-3 proven channels: Now you can run parallel experiments - but only on things you've already validated. You're optimising, not searching.

‍

The founder I mentioned at the start? Their first milestone was finding one channel with positive unit economics. Not five channels. One.

‍

Once they nail that channel and max it out, then they'll look for the next one.

‍

That's not slow. That's focused.

YOUR STARTING POINT

Look at your experiment list for this quarter. If you've got more than three things running, you're probably spreading too thin.

‍

Pick one to be your primary focus. That's the experiment that gets the best people, most of the budget, and real attention until you've learned what you need to learn from it.

‍

Everything else either supports that experiment or waits its turn.

‍

The companies that grow fastest aren't the ones testing everything. They're the ones learning from each test before moving to the next one.

‍

P.S. If you're thinking "but my competitor is doing everything at once and it seems to be working" - remember you're only seeing their output, not their internal chaos. And more importantly, you're not competing on number of experiments. You're competing on speed of learning. Sequential always beats parallel when it comes to real learning.

‍