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

The End of Innocence

I love TechCrunch. If you’re a startup raising money or just want to see your name online, there’s not a better blog on the web.  Reading this TechCrunch post made me remember the first time I saw someone confront a worldview they didn’t expect.

TechCrunch PRDiscovering that your worldview is wrong or mistaken can be a life-changing event. It’s part of growing up but can happen at any age. What you do when it happens shapes who you’ll become.

Dinner in a Strange Land
When I was in my mid 20’s working at ESL, I was sent overseas to a customer site where the customers were our three-letter intelligence agencies. All of us knew who they were, understood how important this site was for our country, and proud of the work we were doing. (Their national technical means of verification made the world a safer place and hastened the end of the Soviet Union and the Cold War.)

As a single guy, I got to live in a motel-like room on the site while the married guys lived in town in houses and tried to blend in with the locals. When asked what they did, they said they worked at “the xxx research facility.”  (Of course the locals translated that to “oh do you work for the yyy or zzz intelligence agency?”)

One warm summer evening I got invited over to the house of a married couple from my company for a BBQ and after-dinner entertainment – drinking mass quantities of the local beer. The quintessential California couple, they stood out in our crowd as the engineer (in his late 20’s, respected by his peers and the customer) had hair down to his shoulders, sharply contrasting with the military crewcuts of the customers and most of the other contractors.

His wife, about my age, could have been a poster child for the stereotypical California hippie surfer, with politics that matched her style – antiwar, anti government, antiestablishment.

One of the rules in the business was that you didn’t tell your spouse, girlfriend, significant other who you worked for or what you worked on – ever. It was always a welcome change of pace to leave the brown of the unchanging desert and travel into town and have dinner with them and have a non-technical conversation about books, theater, politics, travel, etc. But it was a bit incongruous to hear her get wound up and rail against our government and the very people we were all working for. Her husband would look at me out the corner of his eyes and then we’d segue the conversation to some other topic.

That evening I was there with three other couples cooking over the barbie in their backyard. After night fell we reconvened in their living room as we continued to go through the local beer. The conversation happened to hit on politics and culture and my friend’s’ wife innocently offered up she had lived in a commune in California. Well that created a bit of alcohol-fueled cross-cultural disconnect and heated discussion.

Until one of the other wives changed a few lives forever with a slip of the tongue.

Tell Me it Isn’t True
One of the other wives asked, “Well what would your friends in the commune think of you now that your husband is working for intelligence agencies x and y?”

As soon as the words came out of her mouth, I felt time slow down. The other couples laughed for about half a second expecting my friend’s wife to do so as well. But instead the look on her face went from puzzlement in processing the question, to concentration, as she was thinking and correlating past questions she had about who exactly her husband had been working for. It seemed like forever before she asked with a look of confusion, “What do you mean agencies x and y?”

The laughter in the room stopped way too soon, and the room got deathly quiet. Her face slowly went from a look of puzzlement to betrayal to horror as she realized that that the drunken silence, the dirty looks from other husbands to the wife who made the agency comment, and the wives now staring at their shoes was an answer.

She had married someone who never told her who he was really working for. She was living in a lie with people she hated. In less than a minute her entire worldview had shattered and coming apart in front of us, she started screaming.

This probably took no more than 10 seconds, but watching her face, it felt like hours.

I don’t remember how we all got out of the house or how I got back to the site, but to this day I still remember standing on her lawn staring at strange constellations in the night sky as she was screaming to her husband, “Tell me it isn’t true!”

The next day the site supervisor told me that my friend and his wife had been put on the next plane out of country and sent home (sedated) along with the other couple that made the comment. By the time I came back to the United States, he was gone from the company.

It’s been thirty years, but every once an awhile I still wonder what happened to the rest of their lives.

———-

The End of Innocence
In much smaller ways I’ve watched my children and now my students discover that their worldview is wrong, mistaken or naive. I’ve watched as they realize there’s no Santa Claus and Tooth Fairy; the world has injustice, hypocrisy and inequality; capitalism and politics don’t work like the textbooks and money moves the system; you can’t opt out of dying, and without regulation people will try to “game” whatever system you put in place.

Learning to accept the things you can’t change, finding the courage to change the things you can and acquiring the common sense to know the difference, is part of growing up.

