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

How We Used to Give Startups Very Bad Advice. 2 Minutes to See Why

If you can’t see the video click here

Driving Corporate Innovation: Design Thinking vs. Customer Development

Startups are not smaller versions of large companies, but interestingly we see that companies are not larger versions of startups.

I’ve been spending some time with large companies that are interested in using Lean methods. One of the conundrums is why does innovation take so long to happen in corporations? Previously Hank Chesbrough and I have written about some of the strategic issues that impede innovation inside large corporations here and here.

Two methods, Design Thinking and Customer Development (the core of the Lean Startup) provide the tactical day-to-day process of how to turn ideas into products.

Design Thinking HBR page                                   Why the Lean Startup Changes Everything page

While they both emphasize getting out of the building and taking to customers, they’re not the same. Here’s why.

—–

Urgency Drives Innovation Speed
Startups operate quickly – at a speed driven by the urgency of a proverbial gun-to-their-head called “burn rate.” Any founding CEO can tell you three numbers they live and breathe by:

  • the amount of cash left in the bank
  • their burn rate (the amount of money they’re spending monthly minus any revenue coming in) and
  • the day they run out of money and have to shut the doors (or get a new round of funding.)

If you’re a founder, there’s a constant gnawing fear in the pit of your stomach that it will all end badly; running out of money, having to fire all your employees and failing publicly. (Whoever says, “Failure feels OK in startups has clearly never run a startup.)shutterstock_170739491

A startup CEO adroitly translates this urgency to their employees not with reminders of “we’ll all soon be out of jobs,” but with a bias to action – making measureable progress in getting minimum viable products in front of customers, beating competitors, getting users/customer quickly, and generating revenue. Startups build a culture of commitment and drive to make things happen.

In large companies, the employees are no less smart, but the organization is optimized to deliver repeatable products, revenue and profits. To support this, its corporate culture is dominated by process, procedures and incentives. In large companies, even the most innovative projects (whether it’s process innovation, continuous innovation or disruptive innovation) are not going to make or break the company – and employees know it. Canceling a project may frustrate the team members working on it but unlike in a startup, they still have their jobs, offices and houses and the company won’t close. Attempts to instill urgency via a gun-to-the-head philosophy are frowned on by Corporate HR. All of this adds up to a “complacency culture” rather than an “urgency culture.”

Customer Development versus Design Thinking
This real sense of urgency—and how it shapes employee attitudes and practices – is a big reason why innovation processes in startups are different from those in large companies. One of these processes is how startups versus companies learn from customers. It’s the difference between Customer Development versus Design Thinking.

Customer Development and Design Thinking share similar characteristics in exploring customer needs, but their origins, differences and speed in practice are very different.

I invented the Customer Development process trying to solve two startup problems. First, most Silicon Valley startups were (and primarily still are) technology-driven. They are founded and funded by visionaries who already have products (or product ideas based on technology innovation) and now need to find customers and markets. (Think of the early days of Intel, Apple, Cisco, Google, Facebook, Twitter, etc.) Second, burn rate and dwindling cash meant startups had to find these customers and the attendant product/market fit rapidly – before they ran out of money. These two characteristics– a technology-driven product already in hand and a need for speed– drove the unique characteristics of Customer Development. These include:

  • Moving with speed, speed and did I say speed?
  • Starting with a series of core hypotheses – what the product is, what problem the product solves, and who will use/pay for it
  • Finding “product/market fit” where the first variable is the customer, not the product
  • Pursuing potential customers outside the building to test your hypotheses
  • Trading off certainty for speed and tempo using “Good enough decision making
  • Rapidly building minimum viable products for learning
  • Assuming your hypotheses will be wrong so be ready for rapid iterations and pivots

Design Thinking also focuses on understanding the needs of potential customers outside the building. But its motivations and tactics are different from those of Customer Development. Design Thinking doesn’t start with a founder’s vision and a product in-hand. Instead it starts with “needs finding” and attempts to reduce new product risk by accelerating learning through rapid prototyping. This cycle of Inspiration, Ideation and Implementation is a solutions-based approach to solving customer problems.

Design Thinking is perfectly suited to situations where the process isn’t engineering-driven; time and money are abundant and the cost (and time) of a failure of a major project launch can be substantial. This process makes sense in a large company when the bets on a new product require large investments in engineering, a new factory or spending 10s or 100s of millions on launching a new product line.

But therein lies the conundrum. Because of the size of the dollars at stake (and your career), lots of effort is spent to make sure your understanding of the customer and the product is right. At times large companies will drag out these design-thinking investigations (prototype after prototype) for years. Often there is no place where urgency gets built into the corporate process. (Just to be clear this isn’t a failure of the process. Urgency can be built in, it’s just that most of the time it’s not.)

Design thinking vs cust dev

Both Models Work for Large Companies
There is no right process for all types of corporate innovation. In a perfect world you wouldn’t need Customer Development. No corporate R&D would happen before you understood customer problems and needs. But until that day, the challenge for executives in charge of corporate innovation is to understand the distinction between the two approaches and decide which process best fits which situation. While both get product teams out of the building the differences are in speed, urgency and whether the process is driven by product vision or customer needs.

In one example, you might have a great technology innovation from corporate or division R&D in search of customers. In another, you might have a limited time to respond to rapidly shifting market or changing competitive environment. And in still another, understanding untapped customer needs can offer an opportunity for new innovation.

Often I hear spirited defenses for Customer Development versus Design Thinking or vice versa, and my reaction is to slowly back out of these faith-based conversations. For large companies, it isn’t about which process is right – the reality is that we probably haven’t invented the right process yet. It’s about whether your company is satisfied with the speed, quality and size of the innovations being produced. And whether you’re applying the right customer discovery process to the right situation. No one size fits all.

There’s ample evidence from the National Science Foundation that Customer Development is the right process for commercializing existing technology. There’s equally compelling evidence from IDEO the Stanford D-School and the Biodesign Innovation Process that Design Thinking works great in finding customer needs and building products to match them.

Lessons Learned

  • Customer Development and Design Thinking are both customer discovery processes
  • Customer Development starts with, “I have a technology/product, now who do I sell it to?”
  • Design Thinking starts with, “I need to understand customer needs and iterate prototypes until I find a technology and product that satisfies this need”
  • Customer Development is optimized for speed and “good enough” decision making with limited time and resources
  • Design Thinking is optimized for getting it right before we make big bets
Follow

Get every new post delivered to your Inbox.

Join 180,481 other followers