Herding Cats – Using Lean to Work Together

Posted on March 28, 2017 by steve blank

When Colonel Peter Newell headed up the Army’s Rapid Equipping Force (REF) he used lean methods on the battlefields of Iraq and Afghanistan to provide immediate technology solutions to urgent problems.

Today, his company BMNT does for government and commercial customers what the Rapid Equipping Force did for the U.S. Army.

Pete and I created the Hacking for Defense class (with Joe Felter and Tom Byers.) One of the problems our students run into is that there are always multiple beneficiaries and stakeholders associated with a problem, often with conflicting value propositions and missions. So how do you figure out whose needs to satisfy?

Here’s Pete’s view of how you do it.

Unlike businesses, government organizations don’t sell products, and they don’t earn revenue. Instead, they have missions to accomplish and very hard problems to solve. They use a variant of the Business Model Canvas – the Mission Model Canvas – to map their hypotheses, and they get of the building to do beneficiary discovery. (A beneficiary can be a soldier, program manager, commanding general, government contractor, stakeholder, customer, etc.) And just like in a commercial business they are trying to determine whether the value proposition solves the problem and helps the beneficiary accomplish their mission.

Discovery for both business and government is similar in that the only way to do it is to turn assumptions into facts by generating hypotheses, developing Minimum Viable Products and getting out of the building to test those MVP’s in the trenches where the customers and beneficiaries work. Early in the discovery process, teams are faced with a cacophony of personalities and organizations. Often, they struggle with understanding which person or group represents a beneficiary, supporter, advocate or potential key partner. It’s only through repetitive hypothesis testing that they begin to sort them all out.

It’s in the trenches however, where things become different.

Multiple Beneficiaries, Multiple Conflicts
Unlike their commercial counterparts, government problem solvers are often faced with multiple beneficiaries associated with a problem, often with conflicting value propositions. As these differences become apparent, teams must make decisions about the value proposition trade-offs between conflicting beneficiaries – sometimes even pivoting completely in favor of one beneficiary to the detriment of another.

During last year’s Hacking for Defense class at Stanford Team Aqualink experienced the conflicting beneficiaries’ problem. The result was a significant pivot of both beneficiary and value proposition.

Aqualink started with a problem given to them from the chief medical officer of the Navy SEALS – they had no way to understand chronic long-term health issues divers face. Divers work 60 to 200 feet underwater for 2-4 hours, but Navy doctors currently have no way to monitor divers’ core temperature, maximum dive pressure, blood pressure, pulse and the rebreather (air consumption), or the dive computer (dive profile) data.

Having all this new data would give a diver early warning of hypothermia or the bends. More importantly the data would allow the medical director to individually assess the short and long-term health of each diver. And medical researchers would have access to detailed physiological data. The medical director tasked the team with building a wearable sensor system and developing apps that would allow divers to monitor their own physiological conditions while underwater and to download it for later analysis.

In the first week of the class this team got out of the building, suited up in full Navy diving gear and did customer discovery by spending an hour in the life of the beneficiary.

But as the students on the Aqualink team spoke to the SEAL team divers, (another one of their beneficiaries), they experienced an existential crisis. Most of the divers were “ambivalent” (read hostile) about the introduction of a vitals monitoring platform, (“If you gave to us at 0900, it would end up on the bottom of the ocean by 0905.”) Having worked so hard to get into the SEALS, no diver wanted doctors telling them they could no longer dive.

After further questioning, the team discovered the reason the divers were spending so much time underwater – they often did not know where they were. To find out, they had to get a GPS fix. This meant their minisub (called the SEAL Delivery Vehicle) had to rise to within 6 feet of the ocean surface so the GPS antenna could broach the surface. And to do so they had to surface slowly to avoid giving the divers the bends.

The divers told our student team, “Screw the health sensors. Build us a GPS sensor that can be deployed from 100 feet underwater.”

Now the team had a dilemma. They would have to decide which beneficiary to focus on – the SEAL Team medical director, who was the sponsor of their problem, or the operators of the delivery vehicle and divers within SEAL Delivery Vehicle Team One, along with their immediate chains of command in SDVT-1 and Naval Special Warfare Group 3.

When they went back to the medical director with their findings, he was surprised as they were. “Never knew that’s why they spent all that time down there. Heck, yes, fix their problem first.”

Understanding the Problem Context and Problem Ecosystem
As Aqualink shows, getting out of the building – interviewing the beneficiaries, drawing their workflows and mapping a day-in -their-life – will give you a more complete picture of the context in which a proposed problem exists. Talking to multiple beneficiaries will lead to better understanding of the entire ecosystem of the problem. Often this will show that the problem you have been given is merely a symptom of a larger problem, or is the result of a different problem.

The solution is to:

