Product Management Renaissance

New Structures for Product Growth and Product Centric Organizations

This article was first published in a shortened version at Mind The Product and is based on a talk at Product People Conference in Cologne in September 2023.

In a corporate realm, Sales and Marketing clashed in a communication crisis. Sales sold projects that didn't align with the product, which also didn't match Marketing's promises. Meanwhile, the product had potential but was lost in the chaos.

Internal discussions spiraled into chaos as managers pushed conflicting strategies. External customers grew skeptical as the brand's integrity wavered. Employee morale plummeted, and results stagnated.

This is a story that happens all the time and that many people in product management have already had to experience. Targeted product growth and joint action in closed ranks looks different.

In this article we will explore what a product-centric structure in a company can look like. By first taking a look at current rumors and trends, our focus will encompass various aspects, from product management to team dynamics and scaling agile. This will be followed by a concrete approach to structure Product Growth side by side with agile scaling. This is not blueprint to be established from one day to the other but a pattern, that might give direction. Cultural factors and mindset issues are not targeted. For that you might read Mindset over Framework.

While we won't delve too deeply into frameworks or the basics of collaboration, agile culture, roles, and functions, we aim to provide thought-provoking insights. This article is based on learnings that the author has gained in different environments.

Table of Content

1. Embracing Current Rumors and Trends

   • Airbnb killed Product Management

   • Demystifying the Product Growth Manager

   • The Rise of ProductOps

   • The Reality Behind Spotify’s Structure

   • Exploring Holacracy

   • A Framework for Scaled Agile

   • Other Agile Scaling Models

2. Bridging the Gaps in product Management

3. The Product Growth Team

   • How to scale that Approach

   • Considering Functional Cuts

   • Tackling the Matrix

   • Reality Check or How to Start

   • Homebrew

   • The Evolution of Product Management

   • Management-Part

4. Conclusion

Embracing Current Rumors and Trends

Let's kick off by acknowledging the recent trends and challenges that have emerged in the world of product management. We've witnessed debates surrounding the very essence of product management, but rather than dismissing these discussions, let's explore how they can lead us forward.

Airbnb killed Product Management

This year, this headline has been doing the rounds, and in general, one senses more and more frequently that product management as a discipline is being questioned. In my opinion, this is hardly due to the fact that the topic has become outdated, but rather to the sensitivities of those formerly responsible and the nervousness and clickbait rage of a few. But as we will see in the following lines, it pays to flee forward here.

Long story short: They didn’t kill Product Management, they simply combined it into Product Marketing.

See the CEOs statement on the topic.

Demystifying the Product Growth Manager

Enter the Product Growth Manager, a new role that has gained prominence in organizations where Product Managers face daily operational constraints or may not have the necessary skill set. This role has often been justified with flashy charts displaying exponential growth.

I can assure in such cases the problems lie elsewhere. If a PM can't take care of bringing the product forward, he/she is not doing well or he/she is working in the wrong structure.

The Rise of ProductOps

ProductOps, a term that can be somewhat misleading, is an area of interest that deserves our attention. It's not about layering product management into strategic, tactical, and operational segments. Instead, it's about bolstering decision-making processes by methodically integrating metrics, data, facts and insights into strategic and tactical decisions. While many Product Managers have done this implicitly, larger organizations can benefit from dedicated specialists in this field.

Good read on the topic is Melissa Perris book Product Operations.

The Reality Behind Spotify's Structure

Spotify, often hailed as a model for agile organizational structures, is not the one-size-fits-all solution for every company. Spotify's autonomy within squads and its seemingly flat hierarchy poses not only benefits but also problems. Also it’s legitimate to raise the provocative question: How agile is the Spotify environment, really?

I'm also a big fan of Spotify and I favor flat hierarchies, but making communication channels transparent is also essential!

Not every company is Spotify

- Somebody, somewhere -

Read e.g. this article on the topic.

Exploring Holacracy

Beyond the mainstream approaches, there is the holacracy-approach, which, though not the newest concept, still holds relevance in fostering self-management and scaling without fixed hierarchy.

Holacracy is an organizational approach that emphasizes self-management and distributed authority. In a holacratic structure, power is distributed among self-organized teams or "circles," each with defined roles and accountabilities. Decision-making occurs through structured, transparent processes called "governance meetings," allowing for adaptive and agile responses to changing circumstances.

Best source to dive into holacracy is the original book by Brian J. Robertson.

A Framework for Scaled Agile

We won't engage in SAFe-bashing, but let’s talk honestly about its flexibility and suitability for agile environments. My point of view can be summarized in a simple statement: “by the effort to implement this framework you can see how flexible it is and accordingly it behaves with its suitability for an agile environment”. This is why it might fit in a very regulated environment, where the need to scale on an enterprise and portfolio level is great. Within the agile trains, agility hereby is torpedoed by the planing approach and some other misinterpretations.

To dive deep into SAFe, just use the completely documented framework on their Website.

Other Agile Scaling Models

