Stewart Kettle | 11 Jun 2026

Before launching the iPhone, Apple didn’t hold a Theory of Change workshop. They didn’t debate whether increasing user engagement with touch-based interfaces was an output or an outcome. And they didn’t fill out a logframe. They had a strong idea of what people would want to use, put something into people’s hands, watched what happened, and then adapted it. Again and again.

Of course, Apple and development programmes are not trying to do the same thing. Apple needs people to want, buy, and keep using its products. Development programmes are trying to improve lives, often in places where markets fail and power is uneven. But both depend on behaviour. People choosing to get vaccinated. People maintaining water sources. People turning up to clinics, schools, and employment centres. None of this happens just because something exists, but neither do people buy iPhones just because they exist.

The difference lies in how product teams and development programmes respond when people do not engage. In programme design, monitoring, evaluation and research, we often treat it as a puzzle to be explained after the fact. We commission research, describe “barriers”, and revise the Theory of Change. The implicit assumption is that the intervention may still be right, but the world has failed to comply with it. For product teams, low uptake is usually treated more bluntly. Something about the design, timing, message, incentive, or experience is not working. One system learns mainly through scheduled research moments. The other is built to learn through use, and to adapt when behaviour shows that something is not working.

Tech companies think obsessively about friction: every extra step, every confusing interaction, every moment where someone thinks “this isn’t worth it”. Development programmes often generate friction without noticing: complex eligibility rules, unclear referral pathways, forms that make sense to funders but not users, and training cascades that lose meaning along the way. When uptake is low, there is a tendency to defend the plan rather than question the experience.

The lesson from all this is not “be more like Steve Jobs” with a really clear vision. The better lesson is that the strongest product teams do not choose between vision and feedback. They do both. Apple famously did not ask people whether they wanted an iPhone, but once the product existed, the company paid attention to how people actually used it. Airbnb shows the same tension in a different way: a vision that people might want to stay in strangers’ homes, tested and refined through thousands of small details around trust, photos, payments, and reviews.

MEL culture often gets this balance wrong. At the proposal stage, programmes can be intensely vision-heavy. The pathway is mapped, the assumptions are listed, the indicators are agreed, and the logframe gives the impression of control. But once implementation starts, feedback is often too slow, or too disconnected from decision-making. Deviations from the plan are treated as problems to manage rather than evidence to learn from. Academic papers have their place, but they reinforce the same rhythm: one bounded piece of research, written up after the fact, rather than a live feedback loop that helps teams adapt as they go. The issue is not that programmes have theories, or that they don’t do research to test them. They should, and they already do. The issue is when the theory becomes something to defend rather than something to test, and when feedback isn’t routine or acted on.

This is the gap we keep coming back to at Colectiv. It is now possible to hear from people during implementation, not just after it: from frontline workers, communities, local teams, and the people who quietly stop using a service. That should change what programmes expect from feedback. It should also change how we interpret quantitative indicators. For example, uptake might be the accumulated result of many small experiences: Did someone understand the offer? Did they trust the messenger? Did the referral make sense? And did the frontline worker have enough confidence to explain it? The useful question is not only whether uptake is low, but where people are dropping out, getting confused, losing trust, or deciding it is not worth coming back.

If we are serious about improving the cost-effectiveness of aid, we need to get much better at noticing these moments while programmes are live. Not because every programme should copy tech companies. But because programmes, like products, only work when people can and do use them. You still need a vision. Without one, you’ll end up focusing on anything and everything. But vision without feedback becomes performance rather than progress.

No, Apple does not have a Theory of Change or a logframe. What it has is a relentless relationship with reality. Development programmes need the same discipline: clear goals, fast feedback, and the humility to change when reality disagrees with the plan.