While I love TechCrunch, the post and the quote about the PR agency (“one PR firm has discovered a dynamite strategy, throw ethics out the window”) left me wondering; how do PR agencies interact with TechCrunch and other blog and review sites? Is this behavior an outlier or is it the norm in the PR industry?

Or is it just someones end of innocence?

Listen to the blog post here

Download the podcast here or here

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

The Secret History of Silicon Valley Part X: Stanford Crosses the Rubicon

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 bibliography for sources and supplemental reading.

———————–

Swords Into Plowshares
After the end of World War II, returning veterans were happy to beat swords into plowshares (and microwave tubes) on the Stanford campus. From 1946 until 1950, Stanford’s Electronic Research Lab conducted basic research in microwave tubes.  Although this reseearch would lead to the development of the Backward Wave Oscillator and Traveling Wave Tube for military applications, Stanford was building tubes and circuits not entire systems.  The labs basic research was done by graduate students or Ph.Ds doing postdoctoral internships, supervised by faculty members or hired staff (many from Fred Terman’s WWII Electronic Warfare lab.)

In 1949, with the detection of the first Soviet nuclear weapons test, the Iron Curtain falling across Europe and the fall of China to the Communists, Cold War paranoia drove the U.S. military to rearm and mobilize.

Source: Center for Arms Control and Non-Proliferation (in constant 2009 $’s)

Source: Center for Arms Control and Non-Proliferation (in constant 2009 $’s)

We’ll Do Great in the Next War
Early in 1950, just months before the outbreak of the Korean War the Office of Naval Research asked Fred Terman to build an Applied electronics program for electronic warfare. All branches of the military (the Air Force and Army would fund the program as well) wanted Stanford to build prototypes of electronic intelligence and electronic warfare systems that could be put into production by partners in industry. The Navy informs Terman that, “money was not a problem but time was.”

Pitching the idea to the President of Stanford, Terman enthusiastically said, “In the event of all-out war, Stanford would become one of the giant electronic research centers…”  (A bit optimistic about the outcome perhaps, given that both the U.S. and the Soviet Union had nuclear weapons at this point.)

Crossing the Rubicon – The Applied Electronics Lab
Setting up a separate Applied Electronics Lab for military funded programs doubled the size of the electronics program at Stanford. The new Applied Electronics Laboratory was built with Navy money and a gift from Hewlett-Packard. With the memories of WWII only five years old, and the Cold War now a shooting war in Korea, there was very little discussion (or dissension) about turning a university into a center for the production of military intelligence and electronic warfare systems.

The work in the applied program focused in fields in which faculty members or senior research associates specialized.  Many of the other staff in the applied program were full-time employees hired to work solely on these military programs.

ELINT, Jammers and OTH
The Applied Electronics Lab used the ideas and discoveries (on microwave tubes and receiver circuits) from Terman’s basic research program in the Electronic Research Lab. The Applied Lab would build prototypes of complete systems such as Electronic Intelligence systems, Electronic Warfare Jammers, and Over the Horizon Radar. The Applied Electronics Lab also continued work on the Klystron, pushing the tube to produce megawatts in transmitted power. (Stanford designed Klystrons producing 2½ Megawatts were manufactured by Varian and Litton would power the radar in the BMEWS (Ballistic Missile Early Warning System) built at the height of the cold war.) The close tie between the two labs was a unique aspect of the Stanford Lab. Stanford had a Customer Development loop going on inside their own lab. The discoveries in tube and circuit research suggested new electronic intelligence and countermeasure techniques and systems; in turn the needs of the Applied Lab pushed tube and circuit development.  With the Applied Electronics Lab Stanford was becoming something akin to a federal or corporate lab run under university contract.  The university found government contracts profitable as the government reimbursed their overhead charges (their indirect costs.) This means they could fund other non-military academic programs from this overhead.

The Stanford Applied Electronics Lab built prototypes which were handed off to the military labs for their evaluation. Subsequently military labs would contract with companies to build the devices in volume. In some cases, branches of the military contracted directly with Stanford which worked with local contractors in Silicon Valley to build these components or systems for the military. The prototype ELINT receivers built by the Applied Electronics Lab used the Stanford Traveling Wave Tubes. They quickly went into production at Sylvania Electronic Defense Labs down the street in Mountain View and Hallicrafters in Chicago. Later versions would be built by numerous industry contractors and installed on the fleet of ELINT planes orbiting the Soviet Union. These traveling wave tubes would also become the heart of the panoramic receiver used on the B-52 by the electronic warfare officer to get the bomber through the Soviet Air Defense system.

