How to structure the modern mobile product team (with examples)

Product teams in mobile app development are complex. They can’t build and release features without constant communication and input from other teams. From customer success to data analysis, the product team needs ears and eyes everywhere to fully understand the current limitations of the app or product, how to solve these issues in an efficient way, and to understand user behavior. 

Below we will discuss some examples of product team structures that are commonly used, from start-ups to enterprise businesses, the pros and cons of each, the importance of the core product trio, and how to decide on a team structure for your organization. 

What is the core product trio?

A product trio is usually comprised of a product manager, a designer, and an engineer, with decisions usually being approved by the highest paid person in the organization. It’s mostly agreed that these are the minimum roles you’ll need to fill to be able to create a minimum viable product and effectively improve features. 

One reason that this product team organizational structure has been proven to work well is that the work is handed down to the next responsible member - the product manager writes the requirements, the designer makes the wireframes, and the engineer puts it all together. 

The traditional product trio structure

However, the most important elements of a product team are the way they can collaborate with other teams and their deep understanding of the business goals and user behaviors. According to the Silicon Valley Product Group, working like the above - handing over work to the next responsible person - can result in your product team becoming ‘mercenary teams’, instead of ‘missionary teams’.  

Mercenary teams: 

• Work on what is passed to them or asked of them.

• Can become less aligned what is possible from each stage (for example, engineering limitations). 

• Often have to rewrite requirements or redesign mockups which leads to projects being delivered over budget and late. 

Missionary teams: 

• Are driven by a mission that they are all equally responsible for. 

• Have a deep understanding of user pain points and opportunities. 

• Are encouraged to be more creative with their solutions.

The clear difference between these two styles is that one is more proactive about discovery, whereas the other works on what is passed onto them, with little ownership. When your product team has shared knowledge and a deeper understanding of the user, they are more likely to solve issues that satisfy the user and improve metrics. 

To encourage a style of working that includes more ownership and proactivity, everyone in the product trio should contribute to customer research. Conducting user interviews, and surveys, as well as looking into session replays, heatmaps, and event analytics gives your product trio a holistic understanding of the ‘why’ behind user behavior. Seeing customers use your app firsthand gives extremely useful insights into which parts of your product might not be clear and need reworking.

Collaboration and ownership are the most important skills in product teams. There should be space for both individual discovery and group collaboration. Certain tools can help product teams collaborate better together and share knowledge. A great example of this is sharing customizable dashboards. 

UXCam customizable dashboard and widgets

Being able to customize dashboards means product teams can pick and choose which metrics are most important to their business goals and easily view those important metrics as soon as they open the tool. Sharing these dashboards across teams gives better visibility across the board and a better overall understanding of the progression of those metrics over time. 

“Your product trio should work like an early 2000s JPEG file – blurry at first but slowly gets clearer.”

Examples of product team structures

Of course, once your organization grows there will be a need for a larger product team than just your trio, but we’re also aware that too many cooks in the kitchen can spoil the broth, so there needs to be some balance. 

Let’s look at how some of the biggest brands organize their product teams. 

Amazon

You’ve probably heard about the ‘2 pizza rule’ at Amazon. If your team cannot be happily fed from two pizzas, your team is too large. 

Bigger teams are dangerous as they increase the chance of miscommunication as well as making the process for approvals much longer. With more people to communicate with the likelihood of business objectives getting diluted becomes greater, leading to a less structured focus. 

The upside to a two-pizza rule team structure is that it saves time when responding to requests because each team is responsible for different problems, which also saves time on meetings and reporting. 

However, even though the teams at Amazon stay small, there are still some communication and transparency issues as a lot of smaller teams try to work alongside each other. The structure and processes for teams like this need to be rigid and very well thought through.

Spotify

Spotify’s approach to organizing product teams is a little more complex than Amazon’s, and they describe themselves as a redesigned matrix organization. The teams are set up into different groups of people called tribes, squads, guilds, and chapters. 

Spotify's matrix organization

Spotify has been using this structure for years now after a period of rapid growth and is iterating and reorganizing itself regularly to stay optimal. 

As shown in the visual product team structure example above, Spotify has made space for better communication and cross-functional work. Each tribe is split into squads; each squad has one member as part of a chapter to help with communications within their overall tribe. Each squad is also part of a guild, for cross-tribe collaboration. 

Each squad - usually between 6 and 8 team members working towards the same specific goal - is treated like a mini start-up and is encouraged to be as self-sufficient as possible giving a lot of space for both individual and group work, increasing autonomy and productivity. 

Of course, the downside to this structure is that it is fairly specific and processes need to be rigid for teams to cross-collaborate like this, for example having automated data collection shared across the tribes. There can also be some confusion about priorities as a lot of the team members will be part of more than one mini-team (part of a tribe, squad, and guild). 

