The key for developing a successful digital product is forming a tight knit product team to handle its development and maintenance.
Building a product team is one of the most important things a company can do. It’s the team that is responsible for dreaming up, designing, building, and launching products.
But how do you structure it? Many companies struggle to organize their product teams effectively to ship fast and create as much value as possible. In fact, product organizational structure is one of the most important aspects of this process.
Once you’ve put together the perfect product team, the issue then turns towards tracking the outcomes of your work. That’s where product analytics tools like June.so to improve user engagement and retention. In this article, we’ll explore how best to structure your product team. Looking at examples of how some of the most successful companies around the world structure their product teams will unlock the answers for how best you should structure your product development team for your next SaaS product.
What is a Product Team?
Firstly, we’ll explore what a product team actually is. This is an organizational structure that focuses on adaptability and agility first and foremost and whose main priority is to create and design a product users love. Product teams are small, cross-functional teams designed to focus solely on delivering a holistic product. By cross-functional, we mean that they handle the planning, design and engineering all within this team.
Marty Cagan, author of Inspired: How to Create Tech Products Customers Love, states that product teams should be “focused on outcomes instead of outputs”. By this, he means that product development groups aim to deliver business results instead of features. Product teams contrast with feature teams – who are themselves cross-functional but aim to ship product increments instead. However, product teams’ true opposites are component teams. These are monofunctional – for example, an engineering team or a design team. The issue here with component teams is that they don’t have that same focus on business objectives and are often “output” oriented.
What size should your product team be?
You should keep product teams small. This is because, in a large team, effective team communication can become difficult and unwieldy. For an engineering manager to have daily one-to-one communication with all their team members, it's recommend keeping product teams to less than 10 people. In fact, 6-8 is the sweet spot.
For example, Amazon’s Jeff Bezos sticks by the “2 Pizza Rule”. This is a practice that states product teams should be so small that they should easily be able to be fed by two pizzas. Any larger and those direct communication channels start to break down.
Why are large teams so dangerous?
One of the Laws of software development, Brooks's Law says “Adding manpower to a late software project makes it later”
Much as a surgical team during surgery is led by one surgeon performing the most critical work while directing the team to assist with less critical parts. A product team needs, to have leaders of projects develop critical system components while the rest of a team provides them what is needed at the right time.
Having more people involved won't get the project finish faster.
Product Development Team Roles
A cross-functional team that is both small and effective requires strictly defined and recognisable team roles that directly match with members’ skills. All product teams should represent these key team roles:
An effective product team starts at the top – with product management that is laser-focused on the outcome and business objectives. Intuitively, a product manager is responsible for product management. Product management refers to the skills needed to conceptualize a product, bring it to launch and handle its marketing. Product managers are those responsible for identifying customer needs, relating that to business objectives and organizing the rest of the product team to achieve this.
How do product managers work in practice? Derek Jamieson, a senior product manager at Salesforce notes that the key to PM’ing a cross-functional team is “Transparency and Humility”.
“It’s important to share your thoughts as to why you are making the decisions you are making and to be honest when you take the team down the wrong path” – Derek Jamieson.
These are the engineers that write the code and are responsible for technical planning. With the small nature of product teams, there’s little room for knowledge gaps here.
Developers working in your product team should be full-stack and be able to build features independently end-to-end.
The more handovers are required between engineers, the more time will be spent doing busywork to coordinate. So the more you can avoid separations between "front-end", "back-end" and "dev-ops" the more you can get things done!
Product designers own the users experience. They're responsible for the look and feel of the product. Designers need to have a deep understanding of how software products are used, and how UX principles need to be implemented. They work with engineers and other members of the product team to create prototypes and test products with users.
The best product designers have a good understanding of how programming works. The more a designer is aware of what are the technical constraints of the platforms they design for the better work they can do!
Product designers are essential members of product teams. They help to ensure that products are well-designed and easy to use. Their focus on the user experience helps to ensure that products meet user needs and are successful.
Engineering managers make sure the engineering team are doing their best work. A good engineering manager coaches engineers and helps them find ways to align their professional goals with the company goals.
Engineering managers should have weekly 1:1 conversations with all engineers, to identify any problems that might slow down the team!
How do you structure your Product Development Team?
A basic product team structure is easy enough to understand. But, as products grow, how do you scale them?
Teams often follow one of these three principles when deciding their product team structure:
- Product ownership
- Skills-based PM
- Product squads
We’ll explore two of these approaches here:
You could structure product teams to be responsible for a singular product or product feature. This is the product ownership route. This is the most common product development structure.
As such, these product managers will be responsible for a variety of tasks with teams overseeing customer research, marketing, sales, and product development.
Underneath the product manager are the traditional roles we covered above.
Some considerations you need to make if you’re considering the product ownership approach is:
- How many developers would you assign to your product teams? Often, especially if a product becomes too large for one small team to handle, managers make product teams larger without hiring an additional project manager. This commonly leads to an unwieldy, inefficient product team.
- Who will these project managers report to? PMs are usually intermediate-level roles. Who keeps them in check?
Spotify has – since 2012 – structured its development organization into eight-member large product development teams known as “product squads”. These are extremely agile and adaptable development teams that contradict the traditional product team approach.
These developers are entirely cross-functional and each product squad will be responsible for specific areas of a product.
What is unique to Spotify’s product squad strategy is that each squad has high levels of autonomy, especially with their ability to bring their work to market.
How has this helped their engineering culture?
Firstly, it encourages small and frequent releases thanks to these small teams and complete autonomy. Also, these product squads aim to “cross-pollinate” their skills and working methods to other teams. This is in contrast to the traditional standardized training methods.
Moreover, autonomous squads with clear responsibilities and goals help foster a community between developers outside of their teams. Spotify’s teams love to share their expertise with each other – without the fear of treading on someone’s toes or helping “competing teams”.
How real-world companies handle product development teams
We’ve briefly introduced you to the way Spotify works. But the Swedish audio streaming service isn’t the only tech firm using product teams. Here are some examples of how successful SaaS companies are structuring their product teams.
Shopify: Strong Talent Acquisition and Onboarding
Lumsden reveals that Shopify places a keen interest on building close relationships with their talent acquisition teams. He notes that new talent’s ability to fit into workplace culture is just as important as technical ability.
It is for this reason that Lumsden believes in making sure recruitment teams understand the culture and working environment of your product teams in order to understand which new talent will be the right fit.
Lumsden also comments that Shopify uses pairing to better onboard and introduce new hires to their working environment. Pairing is to let new folks code together with experienced developers, getting them up to speed much faster than if they were left by themselves. This pairing culture extends further than the initial onboarding stages, however, with all team members encouraged to work together. Shopify even has pairing rooms in all their offices for this very reason.
Amazon: 2 Pizzas
We’ve already touched on how Amazon uses the two-pizza rule to limit the size of their product development teams. To recap, teams should be small enough that they can be fed with two pizzas.
Expanding on this, Amazon makes use of the Single-Threaded Owner (STO) approach – where a leader is responsible for one or two product “two-pizza” teams. This ensures that these teams stay focused and an STO is responsible for driving Amazon’s business priorities.
How does Amazon keep track of the success of product teams? They use regular business reviews, program reviews, roadmap reviews and audit STOs to make sure deliverables are kept under check.
Microsoft: Agile, iteration-based development
Microsoft uses what they call “agile development” to guide how they approach their product teams.
At Microsoft, development should favor individuals and interactions over processes, tools and outputs. Also, their product teams focus on iterations and releases as their project goals. They see each iteration as like a small independent project.
Why do they do this? It separates their project development lifecycle into sprints, and affords them a great level of flexibility. This small-scale iteration-based approach allows for requirements to evolve and change. The focus is more on meeting customer demands than project completion.
Track your Product Progress and Success with June
Once you’ve put together an effective product team, the focus then turns to managing your product and tracking its success. The key here is using a quality product analytics tool. This is because collecting data on user engagement and retention can be particularly difficult without an analytics tool.
June creates automatically reports on your most important metrics such as Activation, Retention and Product usage. So you can focus more on development and less on building dashboards.
Get started today at June.so and access BS-free, accessible and beautiful product analytics for your SaaS product.