Doubling Down On a Good Thing: The National Science Foundation’s I-Corps Lite

I’ve known Edmund Pendleton from the University of Maryland as the Director of the D.C. National Science Foundation (NSF) I-Corps Node (a collaboration among the University of Maryland, Virginia Tech, George Washington, and Johns Hopkins). edmund pendeltonBut it wasn’t until seeing him lead the first I-Corps class at the National Institutes of Health that I realized Edmund could teach my class better than I can.

After seeing the results of 500+ teams through the I-Corps, the NSF now offers all teams who’ve received government funding to start a company an introduction to building a Lean Startup.

Here’s Edmund’s description of the I-Corps Lite program.

SBIR/STTR Program and Startup Seed Funding
The Small Business Innovative Research (SBIR) and Small Business Technology Transfer (STTR) programs are startup seed funds created by Congress to encourage U.S. small businesses to turn Government-funded research into commercial businesses. Eleven U.S. agencies participate in the SBIR/STTR program, with DOD, HHS (NIH), NSF, DOE, and NASA offering the majority of funding opportunities.SBIR and STTR program

The SBIR/STTR program made ~6,200 seed stage investments in 2014, dwarfing the seed investments made by venture capital. seed stage investmentThe SBIR/STTR program represents a critical source of seed funding for U.S. startups that don’t fit whatever’s hot in venture capital. In fact, half of all seed stages in tech companies in the U.S. were funded by the SBIR program.

The SBIR/STTR program
The SBIR/STTR program funds companies in three phases. Phase I funding is for teams to prove feasibility, both technical and commercial.

Since most of the founders come from strong technical roots, companies in Phase I tend to focus on the technology – and spend very little time understanding what it takes to turn the company’s technology into a scalable and repeatable commercial business.

SBIR PhasesIn 2011 the National Science Foundation recognized that many of the innovators they were funding were failing – not from an inability to make their technologies work – but because they did not understand how to translate the technology into a successful business. To address this problem, the NSF collaborated with Steve Blank to adapt his Lean LaunchPad class at Stanford for NSF-funded founders. By focusing on hypothesis testing, the Lean LaunchPad had actually developed something akin to the scientific method for entrepreneurship. (see here, here and the results here.) This was an approach that would immediately make sense to the scientists and technologists NSF was funding. Steve and the NSF collaborated on adapting his curriculum and the result was the 9-week NSF I-Corps program.

NSF’s original I-Corps program was specifically designed for academic innovators still in the lab; fundamentally, to help them determine the best path to commercialization before they moved to the start-up stage. (I-Corps participants are at the “pre-company” stage.) But NSF realized the Lean LaunchPad approach would be equally beneficial for the many startups they fund through the SBIR/STTR program.Icorps plus SBIR

The “Beat the Odds” Bootcamp – an I-Corps “Lite”
The good news is that the NSF found that the I-Corps program works spectacularly well. But the class requires a substantial time commitment for the founding team to get out of the building and talk to 10-15 customers a week, and then present what they learned – the class is essentially a full time commitment.

Was there a way to expose every one of ~240 companies/year who receive a NSF grant to the I-Corps? The NSF decided to pilot a “Beat the Odds Boot Camp” (essentially an I-Corps Lite) at the biannual gathering of new SBIR/STTR Phase I grantees in Washington.

Steve provided an overview of the Lean LaunchPad methodology in an introductory webinar. Then the companies were sent off to do customer discovery before coming to an optional “bootcamp workshop” 12 weeks later. Four certified I-Corps instructors provided feedback to these companies at the workshop. The results of the pilot were excellent. The participating companies learned a significant amount about their business models, even in this very light-touch approach. The NSF SBIR/STTR program had found a way to improve the odds of building a successful company.Icorps lite plus sbir

During the past two years, I’ve taken the lead to expand and head up this program, building on what Steve started. We now require the participating companies to attend kick-off and mid-point webinars, and to conduct 30 customer interviews over the twelve-week program. The companies present to I-Corps instructors at a “Beat the Odds Bootcamp” – the day before the biannual NSF Phase I Grantee Workshop.

In March we conducted our fourth iteration of this workshop with a record number of companies participating (about 110 of 120, or 90%) and 14 certified I-Corps instructors giving feedback to teams. This time, we added afternoon one-on-one sessions with the teams in addition to group presentations in the morning. Companies are very happy with the program, and many have requested even more face time with I-Corps instructors throughout the process.

The smart companies in Phase I realize that this Bootcamp program provides a solid foundation for success in Phase II, when more dollars are available.

What’s Next
Currently, once these teams leave I-Corps Lite, they do not have any “formal” touch points with their instructors. Over time, we hope to offer more services to the teams and develop a version of I-Corps (I-Corps-Next?) for Phase II grantees.

We envision even greater startup successes if SBIR/STTR funded teams can take advantage of I-Corps classes through their entire life cycle:

  • “Pre-company” academic researchers – current I-Corps
  • Phase I SBIR/STTR teams – current I-Corps Lite
  • Phase II SBIR/STTR teams – develop a new I-Corps Next class

Icorps next plus SBIR ii and iii

The emphasis and format would change for each, but all would be solidly rooted in the Lean LaunchPad methodology. And of course, we don’t want to stop with only NSF teams/companies…as we all know. The opportunity is huge, and we can have a significant impact on the country’s innovation ecosystem.

NSF led the development of the SBIR program in the late 1970s. It has since been adopted by the entire federal research community. We believe NSF’s leadership with I-Corps will deliver something of equal significance… a program that teaches scientists and engineers what it takes to turn those research projects into products and services for the benefit of society.  I-Corps Lite is one more piece of that program.

