When it comes to product teams, designing an effective structure is probably more important than developing efficient processes. The structure of your product org determines incentives, specialisations, collaboration and communication. Collectively these drive the impact of your product teams.

The right structure is very much up to each individual company – there’s no “correct” way to do it. This guide will talk you through various considerations, and I’ll share some experiences.

"Without conscious planning, organization structures are mirrors of your company’s past. Make sure they are mirrors of where you are now and where you will be tomorrow, rather than where you began." <text-author>- Mark Allen<text-author><text-violet60>  ∙   CTO of Ourspace<text-violet60>

"Any team should be small enough that it could be fed with two pizzas." <text-author>- Jeff Bezos<text-author>

"A mantra that’s often repeated here is that we’re highly aligned, but loosely coupled. Meaning, we all know the direction we’re going in, but there’s enough trust so that we can take our own paths to get there." <text-author>- Courtney Symons<text-author><text-violet60>  ∙   Editor-in-Chief at Shopify<text-violet60>

💡 Defining “product team”

The atomic unit of product org structure is a product team. These are sometimes called pods, or squads. We’ll refer to them here as “team” for simplicity.

The most efficient and effective way for most product orgs to work are in cross-functional teams. Cross-functional meaning you have engineers, designers, and product managers together on a single team. Basically, you need enough skills for the team to be able to ship product as a self-contained unit. This is what we mean by the product team.

A product team might also have product marketers, user researchers, analysts, data scientists, or QA engineers. But the trio of design, product, and engineering is most commonly at the core.

A product team can be created or changed at any point, but we generally recommend only changing a maximum of once per quarter. This gives people in those teams a bit more certainty about what they’re doing and gives them the time to become experts.

‍

Jason Knight, an experienced product leader and consultant at One Knight Consulting, says to make sure not to limit thinking to only the people on the team itself:

"Everyone in a SaaS product company is part of the wider product team - everyone should care about how product thinking affects their functions (even if they’re not in the trio)."

Cross-functional teams

Why cross-functional is best for startups

If a team has all the skillsets needed to ship product, they have full responsibility for problem-solving. If the skillsets sit in separate teams (e.g. if design and engineering are separate), there are gaps in communication and ownership. These gaps lead to slow shipping and bad product which can kill startups.

Cross-functional teams create virtuous cycles; the more the team works together and identifies as a unit, the faster they can ship, and the more they cement their shared identity. The team will refine and improve their ways of working, which spins the flywheel faster, resulting in higher impact.

Jason Knight adds that there is no “Boss” in a cross-functional team:

"Just because the PM has “Manager” in their title doesn’t mean they get to boss people around. This is a collaborative, cross-cutting effort and works best when people treat each other as equals. This is alien to some business leaders who expect there to be a head to chop off when things don’t go well."

Reporting lines

People in cross-functional teams still need functional reporting lines. A design manager is best placed to cultivate design expertise, give career guidance, and generally support designers. You can look at reporting and team structure as two (almost) separate issues.

Stephanie Bowker, founder of Ourspace, frames this as: “cross-functional teams are how work happens & reporting lines are meant to foster coaching & career development.”

With reporting lines, engineering and non-engineering are normally separated. Non-engineering normally falls under “product”. A typical reporting line in product will look something like:

At an earlier stage, it’s common to have design and research reporting directly into a head of product. It’s won’t help to improve their technical skills, but an HoP can help to guide prioritisation, processes, and unblock issues.

At the very early stage, it’s also not uncommon for the HoP/product lead to have the combined role of individual contributor product manager (PM), and product leadership. This is why it’s useful early on to find a unicorn PM – someone who is ready to take on a leadership role, but also happy to get stuck in. There aren’t many of these folks, as you need to catch them in a transition period.

Design reporting into product

Notice that research and content/copywriting normally report into “design” and “design” normally reports into “product”. These are just titles and it’s entirely possible for a design leader to become VP Product. However, it’s more common to have a VP Product that comes from a PM background.

Product and tech can either have joined reporting lines (into a CPTO or “VP of Tech”), or separate (both reporting into CEO). The latter is more typical, and the former really requires a strong person with both skillsets. However, if you can find that person, it can greatly increase speed and alignment across the orgs.

‍

When to split from one team to multiple teams

When to split from a single product team into two is a common question asked by founders.
My general answer is: when you have enough engineers to be able to ship product as a self-contained team.

Why larger teams have lower impact:

Eventually all teams will split, as you add more people to them. The marginal value of adding a person diminishes rapidly, and becomes negative surprisingly early.

One reason for this is communication overhead. As you add more people to a group, the amount of communication lines to maintain increases exponentially. A 50% increase in team size from 6 to 9 leads to a >100% in communication lines.

Keeping track of who’s working on what, and why, becomes very hard.

