We talk about experimentation as if it’s second nature.
It slips easily into conversation “we should test that”, “let’s validate it first”, “maybe we run an experiment”. The language sounds sensible. Progressive. Everyone nods.
And then nothing actually changes.
The reason isn’t resistance. Most teams simply haven’t seen what experimentation looks like when delivery pressure is real and deadlines are close. They’re wired to build. That’s what they’re good at. Take an idea, shape it, deliver it, move on. That muscle has been strengthened over years.
Experimentation, by comparison, can feel like hesitation. Like slowing momentum. Or more uncomfortable still, like publicly admitting you don’t have the answer yet. That’s usually what’s sitting underneath it.
So when I work with teams who haven’t built this habit before, I don’t start with a framework or a big cultural statement. I don’t run a workshop on “creating an experimentation mindset”. That tends to create more theatre than change.
Instead, I introduce a small shift in the conversation. At the point where we’re about to commit to building something, I’ll ask, quietly and without drama, what are we actually least sure about here?
That question changes the tone. It pulls us away from speed for a moment and towards risk. Instead of asking how quickly we can deliver, we begin to ask what assumptions we’re about to invest in.
And that’s where experimentation really starts.
Development experiments: reducing technical guesswork
In development, uncertainty is everywhere. It just hides well. We tell ourselves we’ve done something similar before. We assume the documentation is accurate. We believe performance will hold. We expect the refactor to pay off. Sometimes it does. Sometimes it doesn’t.
Normally, what happens is a debate. Smart people offering informed opinions. Eventually, someone makes a call, and we commit properly. An experiment is simply refusing to commit fully when we’re unsure.
If you think moving validation into another service might reduce failures, don’t re-architect the entire system. Change one endpoint and observe what happens. If you believe a caching layer will improve latency, apply it narrowly and measure. If you’re unsure about an AI integration’s reliability, test it in a constrained environment before wiring it through everything.
The shift for the team is subtle but important. The purpose of this work is not to produce production-ready code. The purpose is to answer a question. Once that lands, the pressure drops. You’re not polishing. You’re learning.
And learning early is always cheaper than fixing late.
Discovery experiments: stopping ourselves from building the wrong thing
Discovery is where teams tend to feel more exposed. There’s still a strong instinct to equate validation with building a thin slice. Sometimes that’s appropriate. Often it isn’t.
If you believe users want an AI-generated summary feature, the default reaction is to design it, estimate it, and add it to the roadmap. But before committing that effort, it’s worth asking a quieter question: do we actually know they care?
You can gauge interest without building the full feature. You can surface the idea in the interface and see if anyone engages. You can manually deliver the outcome for a small group before automating the process. You can show a rough prototype and simply ask someone to explain what they think it does.
In AI-heavy environments, especially, this discipline matters. The ability to build quickly increases the temptation to build prematurely. “It won’t take long” becomes a justification. But building faster doesn’t remove risk. It just accelerates it.
The real barrier usually isn’t skill. It’s safety.
Most teams are more than capable of running experiments. They’re thoughtful, experienced, and technically strong. The issue isn’t intelligence. It’s that experimentation requires admitting uncertainty, and uncertainty can feel uncomfortable in cultures that reward confidence and decisiveness.
If the underlying message is “have the answer”, then saying “I’m not convinced yet” feels risky. Experiments make assumptions visible. They test strong opinions. They occasionally show that a well-argued idea doesn’t stand up.
That’s why this begins with tone, not process.
If you want experimentation to feel normal, you have to model it. You have to be willing to say, calmly, that you’re not sure and you’d rather test than assume. And when something doesn’t validate, you treat it as progress. Not because it worked, but because it saved time.
When that tone shifts, experimentation becomes less personal. It stops being a judgment on someone’s thinking and becomes a shared mechanism for reducing risk. The emotional charge drops. Curiosity increases.
If I were starting tomorrow
I wouldn’t introduce new artefacts. I wouldn’t rename ceremonies. I wouldn’t create a visible “experimentation initiative”.
I’d look at the next item in refinement and ask, what assumption are we making here?
Not as a challenge. As genuine curiosity.
Then I’d work with the team to design the smallest possible way to test that assumption before fully committing. Sometimes that’s a narrow technical proof. Sometimes it’s a lightweight prototype. Sometimes it’s simply putting an idea in front of a handful of users and listening carefully.
Run it quickly. Share what you learned. Move forward.
Do that consistently, and something shifts.
Over time, the team begins to feel different. More curious. Less defensive. More comfortable saying, “we don’t know yet.” And that’s the point.
Experimentation isn’t a capability you announce. It’s a habit you practise. Quietly. Repeatedly. In the middle of real work. Eventually, it stops being something you try to do.
It just becomes how you work.