Lessons Learned

  • The SBIR/STTR program is a critical source of seed funding for technology startups that don’t fit the “whatever’s hot” category for venture capital
  • The program is a national treasure and envied around the world, but we can (and should) improve it.
  • SBIR/STTR Phase I applicants needed more help with “commercial feasibility”…a perfect fit for business model design, customer discovery and agile engineering – so we rolled out the NSF I-Corps
  • The I-Corps was so successful we wanted more NSF funded entrepreneneurs, not just a select few, to be exposed to the Lean methodology – so we built I-Corps Lite

Why Build, Measure, Learn – isn’t just throwing things against the wall to see if they work – the Minimal Viable Product

I am always surprised when critics complain that the Lean Startup’s Build, Measure, Learn approach is nothing more than “throwing incomplete products out of the building to see if they work.”

Unfortunately the Build, Measure, Learn diagram is the cause of that confusion. At first glance it seems like a fire-ready-aim process.

It’s time to update Build, Measure, Learn to what we now know is the best way to build Lean startups.

Here’s how.

Build, Measure, Learn sounds pretty simple. Build a product, get it into the real world, measure customers’ reactions and behaviors, learn from this, and use what you’ve learned to build something better. Repeat, learning whether to iterate, pivot or restart until you have something that customers measure learn

Waterfall Development
While it sounds simple, the Build Measure Learn approach to product development is a radical improvement over the traditional Waterfall model used throughout the 20th century to build and ship products. Back then, an entrepreneur used a serial product development process that proceeded step-by-step with little if any customer feedback. Founders assumed they understood customer problems/needs, wrote engineering requirements documents, designed the product, implemented/built the hardware/software, verified that it worked by testing it, and then introduced the product to customers in a formal coming out called first customer ship.

Waterfall Development was all about execution of the requirements document. While early versions of the product were shared with customers in Alpha and Beta Testing, the goal of early customer access to the product was to uncover bugs not to provide feedback on features or usability. Only after shipping and attempting to sell the product would a startup hear any substantive feedback from customers. And too often, after months or even years of development, entrepreneurs learned the hard way that customers were not buying their product because they did not need or want most of its features.

It often took companies three tries to get products right. Version 1 was built without customer feedback, and before version 1 was complete work had already started on version 2 so it took till version 3 before the customer was really heard (e.g. Microsoft Windows 3.0)

Best practices in software development started to move to agile development in the early 2000’s. This methodology improved on waterfall by building software iteratively and involving the customer. But it lacked a framework for testing all commercialization hypotheses outside of the building. With Agile you could end up satisfying every feature a customer asked for and still go out of business.

Then came the Build-Measure-learn focus of the Lean Startup.

The goal of Build-Measure-Learn is not to build a final product to ship or even to build a prototype of a product, but to maximize learning through incremental and iterative engineering. (Learning could be about product features, customer needs, the right pricing and distribution channel, etc.) The “build” step refers to building a minimal viable product (an MVP.) It’s critical to understand that an MVP is not the product with fewer features. Rather it is the simplest thing that you can show to customers to get the most learning at that point in time. build measure learnEarly on in a startup, an MVP could simply be a PowerPoint slide, wireframe, clay model, sample data set, etc. Each time you build an MVP you also define what you are trying to test/measure. Later, as more is learned, the MVP’s go from low-fidelity to higher fidelity, but the goal continues to be to maximize learning not to build a beta/fully featured prototype of the product.

A major improvement over Waterfall development, Build Measure Learn lets startups be fast, agile and efficient.

The three-circle diagram of Build Measure Learn is good approximation of the process. Unfortunately, using the word “build” first often confuses people. The diagram does seem to imply build stuff and throw it out of the building. A more detailed version of the Build Measure Learn diagram helps to clarify the meaning by adding three more elements: Ideas-Build-Code-Measure-Data-Learn.

ideas build code measureThe five-part version of the Build Measure Learn diagram helps us see that the real intent of building is to test “ideas” – not just to build blindly without an objective. The circle labeled “code” could easily be labeled “build hardware” or “build artificial genome.” The circle labeled “data” indicates that after we measure our experiments we’ll use the data to further refine our learning. And the new learning will influence our next ideas. So we can see that the goal of Build-Measure-Learn isn’t just to build things, the goal is to build things to validate or invalidate the initial idea.

The focus on testing specific ideas counters the concern that build-measure-learn is just throwing things against the wall and see if they work.

But it’s still not good enough. We can now do better.

Start With Hypotheses
What Build-Measure-Learn misses is that new ventures (both startups and new ideas in existing companies) don’t start with “ideas”, they start with hypotheses (a fancy word for guesses.) It’s important to understand that the words “idea ” and “hypotheses” mean two very different things. For most innovators the word “idea” conjures up an insight that immediately requires a plan to bring it to fruition. In contrast, a hypothesis means we have an educated guess that requires experimentation and data to validate or invalidate.

These hypotheses span the gamut from who’s the customer(s), to what’s the value proposition (product/service features), pricing, distribution channel, and demand creation (customer acquisition, activation, retention, etc.)

That the Lean Startup begins with acknowledging that your idea is simply a series of untested hypotheses is a big idea. It’s a really big idea because what you build needs to match the hypothesis you want to test.

The minimum viable product you’ll need to build to find the right customers is different from the minimum viable product you need for testing pricing, which is different from an MVP you would build to test specific product features. And all of these hypotheses (and minimal viable products) change over time as you learn more. So instead of Build-Measure-Learn, the diagram for building minimal viable products in a Lean Startup looks like Hypotheses – Experiments – Tests – Insights.hypotheses experiment

