Panash x SVPG: lessons learned from spending 3 days with Marty Cagan & co. Part 1.

This article is part of a series of 3 articles dedicated to the SVPG application-only event which took place in London in May 2022.

As part of SVPG's Coaching the Coaches initiative, we were invited to join Marty Cagan and 3 of his SVPG Partners in London for 3 intense, insightful and inspirational days in late May 2022.

This first article sets the context of the London SVPG session and sums up some of my learnings and key takeaways, with a focus on what differentiates the best product teams from the rest.

La crème de la crème

First, let me say how inspiring it was, not only to be with the godfather of Product Management for 3 days, but also the entire EU Product mafia.
This being an application-only event, we were with the top 50 product coaches from Europe, and that in itself was incredible.

We were coaches from 18 countries, specialised in agile, product, discovery and leadership coaching. Half of the attendees were from UK, Sweden and Germany, the leading tech hubs in Europe.

The role of coaching

It is Marty's view that if you're a manager of Product Managers, you should be spending 80% of your time in coaching your team members. This was quite comforting to hear as we've been trying to get product leaders to understand that the bulk of their role is to elevate the level of the product organisation through coaching. This has been a driver in the work we do at Panash.

Below is only a sample of topics we've addressed and which resonated based on my own experience.

Confusing product concepts

Empowerment vs. Autonomy
Empowerment is about giving teams a problem to solve and giving them the space to figure out how best to solve that problem.
Autonomy means the team has everything they need to deliver the change which will address the identified problem.
The best product companies feature both dimensions.

Problem vs. Solution Discovery
For people to switch to your product, you want to make your solution x10 better than alternatives. This means most of the team's time has to be spent on solution discovery. Your CEO's patience has limits.
I've seen this happen many times: teams get too comfortable in the discovery process, falling in love with user interviews (entertainment factor) and forgetting to show how the activities they're conducting will impact business outcomes.

Product strategy vs. Prioritisation
Prioritisation is a symptom of a lack of strategy.
Prioritisation should be data-driven.

Team objectives vs. Product Roadmaps
Roadmaps are not fundamentally evil. They lock you in a corner.
In fact, an HBR study shows that 80% of initiatives on roadmaps do not deliver value.
An alternative to traditional roadmaps are outcome-based roadmaps. These are typically informed by problem discovery. In outcome-based roadmaps, we use the term "feature candidate". This qualifier is a great reflection of the outcome-centricity (vs. outputs).

Common PM misconceptions

PM to "make the tough calls"
This is not how it works. A product team is a flat structure.
Forget the "product manager is the mini-CEO of their product". The reality should be much more ego-free, collaborative and cross-functional.
I recently spoke to a company where PMs are line-managers of everyone in their squad i.e. designers, developers, QA engineers, etc. It is so obvious how this alienated relationships between product team members, creates unnecessary friction and is counter-productive in the team's capacity to grow and deliver value for their business.

PM to "Set vision and strategy"
Vision and strategy are the product leader's job.
PMs are responsible for the Discovery strategy.
Take a company with 50 highly-autonomous teams, saying PMs set vision and strategy would mean there would be 50 product visions and strategies across the product organisation and that doesn't make any sense.

PM not sufficiently worried about tech debt
Engineers should not be asking permission to tackle tech debt.
Engineers eventually get fired if tech debt is not tackled.
This a simple accountability situation. Engineers are among the smartest people in the product organisation, they know where to focus and when certain challenges need to be tackled.

Up next

In Part 2 of this series, I'll take a look at the learnings from the Product Leadership perspective (vision, strategy, management, staffing, etc.).