Innovation @ 50x in Companies and Government Agencies

I’ve spent this year working with corporations and government agencies trying to adapt and adopt Lean Methodologies.  In doing so I’ve learned a ton from lots of people. I’ve summarized my learnings in this blog post, and here and here and here and put it all together in the presentation below.

if you can’t see the presentation click here.

But the biggest surprise for me was getting schooled on how extremely difficult it is to be an innovator inside a company of executors.  More on that in the next post.

Graphic recording - SteveBlank - Innovation at 50x - Trent Wakenight OGSystems 20150814

Episode 1 on Sirius XM Channel 111: Alexander Osterwalder and Oren Jacob

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

—–

The focus of our first segment was on Alexander Osterwalder’s Business Model Canvas – how and why he created it and how startups and large companies are using it to search for repeatable, scalable business models.

Alexander Osterwalder co-founded Strategyzer, a software company specializing in tools and content for strategic management and innovation.Osterwalder
He is also author of the international best-seller Business Model Generation, and inventor of the management tool, the Business Model Canvas, used by companies like Coca Cola, GE, and LEGO to design, test, build and manage their business models.

Listen to my entire chat with Alexander here:

If you can’t hear the interview, click here

Click the links below to hear Alexander

What’s the Business Model Canvas?
“It’s basically a visual template that allows you to create a shared language and it gets your idea out of your head onto the poster or a piece of paper to make it crystal-clear. … You capture the idea, you tell the story very quickly on one piece of paper. Then the Lean Startup comes in … you take this one piece of paper and then immediately go test it out. You start rough, you test quickly and you refine only when you have more evidence from the market that your idea could work.”

If you can’t hear the clip, click here

Why Understand Customers?
“We think we need to come up with some kind of prototype first, but first we need to select which customers we’re going to address and we need to deeply understand them. … You don’t want to work for just any kind of customers, but customers that have a budget, that are willing to buy from you. Because at the end of the day a business model only survives if it can be profitable.”

If you can’t hear the clip, click here

Why Test Your Idea?
“You really need to understand first what customers actually want. Because customers don’t care about your idea. … We tend to fall in love with our ideas, but you need to test your ideas. Do your customers want your value proposition? Do the channels you imagine to reach these customers actually want to work with you? The partners you might need to co-create a product — they might not want to work with you. You need to figure out all these things and you need to get hit by reality very quickly —  do a reality check — if your idea could really be turned into a business.”

If you can’t hear the clip, click here

Why Do Big Companies Use the Business Model Canvas?
“They really want to have a shared language across the company to better describe how they’re creating value for their business and how they’re creating value for their customers.”

If you can’t hear the clip, click here

What Are the Surprises When You Work With Big Companies?
“Leadership buy-in is actually not a big issue. Leaders do buy into this and they do want to change the way companies work. The biggest struggle is actually to get the buy-in of middle management — of the people who do the operational work, have huge to do lists, have daily tasks — to get them to adopt a new innovation mindset. … The other thing that still is a surprise to me is that large companies still write business plans for innovation projects. So business plans make a lot of sense in execution, but that they still do this for innovation projects. That blows my mind because …  managers who have to do these business plans don’t believe in them. They all know they’re made up. But large companies continue to ask for business plans.”

If you can’t hear the clip, click here

In our second segment, we’ll talk with Oren Jacob, former CTO of Pixar, now co-founder and CEO of ToyTalk. oren jacobOren talks about what it was like to leave Pixar, where he worked for more than 20 years, to launch a new business.
He offers a candid look at the trials of being a startup founder, including what happens when your product doesn’t work as you thought it would.

Listen to my entire chat with Oren here

If you can’t hear the interview, click here

Click the links below to hear Oren discuss

Advice for Changing Career Course
“If I was not in a position where I could spend a couple of months not working … probably the right thing to do was to spend some evenings with a partner of mine to think about what to work on next and try to dabble in some places until something had enough customer validation that I got excited about it. … (however) At some point you kind of just got to quit.”

If you can’t hear the clip, click here

Where Did the Idea for ToyTalk Come From?:
ToyTalk came about when my daughter, Toby, was 7 at the time. She was on a Skype call with Grandma using an iPhone 2 or 3. … We got off the Skype call with Grandma. We’re in the playroom in my house and Toby holds the phone, looks me, then looks at all the pile of the toys on the shelf and looks at me again and asks, ‘Daddy can I use this to talk to those?’ ”

If you can’t hear the clip, click here

What Was Value Proposition Design?
“Finding what they were looking for their customers and their products and what made sense to them was very important.”

If you can’t hear the clip, click here

What Happens When the Product Doesn’t Work?
“In a closed acoustic environment… it’s a brilliant idea. It works perfectly well. … (however) We ended up in several people houses with our talking teddy bear chatting with Oprah on TV — which is funny, but not a product — and we were unable to control the product experience at all. So our product actually broke in testing. … We were actually within four weeks of legitimately launching and we had to actually bury it in a board meeting several weeks before launch. … It was a very difficult day.”

If you can’t hear the clip, click here

How Do You Handle a Pivot?
We met with the company the next morning at 10 am and said, ‘Well, we’re not bringing this to market.’ At the time, as is often the case, the folks you’re working with are sometimes a little bit ahead of where the CEO is and they’re kind like, “Whew that wasn’t going to work anyway.’ … You know it’s the right choice when people nod their head and say ‘Yeah, was a great college try but it needs more time or go somewhere else.’ … By Friday of that week, we had a new idea to head out the door.”

If you can’t hear the clip, click here

The 7 Deadly Healthcare Startup Sins

Todd Dunn is the Director of Innovation and runs the Intermountain Healthcare Transformation Lab, which is working to foster innovation in the healthcare industry. Todd DunnHe’s now run several Lean LaunchPad classes and has seen a ton of healthcare startups. Here’s his advice for startups in this space.

———

I have spent the last 10 years in the Healthcare space. Over the past couple of years as Director of Innovation for Intermountain Healthcare I’ve mentored and worked with many Healthcare-focused startups. During that time I have seen teams that really seem to understand the industry and those who are relatively uninformed.

Our healthcare system is complex, under intense regulatory pressure, the pressure of the aging population, reimbursement changes, and an oncoming shortage of clinicians, among other challenges. It is in need of innovation on many fronts and is also trying to embrace the amazing amount of innovation happening with early-stage companies.

Yet, I have noticed that many healthcare startups make “leap of faith assumptions” as they try to build their businesses. Let me highlight the 7 deadly healthcare startup sins!

Sin 1: Healthcare startups assume hospitals will let them host patient data in “their portal.” The reality is that healthcare customers know that startups’ portals are likely hosted by AWS, Azure, or Google, and therefore pose security and privacy concerns. My reference points on these startups are digital health startups and small device startups that gather data from patients remotely. Many startups make the key assumption that hospitals will trust their data to a startup’s “cloud” for the long term. For a proof of concept or pilot this may be OK. For the longer term it may not be. The only way to know for sure is to test that assumption by getting out of the office and talking to customers.

Sin 2: Startups assume that clinicians will be willing to access yet another portal for their data. Basically, startups make assumptions about clinicians’ workflow that may be myopic. In completing their Business Model Canvas some startups assume that a clear value is having their solution hosted in the cloud but often overlook the workflow impacts from a value perspective. The challenge is that many of them haven’t done enough “get out of the office” work to understand how their proposed solution will or won’t fit into a healthcare provider’s workflow. Doctors and nurses want more time with patients. In addition, doctors have many data points for making decisions. Having to go to multiple places for data about one patient reduces the time they can spend with each patient and complicates sound decision-making. The “job to be done” is to diagnose and prescribe. One pain that doctors and nurses want to avoid is going to multiple locations to get the needed decision support data. Clinical decision support needs to be simplified. Going to another portal for patient data is simply onerous. If your solution reduces the time a clinician can spend with a patient or makes it harder to make a decision you have reduced the value.

Sin 3: That one doctor or hospital lends enough credibility for other organizations to simply accept a startup’s solution. Many startups believe that if they have a doctor on their team or as an advisor (the idea of having a KOL – Key Opinion Leader), or if one hospital has written a letter of support, they have credibility. The reality is that it doesn’t suffice. More homework needs to be done. Healthcare regulations, processes, and delivery approaches often vary from system to system. A broader base of KOL’s would simply lend credibility to the solution’s applicability across multiple customers.   “Getting out of the office” and talking to customers is a necessary endeavor to get these deep and broad insights from KOL’s.