Generating Hypotheses
Using this new Hypotheses – Experiments – Tests – Insights diagram the question then becomes, “What hypotheses should I test?” Luckily Alexander Osterwalder’s business model canvas presents a visual overview of the nine components of a business on one page. They are:

  • value proposition, product/service the company offers (along with its benefits to customers)
  • customer segments, such as users and payers or moms or teens
  • distribution channels to reach customers and offer them the value proposition
  • customer relationships to create demand
  • revenue streams generated by the value proposition(s)
  • activities necessary to implement the business model
  • resources needed to make the activities possible
  • partners 3rd parties needed to make the activities possible
  • cost structure resulting from the business model

Business Model Canvas

And it brings us to the definition of a startup: A startup is a temporary organization designed to search for a repeatable and scalable business model.

Testing Hypotheses
And once these hypotheses fill the Business Model Canvas, how does an entrepreneur go about testing them? If you’re a scientist the answer is easy: you run experiments. The same is true in a Lean Startup. (The National Science Foundation described the Lean LaunchPad class as the scientific method for entrepreneurship.)

The Customer Development process is a simple methodology for taking new venture hypotheses and getting out of the building to test them. Customer discovery captures the founders’ vision and turns it into a series of business model hypotheses. Then it develops a series of experiments to test customer reactions to those hypotheses and turn them into facts. The experiments can be a series of questions you ask customers but most often a minimal viable product to help potential customers understand your solution accompanies the questions.

So another big idea here is startups are not building minimal viable products to build a prototype. They are building minimal viable products to learn the most they can.

HBR Reprint

Finally, the goal of designing these experiments and minimal viable products is not to get data. The data is not the endpoint. Anyone can collect data. Focus groups collect data. This is not a focus group. The goal is to get insight. The entire point of getting out of the building is to inform the founder’s vision. The insight may come from analyzing customer responses, but it also may come from ignoring the data or realizing that what you are describing is a new, disruptive market that doesn’t exist, and that you need to change your experiments from measuring specifics to inventing the future.

Lessons Learned

  • Build, Measure, Learn is a great improvement over Waterfall product development and provided the framework to truly join the customer to agile development
  • However, emphasizing “Build” or “Ideas” as the first step misses the key insight about a Lean Startup – you are starting with hypotheses to be tested and are searching for repeatable and scalable business model
  • Hypotheses, Experiments, Test, Insights better represents the Lean startup process:
    • Use the Business Model Canvas to frame hypotheses, Customer Development to get out of the building to test hypotheses, and Agile Engineering to build the product iteratively and incrementally

How One Startup Figured Out What Could Really Help Deaf People

Thibault Duchemin and his team applied for our Lean LaunchPad class at UC Berkeley in 2014. We accepted them because it was clear Thibault was driven to solve a very personal problem – he grew up in a Deaf family, the only one who could hear. His team project was to provide automated aids for the hearing impaired.

Here’s his story.


Lean LaunchPad: A Year After
A month ago, Jason, one of my founder friends, shut down his startup. It failed because he forgot the No. 1 rule every founder hears over and over: Nobody wants your product until you prove it.

How come so many founders still wake up to this horrible truth, after months or years of hard work?

Listening to Jason’s story made me realize how critical our experience with the Lean LaunchPad has been in our entrepreneurial journey at Transcense. And why now, despite the time and effort involved, we do not hesitate getting out of our office to meet users.

Pre-Lean LaunchPad – Giving a Voice to the Deaf
Everything started when I applied to the Lean LaunchPad class pitching a big, crazy idea to solve a personal problem of mine. I grew up the only hearing person in a Deaf family. My sister’s dream has always been to become a lawyer, but closing statements and client meetings are impossible situations for her without the help of unaffordable interpreters.


At Berkeley I decided to build smart gloves to translate sign language. With my co-founder Pieter, I built a first basic prototype, which got us a prize and got the team started. It looked like one of the geeky science projects you find in Berkeley halls. Glove nerds we became.started with a glove

That’s also when we met Steve Blank.

More than the signing glove, he was interested by our passion for the problem.

Steve knew that first ideas rarely hit home for users, so to enter the Lean LaunchPad, we had to give in. “We’re not married to the glove,” we said, allowing us to accept the possibility of a pivot. There was no going back.

Lean LaunchPad – Stumbling Upon an Immense Need
Customer Development for us meant a lot of hard-won learnings. Our entire team took a fast-paced American Sign Language course to be able to really connect with our potential users. We spent six weekly hours in complete silence, discovering the subtleties of gestures and expressions. Since I’m French, I spoke for a while a bizarre Franglish in signs. It turned out to be out an excellent icebreaker in our interviews.

After 61 in-person discussions, and hundreds of bike rides across the Bay Area to meet and talk/sign/write for hours with our potential users, we were sure that the community of Deaf people cheered for our signing glove idea and prototype.

But we detected a common frustration when discussing their existing relationships with their hearing coworkers or friends, where the glove couldn’t help at all. This one thing kept coming back across all our interviews, over and over. A frustration so obvious, yet so deeply unresolved that when it became really apparent the day we met Alma, it blew our minds away and made us pivot.

Alma didn’t speak sign language, and relied on her residual hearing, being able to read lips very well in face-to-face situations. But in her own family, at the dinner table, she would read a book while everybody else was conversing.make do


Because following the conversation when multiple people were talking around her was impossible. She avoided the problem the best way she could, by doing something else, or being somewhere else.

We learned that existing solutions are not affordable enough to access in easy, informal social and professional conversational situations. For 400M people in the world with disabling hearing loss, this is an ongoing frustration, encountered every day. This was a big opportunity.