Jammers built by the Stanford Applied Electronics Lab used the Stanford Backward Wave Oscillators to produce high power microwaves. Unlike the simple noise jammers used in World War II, Soviet radars were becoming more sophisticated and newer designs were fairly immune to noise. Instead the jamming signal needed to be much smarter and have a deep understanding of how the targeted radar worked. Taking the information gleaned from our ELINT aircraft, Stanford built prototypes of jammers modulated with two new deception jamming techniques – angle jamming and range-gate pull-off. Some form of these deception jammers would eventually find their way into most electronic warfare defense systems used in the Cold War; first in the U-2, A-12 and SR-71. (Ironically the B-52 bomber, which would become the airborne leg of our nuclear triad, would use dumb noise jammers for two more decades – the Air Force opting to put the smart jammers on the B-58 and B-70, high altitude supersonic bombers – one soon obsolete and other never made it into production.)

The last major area of research that the Applied Electronics Lab group investigated was how radio signals propagated within the earth’s ionosphere. Over the next fifteen years this Radio Science Laboratory would receive the most funding of all departments in the lab (from the CIA) to build a ground based ELINT system. They would build and deploy two Over The Horizon Radar (OTHR) systems to detect Soviet and Chinese ballistic missile tests using ground based radars.

Guards at the DoorStanford Joins the Cold War
In 1953 the Office of Naval Research told Terman that all military-funded projects (basic or applied, classified or not) needed to be in their own separate physical building. As a result Stanford moved the Applied work from the Electronics Research Lab into its own building.

In 1955, the pretense of keeping unclassified and classified work separate imposed too much of an administrative overhead and Stanford merged the Applied Electronics Lab and the Electronics Research Laboratory into the Systems Engineering Lab. The Applied Electronics portion of the lab was now the size of a small company.  It had 100 people, 18 of them full time faculty, 33 research associates and assistants and 33 other tube technicians, draftsman, machinists, etc. Over half this lab would hold clearances for military secrets. (Top Secret: Terman, Harris, McGhie, Secret: 44 others, Confidential: 8 others. Terman, Harris and Rambo also had Atomic Energy Commission “Q” clearances.)  Some students who were getting their engineering graduate degrees wrote masters and PhD thesis that were classified. Unless you had the proper clearances you couldn’t read them.  Terman and Stanford had just made a major bet on the cold war, and Stanford ranked sixth among university defense contractors.

A security guard was stationed at the door of the Applied Electronics Lab to ensure that only those with proper security clearance could enter. The law of unintended consequences meant that this most casual addition in front of a university building would result in the occupation and destruction of the lab (and its twin at MIT) and the end of the program 14 years later.  (More on this in a later post.)

Show and Tell – The Stanford ELINT and Electronic Warfare Contractors Meeting
During a typical year, the Applied Electronics Lab would host classified visits from military labs and defense contractors. By early 1950’s Stanford started holding a two day meeting for contractors and the military.

 

1955 Stanford Contractors Meeting

1955 Stanford Contractors Meeting

 

The 1955 attendee list gives you a feeling of the “who’s who” of the military/industrial establishment: RCA, GE, Motorola, AIL, Bendix, Convair, Mepar, Crosley, Westinghouse, McDonnell Aircraft, Douglas Aircraft, Boeing, Lockheed, Hughes Aircraft, North American, Bell Aircraft, Glen Martin, Ryan Aeronautics, Farnsworth, Sperry, Litton, Polarad, Hallicrafters, Varian, Emerson, Dumont, Maxson, Collins Radio.  Other universities doing classified ELINT and Electronic Warfare work attended including University of Michigan, Georgia Institute of Technology and Cornell. Over a hundred government contractors reviewed Stanford’s work on tubes and systems.

Stanford Contractors Meeting 1955 Attendees

Stanford Contractors Meeting 1955 Attendees

