The Customer Development Manifesto: Reasons for the Revolution (part 1)

This post makes more sense if you read the previous post – The Leading Cause of Startup Death: The Product Development Diagram.

After 20 years of working in startups, I decided to take a step back and look at the product development model I had been following and see why it usually failed to provide useful guidance in activities outside the building – sales, marketing and business development.

Every startup has some methodology for product development, launch and life-cycle management. At their best, these processes provide detailed plans, checkpoints and milestones for every step in getting a product out the door: sizing markets, estimating sales, developing marketing requirements documents, prioritizing product features.  Yet at the end of the day even with all these processes 9 out of 10 of new products are failures.

So what’s wrong the product development model? The first hint lies in its name; this is a product development model, not a marketing model, not a sales hiring model, not a customer acquisition model, not even a financing model (and we’ll also find that in most cases it’s even a poor model to use to develop a product.) Yet startup companies have traditionally used this model to manage and pace not only engineering but also non-engineering activities.

In this post I’m going to describe the flaws of the product development model.  In the next few posts that follow, I’ll describe more specifically how this model distorts startup sales, marketing and business development. And how thinking of a solution to this commonly used model’s failures led to a new model – the Customer Development Model – that offers a new way to approach startup activities outside the building. Finally, I’ll write about how Eric Ries and the Lean Startup concept provided the equivalent model for product development activities inside the building and neatly integrates customer and agile development.

Product Development Diagram

Product Development Diagram

1. Where Are the Customers?
To begin with, the product development model completely ignores a fundamental truth about startups and new products. The greatest risk in startups —and hence the greatest cause of failure—is not the technology risk of developing a product but in the  risk of developing customers and markets. Startups don’t fail because they lack a product; they fail because they lack customers and a profitable business model. This alone should be a pretty good clue about what’s wrong with using the product development diagram as the sole guide to what a startup needs to be doing. Look at the Product Development model and you might wonder, “Where are the customers?”

The reality for most startups today is that the product development model focuses all their attention on activities that go on inside a company’s own building. While customer input may be a checkpoint or “gate” in the process, it doesn’t drive it.

2. The Focus on a First Customer Ship Date
Using the Product Development model also forces sales and marketing to focus on the end point of the process – the first customer ship date. Most sales and marketing executives hired into a startup look at the “first customer ship date,” look at the calendar on the wall, and then work backwards figuring out how to do their job in time so that the fireworks start the day the product is launched.

The flaw in this thinking is that “first customer ship” is simply the date when engineering thinks they “finished” the 1.0 release of the product. The first customer ship date does not mean that the company understands its customers, how to market or sell to them or how to build a profitable business. (Read the preceding sentence again. It’s a big idea.)

Even worse, a startup’s investors are managing their financial milestones by the first customer ship date as well.

The product development model is so focused on building and shipping the product that it ignores the entire process of testing your basic hypothesis about your business model (customers, channel, pricing, etc.) before you ship. Not testing these hypotheses upfront is a fundamental and, in many cases, fatal error most startups make.

Why? Because it isn’t until after first customer ship that a startup discovers that their initial hypotheses were simply wrong (i.e. customers aren’t buying it, the cost of distribution is too high, etc.) As a result the young company is now saddled with an expensive, scaled-up sales organization frustrated trying to execute a losing sales strategy and a marketing organization desperately trying to create demand without a true understanding of customers’ needs.

As Marketing and Sales flail around in search of a sustainable market, the company is burning through its most precious asset—cash.

3. The Focus on Execution Versus Learning and Discovery
The product development model assumes that customers needs are known, the product features are known, and your business model is known. Given this certainty, it’s logical that a startup will hire a sales and marketing team to simply execute your business plan. You interview sales and marketing execs for prior relevant experience and their rolodexes, and hope they execute the playbook that worked for them in prior companies.

All of this is usually a bad idea.  No one asks, “Why are we executing like we know what we are doing? Where exactly did the assumptions in our startup business plan come from?”  Was the sales revenue model based on actually testing the hypotheses outside the building? Or were they a set of spreadsheets put together over late night beers to convince an investor that this is going to be a great deal?

No newly hired sales and marketing exec is going to tell a founder, “Hey my prior experience and assumptions may not actually be relevant to this new startup.” Great sales and marketing people are great at execution – that’s what you hired for. But past experience may not be relevant for your new company. A new company needs to test a series of hypothesis before it can successfully find a repeatable and scalable sales model. For startups in a new or resgemented market, these are not merely execution activities, they are learning and discovery activities that are critical to the company’s success or failure.

4. The Focus on Execution Versus Agility
The product development diagram has a linear flow from left to right. Each step happens in a logical progression that can be PERT charted with milestones and resources assigned to completing each step.

Anyone who has ever taken a new product out to a set of potential customers can tell you that the real world works nothing like that. A good day in front of customers is two steps forward and one step back. In fact, the best way to represent what happens outside the building is more like a series of recursive circles—recursive to represent the iterative nature of what actually happens in a learning and discovery environment. Information and data are gathered about customers and markets incrementally, one step at a time. Yet sometimes those steps take you in the wrong direction or down a blind alley. You find yourself calling on the wrong customers, not understanding why people will buy, not understanding what product features are important. Other times potential customers will suggest a new use for the product, new positioning or even a much better idea.

The ability to learn from those missteps, to recognize new opportunities, and to rapidly change direction is what distinguishes a successful startup from those whose names are forgotten among the vanished.

5. The Outsourcing of Founders Responsibility
The Product Development model separates founders from deeply understanding their customers and market. The responsibility for validating the founders original hypotheses is delegated to employees – the sales and marketing team.

This means the founders are isolated from directly hearing customer input – good, bad and ugly. Worse, founders really won’t understand whether customers will buy and what features are saleable until after first customer ship.

