Episode 5 on Sirius XM Channel 111: Pete Newell, John Kuhn, Matt Weingart, Takashi Tsutsmi and Masato Iino

My guests this past week on Bay Area Ventures on Wharton Business Radio on Sirius XM Channel 111 were:

Listen to the full interviews by downloading them from SoundCloud here, here, here and here(And download any of the past shows here.)

The focus of our first segment is how Silicon Valley and the U.S. military can work together – for access to advanced technology and to learn how to move with agility, speed and urgency. Our guests Pete Newell, John Kuhn and Matt Weingart served for decades in the U.S. military and are now helping government agencies operate with the speed and urgency of Silicon Valley.

Pete Newell retired from the US Army in 2013 as the director of the Rapid Equipping Force (REF), responsible for rapidly understanding problems of soldiers in combat and rapidly providing solutions. Pete NewellPete directed the investment of over $1.4B to these efforts over a three-year period. He was named by Defense News as one of the 100 most influential people in the defense industry in 2012. (Read the Stanford case study about the Rapid Equipping Force.) Pete is managing partner for BMNT Partners and serves on the Board of Directors for Solace Power and Savonix. He is a frequent contributor to Defense Innovation studies, is a member of the Center for a New American Security’s Beyond Offset Working Group and most recently supported a study on Defense Innovation for the Center for Strategic and International Studies.

Listen to my entire chat with Pete

If you can’t hear the clip, click here

Or, click on the links to hear Pete discuss:

If you can’t hear Pete discuss Meeting the Army Robotics Guy, click here

If you can’t hear Pete discuss the Origin of the Army’s REF, click here

If you can’t hear Pete discuss What BMNT Does, click here

If you can’t hear Pete discuss Talk About the Problem Not the Technology, click here

John Kuhn served 20 years in U.S. Army special operations before retiring from active duty service in 2014. john kuhn civilianDuring his military career he served in Bosnia, Afghanistan, Iraq, the Arabian peninsula, Egypt, and the Horn of Africa. John was awarded the Silver Star; six Bronze Stars, including one for valor; an Army Commendation Medal for valor; and two Purple Hearts. John recently co-founded P360, a business that produces animated training content for the military, and he works for BMNT Partners.

Listen to my entire chat with John

If you can’t hear the clip, click here

Or, click the links below to hear John discuss

If you can’t hear John discuss Military Skills that Translate, click here

If you can’t hear Hacking for Defense Explained, click here

If you can’t hear John discuss his Business to Government class, click here

If you can’t hear John discuss his Advice for Other Veterans, click here

Matt Weingart is a program development manager in the Strategic Development Office at the Department of Energy’s Lawrence Livermore National Laboratory. He connects the Lab with the defense user community.  His responsibilities include establishing the partnership frameworks between government, private sector, and academia needed to deliver end-use solutions to national security challenges (cybersecurity, undersea warfare, communications, etc.)

Listen to my entire chat with Matt

If you can’t hear the clip, click here

Or, click on the links below to hear Matt discuss

If you can’t hear Matt discuss Defense Valley, click here

If you can’t hear Matt discuss Self-Selecting Like an Entrepreneur, click here

If you can’t hear Matt discuss The Nation is Upside Down, click here

If you can’t hear Matt discuss Strategic Deterrence, click here

If you can’t hear Matt discuss Grist for the Innovation Mill, click here

In this second segment, Takashi Tsutsumi and Masato Iino talk about how they brought the Lean Startup to Japan. Today they are helping large companies in Japan relearn how to innovate at speed.

Takashi Tsutsumi has been a venture capitalist 15 years incubating and investing in startups in Japan. Prior to that, he worked for an integrated trading company in which he built several new businesses by collaborating with high-tech startups in California.

Masato Iino has been entrepreneur of a couple of startups and an investor for the last twenty years. Prior to that, he worked for the Industrial Bank of Japan and General Electric specializing in deliberative trading, private equity investment, and post merger integration.

Takashi and MasatoTakashi and Masato founded Learning Entrepreneur’s Lab (LEL) in 2014. This seed accelerator uses my Lean LaunchPad class to help incubate startups as well as create new business for enterprises in Japan. Learning Entrepreneur’s Lab is the leader in evangelizing Customer Development/Lean Startup in Japan, being active in lecturing and publishing books including Japanese translations of my books, The Four Steps to the Epiphany and The Startup Owner’s Manual.

Listen to my entire chat with Takashi and Masato

If you can’t hear the clip, click here

Or, click on the links below to hear them discuss

If you can’t hear Tsutsumi and Masato discuss Going Lean In Japan, click here

