April 7, 2026

Happy Tuesday, today's smart brevity count is: ~1700 words, ~7 mins. Edited by Nils Koppelmann.

This week's focus: There's no perfect experimentation org structure — but there is one that fits you.

In today's newsletter, we will go over:

1. Strategic: The org structure question everyone gets wrong
2. Tactical: Which model fits you right now? A 5-question diagnostic
3. Your new job in experimentation?
4. Events

Excited? Read on.

1 big thing: There's No Perfect Experimentation Org Structure. But There Is One That Fits You.

Strategic Insights for Experimentation Leaders

Every few months I see a job posting that signals the same thing: a company scaling experimentation has realised its current setup no longer works. The title changes — Head of Experimentation, VP of Growth, Director of CRO — but the subtext is usually the same. The old structure broke. We're fixing it.

The frustrating part is that most teams never made a deliberate choice in the first place. They started with one person running tests, added a few more, and then woke up one day inside an org model they never designed.

Let's change that.

1. Centralized

One team owns the entire experimentation function. They hold the backlog, run the tests, report the results. Everyone who wants an experiment goes through them.

The upside is real: quality is consistent, methodology is enforced, and it's the fastest way to build a competent function from scratch. When you have three good people and a hundred things to test, centralisation is sensible.

The failure mode is also real: the team becomes a bottleneck. Speed-to-insight drops. Product teams start resenting the queue. And because every request has to be translated across teams, the experiments that get run are often not the most important ones — they're the ones that were easiest to explain.

Centralised models work well early. They almost always need to evolve.

2. Embedded

Experimenters live inside product teams. The payments squad has their tester. The onboarding team has theirs. Tests run where the product decisions are made.

The upside is speed and ownership. There's no backlog to join, no translation layer. The person running the test understands the product context better than anyone.

The failure mode: standards slip. Without a shared methodology, you end up with five teams all deciding what "statistical significance" means to them. Learning stays siloed — the discovery the checkout team made six months ago never reaches the acquisition team. And when budgets get squeezed, embedded roles are always first on the chopping block because they don't have a dedicated cost centre to protect them.

Embedded works well in organisations where product teams have genuine autonomy and are already data-literate. It struggles everywhere else.

3. Center of Excellence (CoE)

A small central team sets the methodology, owns the tooling, and runs enablement. Product teams execute their own experiments — but to a shared standard. The CoE coaches, governs, and synthesises learning across the organisation.

This is the model that scales best. It captures the quality of centralisation and the speed of embedding. But it's also the hardest to build — it requires a central team confident enough to give up execution control, and product teams mature enough to run good tests without a safety net.

Done badly, a CoE becomes a bureaucratic gatekeeping function. Done well, it's the difference between an organisation where 20 teams are all getting smarter at the same time and one where the same mistakes get made in parallel forever.

The Decision Isn't About Best Practice — It's About Fit

Here's the thing that most "org design" frameworks miss: the right model isn't the most advanced one. It's the one that mirrors how your organisation already makes decisions.

If your product teams are genuinely autonomous — if they set their own OKRs, control their roadmaps, and move quickly — then embedding will feel natural. Experimentation becomes part of how they think, not something they request from another team.

If your organisation makes decisions centrally — if there's a strong planning function, centralised analytics, and a culture of standards — then a CoE gives you the governance structure that matches that reality. Embedding would just create chaos.

Trying to install a CoE model in an org that runs bottom-up is like bolting a new engine onto a car with the wrong chassis. It might technically work. It will not feel right.

The Maturity Trap

The other mistake I see consistently: teams treat these models as a progression. Start centralised. Then embed. Then build a CoE.

That's not how it works in practice. Some organisations should never fully embed. Some can go straight to a CoE model if they have the right foundational capabilities. The stage of your experimentation programme matters — but so does the broader organisational context.

What I'd encourage you to do instead is treat this as a diagnostic question: does our current structure enable the volume and quality of testing we need? If the answer is no, ask why — and then ask whether a structural change would actually fix it, or whether the bottleneck is elsewhere (culture, tooling, data quality, executive support).

The One Constant Across All Models

Whatever structure you choose, shared learning is non-negotiable.

Every model breaks down when results stay local. When the team that discovered a major insight about payment flow anxiety doesn't have a way to get that insight to the team designing the checkout confirmation screen.

A knowledge base — even a simple, well-maintained one — is the connective tissue that makes any org model actually work. Not because it's nice to have, but because without it, you're paying the full cost of running experiments and capturing only a fraction of the value.

2. Which Model Fits You Right Now? A 5-Question Diagnostic

Before you restructure anything, run through these five questions. They won't give you a formula — org design never works that way — but they'll surface the signals that actually matter.

1. How does your organisation make decisions?

Not how it says it makes decisions — how it actually does. Are product teams setting their own priorities and moving independently? Or is there a strong central planning function that owns the roadmap?

• Genuinely autonomous product teams → lean toward embedded
• Centralised decision-making → lean toward CoE or centralised
• Mixed → probably CoE with tiered autonomy

2. How many people are actively running experiments?

One or two? Centralise. The overhead of coordination doesn't justify anything else yet.

Five to fifteen, across multiple teams? You're in the transition zone — embedded is probably causing quality drift, but a CoE isn't yet justified. This is the hardest place to be, and the place where most programmes stall.

More than fifteen, across multiple product areas? You need a CoE. The question is just how much autonomy to grant individual teams.

3. How consistent is your methodology across teams?

Pull up three recent test reports from different teams. Do they define success the same way? Use the same significance threshold? Document their hypotheses in a comparable format?

If the answer is no, you have a methodology problem that no org structure will fix on its own. A CoE with a strong enablement mandate is your best lever here.

4. Where do experiments get stuck?

Map the last ten tests that were delayed or cancelled. Did they stall in a backlog? That's a centralisation bottleneck. Did they get deprioritised by product teams? That's an embedding problem — experimentation doesn't yet have enough weight inside the team.

The failure mode you're actually experiencing should point toward the fix.

5. What does leadership actually reward?

This one cuts through everything else. If leadership celebrates teams that move fast and break things, a centralised model will be quietly sabotaged. If leadership rewards rigour and consistency, an embedded model will produce results no one trusts.

Your org structure will only stick if it matches what gets recognised and promoted. If there's a mismatch, fix the incentives before you fix the structure.

3. Your new job in experimentation?

This week's featured roles:

• Medior CRO Specialist at De Mandemakers Groep (Waalwijk, Netherlands)
• Data Analyst (Experimentation & Digital Analytics) at Online Dialogue (Utrecht, Netherlands)
• Senior CRO Specialist at sofatutor (Germany & EMEA)
• Lead Data Engineer, GrabX (Experimentation & Config Management) at Grab (Ho Chi Minh City, Vietnam)
• Landing Page Optimisation and Experimentation Manager at PetLabCo (London, United Kingdom)

Couldn't find a job that's interesting to you? Check out more here.

4. Events

• April 9, Emerce Conversion, Amsterdam NL
• April 14, Experimentation & CRO for Product Managers (Women in Product NL), Amsterdam NL
• April 18, MeasureCamp Amsterdam, Amsterdam NL
• April 22, Unite Vienna 2026 (by Kameleoon), Vienna AT

Find more events over at lu.ma/experimentation-events.

That's a wrap – until next week.

– Nils

P.S.:

If you enjoyed this, please consider sharing with a friend. If a friend sent you this, get the next newsletter by signing up here.

Also, for more resources and content follow me on LinkedIn.