When an adroit and agile founder gets outside the building and hears for the nth time that the product is unsellable they will recognize, regroup and change direction. A process to give the founders continuous customer interaction – from day one – is essential.

6. The Focus on a Finished Product Rather than a Minimum Feature Set
The passion of an entrepreneur coupled with the product development diagram drives you to believe that all you need to do is build the product (in all its full-featured glory) and customers will come. A Waterfall development process reinforces that inanity. The reality is quite different.  Unless you are in an Existing Market, (making a better version of what customers are already buying) you’ll find that your hypothesis about what features customers want had no relationship to what they really wanted.

Most startup code ends up on the floor.

7. Investor Focus on a Broken Model
Ask VC’s why they use the Product Development model to manage a startup and you get answers like, “It’s the way my firm has always done it. Why change something that has worked so well over the last three decades?” Or, “Look at our returns, its always worked for us.” Or at times an even more honest answer, “My senior partners say this is the only way to do it.”

Some firms correctly point out that, “It’s fine if 8 out of 10 of our companies fail if the remaining two return 20x our money. That’s a better return than having 10 out of 10 companies succeed and each return 2x our money.  Therefore we don’t want startups doing anything but swinging for the fences.”

The fallacy is that the product development model is the most efficient model for new ventures swinging for the fences– this year, last year, last decade, or since the first startup met their first investor.

Venture portfolio companies don’t succeed because they used the Product Development model they succeeded in spite of using itThe fact is most successful startups abandon the product development model as soon as they encounter customers.

Today, startups using the product development model iterate and learn and discover by burning investor cash. When cash is tight, they go out of business – or they adopt a more efficient model.

—–

Part 2 of the Customer Development Manifesto to follow.

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

The Leading Cause of Startup Death – Part 1: The Product Development Diagram

When I started working in Silicon Valley, every company bringing a new product to market used some form of the Product Development Model.  Thirty years later we now realize that its one the causes of early startup failure. This series of posts is a brief explanation of how we’ve evolved from Product Development to Customer Development to the Lean Startup.

The Product Development Diagram
Emerging early in the twentieth century, this product-centric model described a process that evolved in manufacturing industries. It was adopted by the consumer packaged goods industry in the 1950s and spread to the technology business in the last quarter of the twentieth century. It has become an integral part of startup culture.

At first glance, the diagram, which illustrates the process of getting a new product into the hands of waiting customers, appears helpful and benign.  Ironically, the model is a good fit when launching a new product into an existing, well-defined market where the basis of competition is understood, and its customers are known.

The irony is that few startups fit these criteria. (None of mine did.)  We had no clue what our market was when we first started. Yet we used the product development model not only to manage product development, but as a road map for finding customers and to time our marketing launch and sales revenue plan. The model became a catchall tool for all schedules, plans, and budgets. Our investors used the product development diagram in our board meeting to see if we were “on plan” and “on schedule.” Everyone was using a road map that was designed for a very different location, yet they are surprised when they end up lost.

Product Development Diagram

Product Development Diagram

To see what’s wrong with using the product development model as a guide to building a startup, let’s first examine how the model is currently used to launch a new product. We’ll look at the model stage-by-stage.

Concept and Seed Stage
In the Concept and Seed Stage, founders capture their passion and vision for the new company and turn them into a set of key ideas, which quickly becomes a business plan, sometimes on the back of the proverbial napkin. The first thing captured and wrestled to paper is the company’s vision.

Then the product needs to be defined: What is the product or service concept? What are the features and benefits? Is it possible to build? Is further technical research needed to ensure that the product can be built?

Next, who will the customers be and where will they be found? Statistical and market research data plus potential customer interviews determine whether the ideas have merit.

After that there’s a discussion of how the product will reach the customer and the potential distribution channel. The distribution discussion leads to some conclusions about competition: who are they and how they differ. The startup develops its first positioning statement and uses this to explain the company and its benefits to venture capitalists.

The distribution discussion also leads to some assumptions about pricing. Combined with product costs, an engineering budget, and schedules, this results in a spreadsheet that faintly resembles the first financial plan in the company’s business plan. If the startup is to be backed by venture capitalists, the financial model has to be alluring as well as believable. If it’s a new division inside a larger company, forecasts talk about return on investment.  in this concept and seed stage, creative writing, passion, and shoe leather combine  in hopes of convincing an investor to fund the company or the new division.

Product Development
In stage two, product development, everyone stops talking and starts working. The respective departments go to their virtual corners as the company begins to specialize by functions.

Engineering focuses on building the product; it designs the product, specifies the first release and hires a staff to build the product. It takes the simple box labeled “product development” and makes detailed critical path method charts, with key milestones. With that information in hand, Engineering estimates delivery dates and development costs.

Meanwhile, Marketing refines the size of the market defined in the business plan (a market is a set of companies with common attributes), and begins to target the first customers. In a well-organized startup (one with a fondness for process),  the marketing folk might even run a focus group or two on the market they think they are in and prepare a Marketing Requirements Document (MRD) for Engineering. Marketing starts to build a sales demo, writes sales materials (presentations, data sheets), and hires a PR agency. In this stage, or by alpha test, the company traditionally hires a VP of Sales who begins to assemble a sales force.

Alpha/Beta Test
In stage three, alpha/beta test, Engineering works with a small group of outside users to make sure that the product works as specified and tests it for bugs. Marketing develops a complete marketing communications plan, provides Sales with a full complement of support material, and starts the public relations bandwagon rolling. The PR agency polishes the positioning and starts contacting the long lead-time press while Marketing starts the branding activities.

Sales signs up the first beta customers (who volunteer to pay for the privilege of testing a new product), begins to build the selected distribution channel, and staffs and scales the sales organization outside the headquarters. The venture investors start measuring progress by number of orders in place by first customer ship.

