First, some background. Ushahidi was born in 2008, after Kenya broke out in violence after a close election. Four Kenyan bloggers, both in Kenya and abroad at the time, wanted to know more about what was happening on the ground. They were texting their families and friends, reading blogs on their already well-curated RSS feeds, flipping through every new article, and following Twitter in real-time. But these bloggers also recognized that many of the important stories they saw around them were underreported by traditional information channels. With the proliferation of social media, there were now many voices that could share their accounts.

Through online conversations, they realized they shared the same problem. They got on a call, and asked: could they build a tool that automated their sporadic running around the web? That week they started building Ushahidi v1, named after the Kiswahili word for witness or testimony. It was a software platform that crowdsourced reports from people via any channel, and geolocated and timestamped them. Anyone could know when there was an attack on their street, and these attacks could be documented, made transparent, and shared across the world.

There was no user experience (UX) study for Ushahidi v1. The creators were the users, and the user experience was the immediate crisis. It took just six days from that first conversation to a working prototype.

Over time, the software became more versatile, open-source, and available on a cloud infrastructure. Over the following five years, it was deployed more than 70,000 times in 159 countries, collecting over 6 million reports. People adapted it for numerous uses beyond the original political crisis case. It has been used for human rights abuse reporting, corruption transparency, election monitoring, disaster response, and environmental change mapping. It has also been used to crowdsource and share people’s favorite hamburger spots in the USA, and for researchers to track the fluctuation in the price of chicken around the world.

In 2012, we had reached Ushahidi v2.6. We knew that we would soon need to rebuild from scratch to be able to accommodate some of the many needs that our community kept requesting. We needed to rebuild using a flexible API so that we could handle complex custom forms, data filtering, and other user requests.

When we decided to reimagine Ushahidi, we said that we would have “no sacred cows.” We started a UX process of interviewing our users, tracking the different user groups, and creating user personas.

Have you ever been riding a bike, seen a pothole coming up, and then while staring at it, you ride right into it? Somehow staring at the pothole made you steer directly for the obstacle you knew you needed to avoid. That is what happened next.

In 2008, the problem was abundantly clear because it was a crisis being experienced in real time and the users were the creators. But this time, we had 70,000 customers and millions of indirect users (reporters and page viewers), all with slightly different needs and opinions. We were no longer just serving the needs of a few; we had to build a process to listen to, compute, and prioritize the needs of thousands. We began facing problems that I now realize many organizations fall into as they grow.

We stared right at that pothole. And then we fell right in and did all the things we knew we shouldn’t do. We did UX (user experience) studies, but got pulled in too many directions from all our users. We tried to be too many things to too many people. We started coding, but got consumed with perfecting our engineering architecture instead of building the user interface. We set ambitious goals that were entirely unrealistic considering our resources.

About 18 months in, in early 2015, we had an intervention. We took a moment to recognize that we were no longer heading for the pothole, but that we were deep in it. It was a tough moment to admit that we had put in so much time and work, but the end goal was still far off.

We stopped asking how we got to this spot, and instead started thinking about how to get where we needed to be. We started asking our users, “Do we create value for you? Why? How? What are we not doing?” The process of asking those questions changed everything.

We reset our strategy from pothole avoidance to climbing out. We empowered our designers and product managers. We found ways for user needs to drive essential priorities. We adopted agile development and started measuring velocity. We asked more questions. We went through every project we had ever done and broke down the features used and the need served. We used that to prioritize features and customers, and we let go of the rest.

And finally, we launched. And then the next day we kept asking questions.

Over the past quarter, we have done continuous deep dive user surveys, in which we have continued to ask, “What problem are we solving, and for whom?” We ask that every day, over and over again.

Reflecting on this journey, there are definitely some issues we could have avoided. But I also want to turn our focus to the two industries we straddle, technology and development. Why do the potholes exist in the first place?

Building a technology product from within the development and humanitarian industry, instead of the private sector, has particular challenges. Foundational funding is limited and not focused on creating earned revenue, but impact. Technology products don’t create impact themselves — the people who use them do.

This slight differentiation is important. There is a burgeoning technology industry that serves the humanitarian, development, and non-profit industries. To you established NGOs: let this new sector serve you. Don’t attempt to build product in-house; there is a burgeoning industry of technology services designed for you, and you can support them by being a client and not a competitor. Excessive fragmentation wastes money, wastes time, and in the end, hurts the marginalized communities that we are all trying to serve. Every time I see a tool built in-house by a large NGO to do incident reporting, it breaks my heart.

Second, a word to the philanthropic industry supporting these products: proper product development costs more than you assume. Also, products need to have a clear pathway to revenue — or you should be prepared to continually support them. Building a product should cost the same, if not more, than taking a product to market in Silicon Valley. Often, we are working in places where there is less real-time data on our users than in the developed world, making it more costly to serve them.

Since our industry serves the most vulnerable, often there isn’t a quick path to profitability, meaning that timelines are often longer. The biggest thing the philanthropic community could do is to give 5–10 year core funding grants tied entirely to continually growing earned revenue. Plan for evolution and changes in the technology, but keep the focus on a slow steady growth of earned revenue.

Third, for the product developers: you are going to fall in that pothole. Have a plan for getting out, not just a plan for avoidance. Ask questions, insatiably.

Sometimes a product appears from an immediate need, but more likely not. It might be that lightbulb moment, like with our four Kenyan founders. But more often it involves a process of in-depth user research. Product development is fundamentally the process of putting yourself into someone else’s experience and holding that viewpoint throughout the entire process of creation. You need to be able to experience empathy for a single user, while simultaneously processing and filtering the needs of thousands.