(106) What is the ideal way to structure your product teams? — Part 1

In the recent days I have been deeply involved in restructuring product teams as my company is going through scaleup phase. The older team structures were no more suited for the growth phase we are in.

I had to step back to find out what best practices are in place to design product teams. Here’s a run down of what I gathered with all my research and readings.

From High Growth Handbook

Most of the time, there is no right or wrong answer and product team restructure is often an exercise in pragmatism. If you are growing fast, you have a different company every 6–12 months and so is the org structure.

When choosing an organizational structure for your high growth startup, focus on the next 6 to 12 months only. Don’t try to find a long term structure as the long term company will be different than today and will have different needs. Eventually, your executive team will start to stabilize but the teams underneath will have more frequent reorgs.

When choosing an organizational structure for your high growth startup, focus on the next 6 to 12 months only. Don’t try to find a long term structure as the long term company will be different than today and will have different needs.

There is no one answer to structure your organization. It is a series of tradeoffs. Two different structures may be equally bad and good.

Communicate to your team that as your company grows quickly, things will shift around. Make it clear that it is normal for that to happen.

When your company is in hypergrowth, you will be doubling the team every 6–12 months on average.

Early on, many of the re-orgs will be at the executive level, and then cascade down.

Decide why you need the new org structure?

• Spell out the logic of why you need the reorg first and then think through the leadership and org structure that works best.
• Why the new structure is better than the old?
• Do you need renewed focus on a specific area?
• Are there collaboration issues?
• Has the team grown dramatically and now needs additional management?
• Has something changed in your market that means you need to re-align functional priorities or set of people working together?

Determine what org structure is most pragmatic?

Nothing you come up with will be 100% perfect and that is okay.

This is what Gofore.com says:

Agile scaling must be based on feature teams.

• Increased value throughput–focus on delivering what the customer or market values most.
• Increased learning–individual and team learning increases because of broader responsibility and because of co-location with colleagues who are specialists in a variety of areas
• Simplified planning–by giving a whole feature to the team, organising and planning becomes easier
• Reduced waste of handoff–since the entire co-located feature team does all the work (analysis, design, code, test), handoff is reduced
• Less waiting; faster cycle time–waiting is reduced because handoff is eliminated and because completing a customer feature does not have to wait for multiple parties each doing part of the work serially
• Self-managing; improved cost and efficiency — The team has responsibility for end-to-end completion and for coordinating their work with others. Feature teams are less expensive–there isn’t the need for extra overhead such as extra managers and coordinators
• Better code/design quality–multiple feature teams working on shared components create pressure to keep the code clean, formatted to standards, constantly refactored, and surrounded by unit tests.
• Better motivation–research shows that if a team feels they have complete end-to-end responsibility, and the goal is customer-directed, then there is higher motivation and job satisfaction
• Change is easier–changes in requirements or design are absorbed by one team; multi-team re-coordination and re-planning are not necessary.

Input from Jens Fabian

In general, the larger an organization, the more formal structure is required. A startup of five people can still get away with very little formal structure.

It’s easy to see why larger organizations need formalized substructures. The number of one-to-one relationships grows with the square of the number of people. In a five-person team, there are 10 one-to-one relationships. In a ten-person team, the number is already 45. For a 20-person team, we’re looking at 190 relationships, and for a 100-person team, a whopping 4950.

Another way to think about this: in a 100-person company, hiring someone new means they have potential relationships with each of the existing 100 people. Clearly, we need substructures for larger teams, or people will be so busy just managing their various relationships and interfaces with other people that they won’t get any work done.

How do these product teams get started?

There is no “correct” answer, but there are a few dimensions along which decisions can be made about their setup.

• Permanence of the teams

The first dimension is how permanent these teams and membership within them is. On one end of the spectrum, teams stay stable basically forever (but their objectives might change over time). New people are hired onto a specific team and expected to remain there. On the other end of the spectrum, teams are spun up to address emerging opportunities and disbanded once their objective has been achieved. There are obviously also models in between these two extremes.

Both ends of the spectrum have their advantages and disadvantages. Stable teams allow people to build deep relationships and teams to iterate on their way of working, making them more effective over time. On the other hand, it can lead to siloing of knowledge and deviating cultures. It can also have an “everything is a nail” effect: a team gets great at a certain way of working and solving problems, and will start applying that way of working to all problems, regardless of whether it is the most appropriate way. Short-lived teams allow for higher flexibility and matching emerging opportunities with the best talent available in the organization. On the other hand, having to build new relationships with team mates frequently can be stressful for team members and lead to friction, reducing effectiveness.

On the whole, over time I have come to favor more stable teams. However, to avoid siloing, I believe that some degree of change to team composition every now and then should be enforced. These team composition shake-ups usually cause some discomfort for team members. However, it is worth noting that some level of discomfort is necessary for all learning. Leaving a team composition intact leaves the team in its comfort zone; changing it causes discomfort but also causes the team to learn and adapt and ideally come out a better team.

Team superstructures

In larger product development organizations, you probably need a superstructure spanning over the product teams — some kind of grouping that helps organize and align the various teams. I am far from an expert on that topic, so instead of diving too deeply into it, let me just mention a few possible organizing criteria by which you might group product teams:

• By product or product area
• By customer/user group
• By overarching goal, e.g. growth vs engagement
• Temporary structures for strategic initiatives comprising multiple teams, e.g. a multi-quarter effort to improve various aspects of onboarding

From Aha.io

There is no one-size-fits-all structure. You can organize your product team around the different products or product lines in your organization, for example. Or you can align around the functional area each team supports — whether that is a product feature or a customer segment.

Consider these questions as you think about the best organizational structure for your product team:

• Who are your target customers? How do their needs vary?
• Which business goals is your team responsible for achieving?
• Are there multiple products or product lines to be managed?
• What are the functions of your product team?
• What resources will be dedicated to each team?

Choose a structure that best supports the goals you need to achieve.

By product or product line

Organizing around a product or product line is the most common structure for product teams, especially at larger organizations. Each product has a dedicated product manager who reports directly to the VP of product or chief product officer. In the example below, you see three product lines with an embedded UX designer.

This structure scales well and gives product managers autonomy over their product or product line so you can deeply focus on customer problems and how to solve them. Within this structure, product managers can make decisions and iterate quickly because they have very clear ownership. This structure can also lead to siloed work — so product managers must be intentional about making time to collaborate with peers outside their area of ownership.

By feature

Organizations with complex products may have teams dedicated to particular product functions or features. In the diagram below, one product manager is responsible for the product’s chat features, another is responsible for the email platform, and so forth.

By customer segment

Some organizations structure their product teams around customer segments. This is common when a product serves the needs of different vertical markets — finance, healthcare, manufacturing, etc. — as in the example below.

FROM BUFFER

Goal-focused squads

Today we have a variety of small teams with many different priorities within the Buffer product. Here’s a look at all the different areas in which we’re working in, each of which has its own devoted team:

Each team generally comprises 1–2 engineers, a product specialist, a designer, a customer development teammate, and oftentimes a growth analyst.

The teams are organized according to the squad model, as explained by Hudl in a super handy post:

On the product side, this new structure has allowed each squad to move quickly and produce lots of cool new features in a relatively short amount of time.

“It’s been fun because we’re doing better in each area and moving things faster,” Joel said. “It’s better for discipline and focus. We’re learning it’s better for each part to move quickly.”

Plus role-based chapters

Defining each squad’s makeup so specifically has also allowed us to dive deeper not just into Buffer’s various pieces but also each role’s speciality. Designers get together, engineers sync up and learn from one another across their squads. Hudl calls these groups “chapters.”

If squads are about goals, chapters are about roles. Cross-squad chapters can go deeper into their specific area and keep learning.

“Sometimes I drop into the design circle and it’s crazy to hear the specifics of what they’re talking about,” Joel said. “What should the color of the primary button be, spacing between the elements. It feels great to form a design culture.”

(When we get a bit bigger, we might see tribes and guilds also. Exciting!)

PRODUCT SQUADS

https://www.productplan.com/blog/product-squads/

The way Spotify has set them up, each of these squads consists of a small team of developers and one product owner — usually, but not necessarily, a product manager.

What makes these squads unique? A few things.

First, product squads are responsible for functional areas of the company’s product line; they do not work across entire products or on ad hoc projects assigned by management.

For example, one squad might focus on exclusively search technology. This allows the company to develop significant expertise and intellectual capital across each functional area of its offering. In other words, it can build teams of true industry experts, rather than a single large team of coding generalists.

The second way product squads deviate from traditional product development approaches is that they are given real autonomy. In fact, Spotify thinks of its squads as independent startups.

What does that mean in practical terms? It means that a squad can select its own areas of functional responsibility to work on. Once it has taken on such an area — again, search technology, for example — it can update the production version of its product anytime. It can push work out to users without waiting for approvals from anyone outside the squad.

So the basic idea is that product squads can lead to much more efficient product development, teams who are highly knowledgeable about the product’s various functional areas, faster development cycles, and ultimately more successful products.

Is the product squad approach right for your organization? It depends. There are benefits and drawbacks, and it isn’t a clear fit for every organizational culture.

Two Reasons the Squad Method Might Improve Your Product Development

1. It can generate true in-house expertise.

The product manager in a squad has a much greater ability to learn about his functional area than he would if he were responsible for an entire product. Sticking with search as our example, a product owner at Spotify can become an unrivaled expert on the technology — how search can be used to improve the overall user experience, best practices, and all of the latest industry improvements.

If that product manager were responsible for the entire product, however, he would only be able to spend so much time on search — or anything else for that matter. He would also have equal responsibility for learning about partner channels, pricing models, securing music contracts, researching the latest developments on UX, and on and on.

By assigning squads to complementary areas of functional responsibility across your product line, you can allow for tremendous knowledge among both your product owners and developers. In fact, this can be a key differentiator for your company, because your competitors will likely still be developing in the everyone-works-on-everything model.

2. It can speed everything: development, feedback and learning, and updates.

Because squads are permanent, small teams, its members get to know each other well, developing chemistry and a team shorthand that can speed the work.

Also, because the squad has the authority to release its product updates directly to the market anytime it wants, it can more quickly learn what’s working and what isn’t. It can then autonomously make improvements and push right back out to its user base.

The squad approach can in some cases be a perfect addition to an agile environment because it supports one of the most important agile principles:

“Working software is the primary measure of progress.”

The more quickly your product squads are able to update the product and push those updates to market, the more quickly they’ll be able to determine if they’re working or how they can be further improved. Ultimately, that will generally lead to a more successful product.

Three Reasons the Squad Method Might Undermine Your Product Development

1. Your product line might not support this model.

Remember, the product squad approach was developed, or at least popularized, by Spotify — a SaaS company. They obviously coded their product in a framework that allows for tinkering and tweaking here and there without negatively affecting any other parts of the product.

Because their code is segmented to such an extent that they can modify the radio functionality without touching their search code, for example, the squad method of autonomous team updates makes perfect sense for Spotify.

What if you sell multiple interrelated products and services, and they were constructed such that an update to one area of a product might affect everything else?

You probably wouldn’t want to restructure your development and product management organizations into squads, because you couldn’t give those small groups the autonomy to update the live products. Otherwise, their updates could jeopardize the stability of the rest of the product.

Additionally, if your product has many components with interdependencies, you would often have instances where one squad had to wait for support from another squad. And this would remove much of the value of operating under a squad model in the first place.

2. You risk breaking your in-house product knowledge into silos.

In an agile context, a product manager’s primary role is to educate the developers on the product’s personas and the problems the product should solve for those personas. In other words, product managers should have a comprehensive understanding of the product as a whole.

But if you break your resources into squads responsible for functional areas, you are in effect dicing up the overall, strategic-level product knowledge across several product owners. Although they might become unrivaled experts in their functional areas, these product owners likely won’t have a full strategic understanding of the entire product. That’s risky.

Additionally, by making your developers hyper-specialists in a few functional areas, without also allowing them to work at times on other projects, you risk isolating your company’s coding talent from the big-picture view of the product?

So if your squads don’t interconnect well and often, then you run the risk of information silos. Who at your organization will have full product knowledge? Which product managers? Which developers? Will any of them?

3. You could lose some of the advocacy from both product management and development.

A third reason squads might not work is that a product’s success often depends on maintaining some distance and objectivity between product management and development. The product owner should be focusing on product vision, strategy, the what. They should then be communicating this to development, who should focus on the how.

So it’s not necessarily a bad approach to have a little tension between product management and development. Product managers should be looking to push boundaries, try new things, and implement themes that might not be so easy for development.

Developers will be motivated to complete the challenges put before them as efficiently and quickly as possible. But the product manager will at times have strategic reasons for wanting to execute on an initiative in a given way — one that might be at odds with the development team’s way of thinking.

But if the product manager is on the same team as the developers, you run the risk that she won’t ask for X because she knows that within her team’s functional area of responsibility, the framework will make it easier to implement Y instead.

Think of the embedded-journalist problem. When war correspondents embed themselves with a military detachment and go out on missions under their protection, you can imagine how difficult it can be for those journalists to then report the facts objectively, particularly if their report would portray the military team unfavorably.

The same potential problem exists with embedding a product manager on a development team.

The product will likely enjoy more success when both product managers and developers are advocating strongly in favor of what they see as best for the product — even if doing so creates a bit of tension between both teams.

Product Squads: Interesting Approach to Product Development, But Not Right for Everyone

Product squads seem to be a great way to build strong, knowledgeable development teams.

They also offer perhaps the best development framework yet to allow companies to quickly and efficiently build and release products and then improve upon them based on how their markets react.

Moreover, they seem to be a logical extension of the agile philosophy. Indeed, one of the more important agile principles is: “The best architectures, requirements, and designs emerge from self-organizing teams.”

And remember, agile development itself is all about doing what works best rather than adhering to any process or development rule.

If the product squad approach sounds like a fit for your organization, it might be worth a try.

But if you’re not sure to what degree your product can handle independent updates at various times, or you worry about sacrificing overall product knowledge to build up your organization’s functional expertise, then you might want to investigate the squad method more deeply first. Implementing the wrong product development strategy can create more problems than it solves.

FROM PRODUCTBOARD

https://www.productboard.com/blog/4-ways-to-structure-scaling-product-organization/

4 ways to organize a scaling PM organization

Principle 1: Organize around jobs-to-be-done

Principle 2: Organize around solutions

Principle 3: Organize around personas

Principle 4: Organize around customer segments

When organized around customer segments, product teams group customers according to specific attributes like geographic location, demographics, job title, or other context-specific dimensions.

Pros: Organizing around customer segments is valid if each has a different need and can be better served by a specific solution that meets those needs.

Cons: Product teams may end up duplicating work if teams arrive at the same solution because the needs of segments are not that different

This approach works well for a physical product and when the needs of segments are differentiated. For example, a toothbrush company might have one product team focus on toothbrushes for adults and another on toothbrushes for children. For children, toothbrush design likely involves making the product attractive and enjoyable so they can build a habit of brushing their teeth. For adults, toothbrush design may focus more on preventing dental problems so they can avoid going to the dentist.

Productboard’s guiding principle

Here at productboard, we’ve chosen jobs-to-be-done as our guiding principle because it makes the most sense for our company at this stage and size. We’ve defined three main jobs:

• Job 1: I as a maker want to systematically learn about the needs of my customers to formulate a product vision.
• Job 2: I as a maker want to prioritize problems to solve via focused objectives to create a clear product strategy.
• Job 3: I as a maker want to align everyone in the organization on what to build next to maximize transparency and seamless execution.

SUMMARY

• Nothing you come up with will be 100% perfect and that is okay. Most of the time, there is no right answer and org structure is often an exercise in pragmatism. It is a series of tradeoffs. Two different structures may be equally bad and good.
• If you are growing fast, you have a different company every 6–12 months and so is the org structure. Don’t try to find a long term structure as the long term company will be different than today and will have different needs.
• Communicate to your team that as your company grows quickly, things will shift around. Make is clear that it is normal for that to happen.
• Team structuring to be based on value throughput — focus on delivering what the customer or market values most.
• Designing team structures oriented toward engineering — above, say, customer value — runs the risk of becoming too inward-looking. Such a company might focus on technical elegance, for example, instead of whether that product can achieve a market fit.

Define the organizing criteria:

• By product or product area
• By customer/customer segments/personas
• By overarching goal, e.g. growth vs engagement
• Temporary structures for strategic initiatives comprising multiple teams, e.g. a multi-quarter effort to improve various aspects of onboarding
• By customer’s jobs to be done.

Designed for ownership: Teams own outcomes and not just tasks. Dedicated, self-managed, self-contained autonomous teams who develop in-house expertise and intellectual capital in their respective areas — functional experts instead of coding generalists. The teams have responsibility for end-to-end completion and for coordinating their work with others.

Designed for durability: We want teams that are stable over time. Innovation comes from teams that know each other well, and trust each other. Durable, small teams, its members get to know each other well, developing chemistry and a team shorthand that can speed the work.

On one end of the spectrum, teams stay stable basically forever (but their objectives might change over time). New people are hired onto a specific team and expected to remain there. On the other end of the spectrum, teams are spun up to address emerging opportunities and disbanded once their objective has been achieved. There are obviously also models in between these two extremes.Both ends of the spectrum have their advantages and disadvantages. Stable teams allow people to build deep relationships and teams to iterate on their way of working, making them more effective over time. On the other hand, it can lead to siloing of knowledge and deviating cultures. It can also have an “everything is a nail” effect: a team gets great at a certain way of working and solving problems, and will start applying that way of working to all problems, regardless of whether it is the most appropriate way. Short-lived teams allow for higher flexibility and matching emerging opportunities with the best talent available in the organization. On the other hand, having to build new relationships with team mates frequently can be stressful for team members and lead to friction, reducing effectiveness. On the whole, over time I have come to favor more stable teams. However, to avoid siloing, I believe that some degree of change to team composition every now and then should be enforced. These team composition shake-ups usually cause some discomfort for team members. However, it is worth noting that some level of discomfort is necessary for all learning. Leaving a team composition intact leaves the team in its comfort zone; changing it causes discomfort but also causes the team to learn and adapt and ideally come out a better team.

Fulfils three criteria for Drive: Mastery, Autonomy, and Purpose. If teams feel they have complete end to end responsibility, and the goal is customer oriented, then there is higher motivation and work satisfaction.