WIXLIB

4 Midlife Crisis Startupsurfers Greg Knoll and others rode these massive forces of nature. Iknew I didn’t have the skill or bravura to join them. The next biggestwave I saw was almost four decades later, when the digital revolutionand the Internet craze built toward a crest. I jumped on the mythicalseventh wave of the seventh set. It was quite a ride. I tried torecapture the thinking that went on during the experience, thefeelings both good and bad, and the emotional texture from clarityand joy to confusion and anger. For the feelings and emotions, thewriting has to stand on its own. I hope I have been revealing enoughto prepare you to encounter some of the vicissitudes I faced. I ameager to share the thinking that took place during the ride this bookdescribes. I hope it aids understanding the process of new-ventureinitiation, particularly for university-based technology, in whichradical innovations can change the way we live in and experience theworld. Ultimately, this is a story about the tension between a world oftechnological genius and a world of business. The masters of theseworlds don’t know how to talk to each other. Yet, so much of themagnificent prospects for our future depend on this communication.I think managers need to extend their thinking at least enough intothe technology that the basis for decision making is not opaque. Andthe technological geniuses of this world need to understand that,while others may be the best judges of the practicality of markets andopportunities, they more than anyone else are the best judges of thetechnological limits of their innovations.I start in the middle of the ride, with the story of the first live test ofthe new technology, before rewinding to the beginnings of 0012/1/19998/1/199910/1/19996/1/19991100

1. Birth of a Notion 51.2July 28, 2000Jason Kapp picked me up at 8 a.m. from my Santa Monica home fora 9 a.m. meeting at Idealab Capital Partners, the Pasadena-basedInternet incubator that spawned eToys, CarsDirect, Cooking.com,Overture, and others. Jason, our VP of client services, had played akey role in helping me start this venture. We had pitched ourapproach to technology-enabled marketing many times before in oursuccessful 5 million B Round. We knew the story: The Internetdangled the prospect of huge potential returns for those who couldmonetize its promise for personalized shopping and browsing. Butthe preparation this time was different. We had heard exaggeratedrumors about successes in our arena by one of Idealab’s portfoliocompanies, as well as tales of their acumen at taking other people’sideas. So the focus centered on what to reveal and what to concealabout our approach. But the dark presence in the car, and over alldiscussions for almost a month, concerned when we would launchour first real market test – a test that would determine the near-termfate of this startup.Through the B-Round representative on our board, we had arrangedwith iPlayer.com to purchase 20 million banner-ad impressionsdesignated for registered users on its popular Internet versions ofvideo games. We would use our segmentation method to learn aboutthe preferences within each segment of its customers; we hoped touse that machine learning to increase the abysmal (and getting worse)click-through rates on the company’s banner ads. Using the site’sown customer data to improve ad targeting fulfilled the marketingmaxim to know your customers and circumvented all the privacy issuesconcerning public-policy makers at the time. June 15 was set as thestarting date. At .75 per thousand, 15,000 to get a live test of theextension of our personalization technology in the Internet ad spaceseemed like a good idea. When the planned test failed to start ontime, Scott Sellers, the VP for business development at iPlayer.com,told us that June inventory was sold out at 5 CPM (cost perthousand) – a much higher rate than we had negotiated. We arrangedto start July 1 at 2.50 CPM, and waited and waited some more.Two VA-Linux machines with our software had been co-locatedwithin the test site’s Web-server racks at Exodus. We had two similarmachines in our own half rack at PSINet in Marina del Rey, and fourmore tied to a T-1 line at our office in Santa Monica. Tests on ourend were fine so far, but within iPlayer.com’s network we couldn’t