Halfway through the Lean LaunchPad, it was time for a major pivot. We dropped the signing glove.

And pivoted to a mobile application that transcribes group conversations using speech-recognition technologies. The app quickly connects all the smartphones in a group, enabling the app to translate and display who said what around the user (while uniquely identifying each speaker) in less than a second. With 24/7 autonomy, it allowed our deaf/hard-of-hearing user to understand and participate in any group situation, effortlessly.

The rest of the 123 total interviews helped us figure out a working business model. By the time we graduated from the Lean LaunchPad class, we had found the root cause of the initial problem we had set out to tackle, and even better, a potential solution for it.a device to understand themPost-Lean LaunchPad – Making Something People Need
Now it was time to build the company. Our team spent our whole summer in Berkeley iterating, testing and running experiments to validate and refine our concept before spending any of our precious resources. For example, we built a “mock-up meeting”, where 5 friends in the meeting called 5 more friends of ours who each transcribed the call to be interfaced to a Deaf tester in the room. Despite the low fidelity of this minimal viable product, some of our testers thought it was a real technology.

a device to understand them2Next, we joined the startup accelerator, where we spent 16 hours a day in a basement to finish the first working version of our app. By now we believed we had tested our hypotheses and wanted to validate whether there was a market. So we launched a crowdfunding campaign on Indiegogo. We raised $30,000 in less than 6 days, almost doubling our goal. The endless emails we received describing the exact need we had uncovered were the powerful validation of the customer development approach.

Now – Bridging the Communication Barrier
Skinner, our third cofounder, joined because of our persistence in talking to our users. The captioner (live-transcriber) we used in demoing to potential deaf customers was so excited about our product that she introduced us to Skinner, a brilliant mobile developer, who is profoundly deaf.

In the early days of Transcense, when we took Skinner to an event, he would grab a drink and go to an isolated space to check his phone. Today, in small groups, he can use the app to communicate with others. At lunch, during our internal meetings, we pull out our phones and stay connected, transcending the silence barrier. What was just my personal story now became a team story while we slowly dissolved the communication barriers within the team.


Every day, these simple moments justify our long hours of work.

But what’s ahead of us is even more exciting.

After a 3-months of beta testing with our community, we’ve seen the same pattern with our early users – we’ve changed their lives, enabling opportunities that had been closed to them so far. Incredibly high usage and impressive retention prove that we are on the right track.

So what now?

In a relentless build-measure-learn cycle, we’re staying focused on the next steps.

We are bridging the deaf/hearing communication gap, an immense mission that will take everyone’s participation to make it happen.

Lessons Learned

  • Dig deep into your customer psychology and test lo-fidelity minimum viable products, before trying to build anything
  • Track the need rather than the desire: solving somebody’s needs will help you much more
  • Eat your own dog food

Hacking For Defense In Silicon Valley

Lead, follow or get the heck out of the way

In peacetime the U.S. military is an immovable and inflexible bureaucracy. In wartime it can adapt and adopt organizational change with startling speed.

BMNT, a new Silicon Valley company, is combining the Lean Methods it learned in combat with the technology expertise and speed of startups.


But first some history…

World War II
In World War II the U.S. government reengineered its approach to building weapons. In a major break from the past, where the military designed all its own weapons, 10,000 scientists and engineers from academia worked in civilian-run weapons labs (most headquartered in universities) in an organization called the Office of Scientific Research and Development (OSRD).

OSRD was tasked to develop military weapons systems and solve military problems but had wide autonomy to determine how to accomplish its tasks and organize its labs. (The weapons were then manufactured in volume by U.S. corporations.)


The OSRD developed advanced electronics: radar, electronic warfare, rockets, sonar, proximity fuse, Napalm, the Bazooka and new drugs such as penicillin and cures for malaria. One OSRD project – the Manhattan Project  – the development of the atomic bomb – was so secret and important that it was spun off as a separate program. The University of California managed research and development of the bomb design at Los Alamos while the US Army managed the Los Alamos facilities and the overall administration of the project.

After the war the U.S. split up the functions of the OSRD. Nuclear weapons went to the new Atomic Energy Commission (AEC), basic weapons systems research went to the Department of Defense (DOD) and all U.S. biomedical and health research went back to the National Institutes of Health (NIH). In 1950, government support of basic science research in U.S. universities became the charter of the National Science Foundation (NSF). Each of these independent research organizations would support a mix of basic and applied research.

The Cold War
During the Cold War the U.S. and the Soviet Union faced off with a nuclear deterrence policy called mutually assured destruction (aptly named MAD.) But to fight a conventional war in Europe, Soviet forces had built a 3 to 1 advantage in tanks, artillery, armored personnel carriers, and soldiers. In response the U.S. developed a new strategy in the late 1970’s to counter the Warsaw Pact. Instead of matching the U.S.S.R. tank for tank or solider to solider, the U.S. saw that it could change the game and take advantage of a lead we had that was getting longer every day – using our computer and chip technology to aggressively build a new generation of weapons that the Soviet Union could not. 

At the heart of this “offset strategy” was “precision strike,” – building stealth aircraft to deliver precision guided munitions unseen by enemy radar, and designing intelligence and reconnaissance systems that would target for them. The offset strategy was smart weapons, smart sensors, and stealth using silicon chips, electronics and computers that only the U.S. could design and produce.

By the mid-1980’s the Soviet military was struggling to keep up with this “revolution in military affairs. The announcement of the Strategic Defense Initiative (Star Wars) further destabilized the Soviet Union.

