Part 1: Establishing a Product Organization Structure
Creating digital products requires multiple people with different skill sets to cooperate in the discovery, design, development, operation, and distribution of the product. As a result, the larger the organization the greater the need for a more formal org structure - one that will clearly determine the “who” (who works together with whom), and processes to address the “how” (what are the steps to take in the work.
Processes: Let’s start with what not to do
Old IT-style hierarchical organizations in which managers make decisions and then delegate implementation tasks to subordinates won’t work super well in modern software product development, here is why:
Empowered cross-functional product teams
A good high level definition for such a team would be that a product team is an atomic product development team consisting of the various disciplines required to build or improve a product: typically a product manager, a designer (UX and UI), about 10 engineers and depending on the and its subject area, there might be other functions like data and user research, or specific subject matter such as agronomy in a digital agriculture setting – but not more than what fits in Amazon’s two pizza rule.
These teams are the key organizational unit in which product work gets done. There typically is no formal reporting line inside these teams, but that is not to say that there is no degree of leadership in the teams. Typically, these teams are led by a “triad” of product manager, designer, and lead engineer who work together and with the rest of the team to make decisions.
Beyond the “core” functions of a product team, there is often the question of how bordering functions should be integrated. For example, how should QA, user research, or infrastructure be integrated? What about product marketing or CRM? The answer of course is “It depends”. For example, having a dedicated QA person on each team can work quite well, but one user researcher might support two product teams.
How exactly the autonomy of the team manifests itself can vary between organizations and from team to team. It depends on the product, the culture, as well as the people on the team and their preferences. One guiding principle, though, is to assign the team problems or opportunities, not projects, and make the team responsible for delivering customer and business outcomes, not output in the form of delivering projects.
Building Product Teams
The first thing to think about is how permanent those teams are. There are a few models between the following extremes:
On the one hand, there is some value to have teams stay stable forever – while their objectives change over time.
After seeing the disasters created by the popular Spotify model and SaFE agile, I suggest to implement more stable teams. In order to avoid siloing, some degree of change to team composition every now and then should happen as well as cross-matrixing of function that can belong to several vertical teams at once (example UX and UI).
Let me know what you think!
DM me @philippemora on IG and Twitter
My name's phil mora and I blog about the things I love: fitness, hacking work, tech and anything holistic.
Head of Digital Product
thinker, doer, designer, coder, leader