If you’ve been following our work, you might have noticed us frequently using terms like ‘product’ or ‘product thinking’. Don’t worry… we’re not pivoting to selling consumer products. Instead, we’re talking about something a little different: how we design tools and solutions to tackle complex problems affecting the lives of residents across African cities. That means focusing not just on those who use the tool directly, but on those who stand to benefit the most from its success: the beneficiaries.

This approach stems from the complexity of our work, where we must balance the needs of multiple stakeholders.

Everyday Examples of Products

If you buy a pair of running shoes, the product team has designed them with your needs in mind. They’ve researched what runners look for - comfort, durability, support - and iterated on the design over time. In this case, you play all four roles in the product life cycle: beneficiary, user, customer, and funder (by purchasing the shoes). This process is relatively straightforward.

Now, imagine a friend buying a baby monitor as a gift for new parents - perhaps at a baby shower. The roles in the product life cycle become a little more distinct:

• Beneficiary: The baby, who benefits from timely care and better sleep through increased monitoring. 
• User: The parents or caregivers, who use the monitor to track the baby’s sleep and respond when needed.
• Customer: The friend, who selects which monitor to buy based on reviews, features, and price. 
• Funder: The same friend, who pays for the monitor as a thoughtful gift from the registry.

This scenario introduces multiple stakeholders, each with their own priorities. 

It highlights how different people can take on separate roles in the product life cycle, making decisions that impact the beneficiary experience. It’s more complex than the running shoes example but still relatively contained because the customer and funder roles are still occupied by the same person.

‍

‍

Understanding Stakeholder Roles

In civic tech, the challenge isn’t just building tools that work, it’s ensuring they work for the people who most need change. That’s why we take time to understand the different roles in the product ecosystem, and why we believe the beneficiary must be at the centre of it all. 

• Beneficiary:  Residents and businesses in the city experience better urban services, infrastructure, and an improved quality of life as a result of the tool’s insights and efficiencies.
• User: City officials and practitioners (e.g. GIS specialists, urban planners, municipal managers) directly interact with the tool to improve service delivery, optimise resources, and make informed decisions. 
• Customer: City management (department heads and decision-makers) decide whether to adopt and integrate the tool into municipal operations. Their decision is influenced by advocacy, demonstrated impact, and alignment with strategic city goals. 
• Funder: Typically external international development agencies or government grant providers supporting the work. Their goal is to enhance urban resilience, improve transparency, and ensure the tool delivers measurable impact. 

Lessons from Building Tools, Running Programmes, and Learning What Sticks

When we first started out (back when we were Open Data Durban), our work was primarily project-based. We were building tools and offering technical support to civil society groups that needed better ways to access and use data. These projects were often short-term, aimed at solving specific problems quickly and effectively.

As we grew, our work shifted towards larger, funded programmes focused on improving data access and use at scale - helping governments and civil society alike build their capacity and use data more meaningfully. This allowed us to broaden our impact, but it also introduced new layers of complexity. We began to see how the models we were working within, whether project- or programme-based, sometimes limited our ability to respond to changing needs on the ground.

Through these experiences, we’ve seen both the strengths and the constraints of these approaches. While they have their place, they don’t always support the kind of long-term sustainability, adaptability, or user engagement we’re aiming for.

Project Thinking: Fixed Deliverables, Limited Flexibility

A project is designed to meet specific deliverables within a set timeline and budget. It typically prioritises the customer’s needs, such as city management and leadership in the case of data tools, focusing on service delivery rather than ongoing user engagement. But what happens when the problem evolves, the project duration is over, and the tool is no longer solving the problem?

Programme Thinking: Broader Scope, But Still Rigid

A programme coordinates multiple projects under a larger initiative, often with longer-term goals. However, because it is often shaped by funder priorities, it may focus more on reporting impact. But what happens if funder priorities change and the tool is no longer within their scope of work? 

While both approaches have value, neither guarantees that solutions remain adaptable, scalable, or beneficiary-focused. 

This realisation pushed us to rethink how we design and deliver our work. We started asking: Are we building something that is actually improving the lives of city residents? Does this still matter once the funding ends? These questions nudged us toward a different approach, one rooted in responsiveness, continuity, and beneficiary-focused impact.

‍

A Subtle Critique of Current User-Centered Paradigms

So, we ended up with product-thinking. We didn’t throw the baby out with the bathwater, per se. Instead, we took the best of what we’d learned from projects and programmes - clear goals, structured delivery, longer term vision - and started asking: What would it look like if we approached our work more like building a product? Something that could adapt over time, stay relevant beyond the funding cycle, and grow alongside the people it’s meant to support.

So, we began to look at our work as products… focusing on continuous evolution, designing to adapt, improve, and scale over time. Here’s why we liked product thinking:

