For twelve years I was a practitioner and researcher in the fields of ICT for development, education, government and digital media, always developing tech solutions for social good. Then, in 2014 I left the non-profit world of international organisations and moved to a corporate when I joined Pearson South Africa’s Innovation Lab.
I made the move purposefully: to learn and to develop a business perspective on education technology, to see it from the “other side.” I always intended to take insights back to the non-profit sector one day, since for-profit and non-profit have much to teach each other, to make each more effective and efficient. I have now returned to UNESCO and so it’s time to reflect on the question: what did I learn in the years at Pearson? What can Business teach Development?
I learned many new things, and was reminded of many known truths (like implementing a tablet program for 8,000 students across 13 nationwide campuses is a deeply complex exercise). But I think my clearest lesson was the value in following an agile product development approach.
During the time I was at Pearson the company started to adopt — across the globe — something it calls a Product Lifecycle (PLC) approach. The PLC consists of six stages: idea (developing the initial concept), explore (researching the need for the product or service), validate (confirming the assumptions and proposed solution are valid), grow (launching the solution and growing revenues, reach and learner outcomes), sustain (maintaining revenues, reach and learner outcomes, and achieving operating efficiencies), and retire (closing down or divesting).
Each stage in this framework has activities and gates, which need to be validated before commencement (or not) to the next stage, as decided by a product council that meets regularly. A product development approach is not new in the development sector. But is it applied at the implementation and funding level? And is it done in an agile way, with a common set of actions, triggers and validation points? Doing this is very effective at (i) quickly weeding out bad ideas and validating good ones, (ii) showing how good ideas may need to pivot, and (iii) being honest about when to kill off projects that have reached their end.
In the development sector at least the first three stages (idea, explore and validate), if not first four (including grow), are bundled into a well-planned pilot – one stage, essentially. This is a bad idea as it isn’t lean enough, doesn’t encourage “fail fast, fail often” in the words of Silicon Valley entrepreneurs. The whole solution is built and rolled out before asking key questions like: does anyone actually want (not need) this service? Will they pay for it – financially or with their time? What are the real pain points of the group we’re serving? In other words, we don’t know at the end if there is a neat product-market fit, because the product hasn’t been developed iteratively with the market.
Development should break down these activities into distinct stages. Each stage is essentially a mini-pilot. Funders should demand the same, but key for them is to offer funding agreements that allow for flexibility and the ability to adapt and learn from the different stage activities. So, there is the potential for full funding of the project, but key gates must be opened along the way. In this model donors fund stages, but commit to fund more based on results.
But surely, you may be thinking, it’s precisely because donors only fund short-term pilots that much development effort suffers from pilot-itis. The problem isn’t that donors fund pilots, it’s that they fund ones that don’t add value. If they follow a more agile approach, there’ll be more early stage pilots and fewer, more successful and sustainable, bigger ones.
When a well-intentioned non-profit organisation proposes a two-year project with neat predicted outcomes, it is essentially saying to funders: we need two years to show you this works before we scale it to the whole world. This is madness. We need proposals – and calls for proposals – that are more agile so that both implementer and funder are open to new trajectories being forged in the project. Even in a five-year programme, the principles of being agile should still apply. The NGO should say: we have an idea and we think it’s a solid one, but we need to explore and validate it before moving further. And if we need to adapt it, we need your support.
There are many agile or lean models, centred around the sound principles of iterative development and designing with real users. Development organisations should choose one and go agile. There are some development pioneers beginning to move in this direction. By moving towards a more agile way of operating – like Google and Facebook – we will get much more impact from preciously scarce funds.
Steven Vosloo 