The Gulf Wars
When I first started teaching customer development (searching, validating and executing a business model), one of my students pointed out that customer development was similar to the theory of a military strategist, John Boyd. In the 1960’s, Boyd, who was a fighter pilot, proposed that instead of executing a fixed plan, wars would be won by those who can Observe, Orient, Decide and Act (the OODA Loop.) After being ignored for decades, Boyd’s OODA Loop drove the U.S. war fighting strategy in both Gulf Wars. The OODA Loop was the Lean Startup philosophy before lean.

Large ooda loop

Iraq, Afghanistan and the Army’s Rapid Equipping Force (REF)
In Afghanistan in 2002 U.S. soldiers were tasked to clear caves that the Taliban used to store equipment. Many of the caves still had Taliban fighters inside while others had been booby-trapped. To clear the caves soldiers threw grappling hooks inside then pulled the hooks out to catch trip-wires and explode bombs. But often this technique did not work and soldiers died. The Army realized they needed to do something more effective. They gave the problem to Colonel Bruce Jette, and 90 days and $750,000 later he had bypassed the existing Army acquisition system and bought existing robots from companies. Exponent provided the PackBot and the Marcbot and deployed them to the field.

From that day the Army’s Rapid Equipping Force (REF) was born.

The REF’s goal is to deliver technology solutions to front-line soldiers in days and weeks, instead of months and years either by using solutions from previous REF efforts or existing government- or commercial-off-the-shelf technologies purchased with a government credit card.

The REF had permission to shortcut the detailed 100+ page requirements documents used by the defense acquisition process. It developed a ten-line short form that listed the most important parts of the requirement. The REF also had its own budget, which it could use to acquire equipment.

Soon the REF was sending teams of civilian and military subject matter experts out into the field to discover what they needed. REF expanded its operations to include forward teams in Kuwait and Iraq to provide technology to fill capability gaps and to counter the highest priority threats.

By the end of 2007, the REF had delivered more than 550 types of equipment and more than 75,000 individual items. The average time from receiving a request from the field to delivering a solution to the soldiers was 111 days.

In 2010 Colonel Peter Newell took over the REF and turned its focus into what we would call a Lean Startup. Pete Newell
Newell insisted that REF started with a deep understanding of soldiers’ problems
 before purchasing a proposed solution. Newell found that four problems accounted for two-thirds of REF requirements:

  1. defeating roadside bombs
  2. supporting soldiers on foot with communications and load carrying devices
  3. providing soldiers with timely intelligence, surveillance, and reconnaissance in combat
  4. supplying and protecting small isolated combat outposts

He came up with his version of the OODA loop to explain to people how REF should behave.

REF Problem Solving Cycle

To get closer to his customers, Newell commissioned three mobile laboratories that were airlifted to forward operating bases. These labs included a Computer Numerical Control milling machine and 3-D printers for rapid prototyping.REF Mobile Lab

Hacking For Defense (H4D)
When Colonel Peter Newell left the Army, he came to Silicon Valley at the urging of a friend and fellow retired Army Colonel, Joe Felter, a Stanford PhD who moved to Palo Alto and Stanford after a career in the Special Forces. Newell accepted Felter’s invitation to join a company he had originally established. BMNT does for the Department of Energy, the Department of Defense and the Intelligence Community what the REF did for the U.S. Army – build teams that deliver solutions to complex problems, with access to the entire network of suppliers and partners that Newell and Felter developed throughout their careers.

To tap into the innovation of Silicon Valley, BMNT, in collaboration with Stanford’s Preventive Defense Project organized Hacking For Defense (H4D) – a series of hackathons – to help the Department of Defense do four things:

  1. Identify new ideas that will solve problems the military expects to see in the future
  2. Map those ideas to the technology that could be used to solve them
  3. Recruit the people who can make it happen
  4. Show the DoD how to engage Silicon Valley with challenging problems and build networks of people to solve them

BMNT‘s first hackathon, “Hacking the Supply Chain,” brought together diverse teams of technologists and users to provide solutions to the questions: How do you supply troops which can be sent on short-notice, for long periods to places where there are no existing bases or supplies? How might we create the most resilient and efficient supply chain possible for our forward-deployed land forces in 2025?

“Hacking the Supply Chain” is focused on:

  • energy and power generation
  • potable water and field expedient sewage systems
  • advanced manufacturing and repair maintenance technologies
  • training and readiness technologies
  • command, control, computers, and communications technologies

In mid-April, the ideas generated at BMNT‘s first hackathon will be presented to a panel of experienced senior entrepreneurs, engineers, and military and government officials and then sent to the Department of Defense with specific recommendations on the technologies with potential to support them.

Ultimately Newell and Felter say they want to use BMNT to create an “insurgency” in Silicon Valley to get cutting-edge innovation into the organizations defending our country. (Click here for information on Hacking for Defense events.)

Hacking the Prime’s
In reality, what BMNT is trying to fix is the way the Department of Defense acquires radically new technology and ideas. While DARPA tries to fill that need, today the primary conduits for bringing new technology to the government are the prime contractors (e.g., Lockheed, Boeing, Raytheon, Northrup Grumman, L3, General Dynamics, et al.) But most of these contractors focus on fulfilling existing technology needs that can be profitable.

If a startup wants to provide new technology to the Department of Defense (DoD),  they have to sell through the prime contractors who own the relationships with the DoD. Most startups and innovative companies are unwilling to risk exposing their Intellectual Property and go through the paperwork of dealing with the government, so they choose not to pursue government ventures. In this way, the primes artificially restrict DoD’s technological funnel.  (Palantir is the most visible Silicon Valley insurgent in this space.)