Cross check the results of your discovery between different beneficiaries. Often, you’ll find that they seldom have a complete understanding of one another’s workflows and pain points but instead are championing the solution to a mere symptom of a different problem.
Share what you learned in discovery among the different beneficiaries. This will arm you with the tools needed to get them (or their leadership) to agree on the right problem that needs to be solved first. In many cases this will lead to your first pivot!

The goal is to sort out who has a value proposition that must be addressed first.

The power of beneficiaries helping one another
While discovery with multiple beneficiaries can be confusing and exhausting, there is immense power when all the beneficiaries work together. Therefore, the goal of customer discovery is not just to understand the pains and gains of individual beneficiaries, but to find a shared purpose between all of them.

Once they understand they share the same goal, they can solve pain points or create gains for each other using the resources they already control. A “shared” sense of purpose is a very powerful step in the pathway towards a deployable solution.

When the Department of Energy asked BMNT to build a training program for getting veterans into advanced manufacturing jobs, we saw the power of a shared purpose between multiple beneficiaries first hand.

The problem we were asked to solve is that of the 10,000 veterans who leave military service every month, many remain unemployed or underemployed, yet at the same time the number of unfilled advanced manufacturing jobs in the U.S. is expected to climb to over a million by 2020. From a business perspective, obtaining technically qualified talent is among the top constraints to growth in the US.

Seems like it would be a match made in heaven, right? Not so fast…

While we initially thought the beneficiaries of the effort were the veterans, we quickly discovered there were other beneficiaries in advanced manufacturing. We found these additional beneficiaries had different pains and gains which in turn required different value propositions to solve their problems.

Our customer discovery taught us that there were three additional beneficiaries:

Universities needed to grow their enrollments. Our discovery showed us universities were willing to create programming for Advanced Manufacturing, but first needed to see a business case for how it would increase their enrollment to make it a worthwhile effort.
Industry needed to attract and hire qualified employees. We learned that technically qualified employees within industry were in such demand that the number one way to get qualified employees was to pilfer them from others.
Government Agencies needed to help their communities build skilled labor pools to attract new industries.

And we learned that our initial beneficiary, veterans leaving service, didn’t need internships or low-paying jobs, but needed jobs that paid enough to support their families.

We found each of these beneficiaries had a shared purpose. And each of them had a value proposition that would create a gain or relieve a pain point for another beneficiary. These were big ideas.

We found that as these overlapping value propositions emerged, we used the results to get the beneficiaries to come together in a workshop designed to jointly create a shared minimum viable product that they could then use to test within their own organizations.

Bringing the groups together in a workshop also served to align value propositions between beneficiaries by demonstrating that there was a way to create a single program that served all their needs. And we created an environment that allowed each beneficiary to discover that the other beneficiaries were partners they could work with in the future.

What was the impact of bringing the beneficiaries together in a workshop and creating this beneficiary ecosystem for advanced manufacturing?

Lawrence Livermore National Lab (LLNL) created a veterans’ jobs program. They teamed with a local college to create internships that allowed veterans to work during the summer. In turn, the local college created additional advanced manufacturing classes to meet LLNL’s technical needs and the regional workforce investment board provided funding.

In Fort Riley, the Army base in Kansas, the military teamed with Kansas State University to create an advanced manufacturing program. Kansas State created a series of advanced manufacturing classes. Soldiers leaving the service can take these courses at a nearby campus beginning up to six months before they leave service.

An unexpected consequence is that today there are soldiers from Fort Riley using advanced manufacturing processes to create parts for vehicles and equipment at the Army base.

Lessons learned

Government problem solvers will often be faced with multiple beneficiaries with different value propositions. Share what you learn from different beneficiaries with each other to sort out which has a value proposition that must be addressed first.

The benefit of having multiple beneficiaries is that their strengths can be used to help one another create gains and relieve pains for one another. Creating a shared sense of empowerment from working together smooths the pathway towards scaling the right solution.

Filed under: Customer Development, Hacking For Defense, Lean LaunchPad | 3 Comments »

Hacking for Defense Goes National

Posted on January 17, 2017 by steve blank

Our goal was to scale Hacking for Defense classes across the US – giving students the opportunity to perform national service by solving real defense/diplomacy problems using Lean Methods. In exchange our government sponsors benefit from 1) access to talent that most likely would never have served the country, 2) getting solutions as minimum viable products/prototypes in 10 weeks, 3) exposure to a problem solving methodology used in Silicon Valley and battle tested in Iraq and Afghanistan.

This week we are doing what we said we’ll do – scale the class nationally:

Hacking for Defense at Georgetown: Began Wednesday, January 11
http://www.hacking4defensegu.com/#welcome

Hacking for Defense at James Madison: Began Thursday, January 12
http://jmuxlabs.org/hacking-for-defense/