Hopefully, somewhere around this point the investors are happy with the company’s product and its progress with customers, and the investors are thinking of bringing in more money. The CEO refines his or her fund-raising pitch and hits the street and the phone searching for additional capital.

Product Launch and First Customer Ship
Product launch and first customer ship is the final step in this model, and the goal the company has been driving for. With the product working (sort of), the company goes into “big bang” spending mode. Sales is heavily building and staffing a national sales organization; the sales channel has quotas and sales goals. Marketing is at its peak. The company has a large press event, and Marketing launches a series of programs to create end-user demand (trade shows, seminars, advertising, email, and so on). The board begins measuring the company’s performance on sales execution against its business plan (which typically was written a year or more earlier, when the entrepreneur was looking for initial investments).

Building the sales channel and supporting the marketing can burn a lot of cash. Assuming no early liquidity (via an IPO or merger) for the company, more fund raising is required. The CEO looks at the product launch activities and the scale-up of the sales and marketing team, and yet again goes out, palm up, to the investor community. (In the dot-com bubble economy, the investors used an IPO at product launch to take the money and run, before there was a track record of success or failure.)

The Leading Cause of Startup Death
If you’ve ever been involved in a startup, the operational model no doubt sounds familiar. It is a product-centric and process-centric model used by countless startups to take their first product to market.  It used to be if you developed a plan on model that looked like this your investors would have thought you were geniuses.

In hindsight both you and your investors were idiots. Following this diagram religiously will more often than not put you out of business. The diagram was developed to be used by existing companies doing product line extensions – not startups creating new markets or resegmenting existing ones. Most experienced entrepreneurs will tell you that the model collapses at first contact with customers.

VC’s who still believe in the product development model in the 21st century offer no value in building a company other than their rolodex and/or checkbook.

Coming next Part 2: What’s Wrong with Product Development as a Model?

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Coffee With Startups

I’ve just met four great startups in the last three days.

An Existing Market
All four were trying to resegment an “Existing Market.” An existing market is one where competitors have a profitable business selling to customers who can name the market and can tell you about the features that matter to them. Resegmentation means these startups are trying to lure some of the current or potential customers away from incumbents by either offering a lower cost product, or by offering features that appealed to a specific niche or subset of the existing users.

Some of the conversations went like this:

Startup 1
Entrepreneur -“I’m competing against Company x and have been following the Customer Development process and I’ve talked to lots of customers.”
Me – “Have you used Company x’s product? Do you know have they distribute their product? Do you know how they create demand? Do you know how many units they are selling? Do you know the archetype of their customers?
Entrepreneur -“Well no but my product is much better than their product and I have this great idea….”

Rule 1: In an existing market Customer Development means not only understanding potential customers, but your competitors in detail – their product features, their sales channels, their demand creation strategy, their business model, etc.

Startup 2
Entrepreneur -“I’m competing against Company x and we are going to offer a lower-cost, web-based version. We’re about to ship next week.”
Me –“That’s a great hypothesis, do customers tell you that they’d buy your version if it was cheaper or on the web?
Entrepreneur -“Well no but my product is much cheaper and everyone’s on the web and I have this great idea….”

Rule 2: In an existing market Customer Development means understanding whether your hypothesis of why customers will buy match reality. This is easy to test. Do this before you write code you may end up throwing away.

Startup 3
Entrepreneur -“I’m competing against Large Company x and we solve problems for a set of customers – I’ve talked to many of them and they would buy it.”
Me – “So what’s the problem?”
Entrepreneur – “We just started letting early customers access the product and adoption/sales isn’t taking off the way we thought it would. We only have 20 customers, and Large Company x has millions.”
Me – “How are you positioning your product?”
Entrepreneur – “We tell potential customers about all our features.”

Rule 3: In an existing market directly compare your product against the incumbent and specifically describe the problems you solve and why Company x’s products do not.”

Startup 4
Entrepreneur -“I have something really, really new. No one has anything like it.”
Me – “Isn’t it kind of like Twitter but better?”
Entrepreneur – “You don’t get it.”

Rule 4: You may want to think twice positioning as a New Market. If customers immediately get an analogy for your product, don’t dissuade them. Save the “New Billion Dollar Market” positioning for the investors, not customers.

Lessons Learned

  • Deeply understand the incumbents that make up the Existing Market
  • The “hypotheses tested to lines of code written” ratio ought to be high
  • Position against the incumbents weaknesses – their customers will tell you what they are
  • Existing Markets adoption rates are measured in % market share gained, New Markets have adoption rates which may occur in your company’s lifetime

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Touching the Hot Stove – Experiential versus Theoretical Learning

I’m a slow learner.  It took me 8 startups and 21 years to get it right, (and one can argue success was due to the Internet bubble rather then any brilliance.)

In 1978 when I joined my first company, information about how to start companies simply didn’t exist. No internet, no blogs, no books on startups, no entrepreneurship departments in universities, etc.  It took lots of trial and error, learning by experience and resilience through multiple failures.

The first few months of my startups were centered around building the founding team, prototyping the product and raising money. Since I wasn’t an engineer, my contribution was around the team-building and fund raising.

I was an idiot.

Customer Development/Lean Startups
In hindsight startups and the venture capital community left out the most important first step any startup ought to be doing – hypothesis testing in front of customers- from day one.

I’m convinced that starting a company without talking to customers is like throwing your time and money in the street (unless you’re already a domain expert).

This mantra of talking to customers and iterating the product is the basis of the Lean Startup Methodology that Eric Ries has been evangelizing and I’ve been teaching at U.C. Berkeley and at Stanford. It’s what my textbook on Customer Development describes.

Experiential versus Theoretical Learning
After teaching this for a few years, I’ve discovered that subjects like Lean Startups and Customer Development are best learned experientially rather than solely theoretically.

