Mosquitoes, Snakes, and Sector Specific Startup Accelerators

A perfection of means, and confusion of aims, seems to be our main problem.
Albert Einstein

Last week I was fortunate to visit Leancamp (a masterful gathering of people exchanging on startup methodology and experience). I was curious to learn for myself whether there would be any advantage or added value that sector specific knowledge could have in supporting startup development. Generic accelerator programs seem to be more prevalent in the startup ecosystem, but could it just be that there is a niche for sector specific focus?

In the series of scheduled Leancamp events, I attended an excellent session by @tor on the idea generation process. Tor’s discussion was on using discovery and ideation in the startup development process. His open-ended question was whether it would be better to use many ideas to come to a notion of killer game changing ideas, or whether singular ideas would work better, focusing efforts on making one, or a few things work.

Though there was of course no real answer to this question, the session did succeed in its’ outset to prompt my thinking on sector specific acceleration. I serendipitously linked back to a story told to me by my former Zameen Organic co-founder, Gijs, in India about the problem he had with snakes. Through this link I was able to better frame the advantages, which sector specific accelerators could bring to shaping and selecting ideas for customer problem solving.

It’s a snake eat frog world out there
The story Gijs told me a few months ago was about a problem he was having with snakes entering his home in India’s rural Auroville, located near Pondicherry. The snakes we’re talking about here are not just benign pests: we’re talking about one of the most venomous creatures that crawl this earth, the common krait (click on pic below). Nothing you really need to have hanging out with your kids.

Initially Gijs believed that the snakes were looking for refuge at his home from the scorching (> 45 degrees Celsius) heat of the sun. But he soon found his hypothesis debunked when he observed that snakes, amongst which the krait, mostly entered during the evening and at night time (always check what’s under your sheets before nesting in for the night!!)

Correlated with the observation that the snakes moved in a lot at night, was another the observation that there were also frogs hopping around the house. This brought up a second hypothesis: are the snakes coming in for the frogs? Indeed they were. In fact, kraits love feeding on frogs.

The question was now: what are these frogs doing here? The answer to that had the same structure as the previous question: the frogs hopped inside to get a bite to eat. They were enjoying the mass of mosquitoes that was humming around in house, and had been bothering Gijs and the family for quite some while. So at this point Gijs had some notion of a problem hypothesis, and also a starting point where to go from to finding a solution: the mosquitoes. If you take away the reason why frogs are in the house, then you probably take away the motive for snakes to visit.

So any guesses as to what Gijs did about the source of mosquitoes? The quick fix solution would be to grab for the spray can. But Gijs being an eco-minded agronomist, and an avid systems thinker, didn’t see the appeal to this fix, nor the long-term resolve it would bring. Rather, Gijs aimed for the source. He found the source in the pond next door, which was squirming with larvae but contained no fish. So, as an experiment, Gijs set out fish in the pond, hoping they would feast on the larvae, and reduce the incidence of mosquitoes. The fish did indeed solve the mosquito problem, and the predicted chain of causality set in, drastically reducing the incidence of frogs and snakes in the house.

And the specific point being…
Last week‘s Leancamp session was excellent. I advise any aspiring and seasoned entrepreneur to attend and share knowledge at future events. I remain in amazement of the power that the methods of leanstartup and customer development bring to help markets smartly solve part of the world’s major problems. Although these tools help you to frame any real world problem and devise related solutions, they could definitely be supported with knowledge from people who know both the methodology, as well as hold experience in certain corners where the problems are occurring. In my case this would be agriculture’s corner. I would say there could be two advantages:

1) Sink your teeth in the right problem.
The first point is that understanding the part in the order of the system you work with is highly beneficial. If you don’t, you would probably have started off with developing snake traps (snakes being the most terrifying facet of the problem), and move further down that line if that didn’t work. This could probably take you to the real solution at some point, but it would have taken you much longer to get there. We all know the pressure startups need to work under to build things faster than their peers to compete. So sector specific knowledge could help you to build faster through better targeting.

2) Don’t give up too easily on your solution.
The second point is that specific knowledge could help affirm your direction in tinkering with your prototype solutions. Gijs had a great one shot hit through introducing the fish, but this could also have just as likely been a wrong hypothesis. If the fish wouldn’t have worked then, Gijs, with his background, would have started working on another solution for the mosquitoes, concluding that the fish was the wrong hypothesis, but at the right level. However, if he didn’t have the systems understanding, he could also be tempted to conclude (falsely) that the more simple solution would be to start at a different level of the problem chain; on something that ousts-the-frogs-to-oust-the-snakes. So in other words you could say that sector specific knowledge could help to improve the direction of your pivot, should you ever need to perform one.

Now these are just hypotheses, but I’ll work diligently over the coming time to validate them by helping agri-startups to focus their aim.

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.