Google has received a good deal of attention for its pro-active encourage of new product ideas from employees through its “70/20/10” rule, which Thompson described as the expectation of top management that employees would “devote 70 percent of every work day to whichever projects are assigned by management, 20 percent of each day to new projects or ideas related to their core projects, and 10 percent to any new ideas they want to pursue regardless of what they might be”. Obviously such a system became unwieldy as the company’s growth exploded and additional steps needed to be taken to manage the flow of potential innovation including initiating the practice of having employees meet on a regular basis with the founders and other top executives of the company to pitch their new ideas and projects.
A fascinating window into the product development and management process at Google during the early 2000s comes from notes taken by Rodriguez on a presentation given in 2003 by Google product manager Marissa Mayer, who was later to become CEO of Silicon Valley icon Yahoo. In her presentation Mayer noted that product development at Google was rigorously tied to the company overall mission of organizing the world information to make it universally accessible and useful and that “accessibility” and “utility” were thus key goals in each product development initiative. In fact, Mayer stressed several times that “user-centered design” was extremely important in the product development at Google and that this meant building products that people really wanted based on identifying and understanding user needs and desires. According to the notes prepared by Rodriguez the Google product development process began by accepting ideas from everywhere (i.e., employees and customers)—Google expended a lot of effort to encourage new ideas including sponsoring various forms and mediums for idea-collection and participation—and then prioritizing those ideas on a “Top 100” list based on several factors including utility to users, the likelihood that it would assist user retention, chances for success, the contribution it might make to diversifying revenue stream and, finally, the level of effort required relative to impact.
When a new product idea was selected for further development it was assigned to one of many small, agile engineering teams that were allowed a great deal of autonomy with respect to their internal organization. Google did not have a formal product development department and instead viewed each team, which typically had three engineers, as the relevant business unit for each project. Members of the team were co-located and worked exclusively on the project for three or four months before moving on to a new project. One of the engineers was designated as the “technical lead” for the team and had responsibility for the technical excellence of the project. At this early stage product documentation was very sparse and the team prepared only what was necessary to create a product requirements document that would be analyzed at the end of the initial development process. A Google product manager was continuously involved in the work of each team and product managers generally worked with nine or ten engineers across several teams at the same time. Larger projects were explored using the same methods applied to smaller projects by breaking the tasks into logical modules that could each be addressed by small teams (e.g., a large project might have four units of three people, a total of twelve people, each working on a discrete piece at the same time).
Rodriguez recorded several other interesting characteristics of the Google product development process. First, once the company was satisfied that a new product or service was likely to be seen as useful by users teams were created to create and execute an explicit “monetization” strategy for the product or service. Second, Google created organizational tools to ensure that the plans for launching each new product, including calendars and current status reports, were readily visible throughout the company. Third, as mentioned above, the focus on user-centered design was continuously reinforced and the product development path included weekly user studies, emphasis on quality and understanding what users really care about, experimentation and iteration. Finally, Google had a bias toward “expedient solutions” and getting new products and services out into the market quickly even if the company knew that further work would be needed to improve performance and the quality of the solution offered to users.
Rush et al. conducted ongoing research to identify best practices of highly successful new product development teams operating among Silicon Valley technology companies. They were particularly interested in exploring the methods used by these companies to get new products to market quickly and efficiently while ensuring that customer requirements are satisfied. Among other things they found that the most successful companies were those that recognized that customer requirements were likely to change continuously during the development process and that it was a mistake to freeze the product specifications early in the process and not engage in regular contract with customers to gather feedback. In fact, the researchers found that the most successful product development teams proactively sought out product requirements from the most suitable and dominant customers in the market segment that the companies had chosen for the new product.
Jaruzelski and Le Merle argued that Silicon Valley companies were more successful at innovation than their counterparts in other parts of the world because Silicon Valley companies did a much better job of creating and maintaining strong alignment between their innovation and business strategies and emphasized that the most successful Silicon Valley companies anticipated customer needs, had their top technical executives report directly to the CEO, ensured that innovation strategies were developed and communication from the top throughout the company, and constantly refreshed their product development staffs.