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.

Private Sector Development projects and “the Pivot”

A pivot is a change in strategy without a change in vision – Eric Ries

Development projects are not really known for their effectiveness. There is much discussion on what works, and what doesn’t. One of the big hypotheses out there is called Private Sector Development (PSD). The thought here is that government can create public goods by supporting the development of private enterprise in developing countries to contribute to social/economic empowerment of the population, creating jobs, stimulating other enterprise, achieving sustainability, etc.

PSD, a problem of project management
Despite the initial clarity in logic, there are many issues with this form of enterprise development. For one, enterprise, government, and civil society have not found a common language on their projects and can’t properly communicate their respective objectives and priorities. What aggravates the lack of common understanding is that government and civil society have a domineering role in organizing development projects. Therefore, such projects are still very much designed according to government and civil society principles: principles of the logical framework (activity to output schemes), budget lines, and spending targets.

The result is that PSD projects are required to commit to pre-planned project outputs to obtain funding. Even though business ideas are still in a hypothesis phase at the start of project, funding requirements impose an implicit assumption that the basic business model is known, and that the project can start at the point of execution of that model. A project is considered to be completed if it has neatly run through all the activity lines and depleted its’ budget.

It should come as no surprise that these projects regularly tank when the pre-conceived business idea with its’ underlying mechanical execution assumptions is floated onto the bustle of the market. Worse even is that success or failure in this context is determined by whether or not the implemented plan has led to any meaningful market traction. Unfortunately this result tells only about the plan. It rarely tells anything about the business idea itself, and whether there was actually evidence for market uptake potential or not.

On a positive note, the academic community sees this problem with PSD, and is wakening to the challenge in project management design. Scholars are creating workarounds for the mechanistic approach through developing new impact assessment methodologies. Theories of impact are jointly formulated between all project initiators, and project performance indicators are defined based on common understanding of the impact which is to be achieved.

Despite these project management innovations, assessment methodologies themselves face the challenge of execution: academic priorities lie with methodological novelty, publishability, and gathering of rigorous data. As a consequence, assessment learning loops are stretched out over too long a period- not feeding into real time project decision making. They are too burdensome for commercial ventures to apply. In an attempt to patch such deficiencies, even more innovations are appearing, like running multiple/parallel experiments, and using judgmental decision making to enhance agility and adapt to changing circumstances during project execution. But these measures can’t take away the reality that methodologies provided are still too cumbersome to apply in a PSD setting where one is starting up private enterprise in a difficult market.

A PSD project is actually a startup project….
Regardless of the methodological work-arounds, PSD remains stuck with a faulty premise in basic project management design. Unless this is addressed, all PSD projects will be incessantly running futile attempts to blindly bash innovation complexity into linear bounds. To break with this problem, we should come to realize that PSD is actually more an entrepreneurial endeavor than an execution plan. PSD projects aim to develop an often “sort of known” product for a currently non-existing market. Customer needs are usually unknown, and as such the solutions for that market. Key decision making in PSD is thus fraught with fundamental uncertainty.  Under such conditions a different project logic applies, namely that of progressive learning in a search for a scalable, repeatable business model. This is completely different from executing on a known business model. In other words, what a PSD project should come to grounds with is that it needs to run more like an entrepreneurial startup. In all modesty ,PSD, as “any startup on day-0, is a faith-based initiative” (Steve Blank & Bob Dorf, 2012, Startup Owner’s Manual). Such projects are not yet ready for execution.

The  interesting thing about the comparison between PSD in startups, is that world of startups has had to traverse the same type of project logic problem as PSD is currently facing. Startups have by and large been applying waterfall design logic, where the objective is to spec a product for a known market requirement, to a setting where the market requirement is in fact deeply unknown. Development success in this manner can be explained more by good luck, than by good judgment.

The result of faulty application of project design logic, is that large investments are made in execution activities when even the basic premise of the startup remains unanswered: Who is your customer?, What is the job your customer is trying to get done?, What (part of) their job do you solve?, and What is your sales plan for reaching out to that market? These are the first steps you need to get validated in the startup development process. You test these questions to find out whether you have a scalable repeatable busines model, before actually investing in scaling it up. The startup world has only over the last decade come to realize that confusing search priorities with execution objectives leads to catastrophic results. If you don’t respect this difference, you will end up burning a lot of money based of a set of wild assumptions.