Hacking for Defense at University of Pittsburgh: Began Monday, January 9
http://www.engineering.pitt.edu/hacking4defense/

Hacking for Defense at Boise State: Began Monday, January 9
https://cid.boisestate.edu/venturecollege/hacking-for-defense/

Hacking For Energy @ Columbia/NYU / CUNY: Begins: January 15
http://www.hacking4energy.com

Hacking for Defense at UC San Diego: Taught Fall 2016/next class 2017
http://jacobsschool.ucsd.edu/hackingfordefense/

Hacking for Defense at Stanford: Taught Spring 2016/next class Spring 2017
http://hacking4defense.stanford.edu

None of this would be possible without Pete Newell and Joe Felter and the entire team at BMNT and the extraordinary teaching team at each of these universities.

This week I’m in Washington co-teaching the 2nd Hacking for Defense Educators and Sponsor class. More universities coming to the program, more government sponsors sharing problems, more variants being taught in 2017 (Diplomacy, Impact/Development, Space, Cities, Hollywood, etc.)

Filed under: Hacking For Defense | 4 Comments »

The Innovation Insurgency Gets Educated: Hacking for Defense, Diplomacy, Development, …

Posted on December 16, 2016 by steve blank

We’re holding our 2^nd Hacking for Defense, Diplomacy,… educators and sponsors class January 17-19 at Georgetown University. The class is for:

educators who want to learn how to teach a Hacking for Defense, Diplomacy, Development, etc. class;
problem sponsors who want to learn how to get the most out of their interaction with student teams and how to use the teams to help accelerate their problem
government organizations who want to a more efficient way to deliver needed solutions with speed and urgency to their stakeholders.
corporate innovation leaders and technologists who want to engage with both emerging national problems and students who are the future corporate work force

The Innovation Insurgency
We taught the first Hacking for Defense class less than 6 months ago

hacking classes Our first Hacking for Diplomacy class ended this month.

Our goal was to scale these classes across the US giving students the opportunity to perform national service by getting solving real defense/diplomacy problems using Lean Methods. In exchange our government sponsors benefit from access to talent that most likely would never have served the country.

We trained our first group of educators and sponsors three months ago. Since then 8 universities have taught the Hacking for Defense class or put it on their academic calendar for 2017: UC San Diego, Georgetown, Air Force, University of Pittsburgh, James Madison University, Boise State, RIT, and Stanford.

Since then our Hacking for Defense our original sponsors; (JIDO, ARCYBER, AWG, USMC, NSA, AFNWC, SOCOM, 75th Ranger Regiment, USTRANSCOM, Cyber Force Protection Brigade, National Defense University, and the Center for Technology and National Security Policy) and a host of new ones have given us another 45 national security problems for these universities to solve.

Our Hacking for Diplomacy sponsors at State gave us 15 problems for the students to solve. The students selected seven from the the Office of Space and Advanced Technology, the Bureau of Political-Military Affairs, the Bureau of Conflict and Stabilization Operations the Bureau of Counterterrorism and Countering Violent Extremism, the Bureau of Population, Refugees, and Migration and the Office to Monitor and Combat Trafficking in Persons.

What We’ve Learned: Hacking for X
As soon as we stood up the first Hacking for Defense class we began to get requests from universities that sounded like, “can we start a Hacking for Energy class?” or “How about a NASA or the NRO class with Hacking for Space as the topic?” As soon as we followed it up with Hacking for Diplomacy we got asked, “Will this work at USAID with Hacking for Development?” How about a completely classified version? Or my favorite, “How about we get the movie studios give us some of their toughest challenges and we offer a “Hacking for Hollywood class in a Los Angeles university?”

More encouraging was that program managers inside of existing government agencies started asking, “could we use this method to better understand our stakeholder/warfighter needs to build and deliver needed solutions with speed and urgency?”

Most encouraging was the reaction of our students, who as Dean Al Pisano at the University of San Diego Jacobs School of Engineering put it “Will never look at their education curriculum the same way again.” Many of these same students whom have never been given an opportunity to provide a public service to their country are now consider solving our nation’s problems the coolest job they could have.

The answers to all of these questions are yes, yes, yes and yes.

Why this is possible is that at its core the Hacking for X for pedagogy is built around the same Lean methodology that’s been proven on the battlefield of Iraq and Afghanistan, Silicon Valley and the 1000+ teams from the National Science Foundation. Modifying the curriculum for a specific technology or field of interest; whether it’s defense, diplomacy or development or something that has yet to be asked for, is relatively simple.

Hacking for X Educators Class
We done five things to make this possible.

First, we (Pete Newell, Joe Felter, Tom Byers and I) set up a non-profit – H4Di.org to coordinate all these educational opportunities.

