Building Product Teams: Examples from Amazon, Google, Apple, Basecamp and Fog Creek
Overview: The final article in our series on product development for we.st deals with building product teams. Product teams may be highly subjective but there are general rules for building multifunctional teams that are both agile and creative. Explore the building blocks of successful teams alongside examples from Amazon, Google, Apple, Basecamp and Fog Creek.
“Making a product is hard but making a team that can continually make products is even harder. The product I’m most proud of is Apple and the team I built at Apple.” Steve Jobs as remembered by his biographer, Walter Isaacson in 2014
Product teams solve problems — problems that have never been solved before. Therefore, product teams must be highly competent in order to come up with the goods. Unfortunately, there is no tried and tested formula that will guarantee high performing teams — different companies use different approaches — but knowing what has worked in the past will help the CEO and business leader build successful teams and a culture to sustain them.
This article presents some of the latest research and observations on building product teams. We present examples of market leaders’ strategies; specifically, Google’s 20 percent policy, Fog Creek Software’s “creek weeks,” and Amazon’s “two-pizza teams.” These examples illustrate the factors that are critical to building and motivating creative teams.
Leadership Styles and Culture for Team Building
Much of team development depends on the leadership and culture within an organization. Some leaders are comfortable allowing teams to develop spontaneously. Joel Spolsky of Trello and Stack Exchange fame is a good example of this type of leader, whereas Steve Jobs preferred to build the ship before trying to steer it. Jobs’ modus operandi was to hire the best talent he could find before even beginning to create teams.
And there are secondary factors that are just as crucial if teams are to succeed, such as a safe psychological working environment. Team participants must feel confident enough to go out on a limb and take risks without fear of recrimination if they make a mistake. Finally, they must have the tools and resources that will encourage and help them to create their visions.
What is a Product Team?
Aha! is a company that develops product roadmap software. According to them, the product team is cross-functional and has diverse perspectives from team members.
A product team’s role is wide-ranging, and its responsibilities may include marketing, forecasting, and profit and loss (P&L) responsibilities in addition to product development. Aha! describes the product team as the product’s own, personal C-suite. The team’s role is to bring that product to market, and to do so it must rely on other teams throughout the organization.
What Does the Perfect Product Team Look Like?
For many CEOs, the perfect product team is an intangible entity. Some research lists general factors that create the perfect team while other research is anecdotal and case-specific. The perfect product team will be formed according to the culture and operations of its organization and, therefore, will differ in each case. In some instances, teams will form spontaneously, in others, a system will assign people to teams with strict deadlines and goals. What is the measure of a great product team? Is there a way to determine how successful a team will be? Unfortunately, there is little consensus on a method to build a great team, but there are recurring themes in the discussion such as communication, culture, and the physical environment.
An article by Alex Pentland, director of MIT’s Human Dynamics Laboratory and the MIT Media Lab Entrepreneurship Program, goes into great depth on patterns of communication, or the “sociometrics” within teams.
The research conducted by Pentland used wireless and sensor technology to create badges worn by participants in investment teams. The badges generated over 100 data points a minute on gestures, talking and listening behaviors, and levels of empathy and extroversion. The badges were distributed to team participants in 21 organizations over seven years to measure the communication patterns of around 2,500 people.
Based on his research, Pentland claimed that communication patterns could predict the financial results of an investment team. According to Pentland, the patterns “foretell, for example, which teams will win a business plan contest, solely on the basis of data collected from team members wearing badges at a cocktail reception.”
Pentland’s insights are valuable, but while effective communication among team members is crucial, it is also obvious. So, what are the less obvious factors that are applicable in unique circumstances, because, after all, every company is unique?
Let’s take a look at some exceptional product team models and the factors that make them so.
Google’s Product Teams
In 2015, Google set out to bring empirical evidence to the team debate. The company embarked on “Project Aristotle,” which identified 180 teams in its engineering and sales groups. The sample included a mix of high and low-performing teams who were then subjected to a series of double-blind interviews to determine which factors contributed the most to team success at Google.
The project leaders first had to define success. Google quantitatively defined team effectiveness by examining factors such as written lines of code, the number of bugs fixed, and customer satisfaction.
However, the researchers also obtained qualitative input from executives, team leaders, and team members because quantitative measures alone are misleading. For example, more code is not always better. Google used four different types of quantitative measures for more nuanced and less subjective results.
What really mattered for team success, according to the researchers, was how the team worked together, not who was on the team. The most important factor for team members was psychological safety; team members wanted to feel that they would not be vilified for going out on a limb or for making a mistake. Also, team participants wanted to be able to depend on their peers, and they wanted structure and clarity in their purpose.
The researchers also found factors that were not particularly significant for successful team performance. According to Google’s research, teammate proximity, a consensus when making decisions, extroverted personalities, the individual performance of team members, the amount of work, seniority, team size, and tenure of teammates were not major influencing factors on team performance.
What are you doing to grow your career and company?
We spent 15k hours researching best practice. Visit our website, explore hundreds of resources, and learn how to get things done.
Amazon’s Two-pizza Teams
Amazon’s “two-pizza teams” have become gospel for managers and startups. This team method is so-called because the teams are small enough (six to 10 people) to be satiated with two pizzas when working hard on a project into the evening hours. Everyone loves to quote the term, but how and why does the model work?
The model originated from Bezos’ desire to create a decentralized company where teams can run with ideas independently of other operations. This is in stark contrast with the definition of Aha!, which states that product teams must rely on other teams throughout the organization.
Jason Crawford, co-founder and CEO of Fieldbook, characterizes two-pizza teams as the ultimate embodiment of a divisional organization. In a divisional organization, product teams act as independent entities within the greater organization. They have their own marketing, sales, engineering, and finance functions so that they have autonomy and accountability. “Most crucially, each product has its own profit-and-loss statement (P&L),” said Crawford.
Amazon’s two-pizza teams excel. Structure, clarity, meaning, and impact are all part of the two-pizza team design. Amazon’s special forces are deeply aware of their goals, which are cemented by highly visible metrics. And while Google’s research didn’t find a statistically significant correlation with team size and success, the size of Amazon’s team ensures everyone is recognized for their impact.
Google’s 20 Percent Time
Abandoned in 2013, Google’s policy of “20 percent time” gave employees the opportunity to work on a project (company-related) of their choice for one day each week. Employees with a new idea pitched it to coworkers. If it was well received, they could create a product team with funding to explore the venture.
Gmail was one of many products that were supposedly born from the policy. Marissa Meyer, Yahoo CEO, dampened enthusiasm for the concept stating that projects cannot be adequately explored in the time allocated and that employees must follow their vocations in addition to their regular work. In other words, 20 percent time was more like 120 percent time. Still, other big names such as LinkedIn, Apple, and Microsoft have introduced similar policies.
Fog Creek’s Creek Weeks
Joel Spolsky built up a pair of hit companies, Fog Creek Software that creates web-based project management systems, and Stack Exchange, a collection and answer platform. Spolsky has also launched Trello, an online collaboration tool. All of the company’s products were fundamentally created during employees’ free time thanks to “creek weeks.”
Spolsky has successfully spawned spontaneous teams through Fog Creek’s “creek weeks.” According to the company, a creek week is an opportunity for an employee to leave their day-to-day responsibilities for a week to focus on an idea. But only on one condition, that they convince another staff member to join them.
The unique approach of Fog Creek Software is that teams focus on validating a project by figuring out why the idea won’t work. Teams are encouraged to think how the idea might be shot down by a challenger with the right questions. For example, is the product solving a problem that many people have? Will those people like the solution and pay for it? “A typical [creek] week involves a mixture of thinking, coding, research, and a lot of talking,” says the company.
If the project still looks promising, additional resources are allocated. “As the product develops, and the idea and approach solidify, we add additional resources as needed. Glitch, for example, quickly moved from two to three people.” The team built the core product before additional resources were added in the final months before launch.
In this YouTube video, Spolsky explains how he designs his teams, typically with fewer than eight people, and how he allocates another “person” — Spolsky avoids using the title “manager” — whose full-time job it is to just manage communication paths among team members.
Basecamp’s Teams of Three
Jason Fried is founder of Basecamp, project manager and team communication software. According to Fried, the teams at Basecamp are limited to two or three people — one programmer and one designer, or two programmers and one designer. “Everything we take on has to be done by a team of three, max,” said Fried in an interview published on Medium. “We think three is the ideal size for most things — complexity begins to increase exponentially beyond that.”
The teams are formed spontaneously and according to the interests and preferences of the participants. There are no dedicated project managers, but designers and programmers work closely. Nor is there any formal tracking of time. According to Fried:
“We don’t measure efficiency or compare actuals vs. estimates. We have six weeks to get something done. However, if a team decides to get it done during that time, it is up to them.”
But this seemingly loosey-goosy approach stimulates ideas. Fried says:
“Ideas come from all over and are offered up any time. They come from us, they come from customers… There’s always a bubbling ocean of ideas. Every once in a while, a bubble floats out of the ocean and lands on the shore. That’s when we begin to take a closer look.”
At Basecamp, these ideas become pitches, which are written down rather than discussed in real time so that readers can parse the full story. From there, Fried, the CTO, and the strategy chief debate the pitches on either Skype or Hangout and make final decisions within 30 minutes. Basecamp’s projects have a strict timeline of six weeks. Perhaps not so loosey-goosey after all.
Spontaneous teams can create great products, particularly when the culture is conducive to exploration and employees sense psychological safety. However, sometimes an organization wants more control than fate can offer.
Apple’s Cream of the Crop
When time is of the essence, a CEO needs to build a team from the best of the best. Steve Jobs of Apple was a case in point. Steve Jobs famously said that the product he was most proud of creating was not the iPod or iTunes, but his product teams.
In the book by Rama Dev Jager (Author), Rafael Ortiz “In the Company of Giants: Candid Conversations with the Visionaries of the Digital World,” Steve Jobs’ explained in an interview that his approach to team building was to first find top-notch people.
At one point in an interview, Jobs states, “I think that I’ve consistently figured out who the really smart people were to hang around with. No major work that I have been involved with has been work that can be done by a single person or two people, or even three or four people… In order to do things well, that can’t be done by one person, you must find extraordinary people.”
Jobs addresses hardware design specifically and said, “I noticed that the dynamic range between what an average person could accomplish and what the best person could accomplish was 50 or 100 to 1. Given that, you’re well advised to go after the cream of the cream.”
Good recruiting, for Jobs, was key, and he thought this to be particularly the case for startups and smaller businesses. “When you’re in a startup, the first ten people will determine whether the company succeeds or not,” said Jobs.
For more on hiring for innovation, read “Hiring for Innovation — Courting the Candidate”
Take Aways for Building a Unique Product Team
An effective team can be created either spontaneously or through a curated process and, as we have seen, much of how teams develop depends on the culture of the organization.
For example, Steve Jobs preferred to rely on hiring the best talent that he could find. Jeff Bezos at Amazon chooses a clinical approach to building teams that limits their size, decentralizes them, and gives them autonomy with accountability. Google, LinkedIn, and others have attempted to carve out time for project leaders to develop ideas and create impetus for new products. Basecamp relies on spontaneous teams of three people or less who bandy together on mutually attractive projects, but with a strict six-week deadline for completion.
We hope this article has given you some food for thought on how to develop successful teams. The first step is to look at your current organization, its culture, and its communication patterns. Think about what models might work organically and how you can support a team-building model with great leadership and the best psychological and physical environment.
Most of all, get the feedback of those who will participate. Employee preferences, when respected under competent leadership, are the greatest guides and motivators.