First it was IBM, then Microsoft.  Both of them were high growth, innovative organizations whose cultures and management strategies became examples that many tried to follow. Now that attention has turned to Google.

Founded in 1988, Google rose to prominence on a search engine that now captures 70 percent of the market. But it didn’t stop there. In recent years Google introduced a wide range of additional products to protect its market share, exploit its brand name, and grow revenues. Some of these products include:
•    Google Talk
•    Google Checkout
•    Google Maps
•    Google News
•    Chrome
•    Spreadsheets
•    Google Finance
•    Gmail
•    Google Calendar
•    Google Editions
Most of these were not paradigm-breakers; they offered only a few new features and targeted established markets. Their on-line payment system, Google Checkout, for example, competes head-on with PayPal while their recent introduction, Google Editions, competes head-on with Amazon’s Kindle

How do they do it? How do they create a steady stream of enhancements and new products? And if we learn how they do it, can this knowledge be transferred to other organizations?

Determining how they do it is quite challenging because Google tends to be secretive and as a result little is available that describes their project strategies. Yet, there are some interviews, presentations and trade articles that provide enough insight to help us piece together an explanation of how it is done.

What emerges from these sources is an interesting if not somewhat unorthodox approach to project management. At the very least, they have added several critical success factors to the traditional list that most companies use as guideposts to effective project management.  We begin with a case study of the Google Calendar project.

Case Study: Google Calendar

According to Carl Sjogreen, who led the development team, the idea for a Google calendar was sparked by a few people who were users of current web-based calendars but who recognized the opportunities for a new calendar with improved and new features.  From their perspective there was not much new in calendar design and there was apparently not much going on.

They were under no illusions. In a market dominated by Yahoo’s Calendar and Microsoft’s Outlook, and in a market where they would be a late entrant, it would be challenging to capture market share.   Yet there was a sense that Google could do it. It was worth a try.

While the project unfolded in an organic and iterative way it is useful to organize it into four stages.
•    Front-end design
•    Prototype
•    Backend Design
•    Beta testing
•    Launch

Front-End Design

The project began with a group of three people.  From its start, every attempt was made to go beyond the team’s own experience.  They talked with real customers, not just friends or those interested in the project or other Google employees, but people outside the company; students, business professionals, volunteers in civic organizations, and families.  And in talking with these people every effort was made to obtain a balanced and representational view, not just the opinion of those with technical backgrounds, but those who might be challenged when considering the adoption of new technology.

From these interviews they identified at least five features that would determine the success or failure of the project. The Calendar would have to be:
•    Fast
•    Visually appealing
•    Pleasant to use
•    Easy to enter personal data
•    Simple to share with friends, colleagues, and family
Once they had a rough idea of what had to be done, and once some very simple designs had been drafted, a prototype was developed to test these ideas on users.


A simple but functioning prototype was developed early in the design process to test the feasibility of the ideas that had been proposed. Then, as the design process evolved, new functions and new user interface strategies were incorporated into the prototype. As a result, the prototype became the platform around which the new product evolved and the vehicle for trying and testing new ideas.  Still, the prototypes were simple. The challenge of scaling the prototype to accommodate a more complex and robust system was left to later.

Useful clauses Gypsum cardboard Decorative furnish

The prototype process generated useful feedback. Not only did the users react to what was presented but they also suggested many features that they would like to see in the finished product.  Yet, as they calendar team collected data they still remained cautious because these early users might not necessarily represent the product’s target audience. It was still assumed at each stage that some of the features added to the prototype would eventually be discarded and others, not yet considered, would be added.


Backend Design

After the prototype process was well underway, backend design began. Now the technical staff became involved in translating the features of the calendar into a fully functioning and scalable product. Backend design, however, did not put an end to product design.  As the technical staff worked on the product, the product design team continued to test the system and make sure that the functionality, look, and feel conformed to what it was they wanted.  

Beta Testing

With the basic features incorporated into the product, it was then rolled out for Beta testing. Now, a wider range of real users would put the calendar to the test.  But the iterative process continued.  The Beta version  would not only confirm what worked and what did not work, it would also function as  an opportunity to identify what other improvements or additions needed to be made.  It was during this phase, for example, when the design team discovered that more work needed to be done to facilitate importing data from Yahoo and Outlook calendars, and it also learned that more had to be done if the calendar was to be compatible with small-screen devices and monitors.

Learning from Google

From this case study and other sources, we can begin to piece together Google’s project strategy.  At least six characteristics define the way they create, approve, and execute their projects.
•    More is better than less
•    Small teams
•    User-centered design
•    The best is the enemy of the good
•    Launch early, revise and re-launch

More is Better than Less

It is very difficult, if not impossible, to predict how a new product will evolve through the design and development process. It is also impossible to predict how markets will change over the life cycle of a project or how customers will respond once a product is released.  Indeed, risk is inherent in competitive markets and what started as a competitive product, may fail in the marketplace, left behind by products introduced by competitors.
One strategy is to spread product risk by approving a broad range of products. In other words, rather than spending considerable time and money vetting and developing a few products it might be better to approve many projects, and to expect that some will fail while others survive.

