New structures for product growth and product-centric organizations

Hans-Jörg Roser, Head of Product Management at H&F Solutions GmbH discusses challenges in corporate communication between Sales and Marketing, explores trends in product management, and advocates for a product-centric organizational structure, emphasizing agile scaling and holistic approaches to foster successful transitions and employee empowerment.

12 min read
Share on

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 structuring product growth side by side with agile scaling.

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.

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.

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 you that 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 product ops

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.

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 –

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 a 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.

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 planning approach and some other misinterpretations.

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!

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 daunting, 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 (product manager, product owner, and 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.

A screenshot of a computer screen Description automatically generated

 

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 your 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.

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 arise by challenging the status quo:

  • Communication gaps become 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, technological standpoints, functional perspectives and so on.
  • Find methods to push the mindset, like Role reversal in communication by Tobias Freudenreich.

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 consultants 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.

Conclusion

A successful transition to a product-centric organization involves recognizing the importance of holistic value creation, pattern scaling, and thoughtful design. Organizations can navigate this transformation effectively and thrive in a rapidly evolving landscape by prioritising culture and employee empowerment.

Key learnings:

  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. Organizations can efficiently expand their operations while maintaining consistency by identifying patterns within development teams, product growth teams, and business units.
  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.
  7. 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!