Remember your parents saying, “Don’t touch the hot stove!”  What did you do?  I bet you weren’t confused about what hot meant after that. That’s why I make my students spend a lot of time “touching the hot stove” by talking to customers “outside the building” to test their hypotheses.

However, as hard as I emphasize this point to aspiring entrepreneurs every year I usually get a call or email from a past student asking me to introduce them to my favorite VC’s.  The first questions I ask is “So what did you learn from testing your hypothesis?” and “What did customers think of your prototype?”  These questions I know will be on top of the list that VC’s will ask.

At least 1/3 of the time the response I get is, “Oh that class stuff was real interesting, but we’re too busy building the prototype. I’m going to go do that Customer Development stuff after we raise money.”

Interestingly this response almost always comes from first time entrepreneurs.  Entrepreneurs who have a startup or two under their belt tend to rattle off preliminary customer findings and data that blow me away (not because I think their data is going to be right, but because it means they have built a process for learning and discovery from day one.)

Sigh.  Fundraising isn’t the product.  It’s not a substitute for customer input and understanding.

Sometimes you need a few more lessons touching the hot stove.

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

He’s Only in Field Service

The most important early customers for your startup usually turn out to be quite different from who you think they’re going to be.

He’s Only in Field Service
When I was at Zilog, the Z8000 peripheral chips included the new “Serial Communications Controller” (SCC). As the (very junior) product marketing manager I got a call from our local salesman that someone at Apple wanted more technical information than just the spec sheets about our new (not yet shipping) chip. I vividly remember the sales guy saying, “It’s only some kid in field service. I’m too busy so why don’t you drive over there and talk to him.”  (My guess is that our salesman was busy trying to sell into the “official” projects of Apple, the Lisa and the Apple III.)

Zilog was also in Cupertino near Apple, and I remember driving to a small non-descript Apple building at the intersection of Stevens Creek and Sunnyvale/Saratoga. I had a pleasant meeting and was as convincing as a marketing type could be to a very earnest and quirky field service guy, mostly promising the moon for a versatile but then very buggy piece of silicon. We talked about some simple design rules and I remember him thanking me for coming, saying we were the only chip company who cared enough to call on him (little did he know.)

I thought nothing about the meeting until years later. Long gone from Zilog I saw the picture of the original Macintosh design team. The field service guy I had sold the chip to was Burrell Smith who had designed the Mac hardware.

The SCC had been designed into the Mac and became the hardware which drove all the serial communications as well as the AppleTalk network which allowed Macs to share printers and files.

Some sales guy who was too busy to take the meeting was probably retired in Maui on the commissions.

Your Customers are Not Who You Think
For years I thought this “million unit chip sale by accident” was a “one-off” funny story. That is until I saw that in startup after startup customers come from places you don’t plan on.

Unfortunately most startups learn this by going through the “Fire the first Sales VP” drill: You start your company with a list of potential customers reading like a “who’s who” of whatever vertical market you’re in (or the Fortune 1000 list.) Your board nods sagely at your target customer list.  A year goes by, you miss your revenue plan, and you’ve burned through your first VP of Sales.  What happened?

What happened was that you didn’t understand what “type of startup” you were and consequently you never had a chance to tailor your sales strategy to your “Market Type.” Most startups tend to think they are selling into an Existing market – a market exists and your company has a faster and better product. If that’s you, by all means hire a VP of Sales with a great rolodex and call on established mainstream companies – and ignore the rest of this post.

Market Type
But most startups aren’t in existing markets.  Some are resegmenting an existing market–directed at a niche that an incumbent isn’t satisfying (like Dell and Compaq when they were startups) or providing a low cost alternative to an existing supplier (like Southwest Airlines when it first started.) And other startups are in a New Market — creating a market from scratch (like Apple with the iPhone, or iPod/iTunes.)

(“Market Type” radically changes how you sell and market at each step in Customer Development. It’s one of the subtle distinctions that at times gets lost in the process. I cover this in the Four Steps to the Epiphany.)

market-type

Five Signs You Can Sell to a Large Company
If you’re resegmenting an existing market or creating a new market, the odds are low that your target list of market leaders will become your first customers. In fact having any large company buy from you will be difficult unless you know how to recognize the five signs you can get a large company to buy from a startup:

  • They have a problem
  • They know they have a problem
  • They’ve been actively looking for a solution
  • They tried to solve the problem with piece parts or other vendors
  • They have or can acquire a budget to pay for your solution

I advise startups to first go after the companies that aren’t the market leaders in their industries, but are fighting hard to get there. (They usually fit the checklist above.) Then find the early adopter/internal evangelist inside that company who wants to gain a competitive advantage. These companies will look at innovative startups to help them gain market share from the incumbent.

Sell to the Skunk Works
The other place for a startup to go is the nooks and crannies of a market leader.  Look for some “skunk works” project where the product developers are actively seeking alternatives to their own engineering organization.  In Apple’s case Burrell Smith was designing a computer in a skunk works unbeknownst to the rest of Apple’s engineering.  He was looking for a communications chip that could cut parts cost to build an innovative new type of computer – which turned out to be the Mac.

Lessons Learned

  • Early customers are usually not where you first think they are
  • Where they are depends on Market Type
  • Look for aggressive number 2’s or 3’s who are attacking a market leader
  • Look for a “skunk works” inside a market leader

Download the podcast here or here

an early version of this story appeared on folklore.org

The Road Not Taken

At Zilog I was figuring out how to cope with job burnout.  And one of my conclusions was that I needed to pick one job not two. I had to decide what I wanted to do with my career – go back to ESL, try to work for the Customer, or stay at Zilog?

While it may seem like an easy choice, few people who love technology and who work on black projects leave.  These projects are incredibly seductive.  Let me explain why.

National Efforts
In World War II the U.S. put its resources behind a technical project that dwarfed anything every built – the atomic bomb.  From a standing start in 1942 the U.S. scaled up the production of U-235 and plutonium from micrograms to tens of kilograms by 1945. We built new cities in Hanford, Oak Ridge and Los Alamos and put 130,000 people to work on the project.