6 Midlife Crisis Startupread the cookie – that tiny piece of text code that gives theoriginating site so much information about the customer at the otherend. We needed the site to change six lines of code to share cookiesjust within its complete subnet. Since my technical expertise coverednot cookie logic but the conceptual and analytical models that droveour learning and optimization algorithms, I was barely grasping ontothese problem areas. Early in July, the client’s CTO promised tomake the simple change we required, but it didn’t happen. On July19, the CTO left for a year, supposedly to recover from anunspecified illness. I suspected burnout. It was July 25 before Sellersgot his team to put the new cookie code in place. We found and fixeda small bug in our database agent, and sent a ready-to-go message toSellers. Ravi Srinivasan, the head of our technical-implementationteam and an Anderson MBA student, heard that AdForce, the firmserving iPlayer.com’s ads at that time, had been notified to startsending our ads first thing on July 27 and still we waited.Jason and I agreed to show Idealab much the same demo that hadbeen developed in record time for our first board of directorsmeeting in early February. The demo featured our productrecommendation suite, called PersonalClerk, that incorporated theInternet advertising optimization only as a simple, natural extensionof the personalization solution. We wouldn’t talk about the ad testwith Idealab.The 45-minute meeting went nowhere, but went nowhere smoothly.We learned Idealab’s efforts were mostly vapor – great customerdata, but no sense that the company knew how to use it effectively.Technology-enabled marketing operates at the boundary betweenintelligent information systems and that obscure area called marketingscience. Without strong capabilities in both areas, the problems are atbest half solved and the solutions, consequently, are half-baked.Once back in the car I called Ravi. He sadly reported, “No data yet.”Then I heard Chuck Yu, our hardware guru, in the backgroundyelling that the first ads were being sent. It was 9:52 a.m. and ourlabor pains had just begun. The drive back felt like a rush to thehospital to be in time for the delivery of my first child.When Jason and I arrived back at the bullpen on the second floor,where most of the technology group sat, everyone was gatheredaround Chuck’s desk. One window on his Linux notebook tracked

1. Birth of a Notion 7the number of open sockets – one for each active user. The theorywas that when a user’s browser requested a page, our HTTP agentthat handled the raw traffic opened a socket as a file description,delivered an ad, sent the needed information to our learningalgorithm and a session log, and closed the socket. We watched as thenumber of open sockets increased toward 1,024, blocking the threadand crashing our system. Our design didn’t threaten to bring downthe client site or interfere with its basic operation, but when oursystem crashed, the ads we paid for weren’t being delivered. The datathat were crucial to our machine-learning algorithms weren’t beingcollected. Chuck’s fingers flew over the keyboard each time thethread was blocked. If the sockets were unblocked (closed) when theprocess crashed, a simple chain of commands would restart theprocess immediately. If the sockets remained open – blocked fromaccepting a new-user request -- Chuck had to reboot our Linux boxinside the client’s rack at Exodus before restarting the process. Thenlearning would begin again, until the next blockage.Why was this happening? What could we do about it? I didn’t have aclue. Chuck was madly typing away to keep our downtime to aminimum, and I had no insight into the problems we faced. Thirtyyears of designing and building medium- and large-scale analyticaland statistical systems for squeezing meaning out of market data, andI had never been this clueless. Others had done major chunks ofmany of my earlier projects, sometimes for efficiency and sometimesfor learning. When stumbling blocks were encountered, I had alwaysbeen there to solve the problem. Not this time. After more than threedecades on the faculty of UCLA’s management school, I was nowoutside the ivory tower. I needed to step back, micro-manage less,and grant other people control over a problem-solving process thattranscended my expertise.The intellectual resources available were substantial, but incomplete.Giovanni Giuffrida, a UCLA doctoral candidate in intelligentinformation systems, was our CTO, and had developed wonderfullyinto a leader of the technology group. An ever-reshuffling handful ofprogram developers would gather around the conference table in hisoffice next to the bullpen while Giovanni worked with them throughwhatever was the greatest barrier to our technical progress. Giovanniand I previously had worked together for several years on large-scale