We wrote a 300-page educator guide which illustrates how to set up and teach a canonical “Hacking for…” class.
We wrote a sponsor guide which shows best practices for sponsors who want to offer problems for university students
We wrote a program managers guide to help leaders inside government organizations use the class to speed up their problem solving process
We hold a 2 ½ day educator class twice a year (east coast and west) to train both educators and sponsors on best practices and logistics

Come join us at the January 17-19^th Hacking for Defense, Diplomacy, Development class at Georgetown and learn how this works.

Filed under: Hacking For Defense, Hacking for Diplomacy, Teaching | 1 Comment »

So Here’s What I’ve Been Thinking…

Posted on December 4, 2016 by steve blank

I was interviewed at the Stanford Business School and in listening to the podcast, I realize I repeated some of my usual soundbites but embedded in the conversation were a few things I’ve never shared before about service.

Listen here:

Steve Blank on Silicon Valley, AI and the Future of Innovation

Download the .mp3 here:

Download Episode

Filed under: China, Hacking For Defense, NSF (National Science Foundation), Science and Industrial Policy, Teaching | Leave a comment »

How The Marine Corps Builds an Innovation Culture

Posted on November 10, 2016 by steve blank

Jennifer Edgin is the Chief Technology Officer of the Intelligence Division at the Headquarters of the Marine Corps. As the Senior Technical Advisor to the Director of Intelligence, she is responsible for building and infusing new technologies within the Marine Corps Intelligence, Surveillance, and Reconnaissance Enterprise (MCISRE). Jennifer is one the “innovation insurgents” inside the Department of Defense driving rapid innovation. Here’s her story of the Lean innovation accelerator she’s built for the Marines.

If you asked 100 people to describe a United States Marine, they would probably use words such as “Warrior,” “Fierce,” “Patriot,” “Honorable,” and “Tough.” Marine Corps culture transcends generations and is rooted in the values of courage, honor, and commitment. Marines are known for adapting to change and overcoming obstacles and adversity to meet new mission requirements continuously. Three years ago, Marine Corps Intelligence outlined a mission to harness the disruptions occurring in the new frontier of warfare, the Electronic battlefield. To achieve this mission, we established a framework that leveraged Marine Corps tenacity, agility, and adaptability to create a persistent culture of innovation.

One of our primary goals in establishing this framework was to keep the user front and center, and to quickly deliver solutions to their challenges. To achieve this, we stood up the Marine Corps Intelligence, Surveillance, and Reconnaissance Enterprise (MCISRE) Accelerator. Like a tech startup accelerator, the MCISRE Accelerator assembles a cohort of active duty Marines of all ranks, experiences, and disciplines and pairs them with developers, designers, and mentors through a 12-week “Design—Develop—Deploy” cycle. Marines are taught tools and methodologies from the Lean Startup, Design Thinking, and Service Design practices, which are then used to zero in on a problem; identify the target customer segment; validate the problem and solution by “getting out of the building” and submitting their problem and concept designs to peers for feedback, designing wireframes and prototypes, developing a minimum viable product (MVP); and finally pitch the MVP to the Director of Intelligence (DIRINT) and other leaders and stakeholders for a go/no-go decision for release.

Over the course of the last year, we have carefully measured and monitored our framework so we could quickly identify what was working, what was not working, and tune accordingly so that the end result created value for both the Marines in the cohort and the larger community of Marine Corps Intelligence. Below are the top 5 factors we found are necessary to successfully innovate.

1. Understand Your Customer and Teach Them to Solve Real Problems
Innovation begins and ends with understanding the customer and the specific problems they are facing. Too often in government, problems are talked about in generalizations, users are not part of the design and development of solutions, and anecdotal information gets passed around without data to validate it until at some point it becomes “truth” and is accepted without verification.

One of the most difficult exercises for our cohorts is distilling “world-hunger”-level challenges into discrete, focused problems we can solve in 12 weeks. We learned that if you cannot define your problem in one sentence that a 7 year-old can understand, you don’t understand the problem. If you want to create innovative solutions, you must start by defining real problems. Real problems—when defined properly—have metrics that quantify the scope, magnitude, and impact.

Before we launched the MCISRE Accelerator, we conducted site visits, and spoke with Marines from around the world to hear from them what wasn’t working and what was. After our site visits, we identified common issues across each of the sites, disciplines, and ranks, and launched data surveys to explore and quantify problems. The data showed us how users were currently performing a mission, where deficits existed in enabling technology and processes, and which anecdotal problems were actual problems and which were not. We then compared the results of the surveys with the site survey interviews and prepared a list of the top issues and challenges facing Marine Corps Intelligence. When we launched the MCISRE Accelerator, we used this information to quickly move the focus of the cohort from the world-hunger view to zeroing in one or two key issues that caused major disruptions in their tasking and productivity.