Today, incentives for bringing innovation into the government with speed and urgency are not aligned with the government acquisition, budgeting, and requirements process. As a result, the DoD fails to acquire truly innovative technologies (much less paradigm-changing technologies) in a timely fashion.

Lessons Learned

  • In peacetime the U.S. military is an immovable and inflexible bureaucracy
  • In wartime it can adapt and adopt organizational change with startling speed
  • The Rapid Equipping Force operated with speed and urgency to deliver solutions to real customer problems
  • BMNT and Hacking for Defense are trying to bring this same process to Silicon Valley

Fear of Failure and Lack of Speed In a Large Corporation

I just spent a day working with Bob, the Chief Innovation Officer of a very smart large company I’ll call Acme Widgets.

Bob summarized Acme’s impediments to innovation. “At our company we have a culture that fears failure. A failed project is considered a negative to a corporate career. As a result, few people want to start a project that might not succeed. And worse, even if someone does manage to start something new, our management structure has so many financial, legal and HR hurdles that every initiative needs to match our existing business financial metrics, processes and procedures. So we end up in “paralysis by analysis” – moving slowly to ensure we don’t make mistakes and that everyone signs off on every idea (so we can spread the collective blame if it fails). And when we do make bets, they’re small bets on incremental products or acquisitions that simply add to the bottom line.”

Bob looked wistful, “Our founders built a company known for taking risks and moving fast. Now we’re known for “making the numbers,” living on our past successes. More agile competitors are starting to eat into our business. How can we restart our innovation culture?”


What Drives Innovation?
I pointed out to Bob the irony – in a large company “fear of failure” inhibits speed and risk taking while in a startup “fear of failure” drives speed and urgency.

If we could understand the root cause of that difference, I said, we could help Acme build a system for continuous innovation.

I suggested the best place to start the conversation is with the 21st century definition of a startup: A startup is a temporary organization designed to search for a repeatable and scalable business model.

Startups have finite time and resources to find product/market fit before they run out of money. Therefore startups trade off certainty for speed, adopting “good enough decision making” and iterating and pivoting as they fail, learn, and discover their business model.

The corollary for a large company is: A company is a permanent organization designed to execute a repeatable and scalable business model.

That means in their core business, large companies have a series of knowns. They’ve found product/market fit (what products customers want to buy). They’ve learned the best distribution channel to get the product from their company to the customer. They’ve figured out the revenue model (subscription, license, direct sale, etc.) and how to price the product. They know the activities, resources and partners (manufacturing, regulation, IP, supply chain, etc.) – and the costs to deliver the product/service and have well defined product development and product management tools that emphasize the linear nature of shipping products to existing customers. There are financial metrics (Return on Investment, Hurdle Rate, etc.) for new product development that emphasize immediate returns. And everyone has job titles and job descriptions that describe their role in execution.

Why Execution and Innovation Need Different Tools, Cultures and Organizations
Talking to Bob I realized that at Acme Widgets (and in most large companies) the word “failure” was being used to describe two very different events:

  • failure in execution of a known product in known market
  • failure in searching for innovation when there are many unknowns

Therefore, in a large company, failure to meet a goal – revenue, product delivery, service, etc.– is a failure in execution of an individual and/or organization to perform to a known set of success criteria. In corporations the penalty for repeated failure on known tasks is being reassigned to other tasks or asked to leave the company.

As I sat with Bob and his innovation team, I realized that all of Acme’s new product innovation initiatives were being held to the same standard as those of existing products. Acme was approaching innovation and disruptive product ideas using the same processes, procedures, schedules, and incentives within the same organizational structure and culture as its existing businesses.

No wonder innovation at Acme had stalled.

The Ambidextrous Organization – Execution and Innovation
That companies should be simultaneously executing and innovating isn’t a new insight. For decades others have observed that companies needed to be ambidextrous. So while we did not lack the insight that execution and innovation need to be separate, we did lack the processes, tools, culture and organizational structures to implement it. Corporate innovation initiatives have spent decades looking at other corporate structures as models for innovation when in fact we should have been looking at startups for innovation models – and adapting and adopting them for corporate use.

That’s now changed. The strategy and structure for 21st corporate innovation will come from emulating the speed, urgency, agility and low-cost, rapid experimentation of startups.

What We Now Know about Corporate Innovation
In the last five years, as the need for continuous innovation in companies has become critical, Lean innovation methodologies (Lean LaunchPad/I-Corps) have also emerged. These methods allow rapid experimentation – at startup speed – with the same rigor and discipline as traditional execution processes. Adopted by the National Science Foundation and large companies, over 1000 teams have used the process, and the resulting commercialization success speaks for itself.

But running a Lean Startup inside an organization designed for execution is an exercise in futility. Working with large corporations we’ve learned that innovation groups need their own structure, culture, tools (Lean, Design Thinking, etc.), metrics (validated/invalidated hypotheses, Investment Readiness Level) and processes. And both organizations – execution and innovation – need to understand that the success of the company rests on how well they can cooperate.

Bob’s eyes lit up as he said, “Now I understand why innovation seemed beyond our reach. We were missing four ideas:

  1. Accepting failure and running at speed are part of an innovation culture.
  2. We need to separate out innovation risks from execution risks.
  3. There are now proven Lean innovation methodologies (Lean LaunchPad/I-Corps) that we can use off the shelf in building an innovation culture without inventing our own.
  4. We need to make sure that management no longer uses execution metrics to manage and judge our innovation teams.

Lessons Learned

  • In a startup “fear of failure” drives speed and urgency
  • In a large company “fear of failure” inhibits speed and risk
  • Innovation means experimentation in searching for a business model. Often failure is the norm not the exception.
  • Innovation processes and metrics need to be different from those of the execution organizations
  • There are proven Lean innovation methodologies that work in large existing companies

