One of the most important aspects of Lean Startup is that risk management strategies are baked into your philosophy and practices. Business is risky and starting a business from scratch all the more so. The tactics that enable founders to control risks, to test assumptions, to subdivide large thorny problems into smaller more manageable ones are probably the most critical factors in the recent successes of startups using the Lean Startup methodology.
Nonprofit program development is risky (for the organization, clients or constituents, and funders) for many of the same reasons that product development is risky for startups. This article describes two tools being used in the Lean Startup movement that give startups an edge in managing their risk… But these tools are not just for startups. These are tools that nonprofits can apply as well.
Business Model Canvas
The Business Model Canvas, developed by Alexander Osterwalder, has become standard issue for Lean Startups. The canvas is a framework and visualization tool that allows founders to organize all of the assumptions implicit within their business model, and devise tests to systematically validate or invalidate them. While the business model canvas was designed for business model generation, a version could be adapted for testing assumptions within nonprofit program development.
The canvas is divided into nine boxes, each addressing a different aspect of a typical business model. The right side of the canvas deals with customers and markets, such as Channels, Customer Segments, and Revenue Structure, while the left side covers operations, such as Key Resources and Cost Structure. Typically, the canvas is posted on the wall during a brainstorm session, and the team creates a sticky note for each assumption and places it in the appropriate box. All of the boxes should be filled with at least one assumption by the end of the session. Many teams actually create multiple versions of their model, each with variations they want to test.
Teams then systematically test each assumption in order to validate the viability of the business model. For example, a web startup might assume that Facebook ads are a great way to get customers. To test this, they may create a simple informational landing page, buy some ads to direct traffic to it, and measure the conversion on those ads. This channel assumption is thus tested in isolation before a product is even built, greatly reducing risk by not building something tailored to a specific channel that may not ultimately bring in enough customers to justify its cost of development.
Each of the assumptions on the canvas can be tested in different ways, and preferably teams test assumptions in the order of highest risk or greatest uncertainty. This creates a learning feedback loop that allows possible solutions to be tested with minimal time and cost, one of the foundational concepts of Lean.
In the nonprofit version, some of the boxes would probably stay as they are. For example, most nonprofits still need to test channels for outreach, and they certainly have a cost structure, key resources and key activities. We might want to change Customer Segment into Community or Constituency, but regardless of what boxes we change, the model allows nonprofits to brainstorm all risky assumptions in their organization or program development and systematically test them.
David Snowden’s Cynefin framework is by contrast not yet part of the central Lean Startup canon. However it is gaining adoption in the larger Lean community and there are those in the Lean Startup movement who are illustrating its effectiveness at managing risk.
The framework is used to classify a problem, situation or environment into one of four domains, Simple, Complicated, Complex, or Chaotic, so that an appropriate strategy might be chosen to address it. The rationale is that problems in different domains require different strategies, and applying the wrong strategy can dangerously backfire for an organization. The power of the framework is that it allows organizations (nonprofits included) to properly identify what domain a particular problem is in and then apply a more appropriate strategy. The framework is used currently by a wide range of companies and government agencies.
The two known or knowable domains, Simple and Complicated, are on the right, with the two unknown or unknowable domains, Complex and Chaotic, on the left. Problems in the Simple domain are those where the relationship between cause and effect is direct and obvious. As such, strategies that effectively operate here take the form Sense, Categorize, Respond, and can be described as Best Practice. I find it useful to think of Simple here not as ‘small’ or ‘individual’ but more as ‘rules-based’ or ‘straightforward’. Bureaucratic structures and strategies for example fits in this domain since problems here can simply be filtered through the correctly established set of policies to arrive at appropriate solutions.
The Complicated domain is home for problems that require expertise. The relationship between cause and effect is still knowable but not obvious or direct. Snowden calls strategies here Good Practice because there are usually more than one, and they take the form Sense, Analyze, Respond, where the analysis is performed by someone with specialized knowledge or skill. An example might be hiring an IT consultant to automate some internal process, or outsourcing a research project to a firm. It might be an internal department that specializes in one knowledge or another.
The next two domains are where things really get interesting, and where the link to Lean Startup becomes apparent. The Complex domain is where the relationship between cause and effect is unknown until hindsight. Here strategies must be more like Emergent Practice usually through tests, trials, or iterations. Strategies that work in the complex domain take the form Probe, Sense, Respond. Remember that you cannot predict outcomes here so you must first fumble around in the dark a little bit at a time. It’s pretty clear to me that the Lean Startup ‘build-measure-learn’ loop is an application of problem solving in the complex domain.
The Chaotic domain includes situations where this no apparent relationship between cause and effect. The only strategies that work here take the form of Act, Sense, Respond. This is the realm of Novel Practice, in that there is no prior experience to draw on. Organizations facing challenges in the Chaotic domain must simply try any reasonable strategy at hand to gain a foothold and bring the problem back into one of the other domains. One example of Chaotic problems might be production failures in software systems, where something critical breaks unexpectedly and engineers must rapidly attempt best-guess fixes until some data emerges to help them zero in on the problem. It is usually something high risk, but unplanned. Organizations can fall from Simple into Chaotic at times when they are overwhelmed by demand for services that do not easily fit into their practice areas.
Again, the framework allows any organization to properly identify what domain a particular problem is in. This is important because applying a strategy from the Simple domain on a problem that is really in the Complex domain is likely to fail, and vice versa. For example, if your problem space involves many variables operating at once, say a partnership between several different actors each with unique agendas or motivations, attempting to enforce some kind of standardized best practice on all of them will likely fail. Conversely, encouraging too much loose creativity and exploration around an area that really has standard and well defined practices, such as hiring practices or purchasing policies, may invite too much variation or randomness and can be wasteful or destructive to the organization.
A final very useful aspect of the framework is to recognize that problems can shift from one domain to another, and that can be intentional or not. A common pattern for example is for overly rigid bureaucracies to encounter a problem that they lack the flexibility to cope with, resulting in a catastrophic slip into the Chaotic domain. FEMA during Hurricane Katrina relief could be considered to have fallen into the Chaotic domain for a period as they struggled to respond to overwhelming requests for aid. Conversely, sometimes a little problem solving in the chaotic domain can be generative of novel and creative solutions to stuck or static issues, so long as the problem is quickly moved into the Complex domain once any sort of pattern emerges. In a sense this is what brought about Lean Startup in the first place, as Steve Blank discovered patterns he later named Customer Development out of all of the chaos of his various startup experiences.
Program development in the nonprofit sector is risky, and just like business ventures, include many assumptions that need to be tested and validated (or invalidated) as quickly as possible. Problems or challenges faced by emerging organizations may require dramatically different strategies depending on the domain. My hope is that using the Lean Startup methods, and particularly tools like the Business Model Canvas and the Cynefin framework, nonprofits can control risks and be more successful in rolling out sustainable and enriching programs for their communities.
Want to learn more? Visit us here.