Steve Blank Innovation and Entrepreneurship March 2010

Teaching Entrepreneurship – Logistics

Posted on March 29, 2010 by steve blank

Back from a family humanitarian trip/vacation to one of the last bastions of Communism where “marketing” isn’t even a profession and entrepreneurship is a crime. The irony is that the “Revolutionary Square” in all these Communist countries will be the the first place the McDonald’s go when the system collapses.

——————-

In my last post I described my approach to one of the three classes I teach at Stanford in the engineering school: Fundamentals of Technology Entrepreneurship. The key things I want students to take from the class are:

Understand that a startup is a temporary organization designed to search for a profitable business model
Learn how to put together a business model, not a business plan
Understand that a business model is only a series of hypotheses that need to be validated outside the building

Class Logistics
As described in the previous post, this is a hands-on class. The 55 students formed 11 teams, and each team had to come up with an original idea, size the opportunity, propose a Business Model, get out of the building and test their hypotheses and analyze and explain each of the parts of their model.

The class wouldn’t have been possible without lots of hands other than mine.

Teaching Team
Having a teaching partner makes life a lot easier and the class improves. A partner allows me the flexibility to miss a session or two (my job as a California Coastal Commissioner meets three days every month up and down the coast of California.) But the best benefit is bringing a second set of eyeballs to the curriculum which always makes it better.

This was the year I finally got the “business model versus business plan” concept nailed down. In previous classes I had experimented with moving away from the traditional focus on writing a business plan to a hands-on approach to building a business model.

But it wasn’t until Ann Miura-Ko joined me as a teaching partner that this “teach the model not the plan” idea jelled. Ann who had been my Teaching Assistant while she had finished her PhD at Stanford felt the same frustration about teaching entrepreneurs to assemble a business plan that we knew in the real world wouldn’t survive first contact with customers. After Stanford, Ann joined Mike Maples’ Venture Capital firm Floodgate as a partner. Over the summer we had both been impressed with Alexander Osterwalder’s Business Model Template work. At first we thought of adopting his template for the class, but found that an even more simplified version of a canonical business model that Ann developed worked better.

Teaching Assistants
Teaching at both Stanford and Berkeley I get to see the difference between the resources in a private university and those of a state university. (For the first 5 years at Berkeley, I taught 60 students by myself with no teaching partner or teaching assistant.) As the Stanford entrepreneurship program for the engineering school sits in the Management Science and Engineering Department, most of our TA’s are students in the MS&E PhD program. For this class Daisy Chung and David Hutton were our Teaching Assistants (TA’s.) TA’s make managing 60 students working on cases and team projects manageable.
They set up and keep the class web site updated. They provide logistical support for guest speakers. They answer enumerable emails about logistics as well as substantive questions about class content. In addition to Ann and my office hours, Daisy and David held their own office hours to provide student support.

Most importantly, while Ann I reviewed all the grades, the TA’s managed the logistics of grading: grading the homework (in this class the case study summaries) and the business model written summary, keeping track of class participation and rolling up all the grades from the formal presentation. And they gave us feedback after each class session letting us know if we were particularly incoherent and kept us abreast of the usual student and team dynamics/crisis.

Finally our TA’s managed the mentors we had supporting the students.

Mentors
One part of Silicon Valley culture that doesn’t get enough credit is the generosity of entrepreneurs and VC’s who are willing to share their time with students. Ann and I recruited VC’s and entrepreneurs to be mentors for each team. (We’ve never had a problem in getting help for these classes.) Typically we have a mix of new mentors and those who have volunteered their time before.) I wrote a handbook for the mentors to explain their roles (here.)

Essentially mentors support and coach each team. They typically met once or twice in person with the team, help them network outside the building, answer emails, provide critiques, etc. On average, mentors spent about 6 to 8 hours of time over the quarter with students. Some even came into to class to cheer on their team for their final business model presentations.

Guest Speakers
Two important things I learned early on in teaching are: 1) regardless of how good you are, students get sick of hearing you drone on week after week, and 2) hearing a guest make a point you’ve been trying to get across often makes it stick. So we tried to break up our lectures with guest speakers.

Ideally we attempt to match the guests with the case or class session subject. For example, when we taught the value of getting out of the building and agile development, we had Eric Ries talk about the Lean Startup. When we covered partnerships with the WebTV case, we had Spencer Tall who negotiated the deal with Sony for WebTV come in and explain to the class what really happened. (Ann also kept me in the 21st century by making sure we had several woman entrepreneurs as guest speakers.)

