Steve Blank - The Startup Owner's Manual

In Webvan’s case, Engineering moved along two fronts: building the automated warehouses and designing the website. The automated warehouses were a technological marvel, with automated conveyors and carousels transporting food items off the shelves to workers who packed them for delivery. Webvan also designed its own inventory, warehouse, and route management systems and software to manage the entire customer order and delivery process. This software communicated with the Webvan website and issued order-fulfillment instructions to the distribution center. Once a delivery was scheduled, the system’s custom route-planning feature determined the most efficient route for delivering the goods to customers’ homes.

At the same time, planning began for a marketing and promotion program designed to strengthen the Webvan brand name, get customers to try the service in the first target market, build strong customer loyalty, and maximize repeat usage and purchases. The plan was to build Webvan’s brand name (down to stickering every cup holder in San Francisco’s AT&T Park) and customer loyalty through public relations programs, advertising campaigns and promotional activities. Spending for all these activities was part of the business plan.

In stage three, the alpha/beta test, Engineering continues building along the classic waterfall development model, working toward the first customer ship date. And, by beta test time, working with a small group of outside users to test the product and ensure that it works as specified. Marketing develops a complete marketing communications plan, sets up the corporate website, provides Sales with a full complement of support materials, and starts the public relations bandwagon rolling. The pragency polishes the positioning and starts contacting the long-lead-time press and blogs, while Marketing starts the branding activities.

Sales signs up the first beta customers (who may 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 headquarters. The sales VP works toward achieving the revenue plan as specified in the business plan. Investors and board members start measuring progress by the number of orders in place by first customer ship. The CEO hits the streets and the phone or the parent-company headquarters, searching for additional capital.

Webvan began to beta-test its grocery delivery service in May 1999 with about 1,100 customers. At the same time, the marketing buzz started with a prblitz with hundreds of articles touting the newest entrant in the online grocery business. Private investors poured hundreds of millions of dollars into the company.

With the product working (sort of), the company goes into “big-bang” spending mode. The product and the company are launched. The company has a large press event, and Marketing launches a series of programs to create end-user demand. In anticipation of sales, the company hires a national sales organization; the sales channel has quotas and sales goals. The board begins measuring company performance based on sales execution against its business plan, albeit one typically written at least a year earlier, when the company first sought investment.

Building a sales channel and supporting marketing burn a lot of cash. Assuming no early liquidity event for the company, more fund-raising is often required. The CEO looks at the product-launch activities and the scale-up of the sales and marketing team and goes out yet again, palm up, to the investor community. (In the dot-com bubble economy, investors used an IPO at product launch to take the money and run, before there was a track record of success or failure.) This operational model no doubt sounds familiar to many: a product- and processcentric model used by countless startups to take their first products to market.

Webvan launched its first regional web store in June 1999 (just a month after starting beta test) and filed for its public offering 60 days later. The company raised $400 million and had a market capitalization of $8.5 billion the day of its IPO—larger than the market cap of the top three grocery chains combined. The elation was short-lived.

For new products like Webvan, the business plan fails as a roadmap because both the product and the customer are unknown. For most startups, these nine flawed assumptions are the most toxic of all:

First is the founder’s unwavering belief that he or she understands who the customers will be, what they need, and how to sell it to them. Any dispassionate observer would recognize that on Day One, a startup has no customers, and unless the founder is a true domain expert, he or she can only guess about the customer, problem, and business model. On Day One, a startup is a faith-based initiative built on guesses. Yet the traditional product introduction methodology has founders take these many business model guesses as facts and go design a product and start spending money to build it on a race to “first customer ship”—all before talking to a single customer.

On Day One, a startup is a faith-based initiative…

To succeed, founders need to turn hypotheses or guesses into facts as soon as possible by getting out of the building, asking customers if the hypotheses were correct, and quickly changing those that were wrong.

The second flawed assumption is implicitly driven by the first. Founders, presuming they know their customers, assume they know all the features customers need. These founders specify, design, and build a fully featured product using classic product development methods without ever leaving their building. But wait—isn’t that what startups should do? No—that’s what companies with existing customers do.

…it’s unknown whether the features appeal to customers.

The waterfall development process (see Figure 1.2) proceeds sequentially and without interruption for as long as a year or two. Progress is measured by each new line of code written or new piece of hardware built throughout the process until the product is released. Yet without direct and continuous customer contact, it’s unknown whether the features appeal to customers. Fixing the inevitable product mistakes after building and shipping the entire product is costly and time-consuming, if not deadly. It can render the product obsolete by launch. Worse, it often causes huge engineering waste, with hundreds of hours of work tossed aside, or tons of code cut and dropped to the floor, when customers say the new features aren’t ones they care about. Ironically, startups were often crippled by the very methodology they traditionally used to build new products.

The traditional product introduction model focuses engineering, sales and marketing on the all-important, immovable launch date. Marketing tries to pick an “event” (trade show, conference, blog, etc.) where they can “launch” the product. Executives look at that date and the calendar, working backward to ignite fireworks on the day the product is launched. Neither management nor investors tolerate “wrong turns” that result in delays. In fact, traditional engineering schedules have test cycles with the names alpha, beta, and release but rarely allow time to improve the product. They’re still geared to putting out the original product with minimal bugs, though.

The product launch and first customer ship dates are merely the dates when a product development team thinks the product’s first release is “finished.” It doesn’t mean the company understands its customers or how to market or sell to them, yet in almost every startup, ready or not, departmental clocks are set irrevocably to “first customer ship.” Even worse, a startup’s investors are managing their financial expectations by this date as well.