This was a classified conference at a university, the contractors not only got to hear the conference lectures, but also visited exhibits on the devices and systems the lab had built. The lab would repeat the conference the following week for government agencies doing military work.

Barely noticed at the 1955 conference, a year before the first transistor company opened in Silicon Valley, one of the sessions described how to use a new device called a“transistor” to build wide-band amplifiers. (Terman had sent faculty and graduate students to the University of Illinois in 1953 to learn transistor physics.)

The World Turned Upside Down
The Applied Electronics Lab solidified Stanford’s lead as one of, if not the place in the U.S. military for advanced thinking in ELINT and Electronic Warfare.  It would turn on its head the relationship of universities and corporations.

Traditionally universities chased corporations for funding and patronage, but the military’s dependence on Stanford’s and Fred Terman’s judgment turned that relationship on its head.  Now the military was listening to Terman’s advice about which military contractors should get the order for to mass produce the Stanford systems.  The contractors were now dependent on Stanford.

Terman the Rainmaker
During the 1950’s Fred Terman was an advisor to every major branch of the U.S. military. He was on the Army Signal Corps R&D Advisory Council, the Air Force Electronic Countermeasures Scientific Advisory board, a Trustee of the Institute of Defense Analysis, the Naval Research Advisory Committee, the Defense Science Board, and a consultant to the President’s Science Advisory Committee. His commercial activities had him on the board of directors of HP, Watkins-Johnson, Ampex, and Director and Vice Chairman of SRI.  It’s amazing this guy ever slept.  Terman was the ultimate networking machine for Stanford and its military contracts.

Stanford Industrial Park – Microwave Valley Booms
By the early 1950’s many of the corporations that attended the yearly Stanford Electronic Warfare conferences would establish research labs centered around Stanford for just this reason – to learn from Stanford’s basic and applied research and get a piece of the ELINT and Electronic Warfare contracting pie.

Stanford Industrial Park was the first technology office park set up to house local and out of state microwave and electronics startups. First occupied in 1953 it would include Varian, Watkins Johnson, Admiral, HP, General Electric, Kodak, Lockheed.  Other east coast companies which established branches in Microwave valley in the 1950’s included IBM, Sylvania, Philco, Zenith and ITT.

The Future is Clear – Microwave Valley Forever
By 1956 Fred Terman had every right to be pleased with what he had helped build in the last ten years in and around Stanford.  The Stanford Electronics Lab was now the center of ELINT and Electronic Warfare.

Startups were sprouting all over Microwave Valley delivering microwave tubes and complete military systems, slowiy replacing the orchards and fruit trees. Granger Associates was a 1956 startup founded by Bill Ayer, a graduate student in the Applied Electronics Radioscience Lab, and John Granger, a former RRL researcher, building ELINT and Electronic Warfare systems (the Granger jammer was carried on the U-2.) Four years later Ayer and another Granger engineer would leave Granger and found one of the preeminent electronic warfare and ELINT companies: Applied Technologies.

The future of the valley was clear – microwaves.

1956 – Change Everything
Yet in 1956 two events would change everything.  At the time neither appeared earthshaking or momentous. First, a Bell Labs researcher who had grown up in Palo Alto, had his own interesting World War II career, and recently served as a military advisor on cold war weapons systems, decided to follow Fred Terman’s advice to locate his semiconductor company near Stanford.

The second was when a Southern Californian aircraft company decided to break into the missiles and space field by partnering with Stanford electronics expertise. It moved its electronics research group from Burbank to the new Stanford Industrial Park and built its manufacturing facility in Sunnyvale.

Shockley Semiconductor Laboratory and Lockheed Missiles Systems Division would change everything. Read about it in Part XI of the Secret History of Silicon Valley here.

I’m From the Government and I’m Here to Help You

Apologies for a “Secret History” post that appeared today and now is gone from the blog.  (Those of you with a reader still have it.)  It was a rough draft you’ll see again when I can finish complete sentences.  (Something you can appreciate if you’ve read my class text on Customer Development.)

My only excuse is that this week I’m doing public service in my role as a California Coastal Commissioner.  Long days, lots of items on the calendar, dedicated staff, very bright fellow commissioners. Greatest hits here.

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

Follow

Get every new post delivered to your Inbox.

Join 160,742 other followers