My view on “How to build great product teams?”

A few weeks ago I was having a discussion on the topic “building product teams”. The conversation focused on answering 7 key questions:

1. How does your (product) team look like?
2. What’s different in product teams vs. other teams?
3. What is your biggest challenge as a product leader?
4. Should the product manager be the team leader?
5. What do you look for in engineers or designers looking to become PMs?
6. How do you measure success of a product team? Is it product success?
7. What are the “hard things about hard things” in PM — what’s not sexy, but is crucial, in leading a PM team?

I’ve seen myself answering this often when I speak with product (and non-product) people. So here’s a dump of what I think. PS: I hope this post doesn’t age well, means I am learning more and more.

1. How does your (product) team look like?

In a nutshell, my teams have worked similarly to Spotify’s squads (read here, and here). The product team has also been within a larger group including engineering, design and data. Other teams within this group included platform and data engineering, data science, user research and quality assurance. A squad is an “end-to-end team” capable of delivering a working product. I prefer PMs to be all-rounded, able to side with designers and run customer interviews, write stories, manage the delivery, run retrospectives, understand the data, own P&L / performance metrics, etc. I generally don’t like the PM/PO role separation. One important thing: having a team with diverse backgrounds (eng, non-eng, designers, etc) helps shape squads with their own culture, bringing fresh learning opportunities.

2. What’s different in product teams vs. other teams?

1) Servant teams at their core

If we only had one goal it would be to accelerate others. In this context, “accelerating” means doing anything, independently of the nature of the task, in order to make everyone around us faster, better, stronger. This means embracing a “servant” mindset, discovering what your team needs over what you need.

2) 99% soft-skill based

While engineers build, designers design, product managers “find ways”. You need to convince others to do what you believe needs to be done. Your technical knowledge (aka hard skills) will matter significantly less compared with the power of your words. Look at “finding ways” as having an always-on pragmatic “how can this be done with 10x less, 10x faster, 10x easier” mindset. And then convincing others of it.

3) No one manages no one.

PM’s have the title “manager” but actually manage no one. They have the accountability without the authority. Their execution and performance depends more on their capacity to empower their team instead of themselves. Each member has their own manager, but they all answer to their metric, theme or goal, instead of a physical team leader.

3. What is your biggest challenge as a product leader?

Not on a specific order:

1. Hiring and retaining top talent while keeping the bar up and pushing people beyond what they believe (without breaking or burning).
2. Delivering on products and solutions on time, with the expected quality, within the defined scope. Product is a “triangle where you need to chose 2”, but where doing the three is what makes you win.
3. Managing priorities, managing stakeholders, managing communication, managing emotions. In the end, it’s all about people.
4. Measuring the right thing. Measuring things right. Measuring the team’s success. Making others understand why measurement matters and why it should drive decision.
5. Making sure the roadmap is aligned with company strategy, founder’s vision, board’s expectations and team’s desires (last one is the hardest one).
6. Empowering without losing control. Controlling without killing empowerment. Guidance over micromanagement.
7. Making sure everyone is aware of the urgency without abusing the “ASAP” acronym. Sometimes it happens.
8. Getting people to trust each other more. Creating psychological safety and a happy and challenging environment, without sacrificing competitiveness and aggressiveness.

4. Should the product manager be the team leader?

It depends, as different squads have different dynamics, requiring different structures. Generally in cross-functional squads team leaders don’t make decisions, they drive consensus. Decisions come from the whole team, not the team leader. This tends to be a massive breaking point for a lot of “teams” who end up being autocratically driven by a sole decision-maker.

But considering dynamics, if you have a strongly opinionated, confident and extrovert squad with outspoken members (developers, designers, PMs and analysts) then team leading tends to be a shared role. Whoever is the “face” of decisions can also vary. If you have a more introspective, less outspoken squad, then the PM tends to take team leading role and be the face of decisions. This a correlation with the normal PM profile (high energy, get-go person, storyteller) than an official position. Each team is different.

5. What do you look for in engineers or designers looking to become PMs?

I believe you fall into product. Nobody studies “product management” or gets a degree in PM and starts a career this way. I wrote about “falling into product” but to summarise:

1. People who kickass at their role, who are high performers, who get a kick from competing to win, who are knowledgeable in their area, and who others trust in their performance.
2. People who have a natural empathy the company, the industry, the product, the pains of the user without even realising it.
3. People who love problems over solutions, and who are curious about how they’re actually solved. Someone who asks a lot of questions.

6. How do you measure success of a product team? Is it product success?

Hardest question.

The majority of teams either 1) don’t track success OR 2) track success on shipping features. Both are wrong but the second is worse because you feel this done, in the first there’s still hope you get it right. Success measuring doesn’t end at shipping; it begins.

You can’t just measure product metrics as it doesn’t just depend on you (sales, marketing, finance, even what founders do influences metrics) but you also have to include them (as it means company success) so I split success measurement in two: the first is through something similar to what John Cutler’s wrote here. Check this spreadsheet. Theoretically, if everyone succeeds at the core actions, it outputs positive results for the user (therefore the product performance).

The second is through OKRs using product metrics. Each PM and respective squad should have ownership of their roadmap, they should be empowered to build “anything” (with some guidance) to reach the target. Their success is their KPI’s success.

7. Everything in PM is very “sexy”! What are the “hard things about hard things” — what’s not sexy, but crucial – in leading a PM team?

1. Realising you’re not here to do product but to accelerate those that do product. Focus where you add value and not on the “easy and urgent”.
2. That all PMs are different and adapting the product process to them instead of them to the process will yield better results.
3. Communication and providing visibility is ?your roadmap? and a big part of it is spreadsheets and slides. Might not be as fun as dealing with developers and designers, working on JIRA or running customer interviews but that is how you get buy-in for your team to do those very same things.
4. Measuring impact, defending your own team’s contribution to the bottom line and highlighting the wins while learning from the losses.

Also wrote about “hard things” of being a PM here, but here’s a summary:

1. Product is chaos, and it will always be chaos.
2. You will say no more often than yes, and people will not like you for that, so get used to it.
3. If you spend too long on the vision and not on building, you will lose trust.
4. Everything takes longer than expected. Much longer.
5. Silver bullets don’t exist, and the impact is (generally) much lower than your expectations.

Original here, check other stuff I write on albuquerque.io