Stories about the growth of product teams have always interested me. Especially stories about how a few people working their magic in a garage can grow to 50+ experts under the same roof. These stories always make me wonder: What is the secret to building an outstanding product development team? 🤔
Digital products with the highest value are always the result of great teamwork. Yet, in my experience, assembling a product development team is a tall order. So how do the best companies build their product teams?
Fortunately, many companies are now ‘building in public.’ They open up their processes to the public, revealing how their product teams make it all happen. Back in 2013, Spotify talked about their team models, and later more companies like Intercom, Dropbox, and Transferwise followed suit.
In this post, I’ll share the best practices of crafting successful product teams, specifically:
- Why choosing the right team size is important.
- Why autonomy is the foundation for building high-performing teams.
- The guiding principles for building strong product teams.
So let’s get started.
How to build a solid foundation for a great product team
“I don’t think you should be building a product. I think you should be building an organization that builds a product,” Kris Gale, VP of Engineering at Yammer.
I've included this quotation because great product teams are more about assembling the right people than developing a product. People who love technology will bring innovative ideas to life, and more practical or day-to-day products will be developed by people who can see a need in the market.
For this reason, we have to pay attention to the factors that help startup owners find the right people to design the right software products for them.
I love many of the principles of forming product teams from Marty Cagan’s book “Inspired: How To Create Tech Products Customers Love” and suggest adapting some of them to your particular needs. The book is a technology product management classic. The book's second chapter is called The Right People and explains the principles of building strong product teams.
Let’s take a look at some of them.
There is no single rule that will tell you what the proper structure for your particular product development team is. It depends on the type of product you’ll be working on, the size of your company, the industry or niche you’re working in, the scope of the product, and more. Yet all digital products need similar things to get them off the ground and usually face the same stumbling blocks that prevent them from doing that.
Now let’s take a look at the most common roles in product development projects.
Once you have carefully thought over the structure of your team, you can decide how many people a strong product development team requires.
According to Scrum methodology, the optimal development team size is somewhere between three and nine. This has been the topic of many discussions, but the consensus is that having more than nine team members demands too much coordination and generates too much complexity.
Still, opinions differ regarding how to determine the ideal number of team members. For example, Amazon has the famous two-pizza rule for teams. “One team should be small enough that it can be fed with two pizzas,” according to Jeff Bezos. Amazon uses this rule to encourage greater autonomy and innovation while preserving small team size, which is critical in terms of the team’s agility.
Another company focusing on small teams is Twilio. “At Twilio, a commitment to small teams is a cornerstone of how we operate. As we’ve grown from tens to thousands of employees, our teams have remained independent units of no more than ten people,” Ott Kaukver, CTO at Twilio, explains.
Small, independent teams can make decisions on their own, implement independent execution, maintain better focus, and deliver innovative and valuable products faster. Thanks to this model, Twilio now call themselves ‘a collection of startups working symbiotically within a large company.’
The next vital question for the establishment of product teams is: What is the scope or charter of each team? In other words, we need to determine what the team is responsible for.
There are two dimensions to this. The first is the type of work to be done. Remember that a product team has responsibility for all the project-related tasks and their outcomes—features, bug fixes, performance, and optimizations.
The second dimension is the actual amount of work to be done. In some companies, the product team is responsible for the entire product. In others, each team works to deliver smaller product components. For example, the development of a specific feature, native mobile app development, or a web platform with extended functionality. There are also cases where each team is responsible for product development for a particular type of device.
It’s become an accepted fact that the way in which a team works together is equally, if not more, important than the individuals that make it up. For example, during the course of Project Aristotle, Google found that the individual talents of team members have no great impact. Actually, it’s how people work together that makes the difference in its most successful teams. In successful product teams, collaborative and technical skills go side by side, so we should never underestimate them.
Even with the Covid-19 pandemic forcing most companies to shift to remote work, effective collaboration shouldn’t be at risk. We can call into play the whole array of tools, not only collaboration and digital communication tools, although the use of these has soared.
Have you ever heard that virtual collaborations can be more mentally exhausting than in-person interactions? The Wall Street Journal claims they might be. To combat this, try holding shorter, more frequent meetings with more attendees. Making this change will reduce the total number of hours that team members spend in meetings, equalling more productivity and less stress.
In the context of product management, durable teams are teams that were initially formed to tackle a specific business challenge but aren’t immediately disbanded when the desired outcome has been achieved, as is the case with agile project teams. Instead, the team members stay together and continue working on multiple projects, with minimal changes over a considerable period of time.
It takes time to get to know each other, to form firm collaborative bonds, and fine-tune the efficiency of the working process. So it’s a shame when all that is lost and can’t be capitalized upon in future projects. What’s good about durable teams is that they form a group memory and a knowledge base accessible to each team member whenever necessary. There is no doubt that this improves productivity.
Another reason why durability is important is that people need time to establish ties to the product they’re building. This is also true for the context of their work. It’s almost impossible to gain the necessary expertise and feel a sense of ownership over a product when team members are working on the hop.
If you’ve ever watched how a world-class sport team plays, you know that although each team member has specific skills, nothing is achieved without the collaboration of everyone. They have a shared goal, but they operate autonomously. This is the primary strength of a team: autonomy.
According to Marty Cagan, if we want teams to feel motivated, we need to give them a significant degree of autonomy. This means they are able to try solving the problems they are assigned in the best way they see fit. It also means minimizing dependencies between teams.
Jonathan Golden from Airbnb has this to say about the autonomy of their product teams: “We allow each team to figure out their own cadence, their own process, and structure. We like to see each team have it’s own character—a little bit of identity.”
A company like Wise (Transferwise), which is built out of autonomous, independent teams is another good example. They’ve learned not only how to benefit from the autonomous structure but also how to tackle some of its challenges, like duplicating tasks. “When teams are focused on their own codebase, it’s easy to end up duplicating work through solving the same problem,” explains Helin Ece Akgül, engineering lead at Wise, in a corporate blog post. “Thus, we have forums where we discuss engineering-wide problems and share knowledge on challenges and learnings. Also, we use internal libraries to solve recurring problems in different systems.”
Guidelines for building product teams
Building a strong product team always involves creating the proper product culture for success and taking the proper steps to equip each team member with an understanding of the mission. We have to pay a lot of attention to team structuring because if it’s done well, it helps a company to scale gracefully and maximize the value delivered to the customer. This is achieved by having the necessary context and resources to build and iterate without tons of synchronization.
What do the context and resources mean in practice? We’ll discuss this below. Let’s learn about the building blocks that should be put together to compose a rational and effective product development team.
Strong company culture
A shared organizational culture has become a significant differentiator both for startups and enterprises in recent years. Culture permits no delay, and it can’t create itself.
You might take the advice of Kevin Scott, CTO of Microsoft, who suggests drawing up your cultural manifesto as quickly as possible. Compiling it in the form of a document or a set of materials will help you to understand, discuss, note down, and observe the principles of:
- How your company does things.
- How you operate.
- How you function as a team.
Companies with solid cultures often have a high degree of uniformity in their decision-making process and the kinds of people they hire.
Specific product culture
The term “product culture” describes fundamental beliefs surrounding product development. It’s a less widely known notion than company culture and basically refers to “How your company does things.” Product culture can reveal a lot about startup owners, reflecting the strengths and weaknesses of their approach to product development. It acts like a magnet, attracting people who share the same values, which will help you build truly strong teams.
Successful companies may have different attitudes towards product culture, placing importance on diverse aspects of the product life cycle. Your task as a product owner is to choose which approach resonates most with you, which will lead to creating a product with real value.
Sachin Rekhi, founder & CEO at Notejoy, discusses four specific product cultures that dominate tech companies: engineering-driven, data-driven, design-driven, and sales-driven product cultures.
Are all of these companies successful product developers? Sure they are. Do their product cultures differ a lot? Yes, they do.
Sachin Rekhi also claims that companies typically have a dominant product culture, as well as elements of secondary product culture. In my experience, if a product manager has discovered the right balance between product and engineering cultures, they’ll manage to assemble a team with the strongest players.
The more the global community acknowledges how diverse the preferences and needs of people are, the more brilliant and innovative products appear on the market. The same principle applies to assembling product teams. If product owners are open to diverse skills and mindsets, they can expect more varied contributions to the shared outcome.
Research has proven that diverse companies are better positioned to win top talents and improve customer satisfaction. According to McKinsey&Company, “Ethnically-diverse companies are 35% more likely to outperform financially, with gender-diverse companies 15% more likely to outperform.”
Diversity applies to different facets of team life. It may concern assembling people with distinct heritages or people that have different skills or industry experience. In any case, assembling a team in such a way that it becomes a collection of complementary skill sets will reach a wider audience and build better products.
Empowerment and accountability
One of the central best practices of modern product development is the empowered product team—a term coined by Marty Cagan. He defines this as a team that truly owns its product. That sense of empowerment develops when a team has enough freedom, trust, and knowledge to act within clearly defined objectives posed for the product development project. Marty Cagan affirms that such empowered teams usually succeed in innovation, quality, agility, and speed of product development.
Aside from ownership, the term “empowered” also refers to how each team member feels and acts within a product team. There is one more factor I’d like to stress in this respect, and that’s accountability. Truly successful teams are empowered to go find the best solutions for your business objectives on their own while also holding each other accountable for those objectives, team development, and success.
Buffer company even has a special term for it—“empowered accountability.” It means that every team member is empowered and confident in making every necessary decision and takes responsibility for them.
The most successful teams communicate frequently, often engage in informal chats, and constantly explore new ideas and information. With that said, according to the 2021 State of Product Management Report, 56% of product people are either unhappy with or feel average about their process for communicating their product strategy.
And what if it’s critical to ensure communication between multiple teams? Here’s some advice from Credit Karma’s former Chief Product Officer, Nikhyl Singhal: “You need to start establishing more advanced communication rituals beyond weekly standups. At Credit Karma, we introduced biweekly product demos for the whole company, monthly offsites for the product team, monthly executive product reviews to actively provide that context others are seeking,” he says. “Bias towards active communication here. A company can’t hope all relevant info will passively trickle down.”
When product teams can easily share information between their members, and the members of other teams, they make decisions more quickly. To ensure effective communication in remote teams, think about your communication strategy ahead of time, have a clear agenda, and have all the communication tools you need on hand.
Choose your communication platforms based on your specific needs. Google Teams or Slack may work the best for a quick check-up of your team’s progress, while GoToMeeting, Microsoft Teams, Google Meet, or Zoom are great for both simple check-ins and for presentations, product discovery workshops, or brainstorming sessions. G Suite is a great shared place to work with documents, and Lucidchart and Draw.io are also decent visual shared workspaces.
Focus on ‘how’ instead of ‘what’
Kevin Scott, the CTO of Microsoft, who has more than a decade of experience structuring engineering teams, said that teams should focus on asking the ‘how’ questions instead of the ‘what’ ones. Answers to the ‘what’ questions are immediate and prone to change, while the ‘how’ responses are more in-depth and strategic, offering lasting solutions. This is precisely what your team needs to rely on.
Let’s be honest, composing and structuring a product development team is a tall order. Especially when a startup needs to figure out how to scale. On the one hand, the founders are pressed by fast-moving industry needs. On the other, they have to make sure team members feel empowered and accountable and have crystal clear guidance as to the outcome.
Luckily, as the global startup community grows bigger and becomes more diverse, it gives us more opportunities to learn by example. I hope that today’s collection of team composition principles and guidelines about how to grow amazing product teams will give you the insight and confidence you need.
This is the bottom line for today: Explain yourself by setting clear objectives. Grant your team autonomy, and they will pursue your objectives. If you invest in a particular product and company culture, it will help your team find the right roadmap. Finally, and probably the most important, remember the purpose of what you’re doing and why it matters so that you can inspire others with your product vision.
If you are interested in reading more on this topic, here is some other quality content:
- “INSPIRED: How to Create Tech Products Customers Love,” a book by Marty Cagan.
- Building Awesome Product Teams, by Martin Eriksson, a video on Vimeo.
- Des Traynor on YouTube, on lessons learned from scaling a team at Intercom.
- NYT article, “What Google Learned From Its Quest to Build the Perfect Team.”
And of course, if you have questions, I’m here to discuss your thoughts about product structures, and more. Just drop me a line!