Month: February 2016

The Mission Model Canvas – An adapted business model for mission-driven organizations

Mission Model Canvas

As we prepared for the new Hacking for Defense class at Stanford, we had to stop and ask ourselves: How do we use the Business Model Canvas if the primary goal is not to earn money, but to fulfill a mission?

In other words, how can we adapt the Business Model Canvas when the metrics of success for an organization is not revenue?

Alexander Osterwalder and I think we have the answer – the new Mission Model Canvas.

Here are our collective thoughts.

The Lean Startup is the way most innovators build startups and innovate inside of existing companies.

As a formal method, the Lean Startup consists of three parts:

The Business Model Canvas has been a great invention for everyone from startups to large companies. Unlike an org chart, which describes how a company executes to deliver known products to known customers, the Business Model Canvas illustrates the search for the unknowns that most new ventures face. The 9 boxes of the canvas let you visualize all the components needed to turn customer needs/problems into a profitable company.

From revenue streams to mission achievement

The Business Model Canvas has served all of us well in thinking about building businesses – and therein lies the problem. In a business the aim is to earn more money than you spend. What if you’re a government or a military organization or part of the intelligence community? In these cases you don’t earn money, but you mobilize resources and a budget to solve a particular problem and create value for a set of beneficiaries (customers, support organizations, warfighters, Congress, the country, etc.).

For these organizations, the canvas box labeled Revenue Streams doesn’t make sense.

In a mission-driven organization such as the defense and intelligence community, there is no revenue to measure. So, the first step in building a canvas for mission-driven organizations is to change the Revenue Stream box in the canvas and come up with a counterpart that would provide a measure of success.

We’re calling this alternative Mission Achievement. Later, in this post I’ll explain how we’ll measure and describe Mission Achievement, but first our Mission Model Canvas needs four more tweaks.

  • Customer Segments is changed to Beneficiaries
  • Cost Structure is changed to Mission Cost/Budget
  • Channel is changed to Deployment
  • Customer Relationships is changed to Buy-in/Support

The rest of this blog post explains the how and why of these changes to the canvas.

Customer segments change to beneficiaries

At first glance, when developing a new technology for use in the defense and intelligence community, the customer appears obvious – it’s the ultimate war fighter. They will articulate pains in terms of size, weight, form fit, complexity and durability. But there are other key players involved.  Requirement writers and acquisition folks look at systems integration across the battlefield system, while contracting officers, yet another segment, will count beans, measure the degree of competition and assess the quality of market research involved. The support organizations need to worry about maintainability of code or hardware. Does legal need to sign off for cyber operations?  So yes, war fighters are one customer segment, but others need to be involved before the war fighter can ever see the product.

So, the first insight is that in the defense and intelligence community mission models are always multi-sided markets with the goal of not just building a great demo but getting the product adopted and deployed.

Second, in the defense and intelligence communities almost all of the mission models look like that of an OEM supplier – meaning there are multiple layers of customers in the value chain. Your product/service is just part of someone else’s larger system.

So, to differentiate “customers” from the standard business model canvas, we’ll call all the different customer segments and the layers in the defense and intelligence value chain beneficiaries.

The value proposition canvas

Of all the nine boxes of the canvas, two important parts of the model are the relationship between the Value Proposition (what you’re building) and the beneficiaries. These two components of the business model are so important we give them their own name, Product/Market Fit.

Because of the complexity of multiple beneficiaries and to get more detail about their gains and pains, Osterwalder added an additional canvas called the Value Proposition Canvas. This functions like a plug-in to the Mission Model Canvas, zooming in to the value proposition to describe the interactions among these beneficiaries, war fighters, etc. and the product/service in more detail. Using the Value Proposition Canvas with the Mission Model Canvas lets you see both the big picture at the mission model level and the detailed picture of each beneficiary at the “product/market fit” level.

Value prop zoom bus modelIn the defense and intelligence community mission models, there will always be multiple beneficiaries. It’s important that each beneficiary gets its own separate Value Proposition Canvas.

value_proposition_canvas

Distribution channel changes to deployment

In the commercial world we ask, “What type of distribution channel (direct sales, app store, system integrator, etc.) do we use to get the product/service from our company to the customer segments?”

For the Department of Defense or Intelligence organizations, we ask instead:

  • “What will it take to deploy the product/service from our current Minimum Viable Product to widespread use among people who need it?” (What architecture components can they innovate on and what can’t they?)
  • “What constitutes a successful deployment? (number of users, units in the field, time to get it into the field, success in the field, etc.)”
  • “How do we turn a Horizon 3 innovation into something that gets adopted by a Horizon 1 organization?”

Customer relationships changes to buy-in/support

In an existing business, Customer Relationships is defined as establishing and maintaining a relationship to support existing customers. In a startup we redefined Customer Relationships to answer the question: How does a company get, keep and grow customers?

