Product Design and International Development

Over the past few years, we’ve been working with many of the largest organizations within the international development and humanitarian communities, infusing our product design methodology and bringing many of the lessons learned from the startup world to a space that is in great need of innovation.

A couple weeks ago, I found myself sharing again some of our thoughts on this topic with the PeaceTech Labs folks (at the gorgeous USIP office). While I intend to explore more deeply this topic, I thought I’d share what I already have put together.

Some of the key points that I hope to develop in future posts:

• RFPs are the enemy of innovation; in many cases, our client and partners initially come to us with lengthy and specific RFPs. The expectation is that these documents end up being a blueprint of what will be built, sometimes even specifying what technologies should be used.

  We usually end up going back to running product design workshops along with stakeholders and user interviews to help the teams we partner with better understand the problems they’re trying to solve, and focus on their users. We rarely get things right the first time and tend to focus on releasing prototypes early and often to their intended users (as opposed to trying to come up with a perfect plan without any user testing). In this context, technology is very much a tool rather than the central piece of the discussion.

• The “+1” game; many in this space have seen this scenario playing out where an organization feels the need to simply copy what their “competition” does (a somehow surprising term in this field) and adding a couple more features to “+1” them, rather than figuring out how to build truly innovative and useful services. We’ve often been asked to “build the same thing as what you did for World Bank, except with feature X” (you’d be surprised how common that is).

• Lack of resources & technical debt; we warn against poor technical investments which are particularly taxing for organizations with limited resources.

• Incentives and failure; many of the organizations we work with are still struggling with accepting failure (which are usually hidden or disguised as success) and a lack of clear incentive structure (unlike for-profits).

• We give a fair amount of pointers as to what our product design methodology is, how we think teams in this space should invest more into understanding what their users need, and how to answer to these needs and keeping in mind that most of the investment into building a successful product, however technical, should go towards support, marketing, and design rather than technology.

Below are my slides. Reach out if you feel like discussing some of these points, I will anyway develop further some of them in the coming weeks.

Picture from Wikimedia