How Product leaders can shape their teams in the most productive way?
It’s a proven fact that what product teams deliver will be a reflection of their organizational culture. For instance, if one PM owns the Web experience & another PM owns the Mobile App experience & there isn’t seamless teamwork between the two PMs then there is a high probability that the user experience will be varying by high degrees which is going to adversely impact the overall product.
It’s imperative that in order to ensure consistency across various touch points of the product, the stitching of the PMs should be done to minimize unfavourable consequences on the user experience & business outcomes.
There isn’t a perfect solution to this problem. However, it can be optimized based on the categorization of the team of PMs Let’s discuss a few ways in this article.
7 ways to categorize a team of Product Managers
#1 Product based
Organizations with various products can choose this methodology based on the complexity of the dependencies.
For example, Microsoft offers a number of distinct products: MS Office, MS Excel, MS Teams and so on. For Microsoft, categorizing based on products would imply a PM for each of the products.
The key benefits include less confusion among the stakeholders. However, it requires a lot of cross-functional coordination in case the products are rigidly integrated with each other.
#2 Product features based
A PM team can be categorized based on product features. For instance, a stock broking app has tons of features: account opening, adding funds, creating a watchlist, placing an order and so on. PMs can be assigned to each of the features.
It’s the most common methodology to organize a team of PMs, however, it results in multiple dependencies as some features might need a development from various teams, which can delay the GTM strategy of the features.
#3 Platform based
It’s best suited for organizations which possess highly technical or complex products. In this scenario — Android, iPhone & Web will have specific teams dedicated to each platform & there will be a single back-end supporting all three platforms. This also results in high dependencies on the engineering team.
It’s the most discouraging method to categorize the PM teams since it creates a false impression that the feature is developed, however, most of the time it’s only the front end which is being developed whereas the backend development is yet to begin. It’s a classic case of a dependency rabbit hole.
#4 User persona based
It’s usually applicable to organizations which cater to a variety of user personas. For example, a stock broking app catering to B2C users, B2B users or B2B2C users. A different PM would be assigned to achieve success for each user persona.
It helps to get the team focused on each user persona & their needs, however, it demands hefty coordination among the team members in order to circumvent duplicating dev efforts & ensuring consistency across the design system.
#5 User journey based
It’s the most intuitive methodology to categorize the teams as it is coherently stitched to the user journey. It’s the most natural & organic alignment of the team. It’s usually tied to the AARRR metrics framework where each team of PM owns the acquisition, activation, retention, referral & revenue part of the user funnel. However, this methodology put a lot of onus on consistency across the design at various junctures of the user journey. For instance, the transition of the user from acquisition to activation should happen smoothly as it deeply impacts the FTUX (First-time user experience ). An organization which possesses a well-defined linear user journey usually adopts this categorization.
#6 Product metrics based
Organizations having well-defined north start metrics and product KPIs to drive business values usually choose this methodology.
For instance, Amazon might choose a different team of PMs for NPS ( Net Promoter Score ), ARPU ( Average Revenue Per User ) & CLTV ( Customer Life Time Value ).
The biggest advantage of this approach is ensuring 100% accountability to individual sets of PMs. However, the pre-requisite involves long-term & stable KPIs across the organization.
#7 Technology Services based
It’s also the most deployed methodology among the organization where the services are owned by the PMs. For instance, imagine a PM owning communications for the whole organization whether it is notifications, email or SMS. Similarly, imagine a team of PMs owning payments for the organization. Since it’s highly dependent on a particular PM so a small feature or change might require a lot of coordination & effort. It results in delayed delivery of value to the users.
Thanks for reading! If you’ve got ideas to contribute to this conversation please comment. If you like what you read and want to see more, clap me some love! Follow me here, or connect with me on LinkedIn or Twitter.
Do check out exclusive Product Management resources 👇
- The Ultimate List of 100+ Product Management tools 🛠https://rohitverma.gumroad.com/l/PM-tools
- The Ultimate List of Product Management Frameworks ⚙️
https://rohitverma.gumroad.com/l/PM-frameworks - The most exhaustive OKRs notion template 📔https://rohitverma.gumroad.com/l/OKR-Template