While Scrum@Scale and Nexus may not receive as much attention as they should, LeSS (Large Scale Scrum) offers comprehensive insights. The essence is always to ensure common goal orientation and increments with synchronous cadences and partly overlapping meetings.

It might be that they focus less on overarching organizational structures, but for scaling teams they are fitting much better into an agile mindset than SAFe!

Best reads are the following:

• Scrum@Scale Guide by Jeff Sutherland

• Nexus Guide by Scrum.org

• Book on Large Scale Scrum by Craig Larmann, Bas Vodde, Björn Jensen, Alexander Marquart

Bridging the Gaps in Product Management

Regardless of the ongoing debates, it is possible to identify six needs for innovation in those discussions.

1. The interface between product management, product marketing, and sales
   remains a vulnerable area in many organizations. The hope that transparency alone would resolve this issue was for sure not true! Sometimes it even comes down to a tussle over competencies!

2. Product management is now perceived more and this results in an understanding of Product Management as a discipline in the company that goes beyond a single role. But here is a chance to consult more and to maneuver the company much stronger into a value creation than through operative creation!

3. Product Management is not always the same. Be it that products are differing between industries or that the maturity levels are different, there is always a diversity of topics and thereby a subset of skills demanded. Many think they know a recipe for successful Product Management and this results in things like the Product Growth Manager as a role. But there is no blueprint , only a set of best practices.

4. Product Managers always have at least two structures in which they work, often more. But what determines what belongs together? And besides, it's not agile anyway, is it? Is the topic of cross-functionality the driving factor or an organizational structure based on common disciplines?

5. Is the product and accordingly the organization big enough that cross-functional decisions have to be made? Then you should scale on an enterprise level with business units. And this is not the same as scaling for a portfolio of similar products!

6. Scaling agile practices can be a daunting task, but a fundamental principle must remain: a willingness to embrace change at all levels. Transparency is vital, especially as organizations grow and evolve.

The Product Growth Team

What remains of the Growth Product Manager is the idea to move a product-centric organization to where it belongs: It is about the strategic, goal-oriented development and communication of a product. And to finally close the typical gaps between internal and external view and between the internal interfaces, the combination of the roles mainly working towards this common goal is crucial. Within these collaborative teams, a holistic understanding of the market, the customers and the products emerges. Diverse perspectives ensure a wealth of information flows seamlessly in and out.

The different roles PM, PO, Product Lead are not essential. It has more to do with the focus and skills of the employees and how the roles are defined internally. In such a team it is even possible to have mixed roles!

Let the team define the internal interfaces and cut down the tasks, etc. just like you do for any agile team you build up and coach: by a common target!

Combining Product Management, Product Operations, Product Marketing and optionally even UX/UI Design to form a cohesive Product Growth Team is a winning strategy for building a product-led company. The synergy created by integrating these functions fosters a deep understanding of customers, streamlines strategy execution, and drives user adoption and revenue growth.

What is achieved:

1. Holistic customer understanding - The different perspectives together ensure that broader information goes in and out as well.

2. Seamless strategy execution - Strategic product development and positioning under one responsibility.

3. Accelerated user adoption - Eliminates the need to communicate the most basic product information across team boundaries.

4. Less need for hierarchies that artificially maintain communication.

How to scale that approach

Is it possible to scale that approach in a scaling, agile environment? Long answer short: it fits well!

Agile Scaling and the described approach work together pretty well. While the typical scaling frameworks recommend a maximum of around 4 teams in one common Domain, this is also the amount of teams that you are able to cover with one Product Growth Team. As the tasks are a bit more independent, these Product Growth Teams can get relatively big, without losing traction. This way you also shift around the downside in many agile scaling frameworks that propagate a central Product Owner role to take on all agile development teams at the same time. You can simply split up that work within you PG-Team.

With that approach you are now able to scale Domains. In layers above that classical organizational structures like business units and enterprise scaling might fit better than cascading the principle of agile teams. But still: the mindset should stay the same. Stay lean, stay agile in mind!

Side Note: From here, Community of Practices (CoPs) may indeed become more relevant. However, aligning domains with autonomous products requires deliberate organizational design, demanding more proactive efforts.

Considering Functional Cuts

Deciding on the functional cut between the domains is no easy task. You are always on the edge between the maximum complexity of a single domain and the set of skills you need for that in each single team.

Here I’ll introduce you to the theoretically possible cuts to make:

• Vertical Domain by customer-oriented function
  Downside: who is working on the platform if needed?

• Onion Domain by cascading functions
  Downside: longer runtime of features because they have to wait for each other

• Technical Domain like platform and business application
  Downside: too many interdependencies

• Technology e.g. Frontend and Backend
  Downside: not value-oriented nor cross-functional

• Full Stack aka Feature-Teams
  Downside: a lot of knowledge and skills needed for each cross-functional team

It comes down to two approaches that are worth considering:

1. If the complexity of the domain or product allows it, build full stack teams and define some common areas with Communities of Practice and maybe some additional responsibilities within the teams.

2. If the single domains get to complex consider a vertical domain cut by customer-oriented functions. This way both teams are still able to deliver value to the customer. This is also the approach if you have to scale more and more after already building up multiple full-stack-teams.