• Focus on Outcomes, Not Just Outputs: Unlike projects, which measure success by deliverables, product thinking prioritises outcomes, ensuring that tools actually solve the problems they were designed for. A project might deliver a data dashboard, but product thinking ensures that city officials find it intuitive, practical, and continuously improved based on their feedback… and that it ultimately improves residents’ lives.
• Continuous Evolution Through Iteration: In project and programme thinking, a solution is typically built, delivered, and then left as-is. Product thinking treats solutions as living, evolving tools. They are refined over time, incorporating feedback, adapting to new challenges, and scaling when needed.
• User-Centric Design: Product thinking starts with the user (those who interact with the tool regularly) and prioritises their experience, context, and feedback. It ensures that design and delivery revolve around what makes sense and works best for them. 
• Long-Term Sustainability and Scalability A project might have a fixed end date, but a product is designed to continue evolving. This means thinking about how the solution will scale, how it will be maintained, and how it will remain useful in the long run. Ultimately, it’s about co-creating solutions for problems affecting people in a way that is meaningful and lasting.

OCL’s Product Thinking Twist: Putting Beneficiaries First

But as we leaned into product thinking, some of you might be wondering: Aren’t you still prioritising users over beneficiaries? And you’re right to ask.

Product thinking helped us focus on tools that work well for city practitioners, the people who actually use them. That shift made a huge difference. But it wasn’t enough. We realised that just because the tool works for the user doesn’t mean it delivers better outcomes for the people it’s ultimately meant to serve - city residents.

So, we had to add our own twist.

These days, we start every project by focusing on the beneficiary’s problem. If a solution doesn’t make a meaningful difference to their lives, it doesn’t matter how sleek, efficient, or technically impressive it is. Everyone else (users, customers, funders) should be aligned around that central goal. And because city practitioners (users) are ultimately in service of city residents (beneficiaries), designing for users is often the most effective way to reach the people who matter most. But that approach alone doesn’t guarantee impact. 

We know that tools that improve internal processes can end up reinforcing the wrong incentives, especially in contexts where governance is weak. Efficiency can serve corruption just as well as it can serve communities. And capacitating civil servants doesn’t automatically translate to improved services. That’s why, even if we work through users, we can’t lose sight of who we’re really building for.

It’s a bit like designing a dashboard to track infrastructure repairs - great in theory. Engineers might use it daily, the city manager might love the reporting metrics. But if residents don’t end up getting faster, more reliable repairs? Then it’s just another shiny tool that missed the mark.

That’s why in our evolving theory of change, city residents (especially those bearing the brunt of inequality, poor services, or exclusion) remain our north star. When a project/programme/product starts drifting toward user convenience or reporting for its own sake, we try to pause, reflect, and if needed, course correct. Right now, we’re actively working on how to bake this thinking into every stage of our work. It’s even pushed us to look back and ask: in past projects, were we really making cities more livable for city residents? Were we really solving their problem? And if not, what would we do differently next time?

‍

So, How do we Define a ‘Product’ at OCL, anyway?

After all that reflection, we realised we needed to be clear with ourselves and others about what we mean when we talk about ‘products’. At OCL, a product isn’t just a tool or some fancy piece of tech. It’s a way of solving problems that starts with the people most affected, is implemented by those closest to the work, and keeps real-world impact at the centre.

Here’s how we define it:

• A user with a problem
  Our products begin with people, but not just those who use the tool. We focus on the end problem faced by the beneficiary, whether it’s a resident navigating poor transport or a community trying to hold local government accountable.
• A set of tools
  A product consists of multiple tools that work together to address user and beneficiary needs.
• A methodology driven by user needs
  Problem-solving isn’t one-size-fits-all. Users are experts of their own realities, so we collaborate with them in creating tailored approaches that combine tools and strategies based on their needs. This process is iterative and agile, allowing for continuous improvement.
• A clear use case
  Each product we design has a defined purpose and delivers real outcomes for its users and tangible impact for beneficiaries.

‍

After All, It’s All About the Beneficiaries

Our journey over the years has never been static. It has shifted in form… projects, programmes, and now products… but the goal has stayed the same: creating tools and processes that make it easier for residents to access better services, hold institutions accountable, and build better cities.

Product thinking hasn’t replaced our past ways of working, it’s built on them. It helps us stay focused as we scale, keeping the resident’s problem at the centre even when navigating complex partnerships and systems. It also gives us a language and structure to revisit old challenges with fresh perspectives and long-term sustainability in mind.

We’re still learning, tweaking, and trying things out. As we deepen our approach, we're beginning to see how individual tools and pieces of tech can become part of something larger - inconnected building blocks that support city systems and help residents experience meaningful change.

‍