8 Midlife Crisis Startupforecasting projects1 and research-oriented datamining projects thathad led to the first datamining article published in the mainstreammanagement literature.2 Our big-data experience mostly concernedretail scanner records. We had to deal with about 25 million recordsat a time and be prepared to create up to 800 million forecasts a year.Those are very small numbers compared to what we faced on theWeb.Our main Web expert, Fabrizio diMauro, an amazing code hacker,was stuck on a trans-Atlantic flight returning from Italy – andgrounded in Newfoundland when his girlfriend became extremely illin flight. When Giovanni, Jason, David VanArsdale (VP/admin) andI had started this venture together, Fabrizio was the first person hiredin the technology group. Giuseppe Blanco, a Web-design specialist, Cprogrammer, and the third part of the Sicilian Connection, was in thebullpen. Not only did these three grow up in the same small town inSicily, they all reconnected in computer-science graduate programs atUCLA. Brandon Davinski, the UCLA computer-science undergradwho worked with us full time in the summer, brought an almost scaryknowledge of Web programming. He already had found a majorsecurity hole in another client’s cash-register program. He couldchange the price for anything in his or anybody’s current shoppingbasket. Many times I mumbled to myself that I was glad Davinskiwas on our side. Wesley Rhim was a database expert with deep SQLand Perl skills. Murilo, a great C programmer with a PhD in physics,had just started earlier that week. Nick, a computer-science undergradfrom MIT, worked with us that summer. So did Jonathan, the bestcomputer mind in my older son’s cohort (then 20), who hadprogrammed the common object module (COM) needed for dealingwith the Microsoft servers that the client used. In supporting roleswere a group of very talented college students in their first importantsummer jobs.At first, the core technology team tried to force the sockets to close –fix the symptom and ignore the problem. We didn’t find a way to dothis. Maybe the level of simultaneous traffic was too heavy for only1,024 sockets, but this seemed unlikely given the short duration1Cooper, Lee G., Penny Baron, Wayne Levy, Michael Swisher, and Paris Gogos(1999), “PromoCast: A New Forecasting Method for Promotion Planning,”Marketing Science, 18, 3, 301-316.2Cooper, Lee G. and Giovanni Giuffrida (2000), “Turning Datamining into aManagement Science Tool,” Management Science, 46, 2 (February), 249-264.

1. Birth of a Notion 9(milliseconds) that each request required. So Giuseppe and Jonathanpulled a 10-thread version of the HTTP agent from the programrepository and tested it. Chuck copied it over to the machines atExodus, compiled it – keeping the other system going to the lastsecond -- and then started the 10-thread code. The inexorable rise inblocked sockets foretold the outcome. Blocked sockets led to crashedthreads. It took 10 times as long to crash the whole program, but thistry eliminated traffic volume as the possible cause. To eliminatebandwidth issues, the banner ads were copied over to the extramachines at PSINet and served from there. No discernibledifference.By mid-afternoon, someone suggested that possibly old or strangebrowsers contributed to the problem. Our session logs were full ofrequests from newer Internet Explorer and Netscape browsers, butnone from the much older versions of these or from WebTVbrowsers. Jonathan grabbed a WebTV emulator that we used to loginto iPlayer.com. No ad was delivered and no record of the usershowed up in the session log. This signaled that the problem was inhow our HTTP agent handled old or odd browsers. The HTTP agentwas our interface to Internet traffic – in essence, a Web-serveroperating system stripped down for speed. We could handle about1,200 requests per second, per box in a system we knew how to easilyparallelize, if additional speed was needed for high-volumecommercial sites. But apparently, too much of the browser handlinghad been stripped out. The fix required putting a whole APACHEWeb-server operating system in front of our HTTP agent to takeover the browser handling. Giovanni understood the best talents ofhis core team and assigned David and Jonathan to the APACHEtasks,

roller coaster that launching a new venture entails. I think this evokes the wrong image. A roller coaster has a fixed track. You can see when you are climbing to the peak or diving into a valley, and you can see the bottom. You are also strapped in, and insurance companies have signed off on