Results
In the last decade, entrepreneurship has become faddish, particularly in college. It’s now “cool” to be an entrepreneur, and every school wants some type of entrepreneurship course. While that’s gratifying, the fact is that most people are ill suited to survive in the wild as founders or early employees.

I taught this introductory undergraduate class without many compromises. If you want to know what being an entrepreneur is going to be like you didn’t get to sit in a classroom listening to lectures for a quarter and then write a business plan. (I also teach a less intense introduction class for engineers called the Spirit of Entrepreneurship and the Customer Development Class at Berkeley which I’ll describe in a future post.) I actually hoped that some students who were curious about entrepreneurship would discover that it is definitely not for them. Better to find it out in a classroom than as a career choice.

While that did happen to a few (some are still in shock that I “cold-call” in class, others can’t handle the team dynamics or complain that there is no “right” answer, or were disoriented that the mentors, professors and customers all had different answers) the class seems to have had the opposite effect on an interesting segment.

Sometimes you get emails like this at the end of class:

“Just want to say thank you for the “big ideas” you brought to us. Thanks to your class, I have been thinking thoroughly about my future career and have decided that I would become an entrepreneur rather than anything else. Actually I made up my mind just on my plane to my final round of interview with the Boston Consulting Group. I flew there and told the partner that I would become an entrepreneur instead.”

Oh, oh.

——–

Coming Soon
In the fall Ann and I are going to develop a new graduate-level class for Stanford that will take this one to the next level. Students will not only have to assemble a team, come up with the idea and leave the classroom to test the business model – they’ll need to come back with real customer orders. (And if it’s a web-based product, they’ll have to build it.)

I wonder if we can fill the class.

———–

A few more of the final class presentations are here (click on the thumbnails to enlarge):

One last presentation here:

Filed under: Business Model versus Business Plan, Corporate/Gov't Innovation, Customer Development Manifesto, Teaching | 12 Comments »

On Blog Vacation

Posted on March 15, 2010 by steve blank

I’m off the web for the next week or so. I’m in a place with no cell or internet coverage.

Back blogging by the end of March.

steve

Filed under: Uncategorized | 2 Comments »

Teaching Entrepreneurship – By Getting Out of the Building

Posted on March 11, 2010 by steve blank

One of the classes I teach in the engineering school at Stanford is E145: the Fundamentals of Technology Entrepreneurship, an introduction to building a scalable startup. While the class is open to everyone at the University, we want to teach science and engineering undergraduates how they can take a technical idea and turn it into a profitable and scalable company.

The class which was authored by Tom Byers, is offered every quarter and taught by four different professors. But thanks to Tom, we all get to teach it with a slightly emphasis.

I taught the class this semester with Ann Miura-Ko a partner at Maples Investments.

Teaching Goals
Our goal is to teach students the key concepts of the startup process and help them understand that a startup is a search for a profitable business model. We did this with twice weekly lectures and seven case studies. Most importantly we tied the lectures to a hands-on team project. Students formed 5-person teams, came up with a business idea then got out of the building to validate their business model. (And learn how to pivot their model as reality intrudes.)

Our goal was not to teach the students to write a business plan nor were we trying to teach them how to give a pitch to VC’s.

A Startup is a Search For A Business Model
As I’ve described in previous posts; a startup is an organization formed to search for a repeatable and scalable business model.

A business model describes how your company creates, delivers and captures value. It’s best understood as a diagram that shows all the flows between the different parts of your company. This includes how the product gets distributed to your customers and how money flows back into your company. And it shows your company’s cost structures, how each department interacts with the others and where your company can work with other companies or partners to implement your business.

We want to teach our students to think about how their “idea” for a business translated into a business model and then to see if that business model will survive first contact with customers.

In our class Ann and I offered the students a template of a business model diagram. Their job was to get out of the building and transform the boxes into real data. (I’ll show you some of their examples at the end of this post.)

Class Lectures
We had ten weeks and an hour and fifty minutes twice a week to cover the basics of a startup.

Our lectures were organized as:

Where do ideas come from?
How to decide whether an idea is a scalable business opportunity.
What is a business model?
Distribution, Demand Creation and Partnerships
Customer Discovery
First Team Presentation – What’s the Idea and How Large is the Opportunity
Regulation and Intellectual Property
Building Startup Teams
Metrics That Matter (Business Model Metrics)
Accounting Basics and Multi-stage Finance
Liquidity – the End Game
Final Team Presentation – What’s the Business Model?

