The Startup Owner's Manual. Steve Blank
Чтение книги онлайн.

Читать онлайн книгу The Startup Owner's Manual - Steve Blank страница 17

Название: The Startup Owner's Manual

Автор: Steve Blank

Издательство: John Wiley & Sons Limited

Жанр: Экономика

Серия:

isbn: 9781119690726

isbn:

СКАЧАТЬ 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.

images

      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.

      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

      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:

      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

      …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 СКАЧАТЬ