Along with determining the product strategy and putting in place effective processes for execution, building the product organisation and fostering a high impact culture is a core responsibility of a product leader. Basically, this comes down to three main activities:
- Size and structure – designing the overall shape of the organisation you need
- Team dynamics – making sure there are clear expectations about what people should do, and teams function effectively
- Staffing – filling the roles identified in the org design with the best possible people through hiring and coaching
Size and structure
Product organisations are created from cross-functional squads of PMs, engineers and other specialists. These can be grouped into tribes, which can in turn be grouped themselves into larger divisions and so on to create an organisation of almost any size. Here we’ll discuss what a squad, a tribe and the overall product organisation should look like.
Individual squads
Typical cross-functional product squad Squads vary depending on their objectives, tech stack and culture, but it’s still possible to give a sense of what a typical squad looks like in a product-led organisation. Squads are generally 6-10 people, with a mix of specialists creating a cross-functional unit. Some core disciplines are present in almost every team:
- Product Manager – Leads on strategy, prioritisation and communication within team and to wider organisation.
- Tech Lead – Leads on the technical approach, and often delivery velocity and quality.
- Engineers – (x2-6) Solve users problems with code. Often split by the platform they are working on (front end / back end / mobile / data).
- Product Designer (UX/UI) – Present in squads shipping user facing features. Qualitatively understands user needs and designs solutions.
When product organisations are small, it’s natural for the individuals within them to be fairly generalist in their skillset, so the org can maintain flexibility and responsiveness. As orgs grow, then specialists are brought in to provide additional expertise. The expectations of individuals should therefore be calibrated to how the org is staffed, as a PM at a startup will likely have a much broader remit including user research, data analysis, product marketing and so on, compared to a peer at a larger organisation. Common specialists as a company grows include:
- Data Analyst – Ideally at least x1 per team, but this role is often covered by the PM in smaller startups. Quantitatively understands user needs and designs solutions.
- UX Researchers – Specialising in speaking to users and understanding their fundamental needs and challenges. Typically 1 for every ~4-5 designers.
- Data Scientists – Conduct advanced quantitative analysis, and build algorithms to deliver highly predictive experiences (e.g. personalisation).
- Content Designers – specialising in writing copy that helps users enjoy the full value of a product.
- Product Marketing Managers – specialising in executing successful feature and product launch plans, and driving their adoption by users.
- Delivery Manager – Less common in startups, and more common in larger orgs which often need to coordinate multiple teams. Coordinates engineers and leads on velocity and quality.
- Quality Assurance – Becoming rarer, but still common in mobile teams. Test the quality of the solutions being built by the team.
Overall, a squad should be an autonomous unit of delivery. That means it should have a sense of purpose (a mission), a strategy for how to deliver against this mission, and metrics that measure its progress towards its goal. All this can be documented in a Squad Overview, to keep everyone aligned and make it easy for stakeholders and new joiners to understand what a squad is up to. Dependencies on other squads should be minimised, so it can act as independently as possible to achieve its goals.
Size wise, as we mentioned, squads are typically 6-10 people. You want enough people for the squad to be able to make meaningful progress against its goals, and then as few people as possible to reduce communication overheads. A few other ground rules for setting up a squad for success include:
- Clear roles & responsibilities – within the squad it must be clear who does what.
- Regular check-ins – a core pillar of execution, the team should report on progress regularly (often weekly) to make sure it stays accountable and focused on impact.
- Clear domain – it should be clear which team is responsible for which parts of the code base and which user facing screens. This makes it obvious who is handling necessary maintenance and bug fixes.
- Manageable operational load – if the squad is constantly fixing bugs and responding to ad hoc requests, it won’t be able to make progress on planned (strategic) work. The squad’s domain needs to be defined in such a way to keep this a low percentage (<20%) of overall effort.
- Specialist skills – squads that are focusing on a specialist area such as search or SEO need to have people who know the area to make the best progress. This can be achieved by hiring people who have worked on similar problems before, or using external advisors to get the squad up to speed quickly.
Tribe Structure
Squads can be grouped into a tribe Once you have more than 4-6 squads, you need to create an intermediate layer of product organisation, otherwise it’s very difficult for leaders to coordinate between the squads. Tribes group together squads with similar goals for this reason. As well as having dedicated representatives from the core disciplines (product, engineering, design), they should have leaders from other major functions, even if these individuals are also individual contributors, or cover multiple tribes. The purpose is to ensure it’s clear who can help with any given problem the teams come across, providing coaching and support as necessary.
Some guidelines for forming effective tribes:
- Conway’s Law – tribes should be formed conscious of Conway’s law: organisations design systems that mirror their own structure. So your technical architecture will inevitably mirror your tribe structure.
- Tribe Leadership – this should be the smallest possible group, where each discipline is represented. Some individuals may represent multiple disciplines (e.g. product and design both represented by Group PM).
- Number of reports – Most tribe leaders won’t be able to be effective beyond 4-6 squads / direct reports if they are providing technical support as well as line management. If these are split (as often is the case in engineering), then the number of direct reports will be larger (perhaps 8-10 per line manager)
- Accountability – tribe leaders are accountable for the overall performance of all their squads, and should be empowered to make changes (staffing, process, strategy) to achieve their overall objectives.
- In-filling – tribe leaders are responsible for back-filling vacancies, and covering them on an interim basis if holes in the org are left by people leaving – or reconfiguring the tribe to function effectively with reduced headcount.
- Support functions – some functions (e.g. UX) can cover a tribe rather than be assigned to individual squads
- Seniority – each tribe should include individual contributors with a range of seniority across the squads to allow for progression.
Product organisation structure
Product org made of several tribes Whilst a small start up might have a single tribe or even 1-2 squads, for larger product organisations, the tribe leadership will report into VPs who run the overall product organisation. With each tribe holding 40-60 people, this structure will scale to several hundred members without further layers of organisation, though of course the same principles can be extended to grow even larger product organisations.
Some thoughts on making a product organisation of this scale function effectively:
- Accountability – As at other levels, roles and responsibilities need to be clear, and accountability will usually sit with either a single person, or be split between product and engineering.
- Support disciplines – the top person in other disciplines (design, data, UX, etc.) will then report into either product or engineering.
- Belonging – regular meetings (e.g. at least quarterly) across the whole org maintain a sense of a single org, with a common purpose. These can serve other functions at the same time, such as reviewing the product strategy, answering questions (e.g. Ask Me Anything session) or celebrating outcomes (e.g. Demo sessions)
- Reporting – org leaders will need some reporting to understand what is going on within an org this size, and be accountable for the work going on. This reporting should be as lightweight as possible, whilst still giving them a regular snapshot overview of the entire org, and highlighting where they need to dive deeper.
- Escalation – most tactical issues should be resolved at the tribe level, with org leadership focused on coaching the tribe leaders, and only diving deeper when necessary.
Sizing the product organisation
Building a product management organisation is an investment by the company in creating software that generates value for users and the business. The size and shape of the product organisation should maximise the returns of this investment. Whilst there’s no single right answer right, whichever approach you choose should be well reasoned and coherent, bearing in mind the following aspects:
- What time frame are you making the investment?
- What is your risk tolerance? How much do you want to bet on growth?
- How much could you grow/reduce the product organisation and it remain effective?
- How fast can you grow/shrink the product organisation whilst it remains effective?
- Which parts of the customer journey create strategic value and should be kept in house? Which parts are commoditised, and would be better outsourced to partners or 3rd parties?
- How do you want to allocate investment to product-market fit (increasing value per user), growth (increasing number of users and lifetime value of users) and scalability (ability to serve more users / ship faster in future)?
Team dynamics
With the size and shape of the organisation set, you want to make the product organisation as impactful as possible. As a product leader, this requires tight collaboration with your peers in engineering, design and data. No single discipline within the product-engineering organisation can be effective without the support of the others, and it’s critical to speak with one voice to the rest of the company. Smooth collaboration between disciplines rests on having clear roles and responsibilities for each discipline, as well as agreement on the degrees of delegation allowed for various decisions. It’s worth agreeing these things explicitly and documenting the results to flush out any areas of contention.
Roles and responsibilities
The responsibilities of people with the same title varies significantly between product organisations. It’s therefore a good idea to have a consistent set of expectations of what a role entails across an org as it grows. This makes it clear what different disciplines should expect from each other, allows people to be moved around with minimal disruption, and hiring to become more consistent. If teams are frequently arguing about who does what, the reason is typically a difference in what they think their job is, and what their peers think their job is.
Documenting roles and responsibilities does not need to take huge amounts of time or effort. Typically 6-12 bullet points will describe the main responsibilities of a discipline, with attention paid to areas of potential overlap. This can be thrashed out by discipline leaders in a couple of hours, before being shared with the wider team for feedback and to reset behaviour.
Example role & responsibilities matrix using RACI - Make it explicit – make the roles and responsibilities explicit, especially in larger product organisations, to prevent friction between disciplines.
- Co-create it – this should be an agreement between disciplines, based on feedback from all levels, not a perspective handed out by someone central.
- Be flexible – in large product organisations, it’s fine for some squads to do things slightly differently, if that works for them. People over process – roles and responsibilities should be a baseline, not a straightjacket.
Degrees of delegation
Building on roles and responsibilities, discussing degrees of delegation can help facilitate peer-to-peer and manager-to-report relationships. This acknowledges that the boundaries between individuals’ responsibilities are rarely binary, and facilitates a conversation around the degree to which they are expecting to collaborate or act independently. This can either be done with a RACI format, or a numbered grading system.
RACI:
- Responsible – The (one or more) people doing the work
- Accountable – The single person who owns this activity
- Consulted – People asked for input before action is taken
- Informed – People told about action taken
Delegation scale:
- Tell – I will act without input from or informing others
- Sell – I will inform you of my actions
- Consult – I will consult with you before I act
- Agree – We will discuss and act together
- Advise – You will act after consulting with me
- Inquire – You will inform me of your actions
- Delegate – You will act and have no obligation to inform me
Create a FREE account to access the to the roles and responsibilities templates
Get the roles and responsibilities template (RACI / Degrees of delegation): Google Sheets
Staffing
Product leaders need to fill out the product organisation they have designed by hiring, retaining and developing the individuals reporting into them. Key to finding and keeping the best people for the organisation is developing your Employee Value Proposition – the benefits on offer to people who work for the company.
Employee Value Proposition
Understanding what the company offers, and how to communicate this effectively to candidates and employees is a huge lever for leaders to hire and motivate people. Whilst people have lots of different motivations, some benefits tend to be more effective than others:
- Mission – people want to do meaningful work. If you can articulate how the world needs to change, and that it won’t change without the work you are doing, you create an incredibly powerful reason for people to join you.
- Salary – this directly affects the quality of life people can have, and so naturally is highly valued by most people. It’s also a very clear measure of how valued people are, and so motivating beyond its purely functional value.
- Team culture – people want to work with others who are kind, competent and treat them with respect. This is difficult to quantify, but spreads through word of mouth and via sites like Glassdoor.
- Career development – people enjoy the challenge and reward of overcoming new problems and developing new skills. This will likely increase their earning potential long term as well. Included here is the CV-enhancing quality of working for a company with a strong brand for excellence.
- Stability – too much change prevents people from doing effective work, and erodes their sense of fulfilling their potential. Too little change leaves little room for learning and fresh challenges, making work boring. The best organisations are dynamic, with care taken to communicate and manage change well.
- Working conditions – this covers working hours, location (remote / hybrid / office), office quality and so on. People spend a lot of their waking time working, and want to do this in nice conditions.
- Ancillary benefits – gym memberships, pension contributions and other ancillary benefits rarely have a noticeable impact on being able to hire and retain people, as the impact is so small compared to the other factors above.
Hiring
An effective hiring process allows managers to fill gaps in a product organisation with high quality people in a short period of time. Exactly how good, and how fast will depend on the employee value proposition.
Speed to hire, quality of hire, and strength of employee value proposition all interrelated Hiring plan
As recruiters will remind you whenever given the opportunity, it’s always a good idea to have a hiring plan before jumping into the hiring process. Without one, it’s easy for the process to drag on as stakeholders realise they are looking for different profiles, or an impossible mix of capabilities and experience. A good hiring plan will cover:
- Expected competencies – what are you looking for in candidates
- Reference profiles – what does this look like in practice
- Interview process – how you will assess candidates on these competencies
A good format for creating a concise picture of who you are hiring for is to think across four aspects:
- Experience – what has this person done before in previous roles?
- Motivation – what intrinsic motivation would fit this role well?
- Soft skills – what are the behaviours and ways of communication you are looking for?
- Technical skills – what are the learned skills that this person needs?
By ensuring that you have at least one requirement in each category, and no more than 10 overall, you make sure you are taking a balanced approach to finding someone, without looking for an unrealistic combination of traits.
Hustle Badger hiring plan template Template for a hiring plan for product managers
Job description
Whilst the hiring plan is internally facing, the job description is externally facing. This is an advert to attract high potential candidates into applying for the role. The job description should sell employee value proposition, whilst setting accurate expectations to reduce the chances of candidates dropping out of the funnel later on, or bouncing out of the product organisation after they’ve been hired.
Typically job descriptions will include details of:
- The company as a whole
- The team the person will sit in
- What the role will entail day-to-day
- What you expect the profile of the successful candidate to look like
- The working environment (e.g. remote vs. in office) and benefits on offer
To make this as effective as possible:
- Be aware of bias – the language used in job descriptions can unconsciously code for men or women, so it’s worth using an online tool (e.g. here) to check for this.
- Sell the opportunity – stress the benefits of getting this role. You want to attract the best applicants possible.
- Be realistic – successful hiring is when you hire someone effective in the role, not someone who looks great on paper. Be open about things that you know will put off some candidates, to save yourself time in the long run.
Interview process
Your interview process should help you select candidates that will be successful in the role you are hiring for as efficiently as possible. If you are screening for the ~10 aspects that you identified ideal candidates should have in the hiring plan, this will take ~2-4 rounds of interviews:
- HR screening call (salary expectations, notice period, working environment)
- Phone interview (metrics, competencies, experience)
- Working session (case study, whiteboard session, meet the team)
Example interview plan When planning the interview process, think about the amount of investment required by each side (you and the candidate), as well as the success rate that candidates pass that interview stage. Ideally, you sequence interviews with low time investment and high fail rate up front, so that you only invest time through multiple interviews with candidates that have a high chance of getting hired.
If you are hiring a lot of people through the same process, you can optimise it the same way you would optimise any user funnel: look at the conversion rate from step to step, and gather qualitative feedback on the candidate experience throughout the journey. As you get more sophisticated about hiring, you will want to standardise the question set, and calibrate interviewers against each other to remove as much bias as possible from the process.
Create a FREE account to access the interview guide template
Get the interview guide template: Google Sheets
Onboarding process
Once you have made a hire, it’s important to onboard the candidate correctly, to help them get up to speed as quickly as possible, and reduce the chances of them bouncing out of the organisation. There are some great initiatives you can do to maximise their chances of accepting the offer, and build excitement as they get closer to their joining date:
- Get the hiring manager to call the candidate and make offer personally
- Get their new team to send welcome emails and introduce themselves
- Invite the candidate into office or for a team lunch to get to know people before starting
- Send them some swag to feel part of the team and product organisation in particular
- Buy them books that have had a big influence on team culture
A solid onboarding plan will also help the process of starting at a new role go smoothly. You might consider including:
- Welcome note from manager
- Prioritised list of people to meet
- Articles giving context on the industry and company
- Current strategy and critical insights
- Explanation of product development process at your particular organisation
- Outline team dynamics, performance management + other HR processes
- Links to internal tools and systems (HR as well as product)
- Guidance on Slack channels, email groups and standing meetings to join
- 15/30/60/90 day plan, including check lists of things to do in first few days
Create a FREE account to access the onboarding guide template
Get the onboarding guide template: Google Docs
Performance management
Employee – employer relationships must always balance the needs of both sides. Employers have a job that needs doing – that’s why they hired someone into the role. And employees want to get paid, learn, and do meaningful work. The more these needs are aligned, the happier both sides will be with the relationship, and the more productive the employee is likely to be. Performance management is therefore about helping people fulfil their potential, and make sure the company gets as much value from them as possible.
An effective performance management culture typically involves:
- Context – understanding each of your direct report’s personal circumstances and motivations.
- Career ladder – a standardised way of measuring and rewarding performance.
- Feedback – giving people feedback on how they are doing should be done both ad-hoc, and with a longer time frame in mind.
Context
People only act on feedback that serves their own interests, so as a manager you want to understand your reports’ context and motivations as well as possible. The sweet spot is when you can give feedback that serves their own development goals, as well as improves their performance in-role. It’s worth taking some time when you start managing someone to develop this understanding before diving into the day-to-day, and can do this by asking questions like:
- What brought you here [to this role / company]?
- When have you enjoyed your work the most? When did you feel your performance was best?
- Do you know where you would like to be in 3-5 years? (ok, if not!)
- If you couldn’t progress to be a VP Product / CPO, what would you want to aim for instead?
- What are you hoping to get out of your current role?
- What do you feel your superpowers are?
- Where would you like to develop your skills?
- If you couldn’t be a product manager, what would you do instead?
- What personal commitments do you have? What is important for you to feel like you have a healthy work/life balance?
Career ladder
Career ladders are useful for setting expectations with your team – i.e. what the company wants out of people in different roles. This understanding can facilitate performance discussions and make promotion decisions seem fairer, as long as you recognise this is only one side of the employee-employer relationship.
The best way to create a career ladder is together with your team, to generate buy-in to the structure and content, make sure it’s written in terms everyone can understand. Career ladders do not need to be super detailed, which can make them hard to digest, but often benefit from examples of expected behaviours at different levels.
As with other bits of process, the measure of effectiveness is the outcome, not the output. A good career ladder will make it clear to people where the company would like to see their skills develop before considering a promotion or pay rise. Career ladders also help make it clear why people have the titles they do (e.g. mid vs. senior PM), and justify promotion decisions.
Create a FREE account to access the career ladder template and example
Get the career ladder template: Google Sheets
Feedback
High performance product organisations are invariably high feedback organisations, where it’s normal for people to give each other direct feedback on how they are performing against each other’s expectations, and how they can improve going forward. For feedback to land effectively it needs to be based on objective facts and not opinions, and people often structure their feedback to facilitate this:
- Situation – talk about specific situations, rather than generalising traits people show, to keep the conversations more objective and less personal.
- Behaviour – describe what the person did. This should establish a fact base that both the person giving and receiving feedback can agree on.
- Impact – talk about the effect this behaviour had on you personally. Avoid speculating what impact it had on others.
- Next steps – discuss how a similar situation could be handled differently the next time it arises.
The best feedback is given straight away while the experience is fresh, but it can also be useful to have deeper performance conversations on a quarterly or annual basis. These create time to review where the person wants to develop, and how they are performing overall. Some people like to create development goals off the back of these sorts of conversations, and they can be very effective when driven by the individual. However, going through the motions because this is mandated by HR without the buy-in of the individual concerned is a waste of time.
Some things to think about when doing these longer, scheduled performance reviews:
- Morale – check in on how they are feeling about their job. Assess whether you think they are at risk of churn, and what you could do to mitigate this.
- Context dependent – review what you understand their context is, and want to get out of their current role. This will allow you to frame feedback in ways they will be receptive to.
- Outcome focused – look at outcomes they have driven as the primary indicator of their success. Give them an honest review of how they are doing compared to your expectations. No one benefits from you avoiding hard conversations.
- Whole cycle – remind yourself what they have achieved over the whole cycle, not just what is front of mind from the past few weeks.
- Radical Candour – the best check ins are both honest and compassionate. Try not to make these meetings any more formal than they need to be, and talk as real humans.
- Individual driven – let the individual set their own development goals, and as a manager focus on coaching them to achieve their full potential. There is a much higher chance of them hitting their goals if they set them themselves.
Summary
Defining, building and maintaining a high performance team is a core responsibility of a product leader. Their product organisation needs to be sized and shaped to deliver on the strategy, and the effectiveness of the organisation can be maximised by nurturing healthy team dynamics and ensuring the most suitable people are hired, developed and retained.
Hustle Badger Templates
Create a FREE account to access the following templates:
* Interview guide template: Google Sheets
* Onboarding guide template: Google Docs
* Career ladder template: Google Sheets
* Roles and responsibilities template (RACI / Degrees of delegation): Google Sheets
Further reading
FAQ
How big should my product org be?
There is no simple answer to this. You need to consider how many people, with which skills, are necessary to deliver on your strategy. This will also depend on how fast you want to go, how much you can invest, the amount of risk you are prepared to take. Your product team also needs to stay in proportion to engineering and other disciplines to be an effective investment.
How do I hire great PMs?
To hire great PMs, it’s important to develop a strong employee value proposition, and then have a robust hiring process that articulates what skills and experience you are looking for, and then test candidates for these effectively and efficiently.
How can I retain my best PMs?
Most people are motivated by a combination of doing meaningful work, getting paid a fair salary, being challenged and learning new things, and working in conditions that are pleasant and compatible to their personal lives. Understanding what in particular is important to your best PMs will allow you to frame the benefits you can offer in their terms, and maximise their chances of staying.
How do I work effectively with design and engineering?
As a product leader, your team is not the PMs you manage, but the peers you have in other disciplines. It’s critical that you use tools like roles & responsibilities, and degrees of delegation so that you can be completely aligned on strategy and the direction you are giving both the squads you cover, but also the rest of the business.
