Introducing a product organization

  • 30 July 2021
  • 1 reply


I am currently leading a transformation where I am acting Product manager of an enterprise Cloud platform (Azure) that is developed by a dedicated platform team and it is used by internal dev.teams. In parallell to the ongoing development of this platform we are also aiming to introduce Product organisation practises and roles.

So - Are there anyone out there who would like to give your reflections around the Product organization ”theory” vs ”in practice”? What is crucial to start with and what roles and responsibilities are most important to you?

This topic is now closed for comments.

1 reply

Userlevel 7
Badge +9

@sarafranklin there are lots of perspectives on what a product team should look like and how it should be structured and scale over time.

Taking a problem focus, are there particular team dimensions you’re dealing with in theory vs. practice that are surfacing as problems?

Some thoughts:

  • At the baseline, a Product team is made up of a product manager, designer, and engineer. Ensuring you truly have Product teams is a great place to start (Cagan makes a great distinction between team types in this article)
  • Second, I’d suggest considering your career ladder and how people will progress through their roles and how your organization will evolve as you grow. Having clear tracks for individual contributors, leadership, and also the emergence of managers of managers (MOMs) and other supporting roles like product operations, product analysts, etc. Establishing this can also be a bit of a forcing function for how your organization is structured.
  • Third, there are lots of factors that also impact the theory vs. practice such as your team’s skill level and product knowledge, ability to adapt to change, etc.
  • Fourth, a lot of where things break down between theory and practice often show up in how a team is empowered to work. I’d give Empowered a read if you haven’t already
  • Lastly, executing through the above items will begin to highlight the theory vs. practice. What I like to do here is remain open to change and adjustments and let things be driven bottoms up rather than top-down. Documenting your org and processes as you grow is also hugely valuable.