If you can’t hear Tsutsumi and Masato discuss Lean in Large Companies in Japan, click here

If you can’t hear Tsutsumi and Masato discuss How Failure is Regarded in Japan, click here

If you can’t hear Tsutsumi and Masato discuss What Doesn’t Translate for Startups in Japan, click here

Listen to all four full interviews by downloading them from SoundCloud here, here, here and here(And download any of the past shows here.)

Lean Innovation Management – Making Corporate Innovation Work

I’ve been working with large companies and the U.S. government to help them innovate faster– not just kind of fast, but 10x the number of initiatives in 1/5 the time. A 50x speedup kind of fast.

Here’s how.

Lean Innovation Management
In the last five years “Lean Startup” methodologies have enabled entrepreneurs to efficiently build a startup by searching for product/market fit rather than blindly trying to execute. Companies or Government agencies pursuing innovation can Buy, Build, Partner or use Open Innovation. But trying to find a unified theory of innovation that allows established companies and government agencies to innovate internally with the speed and urgency of startups has eluded our grasp.

The first time a few brave corporate innovators tried to overlay the Lean tools and techniques that work in early-stage startups in an existing corporation or government agency, the result was chaos, confusion, frustration and ultimately, failure. They ended up with “Innovation Theater” – great projects, wonderful press releases about how innovative the company is – but no real substantive change in product trajectory.


In working with Greg Hannon, the head of Innovation at W.L. GoreI’ve found two corporate strategy tools developed by other smart people helpful in bridging Lean Startups with Corporate Innovation. The first, the notion of the “ambidextrous organization” from O’Reilly and Tushman, posits that companies that want to do continuous innovation need to execute their core business model while innovating in parallel. In other words, in an ambidextrous company you need to be able to “chew gum and walk at the same time.”

The second big idea of corporate innovation is the “Three Horizons of Innovation” from Baghai, Coley and White. They suggest that a company allocate its innovations across three categories called “Horizons.”

  • Horizon 1 are mature businesses.Three horizons
  • Horizon 2 are rapidly growing businesses.
  • Horizon 3 are emerging businesses.

Each horizon requires different focus, different management, different tools and different goals.

The Three Horizons provided an incredibly useful taxonomy. However in practice most companies treated the Three Horizons like they are simply incremental execution of the same business model.

While these theories explain how to think about innovation in a company they didn’t tell you how to make it happen.

Fast forward to today. To move innovation faster, we now have 21st century tools —Business Model Canvas, Customer Development, Agile Engineering – all adding up to a Lean Startup. We can adapt these startup tools for use inside the corporation.

HBR Lean Startup articleTo do so we’ll keep the concept of three unique horizons of innovation but reframe and combine them with what we’ve learned about Lean Startups. The result will be:

  • a new, Lean version of the Three Horizons of Innovation
  • an ambidextrous company, and
  • a way for existing organizations to build and test new ideas at blinding speed.

The Lean Definition of the Three Horizons of Innovation
In this new model, the Horizon level of innovation is defined by whether the business model is being executed or searched for.

  • Horizon 1 activities support existing business models.horizons with Bus Model
  • Horizon 2 is focused on extending existing businesses with  partially known business models
  • Horizon 3 is focused on unknown business models.

Horizon 1 is the company’s core business. Here the company executes a known business model (known customers, product features, competitors, pricing, distribution channel, supply chain, etc.) It uses existing capabilities and has low risk in getting the next product out the door. Management in this Horizon 1 works by building repeatable and scalable processes, procedures, incentives and KPI’s to execute and measure the business model. (And if they’re smart they’ll teach Horizon 1 teams to operate with mission and intent, not just process and procedure.)

Innovation and improvement occurs in Horizon 1 on process, procedures, costs, etc. Product management for Horizon 1 uses existing product management tools such as StageGate® or the equivalent.prod mgmt for Horizon 1

In Horizon 2 a company/agency extends its core business. Here the company looks for new opportunities in its existing business model (trying a different distribution channel, using the same technology with new customers or selling existing customers new products, etc.) Horizon 2 uses mostly existing capabilities and has moderate risk in getting new capabilities to get the product out the door. Management in Horizon 2 works by pattern recognition and experimentation inside the current business model.

Horizon 3 is where companies put their crazy entrepreneurs. (Inside of companies these are the mavericks you want to fire for not getting with program. In a startup they’d be the founding CEO.) These innovators want to create new and potentially disruptive business models. Here the company is essentially incubating a startup. They operate with speed and urgency to find a repeatable and scalable business model. Horizon 3 groups need to be physically separate from operating divisions (in a corporate incubator, or their own facility.) And they need their own plans, procedures, policies, incentives and KPI’s different from those in Horizon 1.

Product management for Horizon 2 and 3 uses existing Lean Innovation Management tools such as Lean LaunchPad®, the NSF I-Corps™ or the equivalent. prod mgmt for Horizon 3Using these tools internally a company/agency can get startup speed and urgency. Horizon 3 organizations organized as small (<5 person) teams can talk to 100+ customers in 10 weeks and deliver a series of iterative and incremental minimal viable products.  Given the minimum size of these teams and expenditures, companies can afford to run a large number of these initiatives in parallel.

Get to Yes
Horizon 2 and 3 activities are not entirely separated from the corporate structure. Get to YesTo help Horizon 2 and 3 organizations navigate all the processes, procedures and metrics the company has built to support Horizon 1 activities, individuals from support organizations (legal, finance, procurement, etc.) are assigned to work inside Horizon 3 organizations. Their function is to help Horizon 2 and 3 organizations navigate to a “Yes” inside the company.

Horizon 1 operates on goals and incentives. And Horizon 1 managers need to be incented to embrace and support innovation going on in Horizons 2 and 3. Companies need their Horizon 1 managers to both encourage mavericks to propose projects, as well as to support mavericks and then incentive for adoption and scale of Horizon 3 projects.

If supporting Horizon 2/3 is not part of Horizon 1 goals and incentives, then there is no real commitment to corporate innovation.

Oh no! Yes! We’ve Succeeded
What happens to successful innovations from Horizons 2 and 3? innovation becomes executionThey either get adopted by a Horizon 1 organization (a division, P&L, functional organization,) they reach a size large enough to become a standalone group or they can be sold/spun out. To make this work Horizon 1 execs and managers need incentives and job descriptions to support Horizon 2 and 3 activiities.

One of the biggest complaints from Horizon 1 managers is that successful Horizon 3 innovation projects leave a mess of technical and organization debt that a Horizon 1 organization has to clean up. refactoringThis isn’t some exception; in fact it’s a natural part of corporate innovation.

What is missing is the realization that there needs to be a dedicated corporate group to refactor (cleanup) the debt from successful innovation projects.

Do it Again!?
When a Horizon 2 or 3 program finds success, it can either grow on its own (and hence become their own divisions) or the founders and early employees may get folded back into a Horizon 1 organization that will scale the program. Typically this is a bad idea for all involved. In short-sighted companies the Horizon 2 and 3 innovators get frustrated, and leave. Do it againIn far-sighted companies they get to start a new cycle of disruptive innovation.

Lean Is the Language of Corporate and Government Agency Innovation
We have a common language and process for execution–product management tools, financial reporting etc. Yet we have no common language and process for innovation and searching for business models.

We can adopt the Lean Vocabulary–Business Model Canvas, Customer Development, Hypotheses, Pivots and Minimum Viable Products and Evidence-based entrepreneurship as the corporate language of “search versus execution.” And we can use Lean Metrics (Investment Readiness Level and Technology Readiness Levels) and Lean Portfolio management tools to provide rigor to go/no go funding decisions. Finally we can use the open-source lean classes from the National Science Foundation I-Corps and the Stanford/Berkeley Lean LaunchPad classes to run Horizon 3 projects.

Lean is The Engine for the Ambidextrous Organization
An ambidextrous company or government agency runs large numbers of Horizon 2 and 3 projects simultaneously while relentlessly improving the way it executes its current business model and serves its existing customers. This happenLean Innovation Mgmts when the C-level executives share a common strategic intent, a common vision, explicit values and identity, and they are compensated for both execution of the current business model and the search for new ones. They also realize that operating at all three horizons will require them to tolerate and resolve conflicts.

Lessons Learned

  • Corporate and Government Agency Innovation needs Lean tools
  • When combined with the business model canvas, the Three Horizons of Innovation provide a framework for corporate innovation\
  • Horizon 2 and 3 (new/disruptive innovation) are run with Lean Startup speed and organization
  • Lean Innovation management combines Three Horizons of Innovation with the Lean Startup to deliver an Ambidextrous Organization
  • The entire organization must be incented to value and embrace not only continuous improvement but also successful innovations
  • Result: 10x the number of initiatives in 1/5 the time

Organizational Debt is like Technical debt – but worse

Startups focus on speed since they are burning cash every day as they search for product/market fit. But over time code/hardware written/built to validate hypotheses and find early customers can become unwieldy, difficult to maintain and incapable of scaling. These shortcuts add up and become what is called technical debt. And the size of the problem increases with the success of the company.

You fix technical debt by refactoring, going into the existing code and “cleaning it up” by restructuring it. This work adds no features visible to a user but makes the code stable and understandable.