For the defense and intelligence communities, we have modified Customer Relationships to mean, “For each beneficiary (customer segment), how does the team get “Buy-In” from all the beneficiaries?”

Customer discovery helps you understand whose buy-in is needed in order to deploy the product/service (legal, policy, procurement, etc.) and how to get those beneficiaries to buy-in? (Funding? Mandates? User requested? etc.) In addition, the long-term support and maintenance of new projects need to be articulated, understood and bought-into by the support organizations.

At the Pentagon a favorite way to kill something is to coordinate it to death by requiring buy-in from too many people too early. How to determine who are the small group of critical people to get buy-in from – and how to determine who are the next set required to sustain the iterative development of future MVP’s – is one of the arts of entrepreneurship in the defense and intelligence community.

Revenue streams changes to mission achievement

Mission Achievement is the value you are creating for the sum of all of the beneficiaries / the greater good.

It’s important to distinguish between the value for individual beneficiaries (on the Value Proposition Canvas) and overall Mission Achievement. For example, Mission Achievement could be measured in a variety of ways: the number of refugees housed and fed, the number of soldiers saved from roadside bombs, the number of cyberattacks prevented, the increased target surveillance of sensor fusion, etc. None of these are measured in dollars and cents.

Keep in mind, there is only mission achievement if it delivers value to the end beneficiary.

Insights from federal digital design leaders

U.S. Digital Service

Ethan Marcotte and Karen McGrane have been on a roll lately featuring federal government design leaders on their Responsive Web Design Podcast.

The first episode, with U.S. Digital Service Designer Mollie Ruskin and Lead Front End Designer Julia Elman sharing insights into their design process and prototyping tools (OmniGraffle, Sketch, GitHub) and building the U.S. Web Design Standards, has excellent insights for those focused on this aspect of the civic experience.

Favorite quote from Mollie:

“I think that one thing that you have to just come to terms with in doing a project like this is that there are so many moving pieces and it’s a lot to keep track of all at the same time, and just to sort of like take a meditative, reasoned approach to that because it can be a daunting amount. I had been given that advice before I started, and it was about halfway through that I felt the zen of all of the pieces moving and realized that that was part of the beauty of doing this work, is that by us taking on this complex important problem, we were going to be making it easier for others moving forward. So, I would just encourage a can-do attitude and plow through those times where you feel like you’re building seventeen things all at once, because you will be.”

RWD has also featured designers from Vets.gov, Consumer Financial Protection Bureau and the U.S. Department of State.

Beta government

West Carrollton BETA

West Carrollton BETA

For those unfamiliar with the concept of beta, it’s a term used in software development to push a public prototype to get design and functionality feedback, as well as test and report technical bugs before launching the project as an official service.

Standard operating procedure for government digital services is to create an extensive specifications document and develop a waterfall project management strategy for executing. Once the project is finalized internally, it’s released to the public as-is without any intention of collaboration or feedback from those who will actually use the service.

Beta has eliminated the fear associated with a big launch. Knowing that beta is the beginning of a collaborative process eases that fear and creates a feedback culture that is much-needed in digital government innovation.

More and more, particularly at the federal level, such as Vets.gov, government is releasing web-based projects this way, even openly and proactively discussing the beta as part of an on-going, iterative process. Locally, larger cities such as Boston are also going beta.

Beta as described in 18F’s “Project Stage Definitions“:

Stage and test working software on the public web for use by a subset of the target audience. Implement changes based on user behavior and feedback. Resolve policy compliance or technical integration issues. Define and then validate statistically significant metrics for improvement.

GOV.UK:

The objective of this phase is to build a fully working prototype which you test with users. You’ll continuously improve on the prototype until it’s ready to go live, replacing or integrating with any existing services.

U.S. Department of Veterans Affairs:

This beta release of Vets.gov is just a beginning. We’ve launched it with deep content in the two benefit categories you’ve told us mean the most to you: disability and education. There are many more to come. We’ll be adding new information and tools ongoing. But we wanted to get vets.gov in front of you now, as we build it, so you can tell us what’s working for you and what isn’t.

At ProudCity, we’ve launched our first city beta and, as a government service provider, we’ve learned a great deal about traditional blockers to innovation, and how we can help overcome them. It’s exciting to work with governments who embrace the beta mindset, especially knowing the end product, particularly for true software-as-a-service offerings, will only get better over time.

If you work inside government, demand beta from your digital services providers and bake it into your acquisition process. If you have the luxury of an internal development team, begin building the culture and communications strategy for deploying this.

There are internal, cultural, procurement and process issues governments must address, but ultimately it’s worth redefining the way services are delivered, and these obstacles are easier to overcome than you might imagine, and will be as more governments adopt the concept of beta.

Beta government is the new standard.