The world's leading expert on the global software industry and coauthor of the bestseller Microsoft Secrets reveals the inner workings of software giants like IBM, Microsoft, and Netscape and shows what it takes to create, develop, and manage a successful company -- in good times and bad -- in the most fiercely competitive business in the world.
In the $600 billion software industry it is the business, not the technology, that determines success or failure. This fact -- one that thousands of once glamorous start-ups have unhappily discovered for themselves -- is the well-documented conclusion of this enormously readable and revealing new book by Michael Cusumano, based on nearly twenty years of research and consulting with software producers around the world.
Cusumano builds on dozens of personal experiences and case studies to show how issues of strategy and organization are irrevocably linked with those of managing the technology and demonstrates that a thorough understanding of these issues is vital to success. At the heart of the book Cusumano poses seven questions that underpin a three-pronged management framework. He argues that companies must adopt one of three basic business models: become a products company at one end of the strategic spectrum, a services company at the other end, or a hybrid solutions company in between. The author describes the characteristics of the different models, evaluates their strengths and weaknesses, and shows how each is more or less appropriate for different stages in the evolution of a business as well as in good versus bad economic times. Readers will also find invaluable Cusumano's treatment of software development issues ranging from architecture and teams to project management and testing, as well as two chapters devoted to what it takes to create a successful software start-up. Highlights include eight fundamental guidelines for evaluating potential software winners and Cusumano's probing analysis, based on firsthand knowledge, of ten start-ups that have met with varying degrees of success.
The Business of Software is timely essential reading for managers, programmers, entrepreneurs, and others who follow the global software industry.
Le informazioni nella sezione "Riassunto" possono far riferimento a edizioni diverse di questo titolo.
Michael A. Cusumano is the Sloan Management Review Distinguished Professor at the MIT Sloan School of Management and one of the world's leading authorities on software development and the management of software companies. He is the author or coauthor of seven other books, including the bestsellers Microsoft Secrets and Competing on Internet Time, as well as Japan's Software Factories and most recently Platform Leadership.
Chapter 1
The Business of Software: A Personal View
If the software business were like other businesses, there would be no need for this book. But software is not like other businesses. First of all, the technology consists of a digital "soft" good -- usually English-like programming commands eventually translated into zeros and ones -- that provide instructions to a computer. These instructions form products that companies can standardize for many users, customize for individual users, or do something in between. Companies that rely on this highly malleable technology for their livelihoods must be unique in many ways, particularly in how they deal with business models, product strategy, people (especially software engineers), and management of a core activity: software development.
There are many examples of how software technology and software companies differ from what we see in traditional manufacturing and service industries. In how many businesses does making one copy or one million copies of your product cost about the same? How many businesses have up to 99 percent gross profit margins for their product sales? In how many businesses do many products companies eventually become services or hybrid companies (that is, providing some customization of product features and technical services such as system integration and maintenance), whether they like it or not? In how many businesses is there frequently a ten- or twentyfold difference in productivity between your best employee and your worst one? How many businesses tolerate some 75 to 80 percent of their product-development projects routinely being late and over budget, with "best practice" considered to be 20 percent on time? How about a company where the people who build products often consider themselves artists rather than scientists or engineers and have the mercurial temperament to go with it? In how many businesses are customers "locked in" to a particular vendor because of product decisions someone made a decade or two ago that can't easily be reversed?
The software business also differs from conventional industries because it is not really one kind of business. Software becomes whatever function or application it addresses. This means that the range of possible products and services is almost infinite. Software can help you write a report, calculate your taxes, build a bridge, navigate an automobile, control the space shuttle, or dial your telephone. Not surprisingly, there are many categories and even layers of software products and customized programs that work with one another to form complete systems (such as networking software with operating systems, and operating systems with applications). The definitions of these categories and layers are relatively well accepted, though Microsoft and other companies have been blurring the traditional distinctions for many years.
These and other observations describe aspects of software technology, software companies, and the software business. They also describe some other high-tech markets, such as telecommunications and various types of businesses heavily dependent on information systems and digital content. But surely these observations describe an unusual type of business.
As I discuss in Chapters 2 and 3, get the strategy and the management side right, and the software business can be like having a license to print money. Just ask Bill Gates of Microsoft or Larry Ellison of Oracle, among many other software billionaires and multimillionaires around the world. But get the business model wrong, and -- to borrow a metaphor from Frederick Brooks's The Mythical Man-Month -- software companies can resemble dinosaurs futilely trying to escape the death grip of an ancient tar pit. The more you struggle -- that is, the more time, money, and people you pour into product development, sales, and marketing in the hope of a turnaround -- the deeper you sink and the quicker you die. In the software business, this is not only because the more people you add to a late software project, the later the project can become -- a rule of thumb now described as "Brooks's law" (and not always true). But the broader downward spiral can accelerate for a whole company and become self-fulfilling as present and potential customers flee from software producers unlikely to survive long enough to deliver, support, and upgrade their products.
In bad economic times, or when there is bad corporate news, we can see the sales of once high-flying software companies suddenly drop as if they had fallen off a cliff. Billion-dollar companies can shrink to half their peak size (e.g., i2 Technologies), declare bankruptcy almost overnight (e.g., Baan), or turn suddenly from modern-day gold mines into investment nightmares. SAP, Oracle, Siebel Systems, Business Objects, and many other blue-chip software companies lost 80 to 90 percent of their value at one time or another during 2000-2002, depending on when an investor bought the stock -- despite having solid products and businesses. Even Microsoft dropped about two thirds of its value during this period of boom and bust. We have seen this phenomenon of rapid growth and dramatic decline as well in the telecommunications equipment and services industries (e.g., Lucent and WorldCom), businesses that are also heavily based on software technology but even more distressed in terms of profits and sales.
Since software technology, software companies, their people, and their markets have unique challenges and opportunities, I believe that the business requires a unique approach to strategy and management. For example, software managers, programmers, and entrepreneurs need to encourage innovation wherever and whenever they can, but they have a special need to contain it as well; otherwise projects and plans can spin out of control. Perhaps most important, a large number of software companies -- those selling "enterprise software" to other companies and large organizations -- have to be nimble enough to tailor their products and their strategies to the needs of individual users and particular kinds of customers. Often they must survive the transition from selling high-margin products to selling low-margin services, especially in bad economic times and as their products and customer bases age.
This last idea -- that many software companies need to sell both products and services to maintain a successful business -- is a central theme throughout this book. I argue in Chapter 2 that there are basically three business models that fall along a spectrum: On one end are software products companies, which get all or most of their revenues from new product sales (called "software license fees"). On the opposite end are software services companies, which get a majority of their revenues from IT consulting, custom software development, integration work, technical support, systems maintenance, and related activities. In the middle are what I call hybrid solutions companies -- software firms that have some new product sales but derive as much as 80 percent of their revenues from services and "maintenance" (incremental product updates or special enhancements sold through long-term contracts to the purchasers of the initial software license).
I also argue that even companies trying to emphasize products eventually end up selling more services and incremental maintenance upgrades to their existing customer base than new products to new customers. They often fall unwittingly into the services or hybrid business models and are not prepared for the change. Bad economic times can accelerate this transition as customers postpone purchases of new software products. It also seems an almost inevitable transition for software companies that sell to corporate customers (enterprises): their revenues increasingly consist of sales of services and maintenance upgrades to existing customers, rather than new product sales to new customers. It can be devastating to a software company to find its new-software-product sales collapse, but it happens frequently. This is why managers, programmers, and entrepreneurs need to understand what the future usually holds for enterprise software companies, and how to manage and adapt to that future as effectively as possible. Accordingly, because of the potential for rapid change in the marketplace, software companies must combine extraordinary levels of structure with flexibility. Companies must pay constant attention to strategies and business models as well as continuously evolving their technical skills and core technologies. They must often experiment with new-product development while preventing projects from running years behind schedule or devolving into chaos.
Software as a Technology
How a software firm manages the technology to create and deliver products and services is usually central to its long-term success. Almost any firm can have a onetime hit product. But following this first product with multiple versions for different customer segments or with compelling updates and new services that meet future customer needs requires thought and careful management. But what does "managing the technology" mean in the context of a software producer? In this book, I treat the question in fairly straightforward terms, separating "the technology" from "technology management."
Technology Versus Management
Software technology is many things. I have already described it most directly as code -- programming instructions or algorithms, eventually translated into zeros and ones. But for practical reasons, we must also include system architectures, program designs, the data or digital content that computer programs need to do anything useful, user interfaces, application programming interfaces, programming support and testing tools, test cases, documentation, and other physical and nonphysical artifacts. Software technology also includes the effects of what programs do -- how one module of code interacts with other programs, modules, and computers, and what the whole system enables users to do.
Managing the technology in a software business primarily refers to overseeing the process of designing a software product or information system for a particular customer need and then building, testing, delivering, supporting, and enhancing that software product or system over its lifetime of use. Chapter 4 contains a lot of what I have learned about managing this chain of activities. In addition, though I do not talk much about managing the science, managing the technology should include facilitating communication between scientists pushing the state of the art and engineers building real-life applications.
From a business point of view, managing software technology well should imply knowing how to go through the phases from design to delivery at a cost that is less than the revenues generated from selling the resulting product or service. This may be common sense, but it is not always common practice. Here is where marketing and sales -- and financial discipline -- become as important as anything else in the software business. Managers, programmers, and entrepreneurs need to understand how to build or package technology and price it in a way that both makes people want to buy it and earns them a profit. Selling software and services at enormous losses (and I will discuss many examples of this, ranging from start-ups to established firms) is not a business. Many software companies waste millions and billions of dollars on development efforts, acquisitions, or marketing campaigns that generate no profitable results.
As a researcher and consultant, I have found that managing the technology well becomes a serious problem at one time or another in the lifetime of nearly all software businesses, including dedicated software companies and firms that do a lot of software development for in-house use. As I discuss in Chapter 3, IBM went through the pain of building OS/360 in the 1960s and eventually created a structured process that worked, despite a great deal of variation within the company and without much concern for flexibility or innovation. The Software Engineering Institute (SEI) at Carnegie Mellon University, to a large degree, has disseminated the best practices of IBM for large-scale systems development. The Japanese also attempted to solve problems in large-scale systems development by incorporating many practices similar to IBM's approach into their software factories of the 1970s and 1980s. Microsoft struggled mightily in the 1980s and came up with more flexible but still structured "synch-and-stabilize" techniques that worked well during the 1990s and early 2000s. Another giant, Oracle, in the early 2000s was still figuring out how to build high-quality applications the first time around. And these firms are all success stories! There are many other examples of start-ups and established firms wasting years and millions of dollars on software development, with little or nothing to show for it.
I also know of many cases (such as some of the start-ups described in Chapter 6) where the software engineers knew very well what they were doing but still failed anyway. They were able to create a prototype or small-scale system without spending too much time or money. But then problems almost always set in as these firms tried to build a commercial-grade product with more sophisticated features, or as they took on hybrid-solutions projects that rose quickly in complexity and then overwhelmed their management skills or financial resources. And even where managing development of the technology was not a major problem, understanding how to market and sell the technology they were creating was a major factor in their struggles or demise. As Chris Peters of Microsoft once said, it is just as important in software development to decide what you are not going to do as it is to decide what you are going to do.
Because software can perform an almost infinite number of functions, the challenges of managing the technology well continue to be enormous, especially for inexperienced start-ups or established firms where software development is not the primary business. Managers, programmers, and entrepreneurs have to accommodate different kinds of projects and customer requirements, as well as anticipate changes in the technology and market needs. What do you have to think about if you are working on software for the space shuttle? It is very different from what you must think about if you are working on a video game. What software producers must do well may be the same at a high conceptual level -- they need to design, build, test, deliver, support, and maintain a product or a custom-built system. But the demands vary considerably depending on how customers will deploy the software technology in their particular applications or markets. In short, the requirements of managing software as a technology vary with the requirements of managing software as a business.
My Involvement with the Software Business
This book is very much a personal view of the software business, seen through the lens of nearly two decades of research on the industry, professional involvement with dozens of software companies and organizations, and teaching a class titled "The Software Business" at MIT since 1997. I am not a programmer, but I have been fascinated by computers since first using an IBM mainframe in college during the mid-1970s. But my first recognition that software was a special business with special problems in strategy and management came in 1985. That is when I started studying how Japanese companies built large-scale industrial software systems and were trying to add sophisticated software skills to their already formidable hardware skills. Since the late 1970s, I had been studying Japanese production and quality management techniques, particularly in automobile design and manufacturing. But I had tired of looking at this one industry and thought that the next great challenge for Japan after automobiles would be computer software.
I began the new research by reading about the history of the computer industry in Japan as well as some articles on Japanese software engineering practices. One fact immediately got my attention. Since 1969, the major Japanese computer manufacturers had been concentrating their people with software expertise in relatively large facilities and had been trying to apply the same disciplined approach to software production and quality management as they had done in "hard" manufacturing businesses. I then began to write case studies and conduct surveys of software projects and development practices at Hitachi, Toshiba, NEC, Fujitsu, NTT, and several other Japanese firms. I also studied IBM, DEC, System Development Corporation, and Andersen Consulting, among other U.S. firms, for comparisons. I learned a great deal about process and organization in mostly custom or semicustom software development for mainframe computers. But I ended up wondering why process excellence and "zero defects" did not necessarily make a company successful in software as a business.
I remember giving a press conference for the American Electronics Association's Tokyo chapter in February 1991 to announce the results of my research on Japanese software. I began with the statement that the "$60-billion-dollar question" people had been debating for years was whether or not the Japanese could write software. I said that I finally had an answer, though I divided this into "good news" and "bad news" from the point of view of American firms.
The bad news was that the Japanese could write software. In fact, they wrote a lot of software, and they wrote it as well as or better than U.S. firms in terms of reliability (few "bugs" or defects) and crude measures of productivity (code output per programmer, including large amounts of reused and semiautomatically generated code). The "factory-like" approach that the Japanese computer manufacturers used for software development also differed from the approaches common in the United States. The Japanese emphasized incremental innovation in feature design, standardized development techniques, common training programs, reusable component libraries, computer-aided support tools, rigorous quality assurance techniques, and statistical data to manage projects. The Japanese also tended to staff projects with a combination of experienced people and relatively low-skilled programmers who had merely a few months of training.
But there was also good news, again, from the perspective of U.S. firms: the Japanese approach seemed well suited for building certain kinds of software systems but not others. Moreover, Japanese companies didn't seem to know much about how to make money from software or compete outside Japan, except for software embedded in products such as programmable machine tools, VCRs, and microwave ovens. The Japanese were focused mainly on labor-intensive custom or semicustom information systems built to sell mainframe computers and targeted to Japanese customers. They had limited innovation capabilities and ambitions, although Fujitsu, NEC, and Hitachi routinely beat U.S. competitors in the Japanese market because of their quality, service, and reliability. The Japanese economy would continue to modernize through the introduction of more computers and new PC-based or workstation-based information systems. But there was no dominant global software player likely to come from Japan, except perhaps in niches such as the video game industry. (This was an area of software that the Japanese excelled in, perhaps because of their fascination with comic books from childhood through adulthood.)
After studying Japanese software factories, I decided to "follow the money," so to speak. I decided to look at the company that made the most money and seemed to care the least about the process of product development: Microsoft. As it turned out, I soon learned that Microsoft managers and programmers did care a lot about process. But compared to the approaches followed by traditional U.S., Japanese, and European software organizations, they cared in a way that was much better suited to the fast-paced and somewhat unpredictable world of PC software and, later, the Internet. Microsoft people also cared more about strategy and money than they did about following textbook processes. They were interested in dominating markets -- albeit too interested at times, so much so that the company ran afoul of antitrust laws. My new interest in Microsoft turned into another book published in 1995 with Richard Selby. In subsequent research, I continued to follow the evolution of Microsoft through the Internet age and competition with Netscape as well as into the world of .NET and Web services.
My research also created opportunities to work with approximately fifty software producers in Europe and Asia as well as the United States, beginning in 1987. These organizations include software products and services companies; computer hardware and semiconductor companies with large software businesses; financial services companies heavily dependent on software technology; and telecommunications equipment and services companies. I am also fortunate to have served on approximately a dozen boards of directors and advisers for software companies and venture capital firms in New England, Silicon Valley, and London. What I have written in this book, consequently, is colored not only by my experiences with the Japanese and Microsoft, but also from studying and working with a wide variety of software producers around the world.
Some International Generalizations
My international experiences (including residing in Japan for about seven years) have often led me to compare people and organizations in different parts of the world. Here I would like to offer some generalizations about how the software business might differ in three regions I know reasonably well: Europe, Japan, and the United States. Like all generalizations, there are exceptions. I also think these generalizations were more applicable a decade or two ago than they are today. But I believe that they still contain more than a grain of truth. They also reflect a key motivation for me to write this book: the conviction that software is too important to be treated simply as a technology, or as part of the field of computer science. Software has the power to change the world, especially when treated as a business by managers, programmers, and entrepreneurs who also want to change the world.
The Europeans
The Europeans, along with the Americans, pioneered a lot of the inventions in computer design. But too many European companies I have encountered tend to treat software as a science. The reason is not hard to understand. The Europeans have excellent university-level education in computer science, especially programming languages and principles of design. And so, from Europe, we get things such as formal methods (a way of specifying requirements for software systems in mathematical terms that can be verified and validated mathematically) and object-oriented analysis and design (a clever way of breaking up software programming instructions and data into small, reusable objects, based on certain abstraction principles and design hierarchies).
We also get from Europe enormously rich but complex applications remarkable in their detail and structure, like those the German company SAP has produced. In addition, we can find elegant but simple applications that enable nonprogrammers to query databases and generate useful reports, such as those the French company Business Objects created a decade ago around object-oriented technology. Europe has also produced stunning innovations such as the World Wide Web, invented by Tim Berners-Lee, an Englishman, while he was working at the CERN physics research lab in Switzerland. But I have often found that many European software producers place more attention on achieving elegance in software design than on shipping products for mass markets and making the most money they can from their excellent technical skills.
The Japanese
The Japanese, for much of their history, have followed IBM and a few other American companies in designing and building mainframe computer systems. Japan's computer manufacturers and software firms have shown significant skill in writing programs for all sorts of applications, ranging from real-time banking systems, to fault-free bullet train control and reservation systems, to video game software. But most of these systems are custom-built for specific customers in Japan and contain relatively few innovative features, by design. The largest Japanese producers of software mainly write code to sell hardware and services, as IBM has done for decades. The country has also underinvested in basic research and higher education. Not surprisingly, Japan has had relatively weak university training in computers and information systems. Japan has also lacked the broad diffusion of computers, knowledge of English typing, and programming expertise among young people that has led to a strong "hacker" tradition in the United States and, to a lesser extent, in Europe.
Accordingly, the major Japanese producers of software -- Fujitsu, Hitachi, NEC, Toshiba, and NTT -- have had to train most of their own people on the job and have ended up treating software development mainly as a problem in production. With some exceptions, such as game software and some more creative consumer electronics applications, the big Japanese companies I know well have tackled large-scale systems development with heuristics (engineering rules of thumb), process discipline, some capital (e.g., computer-aided tools), and manpower. Hence, we have software factories. The factories were and remain good at cranking out multiple versions of custom or semicustom applications that follow standardized design patterns and evolve little from their original parameters. Software built in this way is useful in selling hardware and performing basic tasks or making construction of third and fourth versions of similar custom systems a bit easier and cheaper. But it doesn't change the world or make anybody a billionaire.
The Americansar
And then we have the Americans. People in the United States are unmatched in treating software as a business. That is, they see software technology as a vehicle for creating dedicated software companies that produce at least "good-enough" products and try to set industry standards as well as make lots of money in the process. And so, in the United States, we have companies like Microsoft and Netscape, both of which tried to and succeeded in changing the world. Bill Gates, who cofounded Microsoft with Paul Allen in 1975, wanted to see a personal computer on every desktop and was determined that those PCs run Microsoft software. Today more than 90 percent do. Gates also had the great insight in 1975 to conclude that the future value of computing would be in software, not hardware. Marc Andreessen, who cofounded Netscape with Jim Clark in 1994, felt that an easy-to-use browser that ran on Windows as well as other software platforms would make usage of the Internet ubiquitous, for both individuals and organizations. It now is. Microsoft and Netscape went on to introduce products that were no more than "good enough" from a technical point of view: MS-DOS, Windows, and Netscape Navigator.
Of course, software programming can still be science for Americans. Like the Europeans, we have great universities and computer scientists. It most certainly can resemble disciplined engineering practice, especially in the U.S. defense industry and mainframe software worlds, but also in the commercial operations of companies such as IBM, Sun Microsystems, Hewlett-Packard, and, yes, even Microsoft, when it comes to building products such as Windows NT/2000. But many American companies, and the occasional European company that operates like an American company, at least in marketing (witness Business Objects and SAP), have found ways of generating oodles of revenues and profits, and tremendous excitement for their employees and investors, by treating software as a business. This book is about how to do that, whichever country you are from and whichever part of the software industry you are in.
Basics of the Business: Two Case Studies
There are many issues of strategy and technology management that managers, programmers, and entrepreneurs in the software business need to understand in order to have successful companies in both good times and bad. To illustrate some of the key issues here, I introduce the stories of two companies I have worked for over the past several years: Business Objects and i2 Technologies. Both are public software companies. Business Objects (NASDAQ stock symbol: BOBJ) is based in Paris with a second headquarters in Silicon Valley, and i2 (stock symbol: ITWO) has its headquarters in Dallas and much of its development organization in India.
Business Objects is a clear-cut success story of a business intelligence company selling horizontal software to enterprises and institutions. From the beginning, it demonstrated a very focused strategy as a complement to Oracle and then other database products. It has benefited from superb leadership by the founder, disciplined operations, clever product development, and fast and profitable but not un-wieldy growth. The company passed $450 million in revenues in 2002.
i2 Technologies, on the other hand, had a meteoric rise in the market for factory planning and supply chain management software. It went from $2 million in sales in 1992 to almost $900 million in 2001, but also lost nearly $8 billion that year, although most of these losses were write-offs of devalued acquisitions. Though it has made dramatic improvements in the past few months, i2 remains an example of a company that grew too fast during the height of the Internet bubble. The company nearly lost its focus and ability to serve customers. It has a founder and new senior management team with great determination to change, however, and that may be enough to turn the company around.
Business Objects
I was sitting in my office at MIT one day in April 1996. The phone rang, and it was Bernard Liautaud, the CEO and cofounder of Business Objects. He had read Microsoft Secrets and asked me if I could help him make his rapidly growing company work as well as Microsoft. I agreed to try. This led to a weeklong visit in May, a series of reports and recommendations over the next five years, and laudable efforts by Liautaud and many other people in the company to make Business Objects into what became one of the fastest-growing and most consistently profitable software companies in the world. In 2002, the company was the market leader in revenues for business intelligence software, a segment that the International Data Corporation estimated to be about $8 billion in 2001 and expected to double in size by 2005.
Liautaud and a partner, Denis Payre, had founded Business Objects in August 1990. Both men were French nationals who had worked at Oracle France in sales or marketing. The original idea for the company's main product came from another Frenchman, Jean-Michel Cambot, an independent engineer and consultant who worked with Oracle database products. Cambot had approached Liautaud in the late 1980s with a concept for a new decision-support tool based on the latest object-oriented design technology -- software as science leading to a commercial innovation. His product (actually, a short program or set of computer instructions) made it possible to generate SQL (Structured Query Language) statements from a simple user interface, without the user having to know SQL or any other database programming language. Cambot wanted Oracle to make his prototype into a product and distribute it for him. Oracle management declined, even though the response from a sample of Oracle customers to the product idea was very positive. Liautaud and Payre decided to create a company around the product. They secured some funding and bought the software from Cambot in exchange for royalties. After three years of successful sales, Business Objects went public in 1996.
In an interview for this book, Liautaud recalled that, from the beginning, Business Objects went after a big "horizontal niche" rather than a "vertical" market. It attempted to "cross the chasm" separating early adopters from mainstream users by riding on the backs of Oracle customers (more on horizontal versus vertical niches as well as chasm crossing and its alternatives in Chapter 2). Liautaud noted that the company was not trying to create a new platform to work with all database technologies, but rather was positioning itself as a "complement" to Oracle:
We viewed our market as Oracle customers, period. We said we were not going to go after Sybase, Informix, or Microsoft customers. We were going to stay pure Oracle at the beginning. And the main reason was that by doing this we would be able to work with the salespeople at Oracle. We would not be a danger to the Oracle sales force...We were a complement. It would improve their product. They didn't have anything comparable. It would make them win deals more. And, by the way, the very first deal we won with an Oracle France sales guy was a deal where he had lost against Sybase. We came back, and we managed to get a last-minute meeting with the decision maker in the company. We showed our product on top of Oracle, and the guy said, "I'm switching my database, because if that product doesn't work on Sybase, then I want Oracle because that's exactly what I want. I want that product and I will pick the database that works with that product." I can tell you we advertised that to all the Oracle France sales force, and they went crazy....Our crossing the chasm was not a vertical strategy, like going retail. Our strategy was Oracle customers....It was a big niche.
The innovative technology alone was sufficient for leading-edge customers. The product was also attractive because it worked on DOS computers (the most popular business PCs at the time) with an extremely small memory requirement, about three hundred kilo-bytes. Windows was not yet available widely. As for pricing, the company ended up going with a high-end strategy -- $15,000 for eight users as the minimum contract. It used as a pricing benchmark what Oracle was charging for its own query tools. Two years later, in 1992, Liautaud and Payre decided to extend the product to work on other databases.
The two entrepreneurs grew the business from nothing in 1990 to more than $60 million in revenues by 1995, with impressive profits -- surpassing $10 million in 1995 alone. (For financial data on Business Objects, see Appendix Tables 1 and 2.) This is the beauty of software product sales, usually called "software license fees." Software is a digital good, so making one copy or a million copies costs about the same. There is, as a result, tremendous potential in the software products business for economies of scale and rapid, profitable growth. Product sales accounted for more than 80 percent of the company's revenues during 1993-1995, with minimal costs compared to services such as product customization, maintenance, and technical support. In recognition of their performance, Business Week named Liautaud and Payre among the "best entrepreneurs of the year" for 1995.
Business Objects did not do it all alone. The company reached an agreement in 1994 for IBM to resell its core product bundled with IBM's data-warehousing package as well as some industry-targeted vertical solutions. IBM quickly became the company's biggest reseller, a position it still had in 2002. Most of the company's revenues have been through direct sales channels, rather than resellers, although Liautaud commented on the benefits of the ties with IBM: "The [IBM] sales were not huge. It was probably five percent of our revenue per year, not much more. But it gave us the credibility. The marketing leverage was very important. It still is."
The company also had to overcome the usual problems of a rapidly growing start-up. For example, Business Objects' 1997 Form 10-K report to the U.S. Securities and Exchange Commission, with surprising candidness, detailed the difficult state of product development during the spring of 1996. The comedown from the banner year of 1995 was dramatic. The new 4.0 release was a year late -- it had planned to ship the update in June 1995. Moreover, the company admitted that the product code was still riddled with bugs. When I first visited the company, I learned that engineers and managers severely doubted they would ever get the defect level low enough to ship the new version of the core product. In the meantime, sales were dropping as customers waited for the new release. The problem was not easy to solve. Business Objects had redesigned the core product to run on Microsoft's new 32-bit operating system, Windows 95. But this new version (BusinessObjects 4.0) did not run well on the older 16-bit Windows, version 3.1, which was still the most common PC operating system used in corporate settings. Most customers had switched from DOS but had not yet upgraded to Windows 95 or Windows NT (which was also a 32-bit operating system with interfaces similar to those of Windows 95). Managing software design and development better and dealing with platform issues were only some of the hurdles facing the young company, though they were central to survival.
Business Objects did tail off in growth during 1997 ("only" 34 percent over the prior year) due to the delay of the new release, before returning to a more familiar pace (46 percent) in 1998. The company then grew about 45 percent annually, even as license fees (new product sales) declined as a percentage of revenues to about 60 percent in 2001. The company was not immune to the bad times that hit the entire software industry after the bursting of the Internet bubble. Nonetheless, in 2002, Business Objects topped $454 million in sales with operating profits of more than $47 million -- excellent numbers in a bad year for most software companies. As of mid-2003, it had millions of users at more than 17,000 customer sites in eighty countries. More than half the company's sales were from North America, Business Objects' fastest-growing market, and about 40 percent from Europe.
Liautaud has presided over the growth of the company alone since 1996. Payre, who initially had taken the title of president and headed sales, left the company at the end of 1996 to become a venture capitalist in Brussels. It is also significant that Liautaud moved to the United States in July 1997 to give more priority to the U.S. operations. Increasing sales in the biggest software market was critical to making Business Objects a worldwide brand. In recognition of the company's success as well as his leadership, many awards have continued to come to Liautaud personally and to his firm. Of particular note, in 2002 Business Week called Liautaud "France's most successful software entrepreneur" and Time magazine listed him as one of the twenty-five most influential business leaders in Europe.
Business Objects had a clear strategy in the mid-1990s, but the company faced many hurdles in building more capabilities into the product, making the technology rock-solid for the mainstream enterprise market, and upgrading internal processes for software design, development, and testing. At the same time, the young French company had to figure out how to manage highly talented but temperamental French computer scientists, and transform a start-up French organization into a global corporation that could operate equally well in the United States and Europe. It was apparent in the first e-mail Liautaud sent me in 1996 how well prepared he was to tackle hard problems -- the software development process, organization structure, task and project management, viability of the executive team, recruiting, employee morale -- before the company and its challenges got any bigger:
Subject: Re: Consulting
Date: Tue, 16 Apr 96 10:06:30 WET
From: "Bernard LIAUTAUD"
To: "Michael Cusumano"
Yes, I am confirming. I would like to agree on the process and the deliverables for that week.
The way I see it is the following:
1. Short audit of our current software development process
2. Build a set of recommendations, with an emphasis on
Le informazioni nella sezione "Su questo libro" possono far riferimento a edizioni diverse di questo titolo.
EUR 4,50 per la spedizione da Germania a Italia
Destinazione, tempi e costiEUR 2,00 per la spedizione da Irlanda a Italia
Destinazione, tempi e costiDa: medimops, Berlin, Germania
Condizione: good. Befriedigend/Good: Durchschnittlich erhaltenes Buch bzw. Schutzumschlag mit Gebrauchsspuren, aber vollständigen Seiten. / Describes the average WORN book or dust jacket that has all the pages present. Codice articolo M0074321580X-G
Quantità: 1 disponibili
Da: Hamelyn, Madrid, M, Spagna
Condizione: Como nuevo. : En 'The Business of Software', Michael A. Cusumano, experto en la industria del software, revela los secretos de las empresas de software más exitosas del mundo. Basado en años de investigación y consultoría, Cusumano presenta un marco de gestión de tres puntas que ayuda a las empresas a elegir el modelo de negocio adecuado para capitalizar los buenos tiempos y sobrevivir a los malos. Este libro es una guía esencial para gerentes, programadores, emprendedores y cualquier persona interesada en la industria del software. EAN: 9780743215800 Tipo: Libros Categoría: Negocios y Economía|Tecnología Título: The Business of Software Autor: Michael A. Cusumano Editorial: Free Press Idioma: en Páginas: 352 Formato: tapa dura. Codice articolo Happ-2022-08-16-da477167
Quantità: 1 disponibili
Da: ThriftBooks-Atlanta, AUSTELL, GA, U.S.A.
Hardcover. Condizione: As New. No Jacket. Pages are clean and are not marred by notes or folds of any kind. ~ ThriftBooks: Read More, Spend Less 1.1. Codice articolo G074321580XI2N00
Quantità: 1 disponibili
Da: ThriftBooks-Dallas, Dallas, TX, U.S.A.
Hardcover. Condizione: As New. No Jacket. Pages are clean and are not marred by notes or folds of any kind. ~ ThriftBooks: Read More, Spend Less 1.1. Codice articolo G074321580XI2N00
Quantità: 1 disponibili
Da: ThriftBooks-Dallas, Dallas, TX, U.S.A.
Hardcover. Condizione: Very Good. No Jacket. May have limited writing in cover pages. Pages are unmarked. ~ ThriftBooks: Read More, Spend Less 1.1. Codice articolo G074321580XI4N00
Quantità: 1 disponibili
Da: Brit Books, Milton Keynes, Regno Unito
Hardcover. Condizione: Used; Very Good. ***Simply Brit*** Welcome to our online used book store, where affordability meets great quality. Dive into a world of captivating reads without breaking the bank. We take pride in offering a wide selection of used books, from classics to hidden gems, ensuring there is something for every literary palate. All orders are shipped within 24 hours and our lightning fast-delivery within 48 hours coupled with our prompt customer service ensures a smooth journey from ordering to delivery. Discover the joy of reading with us, your trusted source for affordable books that do not compromise on quality. Codice articolo 4043701
Quantità: 1 disponibili
Da: Brit Books, Milton Keynes, Regno Unito
Hardcover. Condizione: Used; Good. ***Simply Brit*** Welcome to our online used book store, where affordability meets great quality. Dive into a world of captivating reads without breaking the bank. We take pride in offering a wide selection of used books, from classics to hidden gems, ensuring there is something for every literary palate. All orders are shipped within 24 hours and our lightning fast-delivery within 48 hours coupled with our prompt customer service ensures a smooth journey from ordering to delivery. Discover the joy of reading with us, your trusted source for affordable books that do not compromise on quality. Codice articolo 1752855
Quantità: 1 disponibili
Da: WorldofBooks, Goring-By-Sea, WS, Regno Unito
Paperback. Condizione: Very Good. The book has been read, but is in excellent condition. Pages are intact and not marred by notes or highlighting. The spine remains undamaged. Codice articolo GOR003137099
Quantità: 3 disponibili
Da: MusicMagpie, Stockport, Regno Unito
Condizione: Very Good. 1752057631. 7/9/2025 10:40:31 AM. Codice articolo U9780743215800
Quantità: 1 disponibili
Da: Better World Books, Mishawaka, IN, U.S.A.
Condizione: Very Good. Used book that is in excellent condition. May show signs of wear or have minor defects. Codice articolo 807031-6
Quantità: 2 disponibili