“The best reason to start an organization is to make meaning; to create a product or service to make the world a better place.”
– Guy Kawasaki, VC and former Head of Evangelism at Apple
The last two weeks have been hectic. Therefore, this Weekend Reading had to be turned into a Halloween Reading. Based on my experience with (re-)organizing product organizations, the topic is scary enough to fit the occasion. In particular, when you try to change the setups of large industrial enterprises.
Many organizations that develop products are everything but designed for the purpose. More often than not they are technology silos or designed for efficiency. But it’s the product team structure that can make magic happen.
Here are my rules for creating product organizations.
Build from Your Strategy
In my slide decks for product strategy and OKR workshops, I always include a quote from Lewis Carroll’s Alice in Wonderland: “If you don’t know where you want to go, then it doesn’t matter which path you take.” In most companies, products are crucial for executing the company’s product strategy. Without a clear direction, you are in Alice’s shoes – your desired outcomes are unclear, and you might end up building anything. You may get lucky and solve a customer problem, but it’s more likely that you’ll only create more costs and frustration.
Don’t Put Technology First
It can be tempting to rely solely on technology to achieve your goals. However, technology should not be the sole focus of your strategy. While it may provide a unique selling proposition or cost advantage, it is often not the most crucial factor. Your strategy and desired outcomes should always come first, so thinking carefully before making technology the organization’s centerpiece is essential.
No Mercenaries
Outsourcing product development to agencies or other suppliers can be an expensive proposition. Such a practice makes it difficult to form coherent teams that share a common goal and develop a deep understanding of the users, customers, and their problem(s) to solve. Usually, you will get exactly what you specified and paid for, neither less nor more. Even though outsourcing may produce quicker results at the start of a product project, it can lead to a decline in speed and quality over time. This often creates openings for a more determined competitor with an „owned“ team. Therefore, it is better to invest resources in solving problems worth solving
Design for Team Longevity
If addressing a customer’s or user’s need has the potential to generate profit and is deemed worth investing in, establish a team that will support the product for as long as the need and the business opportunity exists. This team will develop close customer relationships and gain institutional knowledge that will facilitate faster innovation. Unlike project-based teams that disband after completing their work, a product team will invest in developing expertise in the subject matter and nurturing customer relationships to enhance the solution.
Structure for Customer Proximity
To ensure that your product organization can provide meaningful product outcomes and value to its customers, the organization must have direct access to them and potentially also users if they differ. Otherwise, the communication process can become like the children’s game „Telephone,“ where inaccuracies and misunderstandings accumulate. Product development becomes less effective and inefficient as communicative distance or abstraction of requirements from customers‘ and users‘ problems increases.
Facilitate Developers’ User and Customer Access
To suggest practical and innovative technological solutions and support continuous discovery, engineers need to get as close as possible to the users of the products they are developing. When we were developing navigation solutions a few years back, the most significant progress we made with rerouting around dense traffic was when we put our offshore engineers in traffic jams around Munich for hours on end.
Limit Dependencies
Limiting dependencies is one of the most complex problems to solve, as erring on either side of the solution spectrum can become extremely costly. Still, it is worth trying. After all, dependencies are the biggest killers of timely delivery. Mathematically, every dependency doubles the chances of not delivering in time. Creating a full-stack product or feature team relieves the problem. At the same time, such a „siloed“ organization may increase the requirements for the number of particular specialists while using them inefficiently. An optimal setup is, therefore, likely different for every organization.
Keep Teams as Small as Sensible
Studies have shown that the perfect team size should balance having more contributors and aligning them. According to this research the theoretical optimum team size lies between three and five people, depending on the task. In the words of Jeff Bezos, the ideal team should be small enough to be fed by only two pizzas. An effective team should also possess all the necessary skills to experiment, understand customer needs, and quickly deliver valuable software. A product team should be outcome-oriented rather than skill-based, taking on all responsibilities to support their customers.
Reduce Handovers
Handovers, e.g., from dev to test to ops, increase the risk of insufficient and ineffective communication. Think about how to minimize them. A well-designed infrastructure accessible through APIs plus supporting teams (stream-aligned teams in Team Topologies) is one of many options.
Consider „Product Trios“
It’s important to note that customers and users are usually different people with different needs, especially when it comes to non-consumer products. In this context, the „product trio“ organization, which involves designers, product managers, and engineers, makes even more sense. Designers bring empathy and understanding of user problems, product managers provide the overall business perspective, and engineers open the technological solution space. Effective product organizations, therefore, need to have these three bases covered regardless of how they are implemented.
There are many more factors to be considered. Today’s reads provide more details on product organization structures that can maximize impact and efficiency.
How To Structure Product Teams That Achieve Results
Product Dave lays out four common product team setups that achieve results in different types of contexts.
4 Effective Product Team Structures For 2023
Ravi Mehta details the two vectors that product teams need to be organized around: area of focus and level of accountability.