product organization structures part 1

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: 

• Motivation: product design and development is a highly creative process, product teams can’t just follow procedures, check boxes and create amazing product experiences – they need to be incentivized to do a great job and produce outstanding results. One of the best ways to help foster this drive is to give them autonomy, mastery and purpose. In other words, product teams will do their best work when leadership give them the “why”, have the freedom to decide the “what” and they receive support to grow in the “how”. Team autonomy also generates shorter feedback loops – as autonomous teams react faster to new information from the customer, the market or technology. No need for information to travel up the management chain for a decision and then back down for implementation. 

 
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. 
 

• Stable teams allow people to build deep relationships and teams to iterate on their way of working, making them more effective over time. But the danger is that this can lead to siloing of knowledge and deviating cultures. It can also have an “everything is a nail” effect: a team gets great at a certain way of working and solving problems and will start applying that way of working to all problems, regardless of whether it is the most appropriate way.

 

• And on the other hand, product teams can be spun up to address emerging opportunities and disbanded once the objective has been achieved. This type of config allows for higher flexibility and matching emerging opportunities with the best talent available in the organization. On the other hand, having to build new relationships with team mates frequently can be stressful for team members and lead to friction, reducing effectiveness.

 
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