How can we “experiment” in our sector?
I love the word experimentation because it makes me think of play. Entering a universe you've created feels empowering, especially when you can invite others to shape it with you.
Imagination has always been the engine of human progress, yet we are often taught to suppress it. We’re trained to stick to established concepts, even when those concepts might no longer serve us, and the worst is that we view play as something we do only when we are kids, and experimentation as something only innovators (or scientists) do.
Life is constantly changing, and yet we don’t always believe we’re allowed to change our perspectives, opinions, or even careers. This hesitancy is especially true in the public sector, where experimentation is often seen as unnecessary, even though it could unlock new value and creative solutions.
Structured experimentation is possible
These are called innovation methodologies. We used them to guide the innovation process. You might have heard of human-centered design, lean-startup, or agile. These frameworks exist to guide solution generation, starting with the core needs of the people we serve. Yet, here’s the paradox: while these methodologies provide structure, they also create boundaries that isolate the innovation process. Most often, they exist in carefully controlled environments like Innovation Programmes, making it hard to mainstream innovation throughout daily operations.
We need to start breaking down the structure
The big question is: Can we implement innovation processes outside of these structured programmes to allow for more experimentation? This is an exciting challenge, one that could be answered by the very thing we’re talking about, experimentation.
Take, for example, our work in The Gambia. One of our teams in our organization supported government entities in developing a tool for the agriculture sector using human-centered design. This wasn’t a specific innovation lab project but rather an initiative led by volunteers who believed in the methodology. They convinced stakeholders to design a project that explicitly incorporated human-centered design principles. This example highlights how mainstreaming can happen organically when you have champions who push for experimentation within existing frameworks.
But what if you don’t have those champions? The solution could lie in adopting elements or stages of innovation methodologies at key moments. For instance, in the project design stage, simply using a user persona can align different teams on the needs they’re trying to meet. Similarly, building hypotheses and testing them is a simple, powerful step that can bring fresh insights into problem-solving.
Adopting this toolbox approach can be beneficial and less scary for people to commit to.
Don’t be afraid to criticize the process
Constructive criticism is vital for improving any process. For instance, I’ve found that the lean-startup approach, building hypotheses and iterating through the build-measure-learn cycle, is often easier for teams to grasp than the more complex five-stage human-centered design process (empathize, define, ideate, prototype, test).
Maybe it’s because lean-startup has fewer steps and fewer buzzwords. It feels closer to the scientific method and more practical. At first, I was frustrated, thinking that the human-centered design methodology we embrace so strongly in our sector might be too complex to be practical. But then I realized, why not adapting these methodologies? Why not take the best parts of each and apply what works for us?
In the case of human-centered design, user-centricity is at the core, and that’s something we should embed in every innovation process. It’s essential, no matter which methodology we adopt. But then, if the rest of the process doesn’t serve the purpose of the objective we are trying to achieve, we don’t have to feel forced to stick to it.
Mainstreaming experimentation
So, how do we mainstream experimentation? How do we ensure it becomes part of our daily work and not something relegated to special programs? One answer might be to democratize these innovation methodologies by turning them into a toolkit that people can use on-demand, in a way that serves their specific needs. But even more important than the toolkit itself is the user manual, guidance on when and how to apply the right tools at the right time.
Now, building a good user manual is tricky. We have tried to do it already, and we find that there is a substantial amount of time that should be dedicated to on board people, not once, but twice, and maybe more times. We know that embedding the use of the manual as a compulsory step in project implementation could be a possibility to increase usage, however, it is not the right usage we would be looking for.
If we want to increase organic usage of the toolbox, we need to get more creative: showing success stories of teams who have applied it with great results in terms of impact but also funding leveraged, or time saved, could be a way. Do you have others?