Interspersed among the lectures were seven “case studies”: Chegg, IMVU, WebTV. Nanogene, Wily, Solidworks and Barbara Arenson. Each case study was a real world example of an issue an entrepreneur might encounter as they were building a company.

Final Team Project – What’s the Business Model?
11 student teams of 5 were working outside of class on the Opportunity Assessment Project. Each team had to take an original idea, come up with the positioning and analyze the potential size of the opportunity, propose a Business Model, and analyze and explain each of the parts of their model.

Customer Discovery
Only 5 out of the 55 students had taken an entrepreneurial class before. None of the students were domain experts in their areas, and each team had to figure out how to contact potential customers and channel partners. Yet every team did figure out how to conduct extensive out of building Customer Discovery. (By design we didn’t give them too much Customer Development theory. The emphasis was on getting out of the building and testing their hypothesis.)

Here are some examples the “out of the building” work the students did.

Presenting the Project
As their final project, each of the 11 teams had 15 minutes to present their conclusions and then later submit a written summary. (We were equally happy if the students discovered this would not be a profitable business as we were if they found a killer idea.) The presentations were graded on:

Did they quickly summarize their idea?
Did they articulate the problem?
Did they size the opportunity of solving the problem?
Was their solution clear? (for product companies, this should include manufacturing and cost of goods)
Did they describe demand creation and assign acquisition costs?
Did they describe lifetime value of a customer?
Did they describe distribution channel and assign channel costs?
Did they get out of the building?
Did they tell us what they learned from going out of the building?
Did they adequately diagram the business model?
Did they describe the risks?

Remember the goal was not a fundable pitch deck or a full business plan with pages of spreadsheets. Rather we wanted them to start with an idea and see what it would take to build a real business (and tell us in 15 minutes).

This post and the next will have a few of the final presentations (click on the thumbnails to enlarge.)

And here was another presentation in a very different market.

Lessons Taught

Entrepreneurship is an art not a science.
It is best learned by a combination of theory and practice.
No business model survives first contact with customers
You won’t believe this until you hear customers tell you you’re wrong.
Agility and resiliency are not tested inside the building.
They’re essential outside.

Filed under: Corporate/Gov't Innovation, Customer Development Manifesto, Teaching | 35 Comments »

The Secret History of Silicon Valley Part 15: Agena – The Secret Space Truck, Ferret’s and Stanford

Posted on March 8, 2010 by steve blank

This post is the latest in the “Secret History Series.” They’ll make much more sense if you read some of the earlier ones for context. See the Secret History video and slides as well as the bibliography for sources and supplemental reading.

————

By the early 1960’s Lockheed Missiles Division in Sunnyvale was quickly becoming the largest employer in what would be later called Silicon Valley. Along with its publically acknowledged contract to build the Polaris Submarine Launched Ballistic Missile (SLBM,) Lockheed was also secretly building the first photo reconnaissance satellites (codenamed CORONA) for the CIA in a factory in East Palo Alto.

It was only a matter of time before Stanford’s Applied Electronics Lab research on Electronic and Signals Intelligence and Lockheed’s missiles and spy satellites intersected. Here’s how.

Lockheed Agena

Thor/AgenaD w/Corona

In addition to the CORONA CIA reconnaissance satellites, Lockheed was building another assembly line, this one for the Agena – a space truck. The Agena sat on top of a booster rocket (first the Thor, then the Altas and finally the Titan) and had its own rocket engine that would help haul the secret satellites into space. The engine (made by Bell Aerosystems) used storable hypergolic propellants so it could be restarted in space to change the satellite’s orbit. Unlike other second stage rockets, once in orbit, the CORONA reconnaissance satellite would stay attached to the Agena which stabilized the satellite, pointed it in the right location, and oriented it in the right direction to send its recovery capsule on its way back to earth.

The Agena would be the companion to almost all U.S. intelligence satellites for the next decade. Three different models were built and for over a decade nearly four hundred of them (at the rate of three a month) would be produced on an assembly line in Sunnyvale, and tested in Lockheed’s missile test base in the Santa Cruz mountains.

Agena Ferrets – Program 11/Project 989
As Lockheed engineers gained experience with the Agena and the CORONA photo reconnaissance satellite, they realized that they had room on a rack in the back of the Agena to carry another payload (as well as the extra thrust to lift it into space.) By the summer of 1962, Lockheed proposed a smaller satellite that could be deployed from the rear of the Agena. This subsatellite was called Program 11, or P-11 for short (also called Project 989.) The P-11 subsatellite weighed up to 350lbs, had its own solid rockets to boost it into different orbits, solar arrays for power and was stabilized by either deploying long booms or by spinning 60-80 times a second.

