Lean impact: why the FT Hub uses this methodology
This is a blog post by Johannes Meyer as part of the Frontier Tech Launchpad series, sharing key content from our session on Lean Impact. Learn about the full Launchpad journey here.
The Frontier Tech Launchpad is a space for you to come together with your cohort of fellow Pioneers and partners. Together, you'll experience a series of engaging and practical sessions facilitated by the Hub, designed to level up our shared knowledge and skills relating to multiple aspects of the FT programme.
⚠️ Trigger warning: this blog makes reference to gender-based violence.
Choosing the right methodology for your pilot
The Frontier Tech Hub is set up to support FCDO to test and learn about the application of frontier technologies in international development. Our very purpose means that the pilots we are supporting are working with high uncertainty.
Currently, pilots are asking questions like:
Can an AI-enhanced chatbot provide immediate support to victims of gender-based violence?
Can we use a tech stack consisting of sensors, imagery and machine learning to locate clandestine graves in Mexico?
Can a unique nano-biogel fire retardant substance be deployed using drones over forests in Brazil to stop the spread of wildfires?
These questions have two things in common: They are complex and, therefore, not easy to answer, and they demand we choose the best possible method to investigate them.
Fundamentally, the FT Hub remains method-agnostic. We blend proven approaches like Human-Centered Design, Design Thinking, and Lean Startup/Lean Impact. With that said, it is specifically Lean Startup and Lean Impact which come into their own when considering questions like our three examples.
For example, let’s return to that first pilot question, “Can an AI-enhanced chatbot provide immediate support to victims of gender-based violence?”
There are a lot of uncertainties we need to address to understand this question.
If we were to commit to building a fully-developed solution and then handing it to potential users for testing, we’d take considerable risks: At this point, we don’t know which AI model is most suitable, whether a chatbot is appropriate from victims’ point of view, what the most impactful support looks like - and these are just the surface-level questions. We also don’t know exactly what the solution’s functionality should be, or if it fits into existing support structures. And we don’t know how it could interact with wider ecosystem actors, such as local communities, or the police, who have traditionally held responsibility for tackling gender-based violence (GBV).
Think back to a project you've worked on in the last few months. What would you have done differently if you'd known something sooner?
Lean Impact faces these open questions head-on by prioritising early and frequent contact with the real world in order to answer them.
One of our Launchpad resources shows the difference of approaches between “build in full, then test” (waterfall) and “test early, learn often” (Lean) methods.
Let’s look at how this works in detail.
The lean methodology can be best explained in three core principles: Build, Release/Test, Learn, which occur in short iterative cycles called sprints.
Build, as the first step in the process, aims to create or ‘build’ a minimum viable product or a simple solution that can be tested. Each build should focus on flushing out the answer to the most pressing question you need to answer at this point in time, and take the least resources possible.
Release/Test involves the validation of that solution towards a purpose or target audience and feeding back of data - always prioritising “real world, real user” tests over more abstract feedback methods, such as surveys.
Learn uses the data to evaluate whether the initial hypothesis or solution has been validated, and determines the next course of action.
Each Build - Release/Test - Learn cycle should take you deeper into the question you’re looking to answer, uncovering more insights and refining the idea to be more specifically appropriate to the overall context.
This approach has concrete benefits for your pilot.
By being clear about your pilot’s overall goal yet remaining flexible about how exactly it is achieved, you’ll avoid overcommitting your resources - whether that’s time, money, or your own finite energy.
Let’s think back to the AI chatbot example. If we were to build a full solution from the get-go, ignoring all of the uncertainties and questions, there is roughly a 100% chance we’d end up with a solution that just won’t fit or work. By that point, we’d have committed a large percentage of the pilot’s resources - time, money and energy - and we’d have a really hard time changing tack.
A really handy way to prevent over-committing is to think in assumptions.
In simple terms: An assumption is something that needs to be true in order for you to achieve your goal... but you haven't tested it yet. Thinking in assumptions reminds us that we don’t yet have all the answers, but by being clear and systematic we can find answers, build confidence, and refine our idea.
For our AI chatbot tool to tackle GBV, our starting assumptions might be:
“I believe that an AI tool can effectively understand and respond to inputs from victims of GBV.”
“I believe that an AI tool can appropriately point users to local enforcement, allowing them to be notified when an instance of GBV has occurred.”
“I believe that local enforcement will buy-in to the solution and support its use.”
“I believe that victims of GBV will accept a chatbot as a tool for finding support.”
At the beginning of your pilot, you’ll likely have a long list of assumptions. That’s fine - remember that high uncertainty is in part what makes your pilot worthwhile.
But where to start?
The next step is to categorise assumptions based on their criticality. To determine criticality we use a simple formula - it’s the combination of high uncertainty (you know very little about this question) and high impact (if you were wrong about your assumption and got it wrong, it’d sink your pilot).
User-focused assumptions usually provide a clear example of this. Let’s say you haven’t had much engagement with survivors of GBV in your pilot’s context, and your chatbot was aimed at them. The assumption “I believe that victims of GBV will accept a chatbot as a tool for finding support.” would be of high criticality as you currently know very little, and if you were wrong you wouldn’t have any users.
This Launchpad resource shows how to map your assumptions and surface which are critical.
“It's important to know what’s essential now versus what’s needed for scaling.”
Gabriela, a Frontier Tech Pioneer
The Mindset Shift: Embracing Assumptions and Uncertainty
We are all human, and that means we really, really don’t like uncertainty. And being invested in the success of a pilot, thinking of ourselves as making assumptions can be uncomfortable.
Lean Impact requires a mindset adjustment - one which values learning, clarifying and demystifying over being right, or getting it right first try.
For example, Lean Impact doesn’t “do failure” - in other words, we don’t differentiate between positive and negative validation of an assumption. Whether a Build-Release/Test-Learn cycle proves or disproves a hunch, it’ll inevitably lead to a better understanding of what a good solution will look like. And you’ll have saved more resources than if you’d gone ahead without testing first.
Let’s recap:
Lean Impact is a method for addressing big ideas with a lot of uncertainty attached to them, with limited resources.
Lean allows you to hold your why firmly, while being flexible about the how.
Lean does this by working in Build-Release/Test-Learn cycles.
Assumptions help us think straight about uncertainty. Assumptions are things that need to be true, that you haven't tested yet.
Tested means 'with real users, in the real world'.
Critical is a technical term for high uncertainty x high impact.
Critical assumptions always take priority.
Lean helps you stay true to your purpose while remaining open to new ways of achieving it. By testing real assumptions in real-world settings, Lean allows you to make meaningful progress, even with limited resources.
Facing untested ideas can feel daunting—we’re all human, and we’re all attached to our big plans—but that’s where Lean truly shines. It breaks challenges into manageable steps, letting you focus on what matters most and adapt as you learn.
Why not explore Lean for yourself, on the Frontier Tech Hub? Start small, experiment, and let the process guide you—you might discover solutions you never expected.