During the cold war, the U.S. government kept up the pace.  Hundreds of thousands of people worked on developing strategic weapons, bombers, our ICBM and SLBM missile programs, and the Apollo moon program. These programs dwarfed the size that any single commercial company could do by itself.  They were national efforts of hundreds of companies employing 10’s or 100’s of thousands of engineers.

ESL – National Technical Means of Verification
The project I was working on at ESL fit this category. The 1970’s and ‘80’s were the endgame of the cold war, and the U.S. military realized that our advantage over the Soviet Union was in silicon, software and systems. These technologies which allowed the U.S. to build sensors, stealth and smart weapons previously thought impossible or impractical, would give us a major military advantage.  Building these systems required resources way beyond the scope of a single company.  Imagine coming up with an idea that could work only if you had your own semiconductor fab and could dedicate its output to make specialized chips just for you.  Then imagine you’d have to get some rockets and put this reconnaissance system in space – no, make that several rockets. No one laughed when ESL proposed this class of project to “the customer.”

If you love technology, these projects are hard to walk away from.

The Road Not Taken
At first, I thought my choice was this: working on great technology at ESL or continuing to work on these toy-like microprocessors at Zilog.

But the more I thought about it, the choice wasn’t about the hardware or systems.  There was something about the energy and passion Zilog’s customers had as they kept doing the most unexpected things with our products.

While I couldn’t articulate at it at the time (it would take another 25 years) at ESL the company and the customer had a known problem and were executing to building a  known solution, with a set of desired specifications and PERT charts telling them what they needed to do and in what order to achieve the goal.  There was a ton of engineering innovation and coordination along the way, and the project could have failed at any point. But the insight and creativity occurred at the project’s beginning when the problem and solution was first being defined.  Given where I was in the hierarchy, I calculated that the odds of me being in on those decisions didn’t look high – ever.

In contrast, my customers at Zilog had nothing more than a set of visions, guesses and hallucinations about their customers; who they were, what they wanted to achieve and what was the right path to get there.  At these startups both the problem and solution were unknown.

Startups were not just smaller versions of a large company, they were about invention, innovation and iteration – of business model, product, customers and on and on. Startups were doing discovery of the problem and solution in real-time.  I could see myself doing that – soon.

Unbeknownst to me, I was facing a choice between becoming an entrepreneur or working for a large company.

I chose a path and never looked back.

——

Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth;
Then took the other, as just as fair,
And having perhaps the better claim,
Because it was grassy and wanted wear;
Though as for that the passing there
Had worn them really about the same,
And both that morning equally lay
In leaves no step had trodden black.
Oh, I kept the first for another day!
Yet knowing how way leads on to way,
I doubted if I should ever come back.
I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I—
I took the one less traveled by,
And that has made all the difference.

Robert Frost – The Road Not Taken – 1916

Lessons Learned

  • There is no “right” choice for a career
  • There’s only the choice you make
  • Don’t let a “career” just happen to you
  • A startup is not a smaller version of a large company

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Burnout

If you hang around technology companies long enough, you or someone you know may experience “burnout” – a state of emotional exhaustion, doubt and cynicism.  Burnout can turn productive employees into emotional zombies and destroy careers. But it can also force you to hit the pause button and perhaps take a moment to reevaluate your life and your choices.

Hitting “burnout” changed the trajectory of both ends of my career in Silicon Valley. This post, which is divided in two parts, is the story of the first time it happened to me.

Zilog
Zilog was my first Silicon Valley company where you could utter the customer’s name in public. Zilog produced one of the first 8-bit microprocessors, the Z-80 (competing at the time with Intel’s 8080, Motorola 6800, and MOS Technology 6502.)

I was hired as a training instructor to teach microprocessor system design for the existing Z-80 family and to write a new course for Zilog’s soon to be launched 16-bit processor, the Z-8000. Given the hardware I had worked on at ESL, learning microprocessors wasn’t that hard but figuring out how to teach hardware design and assembly language programming was a bit more challenging.  Luckily while I was teaching classes at headquarters, Zilog’s field application engineers (the technical engineers working alongside our salesmen) would work side-by-side with our large customers as they designed their systems with our chips. So our people in the field could correct any egregious design advice I gave to customers who mattered.

Customers
The irony is that Zilog had no idea who would eventually become its largest customers.  Our salesmen focused on accounts that ordered the largest number of chips and ignored tiny little startups that wanted to build personal computers around these chips (like Cromemco, Osborne, Kaypro, Coleco, Radio Shack, Amstrad, Sinclair, Morrow, Commodore, Intertec, etc.) Keep in mind this is still several years before the IBM PC and DOS. And truth be told, these early systems were laughable, at first having no disk drives (you used tape cassettes,) no monitors (you used your TV set as a display,) and no high level programming languages.  If you wanted your own applications, you had to write them yourself. No mainframe or minicomputer company saw any market for these small machines.

Two Jobs at Once
When I was hired at Zilog part of the deal was that I could consult for the first six months for my last employer, ESL.

Just as I was getting settled into Zilog, the manager of the training department got fired.  (I was beginning to think that my hiring managers were related to red-shirted guys on Star Trek.)  Since the training department was part of sales no one really paid attention to the four of us.  So every day I’d come to work at Zilog at 9, leave at 5 go to ESL and work until 10 or 11 or later.  Repeat every day, six or seven days a week.

Meanwhile, back at ESL the project I was working on wanted to extend my consulting contract, the company was trying to get me to return, and in spite of what I had done on the site, “the customer” had casually asked me if I was interested in talking to them about a job.  Life was good.

But it was all about to catch up to me.