Agena Internals

And they had a customer who couldn’t wait to use the space. While the CORONA reconnaissance satellites were designed to take photographs from space, putting a radar receiver on a satellite would enable it to receive, record and locate Soviet radars deep inside the Soviet Union. For the first time, the National Security Agency (working through the National Reconnaissance Office) and the U.S. Air Force could locate radars which would threaten our manned bombers as well as those that might be part of an anti-ballistic missile system. Most people thought the idea was crazy. How could you pick up a signal so faint while the satellite was moving so rapidly? Could you sort out one radar signal from all the other noise? There was one way to find out. Build the instruments and have them piggyback on the Agena/CORONA photo reconnaissance satellites.

But who could quickly build these satellites to test this idea?

Stanford and Ferrets
Just across the freeway from Lockheed’s secret CORONA assembly plant in Palo Alto, James de Broekert was at Stanford Applied Electronics Laboratory. This was the Lab founded by Fred Terman from his WWII work in Electronic Warfare.

“This was an exciting opportunity for us,” de Broekert remembered. “Instead of flying at 10,000 or 30,000 feet, we could be up at 100 to 300 miles and have a larger field of view and cover much greater geographical area more rapidly. The challenges were establishing geolocation and intercepting the desired signals from such a great distance. Another challenge was ensuring that the design was adapted to handle the large number of signals that would be intercepted by the satellite. We created a model to determine the probability of intercept on the desired and the interference environment from the other radar signals that might be in the field of view, de Broekert explained.

“My function was to develop the system concept and to establish the system parameters. I was the team leader, but the payloads were usually built as a one-man project with one technician and perhaps a second support engineer. Everything we built at Stanford was essentially built with stockroom parts. We built the flight-ready items in the laboratory, and then put them through the shake and shock fall test and temperature cycling…”

Agena and Ferret Subsatellite credit: USAF

Like the cover story for the CORONA (which called them Discoverer scientific research satellites,) the first three P-11 satellites were described as “science” missions with results published in the Journal of Geophysical Research.

Just fifteen years after Fred Terman had built Electronic Intelligence and Electronic Warfare systems for bombers over Nazi Germany, Electronic Intelligence satellites were being launched in space to spy on the Soviet Union.

Close to 50 Ferret subsatellites were launched as secondary payloads aboard Agena photo reconnaissance satellites.

SAMOS/Project 102/698BK/Program 770 – Low Earth Orbit Agena “Heavy” Ferrets
Lockheeds Agena’s would play another role in overhead reconnaissance – they would carry Air Force heavy ferrets (Electronic Intelligence payloads) as part of the SAMOS program.

In the 1960’s the U.S. Air Force Strategic Air Command (SAC) needed to understand the electronic order of battle inside the Soviet Union so B-52 bombers could evade or jam those radars on the way to their targets. (Where were the Soviet early warning radars? The ground controlled intercept radars? What are their technical characteristics?) Other parts of the government wanted to know details about Soviet Anti Ballistic Missile (ABM) systems.

SAMOS originally was supposed to provide photo reconnaissance from space by developing film in orbit and electronically scanning it and beaming it to the ground. For the early 1960’s this approach turned out to be a technical bridge too far. (The U.S. wouldn’t beam down photo reconnaissance images until the KH-11 satellites in December 1976.) The CIA’s CORONA program, which dropped film canisters from space turned out to be a more efficient way to solve the problem. With CORONA successful, and results from the electronic intelligence sensors on P-11 program providing useful information, the Air Force pivoted from photo reconnaissance to electronic reconnaissance, which had already been a secondary SAMOS payload.

32 dedicated Agena heavy ferret missions were launched from the the early 1960’s to the end of the program in 1972.

Ferret Entrepreneur
After student riots in April 1969 at Stanford shut down the Applied Electronics Laboratory, James de Broekert left Stanford. He was a co-founder of three Silicon Valley military intelligence companies: Argo Systems, Signal Science, and Advent Systems,

In 2000 the National Reconnaissance Office recognized James de Broekert as a “pioneer” for his role in the “establishment of the discipline of national space reconnaissance.”

See part 16 “Balloon Wars” of the Secret History of Silicon Valley here