In a Business Week interview (6/30/06) Marissa Mayer, Vice President, Search Products & User Experience, said that we try a bunch of ideas knowing that all will not survive. She continues, “(we) release five things and hopes that one becomes phenomenally popular.”

Small Teams

Teams at Google are small and self-organized.  They usually include three people who sit next to one another and work on the project for three to four months. Work is reviewed by peers in what can be a lengthy process of critical analysis and change.  When their work is done they transition to another project. (

The use of small teams, as well as an organizational structure that is very flat, reflects an organizational culture that emphasizes:
•    An entrepreneurial approach
•    Fewer channels of communication
•    An open attitude toward reasonable risk-taking
•    Team commitment to a project
•    Close ties with the user population.
It is an organizational culture that is agile and unencumbered by the burdens of a bureaucratic process.

User Centered Design

The Calendar case study underscored how Google projects clearly focus on those who are candidates for using the product.  What is interesting is that this target population was not limited to potential customers who were already familiar with web-based calendars but also included those who used other means, such as paper calendars, to keep track of their time. Here, there was a real effort made to avoid a convenience sample of current users or tech-savvy individuals in favor of a truly random sample of the potential user population.

Many projects have a difficult time maintaining a sustained involvement and effective communications with end-users. Often these activities are seen as distractions from getting the “real work” done and meeting schedule deadlines. In these projects, a marketing study is undertaken before project approval. Then, once it is approved little attention is directed toward the customer or end-users as it moves through planning, execution, control and implementation.

Google, takes a very different approach. Engaging the user population is a formal part of the design and development process.  Further, the role of the customer is never finished, even after several releases.  In this way there is a built-in mechanism to ensure that the project team never loses sight of the project’s business objectives.

User involvement at Google is formalized at many stages in the project process. Users are brought into labs and given assignments to complete using recent prototypes. Sometimes this test involves two users who are observed by a third person. The observer records how the users navigate through the pages, how they move from top to bottom and left to right.  In addition, software is used to record eye movements as well as mouse clicks and the data are summarized and analyzed to provide additional insight that will then be used to improve the functionality, look and feel of the system.  A very similar process is used at Fidelity in Boston, where new web pages are tested in a lab environment.

The Best is the Enemy of the Good

It is not unreasonable to assume that product design teams want to do their best before a product is considered ready for launch.  But the best results take time and resources. And the best that the design team can do does not necessarily mean that the product will compete well when it finally reaches the marketplace.

Google chooses to launch early. They resist the temptation to wait for every feature to be added and every test to be run.  Instead, they release “good enough” products. Yet, within the context of an early release, these products still meet Google’s standard of quality.

Clearly releasing a “good enough” product depends upon the product, market competition and the consequences of risking an early release.  We are all quite familiar with the Columbia disaster when seven astronauts perished on February 1, 2003 because the window for launch was closing and there was not enough time to track down engineering reports that the foam insulation on the leading edge of the spacecraft had broken off during previous flights striking the leading edge of the vehicles wing and posing a threat to the spacecraft’s ability to withstand reentry temperatures.
But the consequences of launching a Google product are not nearly the same as the consequences of launching a spacecraft too early.  Google’s Gmail, for example, was in Beta version for five years before it was officially launched in 2009. It took that long before its peer review and end-user review processes were complete.

Launch Early, Revise and Re-launch

If the organization chooses to release “good enough” products, then it must be committed to releasing updates on a regular basis.  Mayer said, “We like to put products out there early, see what users say about them, what additional features they would like to see, and build these out.”  She continues, “We’d rather put something out on [Google’s Beta site] labs ….that gives the team a little bit more time to scale with the requirements. Also it gives us some very important indications about whether or not this product fills a core need well, how big the market is, and also how strong our product is relative to others.”
We might call this an “Extended Agile Approach” because the project management process continues past the first launch and assumes project responsibility for the improvements made to the product over its life cycle.  Accordingly, the project life-cycle and product life cycle are more closely connected. This does not mean, however, that that same project team follows the product life cycle from beginning until the product is dropped from the product line.  Each release could be the responsibility of a new project team.  


While this brief insight into Google’s project strategy helps us to understand how they introduce a continuous stream of new products, the question is whether or not this approach can be useful beyond Google.  The answer depends, of course, upon the organization, its human resources, administrative structure, goals, and markets. For some, this approach, or parts of it, may be appealing and may improve the competitive position of their firm.  For others the transformation to an extended agile project environment may be difficult and will depend upon that organization’s ability to make some significant cultural changes to its management processes and to its project management strategies.  

Organizations characterized by bureaucratic structures and rule-bound decision-making processes as well as those characterized by an internal focus and an aversion to risk, would find it difficult to create Google environments, but it can be done. And transferring some of these ideas beyond Europe and North America would also be challenging.  Asian countries, where organizational cultures are characterized by high power distance and high uncertainty avoidance may find it especially challenging and need to develop a transition process that is sensitive to national and organizational culture.  But even there, it can be done.

Nonetheless, Google does raise some interesting questions. Should your organization be launching more products, taking greater risks and accepting occasional failures as part of the firm’s competitive process?  Should the organization be flatter with small entrepreneurial teams?  Should the user community be more involved throughout the project management process, and should products or services be released earlier in their life cycle.

@2010 Barry Shore. Not to be reproduced or used in any way without the written consent of the author.