How teams are organized will influences your product more than you might realize.
Why organizations matter. Why you should understand. How do you influence organization structure as an individual PM?
Most of my writing on product management is pragmatic. By creating templates and giving advice, I hope to help individual product managers deliver results. However, we must all acknowledge that there are certain factors outside of our control, which will influence the design of our product, its chances of success, and our career. Today, I’m discussing the structure of product teams and how that influences products and PMs.
In 1968, Melvin Conway published an article with the thesis:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
Conway’s observation is simple. People design products. A bunch of people working together makes up an organization. The way people are organized determines how people will communicate with each other (i.e., communication structure). Conway says this communication structure will show up in the product’s design. In other words, software products are architected so that it resembles “the structure of the organization which designed it”.
How does “Conway’s thesis” affect your product and your product career?
Whether you work at a startup or a large company, how your company organizes people will heavily influence what and how you build your product. These “divisions of ownership and responsibilities” matter, even though when division occurs, most focus on the people, then the work, and rarely do we acknowledge the impact on the product through changes in our communication path.
How organizational divisions impact the product is best understood by examining the components or what Conway calls, “subsystems.” As he writes:
… an airplane [product], for example. may possess subsystems for structure, propulsion, power distribution, communication, and payload packaging. The propulsion subsystem has fuel, ignition, and starting subsystems, to name a few.
While it’s easy to understand the concept of product components, deciding how to componentize a product is another matter. I’ve seen products be broken by:
User: Customer-facing vs internal-facing
Technology: Front-end vs back-end
Product development process: Discovery vs delivery
User task process: Step 1, Step 2, Step 3
Metric: Awareness, Activation, Engagement, Retention, Referral, Revenue
If some of these look familiar, it’s because a product manager has likely been assigned to manage a “component” of a product. For example, you might be a product manager who is responsible for a customer-facing application (e.g., ticketing system) and primarily work with front-end engineers on improving UI experiences to improve activation (i.e., onboarding). You’re managing a small component in the overall product.
Principles for creating good product component
Unfortunately, I haven’t come across articles that specifically discuss what are good ways to componentize a product. Every company starts out with a single product manager responsible for everything, but eventually, you have to break it down into components.
Still, I’ve identified two principles by examining what doesn’t work.
a) Don’t establish a permanent group of people to promote best practices
This occurs frequently in growing and established companies. Several people come together to promote best practices, whether that be accessibility, front-end design, a specific technology, or a process. They form a group with the best of intentions. Saying no to them is counterintuitive. Allowing the group to form is perfectly reasonable, but it’s important to establish a clear goal and duration for the group. Otherwise, once the group is established and permanent, people in the group can lose sight of the broader product perspective and will naturally champion the best practices in all cases. The result is that the cost of doing anything new is too high because everything must follow “best practice”.
Instead, practice forming groups with:
established goals that can be achieved within a reasonable period of time
rotate people, both experts and novices, in and out of the group
place experts into execution teams to help teams incorporate those good practices
b) Don’t form a group only because there’s a critical mass of people.
This happens more frequently than I’d like to admit, but just because there are >x people who share the same background doesn’t mean this should be a natural component. For example, just because there’s a group of engineers all interested in infrastructure doesn’t mean there should be an infrastructure team.
This is a lazy method of componentizing a part of a product. Assigning PMs to then manage such a component often creates secondary problems.
With more people, there are more subsystems.
Recently, I learned how at one company, 5 different teams own different parts of a single mobile page, reporting to 5 different management areas. Imagine in the image below, different teams owned search, driving navigation, reviews, map, and the compass. What kind of communication coordination would be required to ship certain features?
Now, you might be a product manager in such an organization and you might not have the authority to directly make changes. What might you do? I have three suggestions:
1. Understand the product and its components.
You can’t be a part of the solution or know the depth of the problem if you don’t understand the whole and its parts. All too often, I speak with product managers who only know their component but don’t understand how their component fits into the overall product.
Going back to Conway’s airplane example, this would equate to a PM who is responsible for the ignition subsystem of the airplane. If you don’t understand your ignition component within propulsion for an airplane, you might champion strategies and features that don’t make sense in an airplane. No wonder you aren’t making any headway and feel frustrated.
2. Identify which components are most important to the product’s success.
Once you understand the components, it’s time to identify which components are more or less important to the success of the product. And this will change over time so components that are important in the past may no longer be as important.
Again, using Conway’s airplane product as an example. Airplanes used to prioritize speed (e.g., think of the Concorde). But more recently, they’ve prioritized fuel efficiency (i.e., cost per passenger mile). While the propulsion subsystem is still important, the importance of different components within propulsion has changed. What about your product? What does it focus upon and which component is more or less important?
3. Identify what and who might incentivize people working on different components to work together versus work independently.
People will talk a lot about “breaking silos” and working together to solve problems. But are there actual processes in place that help break down silos. What does this mean in practice?
To be clear, having silos isn’t a bad thing. Silos is just a negative word to describe specialization, which usually has efficiency gains. Instead, you should look for where silos are being broken down and where silos are maintained. You should identify the people who are trying to keep certain specializations whereas others are trying to remove them.
Once you’ve identified a few areas, ask yourself what this means for the product or subsystem you manage. Are there some people you’re asking and incentivized to communicate with more? Who are the people you’re asked to communicate with less? For example, I’m working in an organization where I’m being asked to work more closely with user research, user experience, and UI design while less with content strategy and content design. That will naturally translate into less focus on words and meaning. Is this trade-off appropriate in the product design?
In summary:
Working on a complex and more mature product requires understanding its components and the organization’s structure (i.e., who manages those components). Bad organizations will operate in silos because these components don’t talk to each other. Slightly better organizations will have people in management positions try to push people to work together, but they don’t have mixed incentives that sometimes operate in support versus conflict of teams working together. Great organizations recognize components that make up the product and make intentional organizational changes to bring people together and apart with the goal of strengthening and weakening certain lines of communication to build a product.
This week’s article took two weeks to write and I still think I’m poorly communicating my observations. If you have found parts of this article confusing, leave a comment and let me know where so I can make corrections or clarify.
Additional Reading
This is a very interesting article. Its very difficult to decide on the exact product components and how to deliver the overall product with different components. I sometimes feel that even after breaking the components and prioritizing them, we are still short of the end goal or vision. May be because my vision is too far and I would need to align that to be much more realistic. I have a question for you, how granular should you think on the components because I somehow feel that the we always play in a comfort zone of align the components based on existing teams in the org. rather than aligning them in a cross functional align teams.