Mission Model Canvas – the Videos

In 2016 Pete Newell, Alexander Osterwalder and I developed the Mission Model Canvas for our Hacking for Defense Class.  We’ve now created a series of videos that explain how this variant of the Business Model Canvas works – 11 videos totaling 17 minutes.

Thanks to BMNT and the National Security Innovation Network for support of this project.

When Pete Newell, Joe Felter and I built the Hacking for Defense class we modeled the syllabus after my earlier Lean LaunchPad and NSF I-Corps classes. Both classes used Alexander Osterwalder’s Business Model Canvas to frame the hypotheses to be tested.

If you can’t see the business model canvas video click here

However, using the business model canvas inside the Dept of Defense was problematical. Teams there pointed out that the standard business model canvas didn’t fit their problem sets. For example, in the Dept of Defense you don’t measure progress by measuring revenue. Instead 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.)

Therefore, the business model canvas box labeled Revenue Streams doesn’t make sense. The defense and intelligence community are mission-driven organizations so there is no revenue to measure. The first step in building a canvas that worked for these organizations was to change the Revenue Stream box to one that would provide a way to measure success.

We called this alternative- Mission Achievement/Success.

Now the Mission Model Canvas just needed four more tweaks.

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

Read the full blog post on the development and use of the Mission Model Canvas here.

And watch the Mission Model Canvas videos below.

If you can’t see the Introduction to the Mission Model Canvas video click here

If you can’t see the Beneficiaries and Stakeholders video click here

If you can’t see the Value Proposition video click here

If you can’t see the Buy-In video click here

If you can’t see the Deployment video click here

If you can’t see the Mission Achievement video click here

If you can’t see the Key Activities video click here

If you can’t see the Key Resources video click here

If you can’t see the Key Partners video click here

If you can’t see the Mission Budget video click here

If you can’t see the Key Concepts video click here

You can find the entire video series collected here

AgileFall – When Waterfall Sneaks Back Into Agile


This article previously appeared in the Harvard Business Review

AgileFall is an ironic term for program management where you try to be agile and lean, but you keep using waterfall development techniques. It often produces a result that’s like combining a floor wax and dessert topping.

I just sat through my a project management meeting where I saw AgileFall happen first-hand. The good news is that a few tweaks in process got us back on track.


I just spent half a day with Henrich, the head of product of a Fortune 10 company. We’re helping them convert one of the critical product lines inside an existing division from a traditional waterfall project management process into Lean.

Henrich is smart, innovative and motivated. His company is facing disruption from new competitors. He realized that traditional Waterfall development wasn’t appropriate when the problem and solution had many unknowns.a

This product line has 15 project managers overseeing 60 projects. Over the last few months we’ve helped him inject the basic tenets of Lean into these projects. All are Horizon 1 or 2 projects – creating new features for existing products targeting existing customers or repurposing existing products, tools, or techniques to new customers. Teams are now creating minimum viable products (MVPs), getting out of the building to actually talk with users and stakeholders, and have permission to pivot, etc.  All good Lean basics.

AgileFall in Real Life
But in our latest meeting I realized Heinrich was still managing his project managers using a Waterfall process. Teams only checked in – wait for it – every three months in a formal schedule review. I listened as Henrich mentioned that the teams complained about the volume of  paperwork he makes them fill out for these quarterly reviews. And he was unhappy with the quality of the reports because he felt most teams wrote the reports the night before the review. How, he asked, could he get even more measures of performance and timely reporting from the project managers?

At first glance I thought, what could be bad about more data? Isn’t that what we want – evidence-based decisions? I was about to get sucked down the seductive path of suggesting even more measures of effectiveness when I realized Henrich still had a process where success was measured by reports, not outcomes. It was the same reporting process used to measure projects that used linear, step-by-step Waterfall.

(To be fair to Henrich, his product team is a Lean island in a company where Waterfall still dominates. While his groups has changed the mindset and cadence of the organization, the folks he reports up to don’t yet get Agile/Lean learning and outcomes. They just want to see the paperwork.)

In both managing down and up we needed a very different project management mindset.

Lean Project Management Philosophy
So our discussion was fun. As the conversation progressed, we agreed about the ways to manage projects using a few operating principles of Lean/Agile project management (without ever mentioning the words Lean or Agile.)

  1. It was the individuals who were creating the value (finding solution/mission ft) not the processes and reports
  2. However, the process and reports were still essential to management above him.
  3. Having the teams build incremental and iterative MVPs was more important than obsessing about early documentation/reporting
  4. Allow teams to pivot to what they learned in customer discovery rather than blindly follow a plan they sold you on day one
  5. Progress to outcomes (solution/mission ft) is non-linear and not all teams progress at the same rate

Pivoting the Process
With not too much convincing, Henrich agreed that rather than quarterly reviews, the leadership team would to talk to 4-5 project managers every week, looking at 16-20 projects. This meant the interaction cycle – while still long – would go from the current three months to at least once a month.

More importantly we decided that he would focus these conversations on outcomes rather than reports. There would be more verbal communication and a lot less paper. The reviews would be about frequent delivery, incremental development and how leadership could remove obstacles. And Henrich’s team would continue to share progress reporting across the teams so they could learn from each other.

In sum, the radical idea for Henrich was tha this role was not to push the paperwork down. It was to push an outcome orientation down, and then translate its progress back up the chain. While this was great for the teams, it put the onus on Henrich to report progress back up to his leadership in a way they wanted to see it.

I knew the lightbulb had fully gone on when near the end of the meeting Henrich asked his team, “Going forward, who are the right team members to manage a Lean process versus a Waterfall?” And I smiled when they concluded that Lean could be managed by fewer people who could operate in a chaotic learning environment, versus a process-driven, execution one.

I can’t wait for the next meeting.

Lessons Learned

  • AgileFall is a seductive trap – using some Lean processes but retaining the onerous parts of Waterfall
  • The goal of leadership in Lean product management is not to push the paperwork down. It’s to push an outcome orientation down and translate its progress back up the chain
%d bloggers like this: