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

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.organizational debt

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

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

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

Getting to “Yes” for Corporate Innovation

I’ve been working with Roberto, the Chief Innovation Officer of a diversified company I’ll call Sprocket Industries.

I hadn’t heard from Roberto in awhile and when we caught up, it was clear his initial optimism had faded. I listened as Roberto listed the obstacles to the new innovation program at Sprocket, “We’ve created innovation teams in both the business units and in corporate. Our CEO is behind the program. The division general managers have given us their support. But the teams still run into what feel like immovable obstacles in every part of the company. Finance, HR, Branding, Legal, you name it, everyone in a division or corporate staff has an excuse for why we can’t do something, and everyone has the power to say no and no urgency to make a change.”

Roberto was frustrated, “How do we get all these organizations to help us move forward with innovation? My CEO wants to fix this and is ready to bring in a big consulting firm to redo all our business processes.”

Uh oh…

—–

As Sprocket’s Chief Innovation Officer, Roberto was a C-level executive responsible for the corporate innovation strategy in a multi-billon dollar company. Over the last 9 months his staff got innovation teams operating with speed and urgency. The innovation pipeline had been rationalized. His groups whole-heartedly adopted and adapted Lean. His organization ran a corporate incubator for disruptive (horizon 3) experiments and provided innovation support for the divisions for process and business model innovations (Horizon 1 and 2.) He had an innovation pipeline of hundreds of employees going through weekend hackathons and 45 different innovation teams going through 3-month rapid Lean LaunchPad programs to validate product/market fit.

The next day Roberto and I sat together and listed what we knew about the innovation conundrum at Sprocket:

  1. Sprocket is a permanent organization designed to execute a repeatable and scalable business model.
  2. Roberto’s innovation teams are temporary organizations designed to search for a repeatable and scalable business model.
  3. Sprocket had world-class resources and capabilities in brand, supply chain, distribution, sales force, financial metrics, all tailored to execute the existing business model, not to help search for a new one
  4. The resources and capabilities optimized for execution interfere with the processes needed to search for a new business model
  5. Sprocket needed new and different processes for innovation while retaining the ones that work well for execution
  6. Sprocket wanted to use the same organizations that provided support for execution (brand, supply chain, distribution, sales force, financial metrics) to provide support for innovation

Roberto’s group had spent the last 9 months educating the company about why they needed to deliver continuous innovation, and why the execution and innovation teams need to work collaboratively. But while there was lots of theory, posters, memos, and lip-service to being innovative, it wasn’t working.

So what to do?

I offered that a top-down revamp of every business process should be a last resort. I suggested that Roberto consider trying a 6-month experimental “Get to Yes” program. His teams, not outside consultants, would write their own innovation processes and procedures.Get to Yes

Recognizing the Roadblocks
Most of the impediments the innovation teams faced were pretty tactical: for example an HR policy that said the innovative groups could only recruit employees by seniority. Or a branding group that refused to allow any form of the Sprocket name to appear on a minimal viable product or web site. Or legal, who said minimal viable products opened the company to lawsuits. Or sales, who shut out innovation groups from doing customer discovery with any existing, or even potential customer. Or finance, who insisted on measuring the success of new ventures on their first year’s revenue and gross margin.

We agreed that the goal was not to change any of the existing execution processes, procedures, incentives, metrics but rather to write new ones for innovation projects.

And these innovation policies would grow one at a time as needed from the bottom of the organization, not top down by some executive mandate.

If we were successful, innovation and execution policies, processes, procedures, incentives, metrics would then co-exist side-by-side. In their day-to-day activities, the support organizations would simply ask, “Are we supporting an execution process (hopefully 90% of the time) or are we supporting an innovation process?” and apply the appropriate policy.

Get to Yes
The “Get to Yes” program was pretty simple. Every time an innovation team needed a new policy, procedure, etc. from an existing organization (legal, finance, sales, HR, branding, etc.), they submitted a standard Sprocket corporate “Get to Yes” request form. The form was a single page. It asked what policy the innovation group wanted changed, why it wanted it changed, how it wanted the new policy to read, the impact the new policy would have on other policies and organizations, and most importantly the risks to the core existing business.

The “Get to Yes” request form looked like this:

Sprocket Get to Yes Form page 1

The appropriate department had one week to ask questions, gather information, meet with the innovation team and evaluate the costs and risks of the proposed process. They could either:

  1. approve and adopt
  2. suggest modifications that the team agreed with
  3. deny the request.

The approval form looked like this:

Sprocket Get to Yes Form page 2

Although it was just a one-page form, the entire concept was radical:

  • The innovation team would be proposing the new process, procedure, metric, etc. – not waiting for one to be written.
  • There was a hard 1-week deadline for the execution team to respond.
  • Yes was the default answer, a No required detailed explanation.
  • Appeals went straight to the Chief Innovation Officer.

The big idea is that Sprocket was going to create innovation by design not by exception, and they were going to do it by co-opting the existing execution machinery.

