the product. The simple box labeled “Product Development” typically expands into a “waterfall” or “spiral” or incremental process of interlacing steps, all focused on minimizing development risk of a defined feature set (Figure 1.2). This process starts with the founder’s vision, which may be expanded into an MRD (and a product requirements document), and expands further into detailed engineering specifications. With those in hand, Engineering begins implementation fueled by cold pizza and long nights and weekends. Once a waterfall process starts, the proverbial train has left the station and the product is nearly impossible to revise. As a rule, the “train” can run almost nonstop for 18 or perhaps 24 months or more, uninterrupted by changes or new ideas no matter how good they might be for the business.
Figure 1.2 The Product Development “Waterfall” Model
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.
Alpha/Beta Test
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.
Product Launch and First Customer Ship
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.
The 9 Deadly Sins of the New Product Introduction Model
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:
1. Assuming “I Know What the Customer Wants”
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.
2. The “I Know What Features to Build” Flaw
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