Building startups using “Customer Development”
One of the pioneers of this discovery is former serial entrepreneur, and current professor of entrepreneurship Steve Blank. Blank describes a startup as a temporary vehicle, dedicated to the search for a repeatbale, scalable business model. The objective of the startup is to learn what its’ market is. Within a search objective the methods applied in tracking performance differ significantly from execution. The performance questions are not about “sales volumes”, and “market share”, but rather about “who is interested in what specifically, and for what purpose”, and “what would be a systematic approach to this customer”.  Once the startup has learned about its’ market and the solution it provides, can it seriously substantiate investment in execution.

The method Blank has developed, called customer development, distinguishes 4 discrete steps in startup development from

  1. initial customer discovery to
  2. validation of customers for a product or service,
  3. market development, and
  4. company building

The prior two steps hold a search priority, the latter execution. Each of the steps is considered as an iterative learning process, where the net result of learning from success and failure determines whether the project is able to proceed to the next step. (see figure below)

One of the most fundamental development process maneuvers in customer development is called “the pivot” (a term coined by the protagonist of the “lean startup” movement, Eric Ries). Upon making the decision to pivot, the entrepreneur comes to realize that her vision needs a different strategy. The business model which the entrepreneur was pursuing contains too many faulty assumptions. However, based on process learnings through applying functional learning metrics, their is a good cause to argue that the business idea can be realized through correcting the business model design. This done by fundamentally altering one or more of the building blocks.

The pivot does not mean that the entrepreneur was incompetent, or wrong. Rather the pivot allows the entrepreneur to redeem (or even leverage) the costs of previous failure. To startup venture capitalists the pivot can be so obviously logical, that they will often agree to follow the entrepreneur in this fundamental change, without losing faith in the entrepreneur and her idea. By tracking learning in startup projects according to the customer development process, business development process is thus provided with a structure to deal with fundamental uncertainty inherent to entrepreneurial venture discovery.

The Customer Development process, based on Steve Blank

Managing and funding PSD like a startup will be key
When you compare the customer development process with PSD, the project trajectories which are followed are strikingly similar. PSD projects start with “value chain, stakeholder, and needs assessments” before they move towards project implementation, scaling up, and institution building. PSD projects subconsciously follow the customer development line, but more in waterfall fashion, with little room for iteration at best, and definitely without the pivot (if you’ve ever considered changing a budget heading in a development project to a different purpose, you will know what I mean).

Again, a lot of the mistakes that were previously made in the startup scene, are currently being made in the development sphere. One of the key aspects which will need to change in PSD project management design is that the performance metrics used should focus on learning about what the market for a business idea is and what works in that market. Metrics should be designed in such a manner that they facilitate learning, and not so much academic publication. Execution and delivering on its’ metrics are of later concern. In this way project reporting will focus on feeding decision making on what to do in the next iteration of development, rather satisfying government or donors’ spending ambitions. If project teams are relieved of the pressure to deliver on execution metrics when they are actually in a learning phase, then more focus can be put on entrepreneurial learning, and actually building a successful product.

If PSD wants to change anything about its’ meager track record, it will need to build in room for dealing with entrepreneurial uncertainty in project decision making. This starts with shifting investment priorities from execution to search, and dealing with performance metrics that respect the difference. Allowing room for this won’t be easy, because it provides a challenge to transparency in the spending of public money. But, we need to treat PSD more like business development in a developing world context, and provide these projects with an allowance to learn as an entrepreneur learns. Otherwise we will needlessly keep burning money on wild guesses, and write off potential high-impact ideas that don’t deliver the initial execution plan, as completely failed initiatives. We need this allowance, because in the end, the result of PSD should be to deliver functional enterprise that solves customer problems, just like a startup. What else would be the point?

Take aways:

– PSD is stuck with a problem of trying to force market based innovation onto a government planning logic

– PSD tries to achieve much of what a startup tries to achieve: to find a scalable repeatable business model.

– Many of the mistakes which have been made in the development of startups, are currently being made in PSD. This is a learning opportunity

– Funding flexibility, and business development based on learning metrics will be key to dealing with these mistakes. Most importantly, PSD funding mechanisms need to build in conditions that allow project teams to make a pivot on project objectives. They can do this based on insights they obtain through progressive learning from failure on previous attempts.