Four people. One year. 35x revenue growth. That’s not just made up numbers. That’s Fyxer, a B2B SaaS company that used A/B testing to grow from $1M to $35M ARR with a team of four, documented in detail by GrowthBook. If you’ve ever been told you need a dedicated experimentation team of ten before you can run a serious program, that case study is worth a read.
The assumption that small teams can’t run effective experimentation programs is one of the more persistent myths in this space. And it’s usually held most strongly by people inside large organisations, because large organisations have made peace with the overhead that comes with size.
The standup that needs eight people…
The test idea that needs three approvals…
The experiment that’s been in QA for 6 weeks because dev resource got pulled…
Small teams don’t have those problems. They have different ones. And when you understand what those are, you can build a program that consistently punches above its weight.
What Small Teams Actually Have That Big Teams Don’t
Speed is the obvious one. A team of three or four can go from test idea to live experiment in days. No committee. No brand review that takes two weeks. No waiting for someone to get back from annual leave before a decision gets made. The decision loop is short because the people making the decision are the same people doing the work.
But there’s something less obvious, and it’s more important. Small teams have focus by necessity. When you’re two or three people running an experimentation program alongside other responsibilities, you cannot run eight experiments at once. You can’t maintain the documentation, the analysis, the ideation pipeline and the stakeholder communication at scale. So you don’t. You pick the experiments that matter most. And that constraint, the one that feels like a disadvantage, is actually doing your program a service.
I’ve watched large CRO teams fall into a specific trap. They have resource, so they run volume. Lots of experiments, lower average quality per test, and a program that starts to look productive on a dashboard while the actual signal-to-noise ratio quietly drops. The prioritisation pressure isn’t there when you have capacity. Small teams don’t have that problem. Every test slot has to earn its place.
The other thing small teams have is clarity of purpose. When you’re small, the people running the program usually know exactly what the business is trying to do. They’re close to the product, close to the commercial goals, close to the conversations that matter. That proximity is genuinely valuable. It means experiment ideas come from real questions, not from someone riffing in a workshop about what would be cool to test.
The Fyxer Benchmark and What It Actually Tells You
The Fyxer story is worth unpacking because it’s not just a nice number. The details matter. A four-person team, running systematic A/b tests, growing from $1M to $35M ARR in a single year. The testing was focused on conversion and activation, the areas where small improvements in behavior compound fastest in a SaaS model. They weren’t running tests on button colours. They were testing the moments that determined whether a user got value from the product quickly enough to stay.
That specificity is the lesson. The testing wasn’t broad. It was targeted at the highest-leverage points in the funnel. And because the team was small, there was no option to spread the effort thin. Every experiment had to be defensible. What question is this answering? Where in the funnel does this land? What’s the business impact if we’re right?
The full case study is at the GrowthBook blog, and if you’re building or rebuilding a program right now, it’s worth reading in full. Not because you’ll replicate the result, but because the process is transferable.
Prioritisation Is the Whole Game
If you’re running a small experimentation program, prioritisation is not one of the things you need to get right. It is the thing. Everything else, your tools, your statistical approach, your documentation etc. is supporting infrastructure. Prioritisation is the program.
Here’s why. A small team running three experiments a month is making twelve or thirteen bets per quarter. A larger team might run thirty. The smaller team needs a higher hit rate on tests that actually move the needle, because they have fewer rolls. Which means the decision about what to test next is, in practical terms, the most important decision the program makes on a recurring basis.
Most teams approach this loosely. Ideas come from meetings, from competitor analysis, from gut feel. Someone senior suggests something and it goes to the top of the pile. That’s not a prioritisation process. That’s a request queue dressed up as one.
The frameworks that actually help here share a common logic. They ask you to score test ideas against dimensions that predict whether the test is worth running. The PIE framework, developed by WiderFunnel, asks you to rate each idea across Potential, Importance, and Ease. Potential is how much improvement is plausible. Importance is whether the page or step you’re testing actually matters to the business goal. Ease is how hard it is to build and launch. You score each dimension, average across them, and rank your backlog.
ICE is a simpler version of the same logic. Impact, Confidence, Ease. It’s faster to apply and slightly less precise. Good for teams that need to move quickly through a long backlog.
Both frameworks have a weakness, which is that they don’t explicitly account for risk. Running the wrong test isn’t neutral. It costs time, dev resource, and in some cases it can move a metric in the wrong direction before you’ve caught it. A framework that doesn’t weight the downside of being wrong is incomplete for any team that’s resource-constrained. Which is every small team.
Prioritisation frameworks tell you which ideas are interesting. Risk weighting tells you which ones are safe to run given what you currently know. You need both.
What Small Teams Should Focus On vs. Deprioritise
One of the clearer patterns I’ve noticed is that small teams often spend too much time on tests that are low-risk but also low-signal. They test things they’re already fairly confident about, they get the win, they report it upward, and the program looks healthy without actually generating much new information.
The tests worth prioritising are the ones that answer questions you genuinely don’t know the answer to. That might feel obvious, but in practice it runs counter to how most backlogs get built. People want to test things they think will win. A test that’s likely to win feels lower-risk. But a test that’s likely to win is also a test that’s likely to confirm something you already believed, which means the learning value is low even if the metric moves.
Small teams should be aggressive about testing earlier in the funnel. The landing page, the onboarding flow, the first moment of value. These are the places where the volume is highest, the behavior is most formative, and the compound effect of small improvements is greatest. Testing a checkout variation on an e-commerce site where ninety percent of drop-off happens at product page level is allocating your limited capacity to the wrong part of the problem.
What small teams should deprioritise is anything that requires significant engineering investment to build a variant that produces unclear signal. If a test is hard to build, hard to measure, and tests something that isn’t directly tied to a core conversion or retention event, it doesn’t deserve a slot when you’re running a program of three. Save that test for when you have the capacity to do it properly, or until a losing experiment elsewhere tells you this is actually where the problem lives.
I’ve also found that small teams benefit from being honest about what’s a CRO problem and what isn’t. A program running on weak traffic, where the acquisition channels are sending users who were never going to convert, isn’t going to be saved by better experiments. The Wine Society taught me something about this:
quantifying what a losing variant would have cost if it had been shipped without testing is often more compelling to stakeholders than the wins.
It reframes the whole program as risk management, not just growth. And it makes the case, when needed, that the problem isn’t the test, it’s something upstream of it.
The Volume Trap and How to Avoid It
There’s a specific mistake that small teams make when they first get momentum. They try to run more experiments. The logic makes sense on the surface. More tests, more learnings, faster velocity. But small teams that chase volume usually end up running tests they haven’t diagnosed properly, which means they’re generating results that are hard to interpret, hard to act on, and gradually filling a backlog with inconclusive data.
Two or three concurrent experiments is a reasonable limit for a team of two to four people managing the full process. That’s ideation, design, build, QA, launch, monitoring, analysis, and documentation. If you’re doing all of that properly, you’re running a tight program. If you’re cutting corners to run more, you’re generating noise.
The discipline here comes from making the experimentation program itself legible to the people running it. A shared backlog with a clear scoring system, a defined process for moving ideas from hypothesis to live test, and a consistent standard for what counts as a result worth acting on. That structure isn’t bureaucracy. For a small team it’s what makes the program sustainable past the first six months.
One thing I’d add. The teams I’ve seen build the most durable small-team programs are the ones that document losses as carefully as wins. A test that loses isn’t a failure. It’s the answer to a question you were previously guessing at. That answer is worth keeping. It informs the next round of prioritisation. It tells you something about your users that you can use even if you never run a follow-up test on that specific question.
The Stakeholder Problem
Small experimentation programs often hit a ceiling that has nothing to do with their technical capability or their process quality. They stall because they don’t have the right people bought in above them. A branding team that blocks variants. A dev squad with no capacity to support builds. A senior stakeholder who doesn’t understand why a test took three weeks and produced an inconclusive result.
The most capable small teams I’ve worked with have understood, sometimes painfully, that this is a politics problem, not an experimentation problem. You can have a perfect program and still spend months being blocked because the people with resource don’t see why they should prioritise it. The fix is not to argue harder about statistical significance. It’s to find the person who oversees the blocking function and give them a reason to care.
That reason is usually framed in risk. Not “here’s what we could gain” but “here’s what it would have cost us to ship this change without testing.” When leadership sees the program as risk management, the conversation shifts. Resource becomes easier to justify. Blocks become easier to resolve. And the program gets traction it couldn’t get by demonstrating wins alone.
Where to Start If You’re Building This Now
If you’re a small team building an experimentation program from scratch, the sequence matters. Start with diagnosis, not testing. Before you run a single experiment, make sure you understand where in the funnel the problem actually is. Session recordings, heatmaps, funnel analysis, user interviews. The test you design is only as good as the question it’s answering, and you need to know what the question is before you design it.
Then build your backlog, score it, and be ruthless about what makes the first cut. You don’t need twenty tests in flight. You need two or three good ones. Get those live, run them clean, document what you find, and let the results inform what comes next.
The biggest mistake small teams make is trying to look like a large-team program before they’ve built the foundations. Velocity comes later. First, you need to know what you’re testing and why it matters more than everything else you could be testing instead.
That last question, what should we test first, is the one that most small teams underinvest in answering properly. If you’re working through it right now, the Risk Ranker (free download) is built specifically for this. It helps small teams weigh up their test ideas against the factors that actually predict whether a test is worth the slot, so the most important decision your program makes doesn’t come down to whoever spoke loudest in the last meeting.
