High-performing teams consist of individuals who collaborate exceptionally well to achieve outstanding results. In my capacity as product manager (PM), I have been fortunate enough to lead such an elite team since June 2021. And in June 2023, I embraced the additional responsibility of a second team.

From the very beginning, I have been deeply committed to helping both teams succeed by leveraging my knowledge and expertise with tried and tested principles originating from Silicon Valley.

Reflecting on the past few years in my role, I am truly proud of the progress I have witnessed in both teams and the steps we have taken towards becoming more empowered. This journey has not only enhanced our collaboration and innovation but also boosted our overall productivity and morale. By becoming more empowered, we’ve been able to tackle challenges more effectively and achieve remarkable results for the greater good.

In this blog, I aim to share the key ingredients to our success and be transparent about the lessons we’ve learned throughout this ongoing journey. My hope is that anyone who engages with this content will find inspiration for their team in some way, shape, or form.

Throughout this blog, you’ll notice that I’ve drawn significant inspiration from the Silicon Valley Product Group (SVPG), particularly from its founder, Marty Cagan. The insights shared in his book, “Inspired,” have truly empowered me to become a better PM.

Instead of one long post, I’ll be breaking it down into four distinct sections. Each section will be published separately, but together they will form one comprehensive blog. Here’s what you can expect:

• Part l: Exploring the different types of teams
• Part ll: Key ingredients for building empowered product teams
• Part lll: Team insights and benefits of the empowered team model

Exploring the different types of teams

Before we proceed, it’s important to establish a mutual understanding of the key terms we’ll use throughout this blog. For guidance, we’ll refer to Scaled Agile Inc., a global organization dedicated to fostering agility in enterprises:

• Feature: Any service, functionality, etc. that fulfills a stakeholder need.
• Product Team: A cross-functional group responsible for defining, building, testing, and delivering increments of value. They must ensure that the product aligns with customer needs and business objectives.

In his book “Inspired”, Marty Cagan recognizes three different team types (refer to table below for an overview).

When I started working as a PM in my department, I noticed that most teams operated as feature teams, often referred to as “feature factories.” In this setup, the PM typically provides the team with a set list of features to build and corresponding priorities. Consequently, the team doing the actual work expects certain inputs and, in return, agrees to deliver specific outputs over a period of time. For example, a feature team might be tasked with building and releasing an API that can perform X, Y, and Z.

Delivery teams expect all of the above and even more, as they also want to be told how to deliver something. However, delivery and feature teams are purely focused on delivering outputs, which poses several risks, such as:

Misalignment with business goals

Outputs may not align with broader business objectives, leading to a disconnect between what is delivered and what the business needs.

Inefficiency and waste

Outputs often do not lead to meaningful outcomes, resulting in wasted resources on features that are not used or valued by customers.

Limited innovation

Teams may not question the underlying problems, stifling creativity and innovation.

Reduced team morale

Focusing solely on outputs can make teams feel like they are on a conveyor belt, reducing job satisfaction and engagement.

Risk of missing the mark

Outputs may not necessarily meet user needs, leading to market failure.

On the other end of the spectrum, we have empowered product teams. These teams only need strategic context (why something is important) and a clear list of problems to tackle (what they will be working on). With this information, they can self-organize and propose innovative solutions that often lead to positive outcomes for the organization. Instead of telling the team how to solve the problem, the PM trusts the team to determine the best possible approach, focusing only on the why and what aspects upfront.

Latching onto the earlier example of developing and releasing an API, an empowered product team would challenge the notion of ‘blindly’ building an API. Instead, they would rephrase the initial instruction to: ‘What problem is this API meant to solve? Is an API even the right solution for this problem?

The key difference between the team types is that in the delivery and feature team model, you will probably have a team of mercenaries, whereas in the empowered product team model, you will find a team of missionaries. Marty Cagan explains it as follows: “While mercenaries build whatever they are told, missionaries are true believers in the vision and are dedicated to solving customer problems.”

An empowered team model was my vision from the start, but I knew it would require a fundamental shift in thinking to make this new model work. In the next section, we will delve into some of the key ingredients for building empowered teams, as outlined by the Silicon Valley Product Group (SVPG).

I hope this post gave you some valuable insights! If you found it helpful or have any thoughts to share, please leave a comment below and let me know. Your feedback helps me create better content for you. Don’t forget to hit that like button if you enjoyed reading! 🚀