How to structure your product team
Product teams consist of various roles and follow different structures. This article describes typical roles in a product team, typical structures of a product team, and helps you decide the best setup for your product team.
So, what are the roles covered in a Product Team? Most product teams work with a cross-functional setup where members have focus areas, fewer product teams work with a strict separation of tasks and concerts deploying strict team roles. While start-ups tend to use cross-function setups, large organizations in mature industries work with strict roles. The following roles can be covered in product teams.
Product Owner and Senior, Chief Product Owner
The product owner takes overall responsibility for a feature, process or product. This can be multiple persons each owning a certain part, or a chief owner taking overall responsibility.
Product Management
Product managers handle all sorts of management and assistive tasks related to managing a product. They can assist the product owner and typically report to a manager taking business responsibility. Product managers handle tasks like inbound/outbound communication and interface to other roles.
Product Design
Design, the process of creating things in a way they can best be used, is a core task of product teams. While visual design is usually covered by specialized visual designers, the actual product usage design is of highest interest and value to product teams. Product design strives to minimize usage friction, reduce click mileage, maximizes business benefit and strives for user happiness.
User Research
Understanding what users do, how they work, and what their real issues are is key to building a successful product.
Product Marketing
The process of bringing a product to the market requires understanding the market, the users and, most importantly, understanding the buyers. Product marketers help positioning the product and shaping the messaging to the market (marketing strategy). Likewise, product marketers also support customer development and customer success activities because customer focus is essential for product success.
Project and Program Management
Stuff needs to get done in a coordinated way. While some organizations use lean & scrum approaches, other product teams rely on project managers and sometimes even a program of various projects. Typical for product teams are hybrid approaches where operative tasks are handled in a scrum flow and lighthouse tasks have a project manager assigned, for example to manage cross-department dependencies.
Engineering & Product Development
Product engineering, which in many industries means product development, is a prominent stakeholder to product teams. While sometimes engineering is a part of the product team (think: micro service, agile squad), the engineering group usually is a separate organization that interacts with product teams. Naturally, engineering work posts real-life limits and needs too many product team responsibilities. Engineering investments need to be prioritized and engineering requirements are to be considered, there cannot be any product change without engineering.
Customer Success
Customer success managers help transitioning sales prospects to active product users. While delivering business benefits to customers, a long-term client relationship is established because these typically provide the highest benefit for both sides, buyer and vendor.
Product Analytics
Understanding the actual product usage is key to shaping a good product. Usually, the role of product analytics is a part time assignment in a product team and deals with the placement of in-product analytical tools.
Operations
Interfacing of product teams with product operations delivers insight into how products are typically operated. While in some industries this mainly relates to cost of operations (e.g. OPS in software as a service), it can relate to understanding the actual end user perspective in other industries (e.g. tools and machinery).
With the various roles covered by product teams being introduced we will now look at how product teams can actually be assembled. This describes their internal structure as well as the cooperation of multiple product teams in a large organization. The following structure patterns appear in product teams.
One Product Manager per Product
Deploying one product manager per product/product line/function is probably the most common product team pattern. This product manager coordinates the activities of market definition, marketing, sales forecasting, funding, budgeting, prioritizing investments into new features, long term roadmap planning, and product development. This comes with the obvious advantage of a single point of contact for all related activities. A disadvantage of this setup is the danger of local optimization where product managers optimize for their individual targets, losing sight of the big picture. Typically, this results in situations where a lack of development capacity is blamed for slow growth and short term deal success is overvalued versus long term strategy.
Product Team Matrix by Function
Product teams can cover activities by function: one person per task for inbound/outbound marketing, engineering, growth, business dev, user research, customer success, development, operations, and similar. This comes with the advantage of putting experts to the job such that all relevant tasks are covered on a cross-product team. A disadvantage is a loss of individual product focus, so the sweet spot of this matrix setup comes with product families and lines of products covered by a whole product team.
Product Squad (aka the Spotify model)
A specialized setup is known to be used at Spotify and Amazon. Amazon established the ‘two-pizza’ approach where, essentially, the number of people being seriously involved in a product can be fed by two pizzas in a team meeting. The Spotify model was first introduced to the public around 2012 when when Henrik Kniberg and Anders Ivarsson published their paper 'Scaling Agile @ Spotify', where they describe an approach to deploy an agile approach in a large organization. While their approach was, apparently, never fully implemented at Spotify - or at least evolved and changed by the time the paper became popular, the notion of product squads stuck and inspired may other organizations. The Spotify model is not a blueprint to copy from, it is rather a motivation and inpiration to give maximum autonomy and trust to local teams (squads). Knowing the Spotify model is beneficial when designing a product organization. The notion of a product squad including the related concepts of tribes, chapters and guilds are an ideal starting point for an ideation process that needs to meet the specific of your product/organization. Ideally, you use the Spotify model as an inspiration and develop your own approach to squads, tribes and guilds - this can give your organization an proud identity to work with.
By Customer *
In single-product companies (or few-product companies) it may make sense to organize product teams by customer. This can be by customer segment, by customer journey phase or sales cycle stage, or by any other meaningful metric (usage, performance, industry). These customer-centric product team setups are natural to B2C environments and B2B markets with a large audience or heterogeneous customer base. As an indicator for deploying a customer * product team setup just check other parts of the organization like sales and support - they may already be following this approach.
So, what's best?
Ultimately, there is no universal best approach for organizing a product team. What’s best for you depends on the above mentioned advantages/disadvantages, but also your willingness to delegate decision power to real product owners (versus using the assistive support of product managers) can make the difference when deciding for a product team setup. As a rule of thumb use a minimum approach where more communication overhead between various product managers roles is minimized by the team design. Less is more, small is beautiful, just keep it simple...
