How to shape a product function
Structuring a product function is hard. It’s a moving target - what works today might not work in six months. With changes come overheads and often a boatload of stress. You can rarely satisfy everybody.
Having worked in over a dozen different organisations I’ve sampled many different structures and studied countless others. The article below is a starter-for-ten template approach that combines the best of the best.
An introduction to the roles within a product team
Each product team is typically made up of a mix of four key practitioner roles, which you can read about in more detail in my earlier core roles article. I’ll give each of these a sentence of context below:
- Product manager (PM) - responsible for ensuring a product meets user needs (value risk) and that the solutions developed by the team work for the wider organisation (business viability risk)
- Product designer (PD) - ensures that users can figure out how to use products (usability risk) and that they have a compelling value proposition (value risk)
- Tech lead (TL) - focuses on understanding how to turn design into scalable products through software engineering (feasibility risk)
- Engineer - works across the full technology stack, from infrastructure to front-end, to develop and ship resilient, scalable, modular, automated, and interoperable software
In addition to these four roles, there may be many other roles in and around teams (also described in the core roles article), but for the sake of clarity, we will assume that only these core roles are present within your organisation.
There are three other distinct product roles that feature in this article:
- Head of product (HoP) - supports three to five closely-related teams, helping with cross-team alignment, vertical alignment with broader business objectives, and overall development of the product managers within their teams
- Director of product (DoP) - where there are many products, or products serve many markets, directors help to set the direction for a given product or market, and align the tribes within their function
- Chief product officer (CPO) - sets the overall product strategy and represents product management at exec level
These roles can have different names (in some cases inverted with each other, just to muddy the waters further!) and this is by no means an exhaustive list - these three are the ones that I have seen more frequently. Two others worthy of mention:
- VP of product - I’ve seen this title given to each of the three of the roles above in different organisations, and sometimes given to a role that complements the CPO, assuming some of the more hands-on elements, such as planning, ways of working, personal development, and recruitment
- Product operations lead - an emerging role that is there solely to enable product managers to carry out their role as effectively as possible. They work to ensure that product managers have the tooling they require, to promote consistency in ways of working, to optimise comms, to improve onboarding - the list goes on.
A crude LinkedIn search on 20th August 2022 gives a feel for the prominence of each of these roles across the UK:
- Product manager - 55,000
- Head of product - 9,800
- Director of product - 10,000
- Chief product officer - 1,800
- VP of product - 1,900
- Product operations lead - 1,800
The five stages
Depending on where your organisation is at in both the life cycle of its product(s), and its maturity in terms of product development practices, you will broadly fall into one of these categories:
And an illustration of what your product function may look like at each of these stages:
Here’s a very loose checklist to help you determine which one you are:
| Question | Start-up: part one | Start-up: part two | Scale-up: part one | Scale-up: part two | Behemoth |
|---|---|---|---|---|---|
| When were you founded? | In the last year | In the last two years | In the last five years | In the last five to ten years | Over a decade ago |
| How many product teams do you have? | One-ish | One or two | Three to ten | Ten to 20 | Countless |
| How many employees do you have? | Less than 20 | Less than 50 | Less than 200 | Less than 500 | They’re like ants |
| How many products do you have? | One-ish | One | One to three | Three to ten | Many |
| How many markets are you in? | None | One | One to three | Three to ten | All of them |
| What funding have you received? | None / seed | Series A | Series B | Series C+ | IPO+ |
| How quickly are you growing? | Not at all | Snail’s pace | Rapidly | Beginning to slow | Not at all |
Start-up: part one
There is very little need for structure at the beginning as the potential for misalignment is small. Often people wear multiple hats. It’s not uncommon to have just one product manager in a small product team - perhaps just one tech lead and one product designer - where the product manager embodies the organisation-wide product function.
Often, a founder or c-suite member (COO, CTO) may serve as the CPO to enable the product manager(s) to focus on their day-to-day.
Ways of working are likely to be unrefined, and less rigour may be required than later on in the organisation’s journey as the focus switches from lightweight experimentation to building products that scale.
Start-up: part two
Rigour and structure begin to take hold. There is likely to be one or perhaps a small number of fully-fledged product teams. Product market fit has likely been achieved and the organisation is now iterating on a live product in anger.
Your product manager(s) can just about get away with the demands on their time. Alignment can begin to become challenging, with a bigger team to support, and a new stakeholder popping up every few weeks.
Scale-up: part one
You have a fully-fledged product. Unless you’re lucky enough to have a super-simple proposition, you’ll likely have multiple teams by this point, and alignment will prove difficult. You’ll also have more stakeholders, and more attention focused on your team, particularly if investment rounds have taken place.
This is where the head of product role comes into its own. At this stage, their role is threefold:
- Help teams to work together more cohesively
- Help teams align with organisational strategy
- Develop the product management function
The head of product may find themself operating as de facto CPO at this point, as the most senior product person in the organisation.
Scale-up: part two
There are now too many products for a single head of product to support. The teams are batched together into tribes, each of which will now have its own head of product, engineering, and design.
A CPO will likely be installed at this point if they are not already in post, to focus more on higher level strategy and to represent product management at exec level, enabling each of the heads to focus on the needs of their tribe. The CPO may be titled ‘Product director’ at this point, if the org chooses to save the c-suite appointments for the next stage, or doesn’t feel that product should have a seat at the top table.
Behemoth
All of the scale-up: part two goodness is continued, but the product is now too complex, there are too many products, or products have been introduced to wildly different markets, meaning the c-suite roles cannot give each the level of service that they deserve.
Product directors may be introduced at this stage, probably to focus on a specific product or market.
When to pull the trigger
There is no right answer here, but there are some tell-tale signs when it might be time to rethink your product setup.
Consider appointing your first head of product when:
- One team goes to release a feature only to find they’re blocked by another team
- Two teams unknowingly build the same thing
- There is nobody available to interview for another product manager
Consider moving to a tribe model and appointing multiple heads of product and a CPO when:
- There are more than five teams
- The head of product no longer has a grasp of what each team is working on
- There is a disconnect between team objectives and business strategy
Consider moving to a multi-function model and appointing product directors when:
- There are multiple products
- There are multiple markets
- There is a disconnect between tribe objectives and business strategy
Further considerations
How do I chop a product up across multiple teams?
There are a couple of common approaches here:
- By user 🙋 - if your product is a marketplace, one for buyers, and one for sellers
- By functional area 🗂 - if your product is an ecommerce site or app, one for registration, one for search, one for checkout
Having a well-crafted and up-to-date service blueprint or story map can help here.
How do I group teams up into tribes?
When you reach this point (probably at the five-team mark), a good question to ask is whether you can break up any of your existing teams into smaller teams. Who are your biggest, most overwhelmed teams? Can you break them down into multiple teams? Do any of them serve multiple users, look after multiple products, functional areas, or services?
When you come to group them, you can use the same criteria you used to split your product across teams to bring focus and alignment to your tribes:
- By user 🙋 - if your product is a delivery app, one tribe for sellers, one for deliverers, and one for customers
- By functional area 🗂 - if your product is an ecommerce site or app, one tribe could focus on the customer experience, another on the back-office experience
I would also recommend introducing some of the concepts from Team Topologies if you haven’t already - this is a good opportunity to identify any candidate platform teams that could focus on shared resources or tooling, and also to introduce the concept of Team APIs to help your teams work together.
Summary
The template laid out above provides a solid platform for how you can look to structure your initial product function and adapt as your organisation and products grow.
Whilst I’ve seen the above structures (or at least variations of them) prove successful at various organisations, I’ve never seen the same structure used in two different places - so I would encourage you to tailor them to suit your existing structure, products, and culture, as you see fit.
Most importantly, the key here is to accept that there is no silver bullet and that you fully expect this to evolve - something which should be front and centre of your comms plan.