I recommend that teams get a least five KOL’s to support their value claims. This isn’t just about conducting 100 customer interviews. This is about getting evidence that Key Opinion Leaders agree that the value proposition offered by the startup can be realized. As Steve recommends, use an MVP to get evidence that validates those opinions.

Sin 4: Believing that ONE key leader inside a hospital is the decision-maker, influencer, etc. all in one role…. The Startup Owner’s Manual clearly articulates the need to understand “how” a company buys a product. ….Most startups I see want to go directly into a pilot and many want to speak directly with the C-level clinical leaders. Part of the weakness is that most startups aren’t asking learning questions … they are making statements vs. being curious enough to test their assumptions.

Sin 5: Thinking that conducting a “proof of concept” and/or pilot is a simple endeavor. In working with eight early-stage companies in the last two months I have consistently asked, “What do you want from us?” Oddly I found some teams did not have a crisp answer. However, all of them wanted to hop directly into a proof of concept within an extremely short time. In wanting to do so, they overlooked

  • the need for an IRB (institutional review board,) (especially where patients are involved)
  • a security review (especially if they are in “the cloud”)
  • a compliance review
  • the time needed to design a study
  • and last but not least signing a contract!

All of these are easily in the “Activity” portion of the Business Model Canvas and few early-stage companies fully understand these needs, especially when working with a large IDN (integrated delivery network) like Intermountain Healthcare.

Sin 6: There isn’t anyone else out there solving the problem. A large percentage of startups struggle to answer the question, “Why do current solutions fail?” This suggests that they haven’t completed a petal diagram to look at the existing offerings, or analyzed the “job” that someone needs to hire a solution for. As an example, a med-adherence solution approached us recently and offered that there wasn’t “anyone” else with a technology like theirs. That may be true…not likely. I suggest that teams thoroughly think through this.

Sin 7: Believing that startups need to have more answers than questions. Almost unanimously startup teams want to have an answer for every question. I understand their desire to appear knowledgeable. But you don’t get out of the office to have answers – you get out of the office to ask questions. This goes back to a fundamental that I believe all startups need until they truly know: curiosity.

hypotheses experimentMy advice to healthcare startups.

  1. Use the Lean Startup tools! Regardless of where you start, it comes down to your value proposition as a starter or non-starter. Use Alexander Osterwalder’s Value Proposition canvas and Steve’s guidance to “get out of the office.”
    value prop map
  2. This often tries the patience of entrepreneurs. I cannot overemphasize the need to use the learning loop in every single part of the Value Proposition and Business Model canvases. The only way to do that is to GET OUT OF THE OFFICE!
  3. Be curious about workflow and how large IDNs (integrated delivery network) like Intermountain Healthcare are thinking about the integration of patient data into a workflow. Be empathetic to your user.
  4. Study the industry more deeply. While you may have a great value proposition for one or two hospitals, how does your solution fit into the regulatory landscape, workflow, etc. of multiple hospitals?
  5. Listen! Assume you don’t have enough evidence to scale your business yet. Act like you don’t know enough. While an entepreneur’s “go get ’em” attitude is appreciated, it isn’t appreciated when the entrepreneur isn’t open to feedback, seems to have all the answers, and has a condescending attitude toward the way “jobs” get done today. Test your assumptions! Come loaded with questions that are related to your assumptions.
  6. Last but not least, structure a learning plan. Embrace the Lean Startup tools and methods. Following this structure will cause you to write a learning plan. A foundational question to guide your learning plan in every part of your business model is “What do we need to learn before we invest more time and money?”

Best of success! Healthcare needs innovative startups and innovative startups need the knowledge and access that Healthcare can provide.

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 happens 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 innovationLean Innovation Mgmt
  • 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

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.

Summary
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.

Build-Measure-Learn
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.

Thibault_sister

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

Why?

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.

trancense

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
Follow

Get every new post delivered to your Inbox.

Join 189,217 other followers