Filed under: Secret History of Silicon Valley | 6 Comments »

Perfection By Subtraction – The Minimum Feature Set

Posted on March 4, 2010 by steve blank

“By knowing things that exist, you can know that which does not exist.”
Book of Five Rings

I was having coffee with a former student who was complained that my idea of building a first product release with a minimum feature set was a bad idea. (One of the principles of Customer Development is to get out of the building and understand the smallest feature-set customers will pay for in the first release.)

“Steve, you’re wrong. I can’t get more than one of ten potential customers to think that this is something they’d buy.” I asked, “So what does the one who likes it say?” “Well he didn’t like it either.” he replied, “but when I started talking about our entire vision, he couldn’t wait to help get our product into his company.”

The Minimum Feature Set is Not The Goal
This minimum feature set (sometimes called the “minimum viable product”) causes lots of confusion. Founders act like the “minimum” part is the goal. Or worse, that every potential customer should want it. In the real world not every customer is going to get overly excited about your minimum feature set. Only a special subset of customers will and what gets them breathing heavy is the long-term vision for your product.

The reality is that the minimum feature set is 1) a tactic to reduce wasted engineering hours (code left on the floor) and 2) to get the product in the hands of early visionary customers as soon as possible.

You’re selling the vision and delivering the minimum feature set to visionaries not everyone.

Why A Minimum Feature Set?
The minimum feature set is the inverse of what most sales and marketing groups ask of their development teams. Usually the cry is for more features, typically based on “Here’s what I heard from the last customer I visited.”

In the Customer Development model, the premise is that a very small group of early visionary customers will guide your product features until you find a profitable business model. Rather than asking customers explicitly about feature X, Y or Z, one approach to defining the minimum features set is to ask, “What is the smallest or least complicated problem that the customer will pay us to solve?”

This rigor of “no new features until you’ve exhausted the search for a business model” counters a natural tendency of people who talk to customers – you tend to collect a list of features that if added, will get one additional customer to buy. Soon you have a ten page feature list just to sell ten customers. Your true goal is to have a feature list that’s just a single paragraph long that you can sell to thousands of customers. Your mantra becomes “Less is more.”

You’re Selling The Vision
Most startups following Customer Development and a Lean Startup methodology understand the idea of a minimal viable product. But they get it wrong in thinking that’s the point. It’s not.

Most customers will not want a product with a minimal feature set. In fact, the majority of customers will hate it. So why do it? Because you are selling the first version of your product to Earlyvangelists.

Earlyvangelists = Early Adopter + Internal Evangelist
Earlyvangelists are a special breed of customers willing to take a risk on your startup’s product or service. They can actually envision its potential to solve a critical and immediate problem—and they have the budget to purchase it. Unfortunately, most customers don’t fit this profile.

Earlyvangelists can be identified by these characteristics:

They have a problem.
They understand they have a problem.
They are actively searching for a solution and has a timetable for finding it.
The problem is painful enough that they have cobbled together an interim solution.
They have, or can quickly acquire, dollars to purchase the product to solve their problem.

These Earlyvangelists are first buying the vision and then the product. They need to fall in love with the idea of your product. It’s the vision that will keep them committed the many times you screw up. You’ll have bugs, your product will eat their data, you’ll get the features wrong, performance will be bad, you’ll argue about pricing, etc.

But Earlyvangelists will stick with you through good and bad because they share your vision. In reality Earlyvangelists are now part of your team. If you’re selling to a business, your Earlyvangelists will end up using your slides and metrics to help sell your product inside their own company!

This means Earlyvangelists, particularly in corporations, will be buying into your entire vision, not just your first product release. They will need to hear what your company plans to deliver over the next 18 to 36 months.

That means your Product and Customer Development groups must agree that:

The minimum feature set is spec’d with Earlyvangelist interaction,
You will provide a one-page product vision or roadmap (typically 18 months to 3 years out) that’s shared with Earlyvangelists
Everyone (including the Earlyvangelists) understand the vision is subject to change.

In Customer Development your goal is not to avoid spending money but to preserve your cash as you search for a repeatable and scalable business model. Seeing a repeatable pattern of sales to Earlyvangelists is a sign you may have found your first scalable business model.

Lessons Learned

Minimum feature set (“minimum viable product”) is a Customer Development tactic to reduce engineering waste and to get product in the hands of Earlyvangelists soonest.
Earlyvangelists require a 18 – 36 month product vision past the minimum feature set.
You’re selling the vision and delivering the minimum feature set.