One of the biggest benefits to this process was that it helped shift the focus of the Marines from nebulous systems-centric thinking—“The network architecture sucks”—to identifying specific pain points impeding their productivity on the job. Because the tools and methodologies we use are simple but highly effective for analysis and problem solving, many of our cohort Marines take them back to their units so that they can reframe problems within their communities of practice.

2. Always Be Shipping
If vision without execution is hallucination, frameworks that don’t produce tangible products breed insanity. Within the MCISRE we have two frameworks that engage Marines. Our yearly technical design meeting (TDM) brings together Marines to identify and address challenges and issues across the MCISRE. The outputs of the technical design meeting are used as primers for defining the problem themes that each MCISRE Accelerator cohort will work on. The MCISRE Accelerator pairs Marines with developers and designers who work collaboratively both in person and virtually to design, prototype, and then develop and build a minimum viable product (MVP) in 12 weeks. These two frameworks allow us to continuously innovate from within, creating a pipeline of challenges to be solved over the long term and implementing against them iteratively and quickly. This rapid implementation creates real metrics that allow us to create quick, measurable value and kill bad ideas before too much time, money, and human capital has been spent on them. Rapid implementation also allows leadership to make quicker decisions on where, when, and how to apply resources.

3. Always Be Measuring
Big idea fairies live everywhere, sometimes for a very long time. This can be particularly true in the government where the acquisition lifecycle imposes “shipbuilding timelines” on information technology systems. Successful innovation requires one simple act: always be measuring. Using the Lean Startup methodology to build, learn, and measure in a 12-week cycle provides quantifiable data and user feedback that allows us to validate problem/solution fit quickly. By the time our cohort is pitching to the DIRINT and other leaders and stakeholders, the minimum viable product (MVP) has metrics that validate its value to users as well as prevent redundancy, loss of, or misalignment of capability, funding, and other key resources.

4. To think differently…be different
Most meetings within the government involve PowerPoint, a conference table, and a bunch of subject matter experts espousing the relative merits or demerits of a point. These meetings can last hours to weeks, and at the end, there might be nothing tangible to show. When we set out to create this culture of innovation, we knew that to get people to do things differently, we had to get them to think differently.

Our first mission value was to create an experience for our Marines, stakeholders, and mentors that was counter to the typical meetings they were used to and focused on establishing a co-creative environment where everyone’s input had value regardless of rank, experience, and skill. Our technical design meetings and Accelerators use little technology; are not set up as lectures; encourage jeans and your favorite T-shirt; and require constant, active participation. When you walk into our rooms, you will see Marines on their feet, Post-It notes and markers in hand, diagramming, sketching, and plotting furiously on white boards, flip charts, and any other available surface. They paper the room with problem statements, lean canvases, journey maps, value proposition canvases, process flows, wireframes, and Pixar-worthy storyboards. By the end of the week, you can walk the walls and see the progression of problem to solution in their words, through their eyes, from their point of view. This process takes Marines outside of the normal rank structure that they are accustomed. It is admittedly uncomfortable for them at first. But within hours of the kickoff, these simple tactics result in ideation, collaboration, and production that is evident to them and fundamentally changes how they approach problem solving and conduct meetings when they return to their units.

5. Do It Again… and Again… and Again
With any new skill, repetition is important. Marines don’t learn close order drill with a one-time explanation, they spend countless hours on the drill field until they have mastered it. We apply the same repetition mindset for our innovation methodology because it creates an environment of continuous learning. With every repetition, we learn more about our problems and how we can solve them. We learn which solutions are working and which ones are not. We learn what techniques for engaging Marines are working and which ones are not. We learn how the operating environment is evolving. Continuous learning is the objective of our innovation activities, and it is more powerful than the solution itself. Learning means successes, learning means failures, learning means growth.

November 10, 2016 marks the 241th anniversary of the formation of the Marine Corps; 241 years of adapting to changes and 241 years of innovation. Innovation does not mean that it has to come from external entities. Sometimes you just need to put Marines in jeans, challenge them to think differently, and give them another opportunity to adapt and overcome.

Filed under: Hacking For Defense, Teaching | 6 Comments »

There are 145 Entrepreneurship Courses at Stanford

Posted on October 6, 2016 by steve blank

Stanford is an incubator with dorms

Download the full text file with links to the courses here.
http://www.slideshare.net/sblank/stanford-entreprenuership-classes

Filed under: Hacking For Defense, Hacking for Diplomacy, Lean LaunchPad, Teaching | 2 Comments »

7 Steps to Hacking for Defense

Posted on September 25, 2016 by steve blank

Filed under: Hacking For Defense, Teaching | Leave a comment »

The Innovation Insurgency Scales – Hacking For Defense (H4D)