Where Am I?
It was a Friday (about ¾’s through my work week) and I was in a sales department meeting. Someone mentioned to me that there were a pile of upcoming classes heading my way, and warned me “remember that the devil is in the details.”  The words “heading my way” and “devil” combined in my head. I immediately responded, “well that’s OK, I got it under control – as long as the devil coming at me isn’t an SS-18.”  Given that everyone in the room knew the NATO codename for the SS-18 was SATAN, I was thinking that this was a witty retort and expected at least a chuckle from someone.

I couldn’t understand why people were staring at me like I was speaking in tongues. The look on their faces were uncomfortable.  The VP of Sales gave me a funny look and just moved on with the agenda.

VP of Sales?  Wait a minute.. where am I?

I looked around the room thinking I’d see the faces of the engineers in the ESL M-4 vault, but these were different people.  Who were these people?  I had a moment of confusion and then a much longer minute of panic trying to figure out where I was.  I wasn’t at ESL I was at Zilog.  As I realized what I had said, a much longer panic set in.  I tried to clear my head and remember what else I had said, like anything that would be really, really, really bad to say outside of a secure facility.

As I left this meeting I realized I didn’t even remember when I had left ESL or how I had gotten to Zilog.  Something weird was happening to me.  As I was sitting in my office looking lost, the VP of Sales came in and said, “you look a bit burned out, take it easy this weekend.”

“Burned out?” What the heck was that? I had been working at this pace since I was 18.

Burnout
I was tired.  No I was more than tired, I was exhausted. I had started to doubt my ability to accomplish everything. Besides seeing my housemates in Palo Alto I had no social life. I was feeling more and more detached at work and emotionally drained. Counting the Air Force I had been pounding out 70 and 80 hour weeks nonstop for almost eight years. I went home and fell asleep at 7pm and didn’t wake up until the next afternoon.

The bill had come due.

Recovery
That weekend I left the Valley and drove along the coast from San Francisco to Monterey. Crammed into Silicon Valley along with millions of people around the San Francisco Bay it’s hard to fathom that 15 air miles away was a stretch of California coast that was still rural. With the Pacific ocean on my right and the Santa Cruz Mountains on my left, Highway 1 cut through mile after mile of farms in rural splendor.  There wasn’t a single stop-light along 2-lane highway for the 45 miles from Half Moon Bay to Santa Cruz.  Looking at the green and yellows of the farms, I realized that my life lacked the same colors.  I had no other life than work. While I was getting satisfaction from what I was learning, the sheer joy of it had diminished.

As the road rolled on, it dawned on me that there was no one looking out for me. There was no one who was going to tell me, “You’ve hit your limit, now work less hours and go enjoy yourself.” The idea that only I could be responsible for taking care of my happiness and health was a real shock.  How did I miss that?

At the end of two days I realized,

  • This was the first full weekend I had taken off since I had moved to California
    3 years ago.
  • I had achieved a lot by working hard, but the positive feedback I was getting just encouraged me to work even harder.
  • I needed to learn how to relax without feeling guilty.
  • I needed a life outside work.

And most importantly I needed to pick one job not two. I had to make a choice about where I wanted to go with my career–back to ESL, try to work for the Customer or stay at Zilog?

More about that choice in the next post.

Lessons Learned

  • No one will tell you to work fewer hours
  • You need to be responsible for your own health and happiness
  • Burnout sneaks up on you
  • Burnout is self-induced.  You created it and own it.
  • Recovery takes an awareness of what happened and…
  • A plan to change the situation that got you there

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Rocket Science 5: Who Needs Domain Experts

What Business Are We In?
While the Rocket Science press juggernaut moved inexorably forward, a few troubling facts kept trying to bubble up into my consciousness. The company was founded to build games with embedded video to bring Hollywood stories, characters, and narratives to a market where “shoot and die” twitch games were in vogue. But underlying the company’s existence was a fundamental hypothesis we refused to see or test – customers would care if we did.

In the game business of the early 1990’s video was at best a brief narrative, a distraction you maybe watched once, not the core of the game. Our potential customers didn’t seem to be calling for Hollywood stories, characters and narrative. That’s OK, because we knew better. We thought we had figured out what the next generation of games was going to be. We were thinking we were in the movie business, but video games were more akin to pinball; both pinball and movies were entertainment but you would never confuse them with each other. Successful pinball companies didn’t hire Hollywood talent.

Meanwhile our company was pouring an enormous amount of dollars into building tools and video compression technology, while also hiring a lot of high-priced Hollywood talent like art directors, and script and story editors.

We Don’t Need Domain Experts
When I looked around at our executive staff, there wasn’t a single founder who was a gamer. Worse, there wasn’t a single person on our executive team who had come from a game company.  Nor was there anyone with game experience on our board. As the company grew a sense of unease started gnawing at the outer fringes of the “you’re in trouble” part of my brain. Meanwhile my partner was in heaven working with his newly hired group of game designers directing and producing our first games. When I pointed out my rising apprehension his response was, “I’ve been playing games since I was 10. I know what’s great and what’s not. We agreed this part of the company was my responsibility. Don’t worry the games are going to be great.” Given my fiduciary responsibility to my board and my investors did his blasé answer force me to grab him by the collar and scream, “Snap out of it, we’re in trouble!”

Nah. Instead I said, “Oh, OK, glad it’s all under control.” Then I went back to raising more money and getting more press for our soon to be spectacular games.

Hire Advice I Can Ignore
But the nagging little voice in the back of my head that said, “This doesn’t feel right,” wouldn’t go away.  So I hired a VP of Marketing from Sega, one of the video game platforms on which our games would run.  After only two weeks on the job, he came into my office and said, “Have you’ve seen the games we are building?”  What kind of question was that?   Of course I had seen pieces of the video we shot and beautiful storyboards. “No,” he insisted, “Have you seen the game play, the part that supposed to keep  players addictively glued to the game console for hours?”   Hmm.  “No, not really, but my partner owns the studio and tells me it’s spectacular and everyone will love it.  Don’t bother him; he knows what he’s doing.  Go spend some time outside the building talking to potential distribution partners.  Tell them how great it’s going to be and see how many pre-orders we can get.”

