Your priority is our focus

Over the past few months I have been studying design approaches applied to sustainable development projects in agricultural value chains in developing countries through the lens of human centered design. Here’s a brief insight into my first experience of one of the principals of the human centered design process (exploring and understanding the problem first, before even starting to contemplate potential solutions) and a description of how it has enriched my own understanding of a thematic area in which I used to consider myself to be knowledgeable

What it takes to search for your problem

  • prioritize understanding before anything else. This means creating space (freedom to think, talk, play, and move around) for working on the prime objective of understanding
  • observe in a lateral sense to discover what significance a problem has, and how it is defined and expressed by the users in their own voice.
  • all discussion which takes place with your users has a topic in mind, but no explicit purpose. Voicing purpose in problem exploration will likely lead to crucial assumptions in your perceptions remaining undefined and thus unvalidated (expert’s bias)
  • refrain from doing any analysis on your observations. They will blind your inquiry into the problem. Only analyze after repetitive patterns start appearing in your observations.

The general feeling I got from this method of inquiry was that of being a total slacker, based on a self-invoked perception of not being productive. But the trick is to not let that feeling permit you to cut short the exploration of the problem area by attempting to nail things down too early. Explore until patterns start repeating and you’re likely to stumble on insights that your expertise has never revealed to you before.

The pains of staying away from describing or even conceiving the solution, whilst discovering the problem

Expertise encourages a tendency to look smart by exposing knowledge about a problem area, voiced in the form of solutions. But:

  • your conception of solutions is a mirage. Despite your knowledgeable background, solutions actually mean nothing until the user starts voicing tentative parameters for a solution herself.
  • signaling solutions instigates memes, and the problem definition starts leading its own life
  • voicing solutions is an implicit promise to deliver a specific solution. You are likely to commit to delivering something that in the end won’t address the real problem at hand, if any problem at all.

The challenge I faced here was to drop my fear of discrediting my skills and competencies by not prescribing what should be done. You need to realize that the pay-off for your efforts (recognition, fame, happy responses) lies further on in the innovation process when you are able to define actionable insights. As with the problem search, tendencies towards immediate gratification by proposing solutions will increase the likelihood of introducing concepts that will not lead to feasible, viable nor desirable outcomes.

The reward
The pains of feeling incompetent, and not playing the expertise card need to be seen as an investment. The leverage that this investment provides will allow you to wield a significant force of creativity: focus, as in

  • prototyping solutions with the right focus on a demarcated innovation space -> your users and their problems. This is where you can try out all your creative solution concepts
  • using all relevant capacities and resources to address the need of the user
  • users instantly understanding the intent of your solution, and intuitively tinkering and helping in your process of prototyping because they are empowered.
  • instant recognition of signals of adoption or rejection with users.

The human centered design process thus ensures that your priority remains our focus, throughout.

The minimum viable product for physical products; what we can learn from the makers.

Imagine you live in rural India and you own a motorbike. Every once in a week or so, you are approached by a passer-by or a neighbor to help out because his bike has run out of gas and the nearest station is 16 kilometers away. Sometimes they’re lucky. You have enough gas to share and you’re able to perform the icky job of siphoning off your gas with mouth and hose. People even pay you extra for your discomfort, enabling you to buy a pack of gum to clear away the taste from your mouth.

So, after a couple of times of doing this, and the unintended near swallowing of petrol, it hits you! Could there by a market for this? Could I build a filling station with the purpose of helping people reaching the next village? A solid discovery of a customer problem, and a potential solution to tackle that problem.

Now the question is what a physical prototype of your business model would look like. Fortunately you’re strapped for cash at your 2 dollar a day income, imperative for lean decision making. It prevents you form asking the wrong type of questions for your prototype like:

  • What colors should my uniform be to look credible enough for my customers to buy from me?
  • Do I serve Coke or Pepsi at my station?
  • How about a drive-through bike wash?

In this case you need to earn before you spend. So no, it won’t be a lavish, fully furbished, high-tech unmanned petrol station. It might look more like something below:

 ….the Minimum Viable Gas Station (photo credit to Niti Bhan).

This prototype would be the most reduced concept (generally referred to as the Minimum Viable Product (MVP)). The MVP enables you to test the most essential parts of your business model: How do customers interact with and value my product? The downside is that it looks scrappy, but the dominant positive side is that you will naturally test better questions about your business model:

  • Would customers pay extra for this type of filling service? And, how much?
  • What volumes will they need, and how much stock do I need to keep?
  • Is there a pattern in demand which is prevalent throughout rural areas?

Through such essential questions you are also more inclined to focus on gathering essential data for testing your idea. So it’s not so much the total number of motor bikes that zip by your station that count as an indicator for the potential of your idea. Depending on that in your case will make your family go hungry. Naturally, it’s the number of people that actually make a stop for a fill that does.

What’s more is that through playing with pricing, you might discover that customers are willing to pay 4-5 times the market rate for petrol, because your service saves so much effort (so radical affordability as the main constraint in servicing the BoP appears to be an assumption). Now you have found the essentials for scaling a profitable business: franchise anyone?

What we can learn from the makers
In short the MVP emphasizes what matters, and prevents you from wasting resources on testing the non essentials and using non-essential data. But conceiving your MVP is hard. How do you define your product in the most undressed way possible to test your product and its features? It is even more difficult to build an MVP for physical products like a gas station than for a web application (where the MVP concept naturally originated from), as you often incur more costs in time and materials to test them.

But, as the example in rural India shows, constraints like money and time spark creativity and can invoke “the maker” in all of us. Play around with representation: there is always a prototype! In our case we redefine the gas station to a jerry can and a funnel: the smallest representation with which all essential features of a gas station can be tested. People like Steve and Woz of Apple started out with just a motherboard.

Invest in defining, and cutting & pasting your MVP. It keeps you from carrying around stupidity for too long; it prevents you from filling the bucket with so much water that it starts spilling over the rim once you start walking. Build with less.