To better prioritize, squads can benefit from shared customizable dashboards so they’re all working off of the same user behavior data. If product managers, engineers, and UX designers were all working off the same data set, they’ll be able to better trust the data.

UXCam customizable dashboard. 

Airbnb

Airbnb takes a more elastic approach to structuring its product teams and has a stakeholder-based product team. Teams are grouped around stakeholders and the customer journey map and each team concentrate on the individual parts of the journey. 

Some of the stakeholders Airbnb focus on are:

• Host experience

• Guest experience

• Investor experience

• Community experience

This way the business goals and objectives are less likely to be left behind and can even be more focused because there are dedicated teams for each one. 

However, the downside to this is that business goals can be diluted as the focus is on specific parts of the customer experience, and not the overarching aims.

Deciding on a product team structure

As we’ve seen, there are many different ways to structure a product team, however, it completely depends on your product, as each one needs different focuses. There is no such thing as a ‘perfect’ team structure.  

In the early days of your organization, the product trio structure will work, as long as product managers and anyone in a higher position can encourage ownership and creativity. Pay attention to the people you have hired for your product team and how they collaborate together. This should provide a base as to how your product team will evolve, how they work together, and what their weaknesses are. Focus on how your product managers, designers, and engineers work together and let them lead with thoughts on how they would prefer to be structured. 

Teams often follow one of these most common principles to decide on the structure of their team. 

• Product ownership

• Skills-based product management 

• Product squads 

Product ownership 

One of the most common ways to structure your product team is the ownership route in which each product trio is responsible for a singular feature or product, with the product manager in the lead, owning that feature. 

Here are examples of product or feature teams you’d find in the mobile product team:

• Recommendations and relevance team: Responsible for just how the app recommends products to customers

• Search team: Focuses on improving how users find what they’re looking for on the app

• Onboarding team: Focuses on activating and onboarding experience

• Supplier tools team: Focusing on just the tools that the suppliers see on the partner side of the app 

The work is then handed to the next responsible person, for example, once the product manager is done with discovery, it will go into the design phase. 

This differs from the squad structure, which is discussed further below, because squads are not usually bound by stakeholder approval processes, like the product ownership structure, and are able to test iterations when they’re ready.  

The product manager oversees each step of the process within the product ownership structure, from the discovery phase, till the solution and deployment of the new feature. This could include market research, budgeting, prioritizing features, working with marketing and sales for messaging, and working with data analysis to look at metrics and properly understand the user. 

This way of working is effective because it encourages responsibility and ownership of each problem, and can work with smaller teams, like the product trio. 

However, depending on how complex the problem being worked on is, there might be issues with capacity. Maybe the design of a new feature needs a lot more research than usual, this could be drastically delayed if there is a shortage of designers on the team.  This would only become clear once the structures have been put in place and projects have been decided on. 

Make sure to put proper processes in place when using this structure so the product manager knows who to report to and who has the final say. 

If using this structure, think about: 

• Who the product manager will report to? It’s not unusual to have a VP of product in this situation. 

• How many developers and designers will you need for each new feature or product release?

Skills-based product management

Unsurprisingly, having a skills-based structure is all about particular skill sets. For example, a product manager with the most experience in market research and personas might be responsible for developing these personas across your entire product line. 

Skills-based product management often looks like having one technical product manager, one design product manager, and a growth product manager, each having their own isolated teams to tackle improvements. 

This structure is especially good for having expert product managers in each field, however, teams might feel out of their depth if the structure changes and they’re no longer focused on one element of the product journey. It’s also a risk that if one of the expert product managers resigns there will need to be a lot of effort put in to replace that level of expertise. 

Product squads

This type of structure is especially cross-functional and each team has a dedicated product manager overlooking a group of developers. Similar to the skills-based product manager structure, the squad structure also works on specific areas of the product, however, it’s not organized by expertise. 

Usually, each team in this structure is able to release their work when ready, there’s no head of product and no stakeholder approval process. 

The aim of this, other than giving each team a good amount of autonomy, is to encourage speed. As each team isn’t limited by approvals, they can test and push out solutions when they’re ready.  

There’s no such thing as the perfect product team structure. Some companies work better with simple structures, while others flourish in more original or unique structures. The most important thing to think about when putting your team together is how you will encourage ownership, communication, and collaboration. 

You may also be interested in: 

• Mobile app KPIs: Top 51 metrics to measure app performance

• How product managers can prepare for rapid user growth

• Building a sticky app: Features that sell themselves

• Getting to the why: How mobile companies are shaping the world