A month later the VP of Marketing appeared in my office again.  “Steve I have to tell you some bad news, I just showed our potential channel partners and customers a few completed pieces of the games we had. They think the games stink.”

loadstar

Now I know I heard his words because years later I can still remember them well enough to write them down.  But somehow the translation between my ears and what I was supposed to do with what I was hearing shut down. Was my response to stop development of the games?  Bring in some outside professionals to review our progress?  Call a board meeting and say we may have a serious problem?  Nah. I said, “That can’t be true! The press is saying we are the hottest super group around.  Look, we’re on the cover of Wired magazine.  They think we’re brilliant.  Our VCs think we are visionary. Stop annoying our game designers and start working on selling and marketing the games.”

Hindsight
In hindsight it’s easy to laugh.  Saying you knew how to build great games because you played them all your life was like saying, “Hey I  eat out a lot so why don’t I open a restaurant.” Or “I’ve seen a lot of movies so let’s start a movie studio.”  Only in Silicon Valley could we have got funded with this idea, and not surprisingly, it was our technology that had the VC’s confused. It was more like we had invented the world’s best new kitchen utensils and wanted to open a restaurant, or had built the world’s finest movie cameras and wanted to start a movie studio. Our venture backers and our executive team confused our technology and our tools — and our passion for the games business — with any practical experience in the real business we were in.  We were an entertainment business – and not a very subtle entertainment business.  As we were about to find out, if video game players wanted a cinematic experience, they went to the movies, they didn’t buy a video game.  Our customers wanted to kill, shoot or hunt for something.  Fancy video narratives and plots were not video games.

Interest Alignment
Why VC’s invested in companies like ours is what’s great and bad about entrepreneurship.  A Venture Capitalist I respect reminded me that he thought about investment risk as either:

  • investing $1 million in 10 companies and have all ten succeed.  With each of those ten companies returning 2x their money for $20 million. Or
  • investing in 10 companies and having 8 fail  – but the remaining two companies returning 20x their money for $40 million.

His point was that it was in the VC’s interest in having entrepreneurs swing for the fences.

However the VC’s are managing a portfolio while you, the entrepreneur are managing one company – yours.  While VC’s might love you and your firm, a 2x return isn’t why they’re in business.  It’s nothing personal, but your interests and your VC’s may not be aligned. (More on this in future posts.)

The Search for the Black Swan
What keeps founders and their investors going is the the dream/belief that your startup will be the Black Swan – a company that breaks all the obvious rules, ignores tradition and does something unique and spectacular and with a result that is unpredicted and financial returns that are breathtaking.

Think of the Microprocessor, Personal Computer, Internet, Twitter, Youtube, Facebook, Google, the iPhone. Creating those technologies and companies required entrepreneurs willing to follow their own vision and convincing  others that the path is worth following.

The mistake isn’t having a vision and taking risks.  The mistake is assuming you are a Black Swan and continuing to ignore the facts as they pile up in front of you.

Customer Development
There was nothing wrong about Rocket Science having a vision radically different than the conventional wisdom.  We could have been right and invented a new form of gaming and entertainment. What went awry was continuing to execute on the vision when all the evidence in front of us told us our hypothesis was wrong.  We compounded the problem when we failed to have an honest discussion about why it made sense to ignore the evidence.  (A tip-off is when you start saying, “they just don’t get it yet.”)

At Rocket Science, hubris took over and was about to lead to the fall.

Customer Development says having a vision, faith and a set of hypotheses are a normal part of the startup experience.  But it is critical to build in a process for testing those hypothesis outside the building and listening to the responses – or you might as well throw your money in the street.

Lessons learned?

  • While a lack of relevant domain expertise is not always fatal, believing you don’t need any is.
  • Founders need to validate their vision in front of customers early and often.
  • Your goals and your VC’s goals may not be aligned.  Make sure they are.

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Rocket Science 4: The Press is Our Best Product

At Rocket Science while my partner Peter was managing the tools and game development, I was managing everything else. Which at this stage of the company was marketing and financing.

Our “Hollywood meets Silicon Valley” story played great in Silicon Valley, they ate it up in Hollywood, and the business press tripped over themselves to talk to us.  The story had universal appeal, and we spun the tale and keep the buzz going.  It worked. Judging by the ink we had gotten, we were the hottest company in the game business, with stories in Fortune, Forbes, Variety, The Hollywood Reporter, and the cover of Wired magazine. Yet we hadn’t shipped a single product.

While it felt wonderful at the time, this was a very bad idea.

Wired 2.11 Cover

Everyone Else is an Idiot
The theme of our press blitz was all about how we were going to show the old tired game companies the right way to make video games. Our press infuriated the established companies who had spent years building games that sold well, but had zero press recognition.  (They all accurately predicted our demise because of our lack of game expertise.)  Ah, the arrogance of inexperience. Fortunately I’ve never been good at lying, to be effective in communicating a story I truly had to believe in what I was saying.  At the time I was a true believer that Rocket Science was going to change the gaming world. The positive effect of the tidal wave of press was as a door opener for us to raise money from corporate partners.  Companies in the entertainment business around the world knew who we were, and were interested in meeting us, if only to see what the hype was about. Our VP of Business Development had no problems getting meetings and fund raising was easy.

The Digital Dream Team
Way before the Internet phenomenon, we had created “Rocket Science the brand” that was much bigger in size and importance than Rocket Science the company. One magazine called us the “Digital Dream Team”, young, edgy and hip, and by the looks of the company (great building, nice furniture, and well dressed 20-year olds) we were trying to live up to the reputation.  All this activity occurring before we actually shipped a product.  We were larger than life, but as one potential investor told us, “You guys are all hat and no cattle.”