In both cases Domain Driven Design helps a lot to work with the inter-dependencies that you will always build up between the teams and within your product components!

Tackling the Matrix

And now comes the matrix organization: executives from the perspective of technology, UX, product, etc. contradict your structure.

The typical problems that rise up by challenging the status quo:

• Communication gaps becomes obvious

• People become aware that different content and signals are spread into the organization.

• It becomes obvious that there is no common strategy

  • Example: The Architectural Runway from SAFe is one example of an additional strategy, that reduces the effect of common strategies.

So how to stop these bullets?

• Push communication at all levels!

• There should be only one Product Strategy and it should combine all that is needed to achieve a goal! So it should include UX/UI, technolgical standpoints, functional perspectives and so on.

• Find methods to push the mindset, like Role reversal in communication by Tobias Freudenreich.

Reality Check or How to Start

Incorporating change is never easy, especially in organizations where Product Management and Product Development are far removed from Marketing and Sales. We'll explore two approaches—Big Bang and gradual integration—and consider the potential pitfalls of both.

Big Bangs are uniquely costly, but they bring with them an opportunity: Change works best in the course of another change. However, this method clashes with day-to-day business at most and must be well prepared.

Step-by-step is more realistic for some, especially if there is less support from above, but unfortunately such measures tend to get stuck halfway!

What can be first and intermediate steps?

1. Bring these functions closer together, possibly in the same area?

2. Also disciplinary! Don't just form cross-functional teams or working groups in addition - they will always be subordinated in the minds of the participants.

3. Reward things that foster cooperation!

4. Talk to the people! Get a feeling for unofficial teams that have formed by themselves!

Homebrew

There's no one-size-fits-all framework for agile practices. Instead, these frameworks serve as foundations for targeted organizational design. Active organizational design is imperative, and nurturing in-house methodological competence is crucial.

Keep in mind:

• There is no way around active organizational design.

• Spice your own soup! Build up the methodological competence on the highest level in house! Although external coaches and consultant are very helpful, stop thinking that by spending money, everything will change by itself.

• Organizational design is also iterative. Use the same practices you use to build a product in an iterative manner. Just never give in.

The Evolution of Product Management

This brings us to the main changes for the role of a Product Manager.

1. Discipline instead of a role
   The role of the Product Manager was the first step toward product-centric organizations. The role should now also increasingly advise internally and align the organization with the product.

2. Team Performance
   Designing a product is becoming more of a team effort. Different characters increase the chance of making a product successful. Focal points in responsibilities remain, but everyone contributes to product centricity

3. Coaching
   It takes one person who can coach or advise the subject.

4. Leader instead of Manager
   This makes leadership much more important than pure administration.

Management-Part

While this organizational structure addresses many aspects, it doesn't answer all questions about working together, forming strategies, etc. Just to mention two essential methods that I like to combine in this context:

• OKRs and task management can be combined effectively, bridging the gap between qualitative goals, quantitative results, and concrete actions.

• Kanban flightlevels are a great way to start, because they pick up the organization and the employees where they are.

Conclusion

A successful transition to a product-centric organization involves recognizing the importance of holistic value creation, pattern scaling, and thoughtful design. By prioritizing culture and employee empowerment, organizations can navigate this transformation effectively and thrive in a rapidly evolving landscape. This article is about how this can be achieved on the basis of holacratic, cross-functional and scaling structures, away from the well-trodden paths of functionally oriented departmental structures.

Key Learning:

1. Bringing Together Value Contributors: Instead of merely focusing on what logically aligns, organizations should bring together all aspects that contribute to a product's success. This holistic approach ensures that all relevant elements are considered, enhancing product growth.

2. Product Growth Teams: Dedicated Product Growth Teams, specializing in product strategy and communication, are crucial for aligning the organization's efforts with its product-centric goals. These teams bridge the gap between internal and external perspectives. Also they take on all the development teams contributing to one domain.

3. Emphasis on Development Teams: The organization's structure should be built around development teams, with a focus on specific domains. This approach promotes specialization and efficiency within each team, ensuring they work cohesively toward their goals.

4. Organizational Design over Blind Framework Adoption: Rather than blindly adopting frameworks, organizations should prioritize designing their structures based on their unique needs and goals. Frameworks can be useful, but they should be tailored to fit the organization's specific context, especially outside of single teams: the higher the abstraction the more a specific design is needed.

5. Scaling According to Patterns: Successful scaling involves recognizing and replicating effective patterns. By identifying patterns within development teams, product growth teams and business units, organizations can efficiently expand their operations while maintaining consistency.

6. Cultural Emphasis over Process: Cultivating the right organizational culture should take precedence over rigid processes. A culture that values collaboration, innovation, and adaptability is essential for success in a product-centric approach.

Prioritizing Employees over Tools: While tools play a role in enabling efficiency, the primary focus should always be on empowering and supporting employees. Invest in employee development and well-being to unlock their full potential within the organization.

Stay Brave! and Subscribe ;-)