While technical debt is an understood problem, it turns out startups also accrue another kind of debt – one that can kill the company even quicker – organizational debt. Organizational debt is all the people/culture compromises made to “just get it done” in the early stages of a startup.

Just when things should be going great, organizational debt can turn a growing company into a chaotic nightmare.

Growing companies need to understand how to recognize and  “refactor” organizational debt.

I had lunch last week with Tom, the CEO of a startup that was quickly becoming a large company – last year’s revenue was $40M, this year likely to be $80M maybe even $100 million in ad revenue. They had reinvented a traditional print media category onto web and mobile devices for a new generation of users who were no longer buying magazines but reading online. Their content was topical, targeted and refreshed daily. Equally important their VP of Marketing had brilliantly executed a stream of social media campaigns (Facebook likes and partnerships, email campaigns, etc.) to drive traffic to their site, which they then turned into ad revenue.

Tom was excited about their next big round of funding that valued them at almost ½ a billion dollars. He talked about how they were trying to maintain their exponential growth and told me how many people they were adding, and the issues of scaling that rapidly. (They had doubled headcount from 100 to 200 in the last year and were planning to double again.) While he kept bringing the conversation back to their big valuation I tried to steer the conversation back to how they were going to deal with:

  • training the influx of new hires – in both culture and job specific tasks
  • retaining their existing hires who were working for intern-like salaries with little equity.

His answer centered on the great location of the new building, what great furniture they were getting, and the compensation plans for the key members of the executive staff.

This didn’t feel good.

They’ve Never Run A Company
Since the meeting had been a courtesy to Phillipe, one of their VC board members, I grabbed coffee and asked him what scaling challenges he saw for the company. I was taken aback when I got a reply that sounded like VC buzzword bingo – phrases like “They’re a platform not a product” and the ever popular “they’re a potential Unicorn.”

While the strategy sounded like a great long-term plan, I poked a bit and asked, “So what’s the training and onboarding plan for the new hires? What are you doing about the pay scales at the bottom of the organization? Aren’t you concerned about losing qualified people that the company spent the last few years training but never compensated adequately?” I got answers that sounded like the Tom’s – new stock grants for the executive staff, great new building, and oh, by the way, Tom and his co-founder got to sell some stock in the new round. And let me tell you about the vision and strategy again.

As Phillipe kept talking I listened but not really, because I started realizing that while he was a genius in finding and nurturing great early-stage deals, and had a vision that sounded great for the new investors, he didn’t have a clue about how to actually scale a company. He had never run one, and worse, had never been on a board of a startup making the transition from searching for a business model and product/market fit, to the next phase of “building” the infrastructure to support scale.

Unless they were planning to flip this company, organizational debt was going to hit faster than they could imagine. They needed a plan to “refactor” organizational debt. And Tom wasn’t going to get it from his board.

Focus on Bottoms Up as well as top Top Down
While the company had a great plan for keeping the top executives, and had all the startup perks like free food and dogs at work, they had spent little time thinking about the organization debt accruing with first 100 employees who had built the company underneath them. These were the employees that had the institutional knowledge and hard-earned skills. Originally they had been attracted by the lure of being part of a new media company that was disrupting the old, and were working for low salaries with minimal stock. And while that had been enough to keep their heads-down and focused on their jobs, the new funding round and onslaught of new employees at much higher salaries had them looking around and updating their resumes.

Surprisingly, given the tidal wave of new hires, formal training and job descriptions were still stuck in the early stage, “we’re too small to need that” mindset. The reality was that with hundreds of new employees coming on board the company desperately needed a formal onboarding process for new employees; first, to get them assimilated to the company culture and second, a formal process to train them in how to do their specific jobs. Unfortunately the people who could best train them were the underpaid employees who were now out looking for new jobs.

Organizational debt was coming due.

Organizational debt circled

“Refactoring” organizational debt
I had promised Tom the CEO we’d grab coffee again. When we did, I asked him about his head of HR, and heard all about what great medical and insurance benefits, stock vesting, automated expense account forms, movie night, company picnics, etc., the company had. I offered that those were great for an early-stage company, but it was time to move to a new phase (and perhaps a new head of HR.) Since Tom was an engineer I explained the “Organizational Debt” metaphor. He got it instantly and before I could even suggest it, he asked, “So how do I refactor organizational debt?”