Believing Your Own BS is Toxic
Lots of noise and smoke before a product ships seems to be a toxic byproduct of enthusiastic entrepreneurs. Every generation of new technology seems to find a willing audience in naïve journalists and eager readers.  However, when the smoke clears the surviving companies are more than likely the ones that focussed on execution, not on creating a cacophony of press releases. If Rocket Science wasn’t a clear enough lesson in the danger of premature enthusiasm, the dot-com bubble that followed should have been. The only difference between us and the Internet bubble that would follow was that we did branding on the cheap by creating our image with public relations, whilethe dot-bomb era was to do it by spending enormous sums on advertising (those large venture rounds had to get spent somewhere.)

Hindsight is wonderful.  For years the one solace I was able to take from the Rocket Science debacle was that I had got the branding right. Then I watched the criminally expensive dot-bomb-bust branding activities to see how futile and wasteful it was to brand a company before it has shipped products.

To a Hammer Everything Looks Like a Nail
In hindsight my failure was that I executed to my strength – telling a compelling story – without actually listening to customer feedback.

It wasn’t that I didn’t know how to listen to customers.  It wasn’t that I didn’t have a smart VP of Marketing who was getting early feedback from customers and screaming that the games didn’t match the hype.  It’s that as CEO I was too busy talking to the press and raising money to hear customer comments directly.

I had outsourced customer feedback and ignored the input. In fact, hearing input that contradicted the story I was telling created cognitive dissonance.  So while the words may have passed through my ears I couldn’t “hear” it.  Not being able to hear negative customer input is an extremely bad idea.

Out of the Ashes
A few of the key tenets of Customer Development, came from the ashes.  The Customer Discovery lessons of “get outside the building and test your hypothesis with customers,” and “the founders need to hear the results,” came from this debacle.

The Customer Validation lesson of, “no formal launch until you have early sales validating the product and sales process” was also born here.  Given the lukewarm feedback we were getting from potential customers and channel buyers we should have dramatically dialed back the hype until the follow-on games could match it. Given the talented people we had, there’s no doubt they would have done so.  Instead the huge mismatch between expectations and reality of our first games diminished the brand and demoralized the company – we never recovered.

Lessons Learned

  • PR is not a product- it is a demand creation activity to fill a sales channel
  • The product needs to come close to the hype
  • Fire the CEO who insists on press and PR before they understand customer feedback
  • Branding is a process that should happen after you have customers

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Rocket Science 3: Hollywood Meets Silicon Valley

What do you mean you don’t want to hear about features?
I was now a CEO of Rocket Science, and having a great time building the company (more about that in future posts.) Unfortunately, while I had gone through phases of video game addiction in my life, in no way could I be described as even a “moderate hard-core gamer,” which ruled me out as a domain expert.  So I got out out of the building to meet and understand our customers and distribution partners. I remember after a month or two of talking to 14-22 year old male gamers (our potential target market,) I realized that for the first time in my career I had no emotional connection to my customers or channel partners.

I was about 90 days into the company when I began to realize there was something very different about this business. In previous companies I could talk about technology details and how the product features could solve a customers problem. But people didn’t buy video games on features and they weren’t looking to solve a problem.  I was in a very, very different business.

I was in the entertainment business.

There couldn’t have been a worse choice for CEO in Silicon Valley.

Alarm bell one should have started ringing – for me and my board.

Rocket Science logo

Hollywood Meets Silicon Valley was an Oxymoron
A key premise of our new company was that our video compression and authoring technology would revolutionize how games were made and played. We believed that by putting full motion video (i.e. movies) into video games we could tell stories, build characters, have narratives and bring all the 100 years of craft and cinematic experience of Hollywood to the sterile “shoot and die” twitch games that were currently in vogue.  (This wasn’t just some random Silicon Valley fantasy. My partner had convinced several major Hollywood names that this was the inevitable consequence of the merger of Hollywood and Silicon Valley.  And at the time it was a plausible scenario.)

But in reality our passionate belief that video would transform gaming was just our hypothesis. There was zero proof in the marketplace that was the case. And we weren’t going to be bothered to go out and prove ourselves wrong with facts.  (Why should we – our VC’s had already told us what geniuses we were by fighting to even get into the deal to fund us.  Never mind that no one on our board was in the game business or even played games.)

Alarm bell two should have started ringing – for me and my board.

Swing For the Fences
Since we were so smart we were going to ramp up and build not one game, but an entire game studio based on this hypothesis.  Why shouldn’t we.  Doing one game and seeing customer reaction meant a) acknowledging that some of our assumptions might be wrong, and 2) wasting time.  We were all about scale and swinging for the fences.  That’s what VC funded companies do, don’t they?

Alarm bell three should have started ringing – for my partner and me.

Tools Are the Not the Product
We were going to build an easy to use authoring system that would revolutionize how games were made. (My partner had convinced several of the key members of the Apple Quicktime team to join us.) Our tools group became as important as our content group. Unfortunately, the market was going to remind us that games are about game play.

Customers don’t care about your tools regardless of what business you’re in. Customers of software applications don’t say, “wow, elegant code base.” In movies theater-goers don’t leave talking about your cameras, just whether they were entertained, and in restaurants diners don’t care about your cooking implements, what matters is what the food tasted like.  The tools may provide efficiencies, but what customers care about is your final product. (Later on, way too late, we’d remind ourselves it’s the game stupid.)

Alarm bell four should have started ringing louder for me.

Lessons learned

  • Never, ever, start a company when you’re not passionate about the company, product and customers
  • Always validate your key assumptions on what makes your company tick
  • Swing for the fences is your VC’s strategy.  Make sure it is yours.
  • Don’t confuse your passion for your tools with why your customers will buy your product.