Posted on September 19, 2016 by steve blank

Hacking for Defense is a battle-tested problem-solving methodology that runs at Silicon Valley speed. We just held our first Hacking for Defense Educators Class with 75 attendees.

The results: 13 Universities will offer the course in the next year, government sponsors committed to keep sending hard problems to the course, the Department of Defense is expanding their use of H4D to include a classified version, and corporate partners are expanding their efforts to support the course and to create their own internal H4D courses.

It was a good three days.

————-

Another Tool for Defense Innovation
Last week we held our first 3-day Hacking for Defense Educator and Sponsor Class. Our goal in this class was to:

Train other educators on how to teach the class at their schools.
Teach Department of Defense /Intelligence Community sponsors how to deliver problems to these schools and how to get the most out of student teams.
Create a national network of colleges and universities that use the Hacking for Defense Course to provide hundreds of solutions to critical national security problems every year.

What our sponsors have recognized is that Hacking for Defense is a new tool in the country’s Defense Innovation toolkit. In 1957 after the Soviet Union launched the Sputnik satellite the U.S. felt that it was the victim of a strategic technological surprise. DARPA was founded in 1958 to ensure that from then on the United States would be the initiator of technological surprises. It does so by funding research that promises the Department of Defense transformational change instead of incremental advances.

By the end of the 20^th century the Central Intelligence Agency (CIA) realized that it was no longer the technology leader it had been when it developed the U-2, SR-71, and CORONA reconnaissance programs in the 1950’s and 1960’s. Its systems were struggling to manage the rapidly increasing torrent of information being collected. They realized that commercial applications of technology were often more advanced than those used internally. The CIA set up In-Q-Tel to be the venture capital arm of the intelligence community to speed the insertion of technologies. In-Q-Tel invests in startups developing technologies that provide ready-soon innovation (within 36 months) vital to the IC mission. More than 70 percent of the In-Q-Tel portfolio companies have never before done business with the government .

In the 21^st century the DOD/IC community have realized that adversaries are moving at a speed that our traditional acquisition systems could not keep up with. Hacking for Defense combines the rapid problem sourcing and curation methodology developed on the battlefields in Afghanistan and Iraq by Colonel Pete Newell and the US Army’s Rapid Equipping Force with the Lean Startup practices that I pioneered in Silicon Valley and which are now the mainstay of the National Science Foundations’ I-Corps program. Hacking for Defense is a problem-solving methodology that offers the DOD/IC community a collaborative approach to innovation that provides ready-now innovation (within 12-36 months).

Train the Trainers
Pete Newell, Joe Felter and I learned a lot developing the Hacking for Defense class, more as we taught it, and even more as we worked with the problem sponsors in the DOD/Intel community. Since one of our goals is to make this class available nationally, now it was time to pass on what we had learned and to train other educators how to teach the class and sponsors how to craft problems that student teams could work on.

(If you want a great overview of the Hacking for Defense class, stop and read this article from War on The Rocks. Seriously.)

When we developed our Hacking for Defense class, we created a ton of course materials (syllabus, slides, videos). In addition, for the Educator Class we captured all we knew about setting up and teaching the class and wrote a 290-page educator’s guide with suggested best practices, sample lesson plans, and detailed lecture scripts and slides for each class session. We developed a separate sponsor guide with ideas about how to get the most out of the student teams and the university.

The Educator Class: What We Learned
One of the surprises for me was seeing the value of having the Department of Defense and other government agency sponsors working together with the university educators. (One bit of learning was that the sponsors portion of the workshop could have been a day shorter.)

Two other things we learned has us modifying the pedagogy of the class.

First, our mantra to the students has been to learn about “Deployment not Demos.” That meant we were asking the students to understand all parts of the mission model canvas, not just the beneficiaries and the value proposition. We wanted them to learn what it takes to get their product/service deployed to the field, not just have another demo to a general. This meant that the minimal viable products the students built were focused on maximizing their learning of what to build, not just building prototypes. While that worked great for the students, we learned from our sponsors that for some of them getting to deployment actually required demos as part of the means to reach this end. They wanted the students to start delivering MVPs early and often and use the sponsor feedback to accelerate their learning.

This conversation made us realize that we had skewed the class to maximize student learning without really appreciating what specific deliverables would make the sponsors feel that the time they’ve invested in the class was worthwhile. So for our next round of classes we will:

require sponsors to specifically define what success from their student team would look like
have students in the first week of class present what sponsors say success looks like
still encourage MVPs that maximize student learning, but also recognize that for some sponsors, learning could be accelerated with earlier functional MVPs

Our second insight that has changed the pedagogy also came from our sponsors. As most of our students have no military experience, we teach a 3-hour introduction to the DOD and Intel Community workshop. While that provides a 30,000-foot overview, it doesn’t describe any detail about the teams’ specific sponsoring organization (NSA, ARCYBER, 7^th Fleet, etc.). (By the end of the quarter every team figures out how their sponsor ecosystem works.) The sponsors suggested that they offer a workshop early in the class and brief their student team on their organizations, budget, issues, etc. We thought this was a great idea as this will greatly accelerate how teams target their customer discovery. When we update the sponsor guide, we will suggest this to all sponsors.

Another surprise was how applicable the “Hacking for…” methodology is for other problems. Working with the State Department we are offering a Hacking for Diplomacy class at Stanford starting later this month. And we now have lots of interest from organizations that have realized that this problem-solving methodology is equally applicable to solving public safety, policy, community and social issues internationally and within our own communities. We’ll soon launch a series of new modules to address these deserving communities.

Lessons Learned

Hacking for Defense = problem-solving methodology for innovation insurgents inside the DOD/Intel Community

The program will scale to 13+ universities in 2017

There is demand to apply the problem-solving methodology to a range of public sector organizations where success is measured by impact and mission achievement versus revenue and profit.

Filed under: Hacking For Defense, Hacking for Diplomacy, Science and Industrial Policy | 2 Comments »

The National Geospatial Intelligence Agency Goes Lean

Posted on August 29, 2016 by steve blank

We tend to associate the government with words like bureaucracy rather than lean innovation. But smart people within government agencies are working to change the culture and embrace new ways of doing things. The National Geospatial Intelligence Agency (NGA) is a great example.

The NGA, an organization within the U.S. Department of Defense, delivers geospatial intelligence (satellite imagery video, and other sensor data) to policymakers, warfighters, intelligence professionals and first responders.

A team from their Enterprise Innovation Office has joined us at NYU as observers at our 5-day Lean LaunchPad class, while another team is in Silicon Valley with the Hacking for Defense team learning how to turn their hard problems into partnerships with commercial companies that lead to deployed solutions.

The Innovation Insurgency
Over the last year the National Geospatial Intelligence Agency (NGA) has become part of the “Innovation Insurgency” inside the U.S. Department of Defense by adopting Lean Methodology inside their agency.

In July the NGA hosted the inaugural 2016 Intelligence Community Innovation Conference with attendees from across the Department of Defense and public sector. At the conference Vice Chairman of the Joint Chiefs of Staff Air Force Gen. Paul Selva said, “Implementing innovation [in the government and large organizations] is like a turning battleship, you may have an upset crew with cooks having to clean up spilled food and sailors falling out of beds but that ship can turn with effort. The end result is often that change can happen but it is going to come at the cost of disruption and difficulty.”

The good news for the country is that the leadership of the National Geospatial Intelligence Agency has decided to turn the ship now.

To connect to innovation centers outside the agency, their research group has set up “NGA Outpost Valley” (NOV), an innovation outpost in Silicon Valley. The NOV is building an ecosystem of innovative companies around NGA’s hard problems to rapidly deploy solutions to solve them.

To promote innovation inside the NGA, they’ve staffed an Enterprise Innovation Office (EIO) to coach, educate and advise the entire agency, from core leadership to the operational edges, with methods and concepts of validated learning through rapid experimentation and customer development.

The NGA has adopted Lean Innovation methods to make this happen. The process starts by collecting agency-wide ideas and/or customer problems, collecting a group insight, and sorts which problems are important enough to pursue. The innovation process uses the Value Proposition canvas, customer development and the Mission Model Canvas to validate hypotheses and deliver minimum viable products. This process allows the agency to rapidly deliver projects at speed.

To help start this innovation program the NGA’s Enterprise Innovation Office has had their innovation teams go through the already established Innovation-Corps classes at the National Security Agency (NSA), and they’re about to stand up their own Innovation-Corps curriculum inside the NGA. (The Innovation-Corps (I-Corps for short) Program is the Lean Innovation class I developed at Stanford and teach there and at Berkeley, Columbia and NYU. It was first adopted by the National Science Foundation and is now offered at 54 universities, and starting last year taught in all research agencies and the DOD.)

This past week a team from the NGA’s Enterprise Innovation Office observed the 5-day Lean LaunchPad class I’m teaching at NYU. Their goal is to integrate these techniques into their own Lean innovation processes. From their comments and critiques of the students, they’re more then ready to teach it themselves.

At the same time the NGA Outpost Valley team was in Silicon Valley going through a Hacking for Defense workshop (we call a “sprint.”) Their goal was to translate one of their problems into a language that commercial companies in the valley could understand and solve, then to figure out how to get the product built and deployed. Like other parts of the Department of Defense (the Joint Improvised Threat Defeat Agency (JIDA) and the Defense Innovation unit Experimental (DIUX),) NGA’s Outpost Valley team is using a Hacking for Defense sprint to build a scalable process for recruiting industry and other partners to get solutions to real problems deployed at speed.

Putting lean principles into NGA’s acquisition practices
As part of the Department of Defense, the NGA acquires technology and information systems through the traditional DOD’s acquisition system – which has been described as the antitheses of rapid customer discovery and agile practices. The current acquisition system seldom validates whether a promised capability actually works until after the government is locked into a multiyear contract, and fixing those problems later often means cost overruns, late delivery, and under performance. And as any startup will tell you, the traditional government acquisition processes create disincentives for startups to participate in the DOD Market. Few startups know where and how to find opportunities to sell to the DOD, they seldom have the resources or expertise to navigate DOD bureaucratic procurement requirements, and the 12 plus months it takes the government to enter into a contract makes it cost prohibitive for startups.

A year ago Sue Gordon, the deputy director of the NGA, sent out an agency-wide memo that said in part, “…we must build speed and flexibility (agility) into our acquisition processes to respond to those evolutions. It is our job to acquire the technologies, data and services that NGA and the NSG need to execute our mission in the most effective, efficient and timely manner possible …”

In addition to NGA’s internal Lean Innovation process and innovation outpost in Silicon Valley, they are starting to use open innovation and crowdsourcing to attract commercial developers to tackle geospatial intelligence problems.

This week the NGA posted its first major open Challenge – The NGA Disparate Data Challenge– on Challenge.gov, the U.S. government’s open innovation and crowdsourcing competition. Government agencies like the NGA can use the site to post challenges and award prizes to citizens who find the best solutions. Putting a challenge on a crowdsourcing platform is a groundbreaking activity for the agency and opens the possibility for a number of benefits.

Presenting a problem instead of a set of requirements to startups leaves the window open to uncover unknown solutions and insights
Setting up the challenge in two stages hopefully gets startups to participate while learning about the NGA and its technical needs
Asking for working solutions offers the potential for minimal viable acquisition to quickly validate who can solve the problem prior to committing large sums of taxpayer funds
Finding solutions at speed by shrinking the timeline for determining the viability of a solution without the need for executing any large scale contract.

The NGA Disparate Data Challenge has two stages.

Stage 1: teams have to demonstrate access and retrieval to analyze NGA provided datasets. (This data is a proxy for the difficulties associated with accessing and using NGA’s real classified data.) Up to 15 teams who can do this can win $10,000. And the winners get to go Stage 2.
Stage 2: the teams demo their solutions and other features they’ve added against a new data set live to an NGA panel of judges, in hackathon style competition. First place will take an additional $25,000; second $15,000; and third $10,000 with an opportunity to be part of a competitive pool for a future pilot contract with NGA.

NGA’s challenge is its first attempt to attract startups that otherwise would not do business with the agency. It’s likely that the prize amounts ($10-$25K) may be off by at least one order of magnitude to get a startup to take their eye off the commercial market. Curating a crowd and persuading them to work together because the work meets their value proposition is hard work that takes incubation not just prizes. However, this is a learning opportunity and a great beginning for the Department of Defense.

Challenges in Embracing Innovation in Government Agencies
Innovation in large organizations are fraught with challenges including; building an innovation pipeline without screwing up current product development, educating senior leadership and (at times intransigent) middle management about the difference between innovation and execution, encouraging hands-on customer development, establishing links between department and functional silos that don’t talk to each other (and often competing for resources), turning innovative prototypes and minimum viable products into deliverable products to customers, etc.

Government agencies have all these challenges and more. Government agencies have more stringent policies and procedures, federally regulated oversight and compliance rules, and line-item budgets for access to funding. In secure locations, IT security can hinder the simplest process while a lack of access to a physical collaboration space and access to data, all set up additional barriers to innovation.

The NGA has embraced promising moves to bring lean methods to the way they innovate internally and acquire technology. But what we’ve seen in other agencies in the Department of Defense is that unless the innovation process is run by, coached and scaled by innovators who have been in the DOD and understand these rules (and have the clearances), using off-the-shelf commercial lean innovation techniques in government agencies is likely to create demos for senior management but few fully deployed products. (The National Security Agency has pioneered getting this process right with the I-Corps@NSA.)

Lessons Learned

Lean Innovation teams are starting up at the National Geospatial Intelligence Agency (NGA)

NGA has an Innovation Outpost in Silicon Valley working on it’s first hacking for Defense Sprint

NGA is experimenting with open innovation with its first problem on Challenge.gov

The goal of Lean in government agencies should mean deployment not demos

In order to successfully deliver products with speed and urgency, this requires coaches and instructors who have been the customer: warfighters, analysts, operators, etc.

It will take innovation built from the inside as well as acquisition from the outside to make it happen