I’m on the Air – On Sirius XM Channel 111

Starting this Monday, March 9th 4-6pm Pacific Time I’ll be on the radio hosting the Bay Area Ventures program on Sirius XM radio Channel 111 – the Wharton Business Radio Channel.Untitled

Over this program I’ll be talking to entrepreneurs, financial experts and academic leaders in the tech and biotech industries. And if the past is prologue I guarantee you that this will be radio worth listening to.

On our first show, Monday March 9th 4-6pm Pacific Time join me, as I chat with Alexander Osterwalder – inventor of the Business Model Canvas, and Oren Jacob, ex-CTO of Pixar and now CEO of ToyTalk on Sirius XM Radio Channel 111.

Oren Jacob - CEO ToyTalk

Oren Jacob – CEO ToyTalk

Alex Osterwalder - Business Models

Alex Osterwalder – Business Models

On Monday’s show we’ll be talking about a range of entrepreneurship topics: what’s a Business Model Canvas, how to build startups efficiently, the 9 deadly sins of a startup, the life of a startup CEO, how large companies can innovate at startup speeds. But it won’t just be us talking; we’ll be taking your questions live and on the air by phone, email or Twitter.

On April 27th, on my next program, my guest will be Eric Ries the author of the Lean Startup. Future guests include Marc Pincus, founder of Zynga, and other interesting founders and investors.

Is there anyone you’d like to hear on the air on future shows? Any specific topics you’d like discussed? Leave me a comment.

Mark your calendar for 4-6pm Pacific Time on Sirius XM Radio Channel 111:

  • March 9th
  • April 27th
  • May 11th
  • June 29th
  • July 13th
  • Aug 24th in NY

Blowing up the Business Plan at U.C. Berkeley Haas Business School

During the Cold War with the Soviet Union, science and engineering at both Stanford and U.C. Berkeley were heavily funded to develop Cold War weapon systems. Stanford’s focus was Electronic Intelligence and those advanced microwave components and systems were useful in a variety of weapons systems. Starting in the 1950’s, Stanford’s engineering department became “outward facing” and developed a culture of spinouts and active faculty support and participation in the first wave of Silicon Valley startups.

At the same time Berkeley was also developing Cold War weapons systems. However its focus was nuclear weapons – not something you wanted to be spinning out. nuclearSo Berkeley started a half century history of “inward facing innovation” focused on the Lawrence Livermore nuclear weapons lab. (See the presentation here.)

Given its inward focus, Berkeley has always been the neglected sibling in Silicon Valley entrepreneurship. That has changed in the last few years.

Today the U.C. Berkeley Haas Business School is a leader in entrepreneurship education. It has replaced how to write a business plan with hands-on Lean Startup methods. It’s teaching the LaunchPad® and the I-Corps for the National Science Foundation and National Institutes of Health, as well as corporate entrepreneurship courses.haas logo

Here’s the story from Andre Marquis, Executive Director of Berkeley’s Lester Center for Entrepreneurship.


When I came to U.C. Berkeley in 2010 to run the Lester Center for Entrepreneurship in the Haas School of Business we were teaching entrepreneurship the same way as when I was a student back in 1995. Our core MBA class used the seminal textbook New Venture Creation by Jeffrey Timmons of Babson College that was first published in 1977. The final deliverable for that class was a 30-page business plan. We had multiple business plan competitions. As I looked around at other schools, I saw pretty much the same landscape – business plan classes, business plan competitions and loosely coupled accelerators that focused primarily on mentoring.

Over my career as a serial entrepreneur I observed that since the late 1990s, no early-stage Silicon Valley investor had used business plans to screen investments. Even those who asked for them never read them. Traction and evidence from customers were what investors were looking for – even in “slow” sectors like healthcare and energy. There had been tectonic shifts in the startup world, but our business school curriculum had barely moved.

There was a big gap in our educational paradigm. To create great entrepreneurs, we had to give our students the experience of navigating the chaos and uncertainty of running a lean startup while providing the same kind of rigorous framework the business plan did in its day. The advantage of following New Venture Creation is that it had a deep pedagogical infrastructure that students took away after they left school. The disadvantage is that its methodology was based on the old waterfall model of product development and not the agile and lean methods that startups use today.

As I began my search to increase the relevance of our entrepreneurship curriculum with the same rigor as Timmons and New Venture Creation, I found the answer right here at Berkeley, in Steve Blank’s Lean LaunchPad class.

(Our founding Executive Director Jerry Engel, recently retired to become dean of faculty for the National Science Foundation I-Corps, had a tradition of incorporating leading practioners, like Steve. These ‘pracademics’ proved to be some of the biggest innovators in entrepreneurship education.)

Seeing Is Believing
The Lean LaunchPad class was completely different from a traditional entrepreneurship class. It taught lean theory (business model design, customer development and agile engineering) and practice.

Every week, each student team stood in front of the class and presented their business model hypotheses, what they had learned from talking to customers, demo’d their minimal viable products and had to explain what they were going to do next. Steve and the venture capitalists at the back of the room relentlessly peppered them with questions and pushed them to get out of the building and call on the real decision-makers instead of talking to people they already knew. Some teams stepped down from the podium proud that they had made real progress that week while others were chastised because they stuck to their comfort zone, were not doing the tough work required by entrepreneurs and on the road to failure.