I suggested that were seven things he could do – some quickly, some over time:

  1. Put together a simple plan for managing this next wave of hiring. Tell each hiring manager:
  • No new hires until you write/update your own job description.
  • Next write your new hire job description.
  • Next write how you will train new hire(s) in their functional job.
  • Next write how their job fits into each level upward and downward
  • And how it supports the mission of each level upward and downward
  1. Realize his expense plan is too low. I offered that it appeared he put together an expense budget using current employee salaries. If so, he was in danger of losing the people he most cared about keeping. He should stop thinking about 10% raises and start thinking about what he’d have to pay to replace employees who hold critical knowledge and train new ones. It felt to me more like 50% raises in quite a few cases.
    He needed to have his head of HR:
  • Do a salary survey of existing employees and industry comparables
  • Identify the employees they wanted to keep
  • Upgrade their salaries and equity ASAP

Some of the harder suggestions had to do with the organization as whole:

  1. He needed to consider refactoring some of the original hires and their roles. Some employees don’t scale from “Search” to this new phase of “Build”. Some because they are performance problems, or don’t fit a bigger organization, attitude etc. Some of these may be friends. Leaving them in the same role destroys a sense of what’s acceptable performance among new employees.  This is hard.
  2. In addition to refactoring the people, it’s time to relook at the company culture. Do the cultural values today take into account the new size and stage of the organization? What are the key elements that have “made it great” so far? Are they the same? different? how? why? It may be time to re-visit what the company stands for.
  3. Now that the company no longer fits in a conference room or even the cafeteria, it needs a way to disseminate information that grows with the organization. At times, this requires the same messages being repeated 4 or 5 times to make up for the fact the CEO isn’t always delivering them personally. Emphasize in the corporate messaging that while it is a period of rapid change, the company culture will be an anchor that we can rely upon for orientation and stability
  4. Does customer communication need to change? In the past any customer could talk to Tom or expected Tom to talk to them.  Is that feasible? Desirable?
  5. Finally, since this is new territory for Tom and board, create an advisory board of other CEOs who’ve been through the “build” stage from a startup to growing company.

Lessons Learned

  • Companies lucky enough to get to the “build” phase have a new set of challenges
    • They’re not just about strategy
    • It’s about fixing all the organizational debt that has collected
  • Onboarding, training, culture, and compensation for employees at the “build” phase all require a fresh look and new approaches
  • Failing to refactor organizational debt can kill a growing company

Episode 3 on SiriusXM Channel 111: Kathryn Gould, Mar Hershenson, Sophie Lebrecht

My guests this week on Bay Area Ventures on Wharton Business Radio on SiriusXM Channel 111 were:Untitled

  • Kathryn Gould co-founder of Foundation Capital
  • Mar Hershenson co-founder of the VC firm Pejman Mar Ventures
  • Sophie Lebrecht co-founder and CEO of Neon Labs

Listen to their interviews by downloading them from SoundCloud here, here and here(And download any of the past shows here.)

All three of my guests started their careers as scientists or engineers and ended up starting companies or venture capital firms.

Kathryn Gould is the co-founder of the VC firm, Foundation Capital and the owner of Battle Mountain Vineyard. kathryn gouldAs one of the first women VC’s in Silicon Valley she founded Foundation in 1995, and went on to be selected for the Midas List based on her investments. Since retiring from Foundation in 2006, Kathryn has helped MicroVC firms: Floodgate, Pejman Mar and Engineering Capital raise money and get started. In 2009 she and her husband started Battle Mountain Vineyard, where they make premium Cabernet wine.

Click on the links to listen to Kathryn Gould answer the questions:



mar hershensonMar Hershenson is the Founding Partner at Pejman Mar Ventures. With her PhD in Electrical Engineering from Stanford, Mar taught the Analog Circuit Design course at Stanford for over a decade. She has co-founded three companies and been awarded both the T35 Young Innovator Award by MIT for her technical work and the Marie R. Pistilli Women in EDA Achievement Award for her work in design automation.

Click on the links to listen to Mar Hershenson answer the questions:


sophie lebrechtSophie Lebrecht has her PhD in Cognitive Science from Brown University, and is currently the CEO and Co-Founder of Neon Labs where she has continued her innovative work extracting and ranking images that are best at attracting online clicks. Neons proprietary science has unlocked the answer to how the human brain responds to images and how that response translates to increases in audience engagement and monetization of visual content. Sophie was named as one of Fast Company’s 100 most creative people in business.

Click on the links to listen to Sophie Lebrecht answer the questions:


Listen to all three interviews by downloading them from SoundCloud here, here and here(And download any of the past shows here.)

Tune in on SiriusXM Channel 111 Monday June 29th 4pm PST/7pm EST for our next interesting program – Hacking for Defense in Silicon Valley.

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 love.build 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 Boost.vc 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
%d bloggers like this: