A team is crucial.
It’s the product roadmap, according to some. It’s the product requirements paperwork, according to others.
In my opinion, Your product team’s performance is largely dependent on its structure.
A cohesive team that outperforms its individual members can be distinguished from a group of infighting and turf fights by having a well-designed PM organisation.
Product managers should prioritise selecting the right people for the right jobs rather than focusing on what has to be built.
But how can a well-organized product team possibly be realised?
To begin with… Which Model Are You Relying on?
A product team can be organised in a plethora of ways.
Which companies should you follow: Oracle, Apple, Microsoft, Facebook, Amazon, or Google?
There’s no correct approach. Neither one appears very attractive, either.
The most common type of intellectual self-soothing people do on this is reading articles about “How X does product.” However, a place’s method of producing a good is just a method.
A, B,C live in totally different market from you are in, so they may get benefited from something on which you cannot.
Every Thing Is Distinctive
Thus, while there are some lessons to be learned from other people’s experiences, it will never be everything.
It is going to be different for you.
-The CEO you have will have a distinct personality.
-Your stakeholders will operate in a new way.
-Your developers’ and designers’ levels of expertise will differ.
That’s the reason you haven’t seen several of those articles on this.
I enjoy reading those pieces. They also have insight. However, a collection of anecdotes by itself leaves a huge gap.
They don’t organise your options or assist you in making a decision.
Today’s Post
This post aims to assist all of us as product leaders in sifting through the available options and offers a decision-making framework:
-A lens through which you can see your possibilities for organising your team
-Examining the 4 commonest structures
-A framework to help you choose the best decision
It serves as a practical manual for product managers on how to organise a team in the age of limitless information.
A lens through which to see your team’s organisational possibilities
Before beginning this article, I asked a few product leaders about the best way to set up a team of people.
The thing that struck me the most was how little everyone had in common when describing the various configurations of a product team.
Most people were aware that organising around a product or product line is the most typical structure for product teams. A specialised product manager for each product works directly under the chief product officer or vice president of products.
For most, however, going any farther was difficult.
What’s taking place here?
The Feature Organization Method Isn’t Everything
Of course, the issue is that everyone only takes the feature method of organisation into account.
While it works well in some circumstances, it is not always the ideal approach.
-The significance of feature vs. product focus is overlooked. A PM who is in favour of a feature is quite unlikely to advocate for its removal. It causes the PM to become more focused on the feature than the overall product.
-It hides the importance of impact. It is assumed that the PM in responsible for a feature will be able to allocate their resources to the business’s strategic priorities. The issue is that this fails a lot. Feature teams perform the work, and often fail, in mapping the features to outcomes.
-It doesn’t address whether cross-functional ownership or solely PM ownership applies to these features. Cross-functional leads participate in a PM-owned organisation, but they are not co-owners of the plan. Many teams and cross-functional stakeholders participate in cross-functionally owned organisations.
An Improved Framework for Understanding Organisation
What better approach to team structure can you take to assist solve these issues with your product team?
It is necessary to ask two questions:
Are teams centred around features or outcomes?
Is it the case that teams share or own their metrics?
The answers to these queries correspond to the kind of product organisation you have.
Here’s an approximate picture of each:
-Owner of the outcome: In this case, the PM is in charge of driving a metric and has exclusive ownership over it.
-Contributor to the outcome: In this case, the PM is not the only one who is focused on a metric rather than a feature.
-Owner of the feature: The PM is the only person with ownership of a feature.
-Contributing feature: This refers to a PM who concentrates on a certain feature but is not the exclusive owner of it.
So how does one PM for each feature of the product fit in? That combines the two most likely options in this scenario: feature owner and feature contributor.
Company Size Matters
Of course, the largest determinant is variance by company size.
When there is only one PM throughout the startup phase, things are not at all like when there is a head of product and other PMs. And that still stands in stark contrast to the massive corporations.
Generally speaking, you can’t decide to concentrate on results until you’ve established product-market fit. Up until that point, the PM’s role as a feature owner or contributor is the only one that counts.
Non-Options for Organization
The literature contains a plethora of awful structural alternatives.
For example, several articles discuss how a team might be organised based on the competencies of a product manager. This piece is new to me. Similarly, team structures based on customer journey stages or customer segments have been proposed.
These seem like a wonderful idea in theory, but no one I’ve spoken to or polled really implements them.
Let’s examine more closely at the various organisational structures used by people to create their product teams and determine which works best for you.