I realized this class was teaching students exactly what it felt like to be an entrepreneur! Great entrepreneurs are on a search for the truth, no matter how wrong their initial conception is. Being an entrepreneur is about starting out with no idea whether you are working on the next big thing or something no one wants and certainly no one will pay for. It’s struggling to find the right path forward through chaos and uncertainty. Killing bad ideas quickly and moving on. Staring at the phone while mentally wrestling to pick it up to make that next cold call. It’s having investors tell you that you’re dead wrong and, perhaps with enough customer traction, showing them the path to a new future neither of you could see at the time.

And there it was. The Lean LaunchPad was unlike any class I’d ever seen.

As a Silicon Valley entrepreneur I had lived the lean approach, yet I had never seen it taught. Done informally as part of an accelerator, yes, but not with a framework based on a clear process and clear pedagogy. The Lean LaunchPad was teaching students concepts and a process that they took away from the class and could use again for their next startup. I realized I was looking at a paradigm shift in entrepreneurial education – away from the business plan-focused model to a Lean Startup model. (The irony is that once you’ve gone through the lean cycle, you have all the information that goes in a business plan: customers, sales strategy, product features, and financial metrics. It’s just that they are validated instead of made up.)

The Business Plan is Dead
Now, 4 years after I arrived at BerkeleyHaas, we don’t teach business plan writing in any of our entrepreneurship classes or in any of our dozens of programs and competitions. We use Customer Development and the Lean LaunchPad to train and accelerate teams U.C. Berkeley-wide.

We’ve gone global as well. In the past year alone, we’ve taught over 250 teams, over 1,000 entrepreneurs and their mentors in dozens of countries how to create scalable startups in domains from software and hardware to healthcare and energy.

Haas global footprint

Haas global footprint

The international teams watch the lectures online, get out of the building, present to us each week via WebEx and get the same brand of relentless and direct feedback their U.C. Berkeley peers got in Steve’s class. For example, our Intel Technology To Market Accelerator took 22 teams from 11 countries across 15 time zones, from northern Russia to southern Chile and from Saudi Arabia to the U.S. (Chicago) through the Lean LaunchPad process. Clearly, lean works globally.

And we’ve been part of the U.S. effort to use the Lean LaunchPad to accelerate commercialization for the country’s best research spinouts from the National Science Foundation and National Institutes of Health. We do this by running classes for the NSF Innovation Corps and The I-Corps at the NIH. And the same lean techniques work just as well in the corporate innovation programs we run such as the Intel Make It Wearable Challenge.

An important distinction is that these programs are accelerators. The teams in them start with an idea or product, meet with customers, build prototypes and search for a scalable business model. All declare their startup a “go” or “no go” at the end. They learn it’s all about building to scale, pivoting or declaring failure, and moving on using a hypothesis-driven search for the truth.

Even our venerable 15-year old business plan competition, once dubbed “bplan,” has transformed into LAUNCH, a multi-month accelerator with a rigorous process combining the Lean LaunchPad, agile product development and a focus on measurable Lean Analytics. Ironically, LAUNCH has turned out to be much more rigorous than the prior business plan competition because we immerse every entrepreneur and their mentors in conquering the chaos and uncertainty that is normal for startups. We expect them to come out with specific knowledge of their markets and business ecosystem, verified metrics, a product and a plan for moving forward based on interacting with their actual customers – not honing the teams for a beauty pageant-like pitch fest or making them produce a business plan that’s fundamentally speculative. As educators, we are having a deep impact on these entrepreneurs and their startups.

Lean LaunchPad Works Across Industries
I often hear the concern that the Lean LaunchPad only works for software. After 700 teams in robotics, materials, hardware, therapeutics, diagnostics, medical devices, and enterprise software, it’s clear that Lean Startup methods work across all industries. We’ve taught versions of the Lean LaunchPad for life sciences at UCSF and as part of the National Institutes of Health, for hardware-focused startups making wearable devices as part of the Intel Make It Wearable Challenge, for teams working on nanotechnology and in education (STEMKids and Build and Imagine). Two of our BerkeleyHaas Faculty, Jorge Calderon and Will Rosenzweig, created a Social Lean LaunchPad class that embraces the mission and stakeholders central to social ventures.

Whether it’s making iPhone apps or medical devices, every startup is looking for a repeatable and scalable business model. Focusing on finding customer needs, figuring out how they buy and how to scale up product delivery are universal.

Where We Are Going From Here
At U.C. Berkeley we’ve undergone a complete transformation in just four years. But the longer journey is to continue to build new lean-tools and classes separate from the 40 year-old, business plan-based tradition.

We continue to ask ourselves, “What can we do to get our students out of the classroom, in cross-functional teams, building for specific customers and having the experience of making hard decisions under conditions of uncertainty? What can we do to expand and deepen the rigor of the Lean Startup methodologies and fully elaborate our curriculum?”

At BerkeleyHaas we are sharing what we are learning (see below). By embracing lean, you can be assured you will be giving your students essential innovation skills they will use for the rest of their lives. You will see great startups focused on solving real customer problems emerge as well. This is an exciting journey and we are all right at the start.

Some resources for shifting the paradigm in your organization:

Lessons Learned

  • Early-stage investors don’t read business plans
  • We are in the middle of a shift in entrepreneurship education from teaching the waterfall model of startup development (enshrined in business plans) to teaching the lean startup model
  • The Lean LaunchPad process works across a wide range of domains – from science and engineering to healthcare, energy, government, the social sector and for corporate innovation
  • Customer Development works outside Silicon Valley. In fact, it works globally
  • The Lean LaunchPad is a business process that teaches entrepreneurs and innovators to make business-focused, evidence-based decisions under conditions of chaos and uncertainty. It’s a big idea

Get every new post delivered to your Inbox.

Join 195,897 other followers