The key to making this work was that if the request was denied, it automatically was kicked upstairs to the Chief Innovation Officer – and would be acted on the next week. And it’s there that the execution department had to make its case of why this request should not be approved. (If there was still no agreement, it became an issue for the executive staff.)

The time for a process resolution in a billion dollar corporation – two weeks. At Sprocket innovation was starting to move at the speed of a startup.

Lessons Learned

  • Innovation by design, not by exception
  • Execution organizations now manage both execution and innovation
  • Innovation teams write their own process and procedures
  • Innovation policy, process and procedures get written as needed, one at a time
  • Over time a set of innovation processes are created from the bottom up
  • Bias for immediate action not perpetual delay

Fear of Failure and Lack of Speed In a Large Corporation

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

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

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

—-

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

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

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

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

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

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

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

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

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

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

No wonder innovation at Acme had stalled.

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

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

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

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

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

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

Lessons Learned

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

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

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

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

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

Oren Jacob - CEO ToyTalk

Oren Jacob – CEO ToyTalk

Alex Osterwalder - Business Models

Alex Osterwalder – Business Models

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

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

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

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

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

Why Corporate Skunk Works Need to Die

In the 20th century corporate skunk works® were used to develop disruptive innovation separate from the rest of the company. They were the hallmark of innovative corporations.

By the middle of the 21st century the only companies with skunk works will be the ones that have failed to master continuous innovation. Skunk works will be the signposts of companies that will be left behind.

 

——–

In the 20th century companies could be leaders in a market for decades by just focusing on their core product(s). Most companies incrementally improved their products with process innovation (better materials, cheaper, product line extensions) and/or through acquisitions. Building disruptive products were thought of as “risky” and a distraction since it was not “core” to the company and did not fit existing corporate structures. Why make big bets if no one was asking for them and competitors weren’t doing so.

a-12

CIA A-12 spy plane. Developed by Lockheed Skunkworks

A few innovative companies did push the envelope. The way they did so was to set up “skunk works” to develop their most advanced, disruptive products. (IBM used the process to develop the IBM PC.) But it was Lockheed, then an aircraft manufacturer that coined the term and perfected the art. The Lockheed Skunk Works® led by Kelly Johnson was responsible for its Advanced Development Projects – everything from the P-80, the first U.S. jet fighter plane, to the U-2 and A-12 spy planes.

Skunk works differed from advanced research groups in that they were more than just product development groups. They had direct interaction with customers and controlled a sales channel which allowed them to negotiate their own deals with customers.

Decades before we were able to articulate the value of “getting out of the building” and the Lean Startup, the value in having skunk works controlling their own distribution was starkly evident. Other companies with world-class R&D groups built radical innovations only to see their company fumble the future and others reap the rewards (think of Xerox and the personal computer, Fairchild and integrated circuits, Kodak and digital photography, etc.) Common themes in these failures were, 1) without a direct connection to the customer advanced R&D groups built products without understanding user needs, and 2) the core of the company was so focused on execution of current products that it couldn’t see that the future didn’t look like the past.

Kelly Johnson’s 14 rules about how to manage a disruptive project described how to remove a small innovative team from the politics, policies, procedures and processes a large company had built to support execution of its core business (and its military customers had developed to procure large numbers of standard aircraft.)

With the vantage point of the 21st century, we can now see that a successful skunk works – separated from its corporate parent, with its own culture, in control of its own R&D and distribution channel – looked much like a startup.

But as successful as skunks works were to the companies that executed them well, innovation and execution couldn’t co-exist in the same corporate structure. Skunk works were emblematic of corporate structures that focused on execution and devalued innovation.

Until now.

Continuous Disruption Requires Continuous Innovation
In the 21st century market share is ephemeral – ask General Motors, Blackberry, Nokia, Microsoft, Blockbuster, etc. –disruption is continual.

Therefore companies need to master continuous innovation – the art of executing on core products while continually inventing new products and new businesses. That means that somehow we need to take the innovation that a skunk works removed from the core of the company and integrate the two.

Here’s how.

We need to realize that skunk works epitomize innovation by exception. But to survive companies need innovation by design.

We now know how to do just that. We can get innovation and execution to work side-by-side.

To start it requires board support and CEO and executive staff agreement. And recognition that cultural, process and procedure changes are needed to embrace learning and experimentation alongside the existing culture of execution.

I’ll provide details on how companies can organize this way in a follow-on post.

Lessons Learned

  • Skunk were advanced/disruptive product groups organizational isolated from the rest of their company
  • Skunk works had control over their sales channel and had direct customer feedback
  • World-class R&D groups that didn’t control the channel often saw their innovation die internally
  • Skunk works looked much like a startup
  • Skunk works epitomized innovation by exception
  • Companies now need innovation by design – innovation and execution that work side-by-side
  • We now know how to do this
Follow

Get every new post delivered to your Inbox.

Join 184,997 other followers