Product at Scale

Certain key prerequisites need to be in place to scale a product management organization successfully.

• Strong leadership and management
  The leadership team has defined and live their role role of management & leadership in the agile customer centric organization. Not less management is needed – just better, different.
• Clear vision, strategy and principles
  An organization bigger than 10 teams needs a clear vision, strategy and principles for orientation.
• Coordinated objectives
  The objectives within a team and the whole organization need to be aligned with the vision and strategy.
• Scalable architecture
  A scalable architecture follows a good / clear product vision. Technical debt is typically a result of growth – a system designed for 5m users can not stand 50m users. Time to rethink! Addressing Technical debt is in the accountability of the CTO and typically referred to as a business continuity issue. 20% of engineering capacity usually goes in Tech debt prevention / reparation. If the backlog is empty, switch to Tech debt removal work. Resolve Tech debt step by step – rewriting is typically the worst answer to this issue. It normally takes twice as long than anticipated. Technical debt killed Netscape and Friendster lost the battle to Facebook due to technical issues.
• Team structure
  The higher goal behind team structure is to create autonomous teams with minimized dependencies – make them work independently for maximum execution capabilities.
• Delivery managers
  Delivery managers identify impediments and remove them. They are a mixture of project managers and SCRUM Masters. Typically, Accenture is a great source of talent for Delivery managers.
• Constant evangelism
  Repeat, repeat, repeat. Constant repetition and sending the product management messages, beginning with the vision over the mission towards hypothesis driven and value orientated work processes, is critical to scale product – especially in big companies.

The role of Leadership

“The combination of curiosity, respect, and kindness combined with crazy work ethic will take you anywhere you want to go.”

Stacee Santi

Leaders in successful organizations are coaches. Their primary goal is to grow people, to support them in succeeding. Below listed are focus points of leadership roles within the product organization.

Product Leaders	‣ evangelism ‣ coaching
Design Leaders	‣ design language ‣ standards ‣ coaching
Engineering Leaders	‣ architecture ‣ standards ‣ coaching
Delivery Manager Leaders	‣ commitment ‣ dependencies
Data Leaders	‣ data tools ‣ common KPI language

At Spotify, any leader within the organization could deliver the coaching function. It’s every leaders’ goal to grow people. Marty mentioned that Christian Idiodi (https://www.linkedin.com/in/cidiodi/) is exceptionally good at growing product people.

Structuring Product Teams

The Product and Technology leads need to come up with an answer to the question on how to structure product teams. Should the organization have vertical teams focusing on specific business topics? Horizontally layered, with frontend, backend and data teams? A mix of both?

A typical setup includes vertical focus teams mixed with Common Services Teams (CST). The CST take special care of architectural topics, scalability and performance and they develop shared services. The PM role is typically more technical focussed and the customers are usually other product teams. Usually, there is no design role needed. Discovery happens in conjunction with other product teams.

The overarching goal of this structuring exercise is to create a setup with minimized dependencies to create fully autonomous teams. Here are some questions to ask during the process:

• How many product teams?
• What is the scope of each team?
• Dependencies between teams?
• Compatibility with architecture?
• What is the size of each team?
• What expertise is required for each?
• Level of autonomy of each?

Code ownership and dependencies

Setting up multiple teams with defined scopes raises another important question – who owns which part of the source code. Typically there are two models – a team owns their code (“request-model”) or the code is owned by everybody (“open-source model”). The request-model implies a higher degree of dependencies between teams needing to work cross-domain. If one team depends on changes done by another team the first team can no longer work fully autonomous. With the open-source model every team can change any part of the source code. This model needs higher standards when it comes to source code management and testing. Marty discusses this on his blog “Autonomy vs. Ownership”.

Amazon’s way to setting up teams

1. Set vision & goal
2. Define architecture
3. Form teams around architecture
4. Set clear accountability and ownership

This blog post is part of a series. It summarizes my personal notes of the workshop held by Marty Cagan “How to Create Tech Products Customers Love” from 5th to 6th of June in 2019 in San Francisco.

• #1 Foreword
• #2 Introduction & Root Causes of Product Failures
• #3 Key Terms & Concepts
• #4 Product Teams & Product People
• #5 Product Vision & Objectives
• #6 Product Analytics
• #7 Product at Scale
• #8 Product Development Process
• #9 Product Discovery Principles
• #10 Product Discovery Techniques
• #11 Product Culture & Transformation