Another reason is that most work can’t be done in parallel. If two engineers are working on the same bit of code it will get messy pretty quickly. If a project will take one month, it’s tempting to think that adding another person will make it take half the time.

Sadly that’s not the case – in software you can quickly get “too many cooks”.

When to split:

To maximise team agility, it’s important that teams are able to ship without relying on other teams – they need to be self-sufficient.

This often will happen around 2 or 3 engineers per team, so around 5 or 6 is when it becomes appropriate to split.

Designers and product folks have an easier time sitting across multiple teams. The nature of their work means they have a lower cost of split focus. It’s much harder for an engineer to physically write two pieces of software at the same time, whereas a designer can typically shift focus with less switching cost. That’s not to say it’s necessarily optimal, but it is possible.

Benefits of splitting:

As well as reducing the pain points mentioned above, there are other benefits of splitting from one team into multiple teams:

• It forces people to specialise. If someone refines their focus from doing “everything” to doing “a subset of everything” then they will get much better at doing that subset. This increases the value of each team member over time.
• You (normally) ship quicker. Delegated decision-making and clearer accountability make for a faster shipping speed.
• It forces focus. When you have a team working on everything, they can work on anything. Splitting teams and giving each a defined focus necessarily cuts down on low priority work. This can be painful, but is almost always a good thing.

📚 Further reading:

• The Mythical Man Month is a fantastic book that talks about fallacy of just adding more people to a team.
• Dynamic Reteaming: The Art & Wisdom of Changing Teams by Heidi Helfand (thanks for the recommendation Jason Knight!)

‍

Organising Product Teams

There are three common ways to set up teams:

1. Teams based on missions (e.g. the team to increase conversion).
2. Teams based on products or features (e.g. the homepage team).
3. Teams based on skillset (e.g. the mobile team).

Mission-based teams:

Mission-driven teams are normally the best way to optimise for impact. This setup ensures that teams have a unified goal that they can continuously optimise for and refer back to.

When a team is mission-driven, they can work on any part of the product. A team may own a feature or technical service, but anyone can work on it.

For example, if a team wants to ship a change to the homepage to meet their objectives, they should be able to work with the team that owns the homepage to make that happen. They shouldn’t have to convince the homepage-owning team to undertake the work.

Expertise: The team will collectively become experts in their mission. They’ll focus primarily on understanding customer problems and the competitive landscape for those problems. This ensures maximum impact.

They have permission to work all over the product surface area, which means that they are less knowledgeable about a single part of the product works.

Incentive: Teams are motivated to solve the mission. They should have a metric to move, and maybe a counter-metric to make sure they act responsibly (e.g. decrease customer contacts without harming NPS). By being incentivised to solve problems, they’ll consider taking actions like adjusting messaging and removing features, rather than just building.

Communication: To make mission-based teams succeed, time and energy needs to be put into effective and clear communication. With multiple teams working on parts of the product, there needs to be extra effort in communication to ensure alignment and non-duplication of work. There also needs to be clear documentation of technology, so that anyone can easily work anywhere. At larger orgs this may be undertaken by product operations, but startups rarely have product ops before product-market-fit.

Feature-based teams:

This is when each team will own a feature, or part of the product surface area. This might be apps or the homepage. The benefit of this approach is that a team can develop deep expertise in a specific area, and there’s less chance of building a Frankenstein product with loads of teams trying to achieve various objectives.

Expertise: Teams will learn a lot about how their specific feature works and they’ll be able to ship faster on them.

Incentive: A big downside of this approach is that teams aren’t directly motivated to solve customer problems. Often success can become just shipping additions to the feature, or making the feature nice and shiny. That can be useful, but often isn’t very valuable to startups.

Communication: There is less need for communication about how the feature works, as the expertise will lie within the team already.

Skillset-based teams:

This is when teams are based around skillsets. This is common for AI / data science teams and early mobile app teams. It’s a sensible approach to take when there is a limited amount of people in the org with that skillset, and they can’t be shared between teams that need them. For example, at an early stage, a primarily web-based product might have a separate mobile team(s), even if they have mission-based teams elsewhere. This could be the case if they have 2 Android engineers, and can’t share them between 5 other teams, so it makes more sense to have a dedicated Android team.

Expertise: These teams can go all in on becoming exceptional at their skillset. This can come at the expense of becoming experts in understanding customers and their problems in a wider context, though.

Incentive: Skillset-based teams are sometimes incentivised by just shipping features, rather than solving customer problems. At the earliest stages that’s fine, when impact can be easily eyeballed (e.g. we didn’t have a mobile app, now we do and it has several thousand users). But as you grow it can be hard to measure success and ROI of those teams.

Communication: Communication is much easier for work done in the team itself, however any communication outside of the team becomes much more difficult. This can be a big blocker in getting anything cross-team done.

Jason Knight says: “Substantial work needs to be put in to keep these people aligned/engaged with the wider team. I’d recommend that they at least round robin through squads, or that there are regular sync ups”

‍

Top-down vs bottom-up

As your company grows, there are cultural decisions to be made on whether to be top-down, or bottom-up. This isn’t strictly org structure, but it will influence how you design your teams.

Top-down:

This is when teams have work delegated to them and they focus on execution.

This approach can cut down on alignment problems, so individual teams don’t need to spend time aligning amongst themselves. More top-down cultures can work well in complex organisations with high alignment costs, or where there is little uncertainty around what to build and how to execute on it.

Bottom-up:

You won’t be surprised to read that bottom-up is the opposite of top-down. It typically means product teams coming up with their own plans, each furthering towards company goals. Leadership still sets those company goals and direction, but teams have the freedom to solve problems in their own ways.

This approach is better when startups are faced with high uncertainty, because it means the decision-makers are closer to the problem and customers. Product teams should be building expertise in their focus area, which gives them more context to solve problems quickly.

In bottom-up environments, teams can generally execute faster because they are more motivated; they’re empowered to make decisions fast; and they don’t rely on senior leaders that can become bottlenecks.

💡 Recommendation:

Most startups operate in very high uncertainty, which means they benefit from a high degree of bottom-up culture. This makes it a better default for startups and scaleups.

The whole lean startup movement is based on the fact that startups are innovating in areas where the winning solution isn’t readily apparent. Disruption necessarily requires new tools and business models, which requires rapid iteration and testing. This typically happens quicker in bottom-up organisations.

However, top-down does have its place. Founders (and senior leaders in general) have far broader context than individual teams, which is very useful. They can also align multiple teams much easier, rather than waiting for teams to align independently. So if going through a pivot, existential threat, or highly complex project, then top-down can be more helpful.

‍

Set in stone?

Things will always change; whether that’s people coming or going, or priorities shifting. A strong startup will always be learning and growing, and their org design will need to adjust for that.

We recommend doing smaller adjustments of moving people around on a quarterly cadence, to give people time to adjust to the new org structure and feel secure in what they’re doing. This doesn’t have to be at the quarter start / end, but it is useful for people to know when to be prepared for change.

For larger adjustments like team focus, something more like 6 months is appropriate. It can take a few months for team to ramp up and start showing consistent impact, so it can be unproductive to change focus each quarter.

Stephanie Bowker says:

Org design should be strategically flexible to adapt to the dyamic nature of change. The best organizations are able to absorb change quicker because they’ve set the mindset for adaptation and take time to prepare clear communication on the reason for the change versus those that stick in a structure for fear “adding more work” or confusing people.

How to re-org better:

Ourspace CEO Megan Murphy gives some key principals when handling a re-org.

1. Reorganisations have huge potential for good and bad impacts. Make sure to take the time to plan deeply and communicate clearly.
2. Make sure to explain why the reorg is happening. Boil it down to a few key themes; if you give lots of reasons, people will get confused.
3. Be clear, not clever. Reorgs for cross-functional teams will affect multiple functions. Make sure it’s clear who is owning the reorg decisions, and who is supporting.
4. Communicate personally. People don’t like surprises, especially public ones. Communicate to individuals if their roles will change, before telling the wider company.
5. Make yourself available. Use whatever medium is most appropriate for you (AMA, Slack, in-person) and be present to answer questions and explain things

Jason Knight adds that when people don’t understand a change they’ll fill in their own blanks with mostly incorrect information. Clarity is key here to avoid a ‘Telephone Game”.

‍

A key principal of org design:

Mark Allen, CTO of org design tool Ourspace writes:

It is unwise to design companies for the exceptional cases — those people will set an unachievable example and eventually move on. Instead, structure your org for the average teams. Tech companies succeed and fail based on the effectiveness, consistency, and predictability of their average teams as much as they do by the rapid velocity of their strongest team.

This is something to keep in mind as you design your org. Don’t create a structure where only the most exceptional individuals will perform well. They’ll likely perform well in most setups.

Instead, make sure that your org design works for most of your teams, by giving them clarity of goals, motivation, and communication.

‍

📚 Further reading:

• Coordination Headwinds – How organisations are like slime mold. A fantastic and apparently informal presentation from a Google manager about why execution becomes so hard at scale.
• Peacetime CEO vs wartime CEO. A fantastic essay by Ben Horowitz about decision making during ‘peacetime’ compared to ‘wartime’.
• Organisational Culture and Leadership – a proper academic textbook, but an incredibly in-depth look into how organisations and culture evolve. Useful if you want to go formal, and very deep.
• Teams Are Immutable by Marcus Hammarberg
• Team Topologies by Matthew Skelton and Manuel Pais