Filed under: Customer Development | 46 Comments »

Death By Competitive Analysis

Posted on March 1, 2010 by steve blank

Trading emails with a startup CEO building an iPhone app, I asked him why potential customers would buy his product. In response he sent me a competitive analysis. It looked like every competitive analysis I had done for 20 years, (ok maybe better.)

And it made me sad. Looking at the spreadsheet, I realized that competitive analysis tables are one of the ways professional marketers screw up startups from day one. And I had done my share.

Here’s why.

Prove What I Already Believe
Most competitive analyses are: 1) sales documents for investors and/or 2) an attempt to rationalize the founders assumptions.

It’s Part of the Plan
Most investors require you to write a business plan which includes a section called a “competitive analysis” in which you tell potential investors how your product compares to products other companies trying to develop and sell to the same customers. While most investors don’t actually read your business plan for a first meeting, a summary of your competitive analysis usually ends up as a slide or two in your PowerPoint presentation.

Your goal in this slide is to tell investors: 1) you understand the market you are selling to, 2) you understand the other companies selling in your market, and 3) you understand how and why you are better than any of the products currently in the market. You are also implicitly telling potential investors, “These features on our competitive slide mean we will sell a lot of what we are planning to build so invest in us.”

Death by Analysis
I looked at the competitive analysis this startup CEO sent to me. This guy was experienced, he worked at lots of large companies, so the table was thorough, it had lots of rows and mentioned all the competitors.

Not only was it wrong, it would set his company back months and possibly even kill them.

Why?

Competitive Analysis Drives Feature Sprawl
In most startups the competitive analysis feature comparison ends up morphing into the Marketing Requirements Document that gets handed to engineering. The mandate becomes; “Our competitors have these features so our startup needs them too. Get to work and add all of these for first customer ship.”

Product development salutes and gets to work building the product. Only after the product ships does the company find out that customers couldn’t have cared less about most of the bells and whistles.

Instead of optimizing for a minimum feature set (that had been defined by customers) a competitive analysis drives a maximum feature set.

This is not good.

Where Are the Customers?
Here’s the problem: How did the founder know which features to choose on the competitive analysis table? When I was running marketing, the answer usually was, “We’ll put up whatever axes or feature comparisons that make us look best in this segment to potential investors. What else would you choose?”

At its best a competitive analysis assumes that you know why customers are going to buy your product. At its worst it exists to rationalize the founder’s assumptions about what they are building. This is a mistake – and it is a contributing factor (if not a root cause) of why most startups get their initial feature set wrong.

If you are building a competitive analysis table, do so only after you understand that the features you are listing matter to customers. Most marketers are happy to build feature comparisons. But customers don’t buy features, they usually buy something that solves a real or perceived need. That’s the comparison you and your investors should be looking at – what do customers say they need or want?

The answer to that question is almost never in your building.

How to Make A Competitive Analysis Useful
A competitive analysis makes sense when your startup is entering an Existing market – where the competitors are known, the customers are known, and most importantly – the basis of competition is known.

(The basis of competition are the features that customers in an existing market have said, “Yes, this is what is extremely important to me. I will dump my current supplier/manufacturer for your new product because yours is smaller/faster/easier to buy/get to/tastes better, etc.)

You win in an existing market when you are better or faster on those metrics that customers have told you are the basis of competition. Your competitive analysis must be around those metrics.

But most startups are not entering an Existing market. They may be trying to:

Take a segment of an existing market by offering a product that
1) costs less (trading fewer features for a lower price) or
2) addresses the specific needs of a customer segment that the existing suppliers have failed to address

Or they may be creating an entirely new market with a disruptive innovation that never existed before.

In a Resegmented market, a competitive analysis starts with the hypothesis of “Here’s the problem we are solving for customers.” The competitive analysis chart highlights the product features that differentiate your startup from the existing market incumbents because of your understanding of specific customer needs (not your opinion) in this niche.

In a New market a competitive analysis starts with the hypothesis of “We are creating something that never existed before for customers.” The competitive analysis table highlights the product features that show what customers could never do before. It compares your company to groups of products or services.

I asked the CEO to go back to the competitive analysis and tell me whether he really knew what features matter most to potential customers. If not, he should get out of the building and find out.

Lessons Learned

Too often competitive analysis drives product requirements in startups.

This can lead engineering to build the maximum feature set rather than minimum feature set.

You need to get outside the building and figure out what features matter to most customers.

No feature lists without facts.