Organizing your product team is a core function for a product leader. Many companies start with the simplest model: the first PM focuses on the first product and new PMs join the team as new products (or product components) are created. That can work when the product portfolio unfolds neatly on market segments with highly cross-functional teams that dynamically adapt practices over time. The reality is that markets evolve in unpredictable ways and teams & practices can grow resistant to change over time.
In this post I lay out some general principles followed by some examples of different organization models and process frameworks that should all be tied together as a coherent system to realize your strategy.
Organizations don’t exist in vacuums — they need to maneuver through the market landscape on their way to their objectives. Before you jump into solutions, you should first understand the environment you are operating in using one of the framework laid out here:
Optimize around your objectives. There is no one-model-fits-all option out there for every organization — each model is an optimization for a set of inputs & outputs.
Consider context. What environment is your company operating? Are you part of a mature market with established players and value chains where there there clarity in the cause-effect of your decisions? Or it is more complicated?
Strive for simplicity. Avoid dependencies between teams where possible. The non-linearity nature of relationships across projects & teams dramatically increase the risk of failure as more resources are added to the organization. E.g. Probability of success for a project with 10 components (e.g. people, teams), each with a 95% success rate results in a 60% likelihood of success for the total project: 0.60 =0.95^10.
Recognize the need for speed. Align your organization’s velocity & clock frequency with the needs of the market. Unless you are in a heavily regulated environment where speed is equated with recklessness, figure out a way to organize your company that makes everything fast.
Weave each role into your organization’s fabric.
Instrument the process so you know when you need to shift models.
What are the output/impact metrics for each team?
How do those fit into the overall objectives for the business?
There is no single one-size-fits-all for organizational models which is why I’m connecting organizations & frameworks together. You need to consider the entire system when designing your team and it all starts with your organizations purpose, the ecosystem & market conditions it needs to operate in, and the people you are leading.
Management by Objective
Peter Drucker introduced Management by Objective when he published
while working at Verily back when we were still part of Google. At first I bristled at the dated stereotypes of the military as a top-down organization but it look like Alex has updated the deck with a caveat (slide 14):
In general, I think Alex’s framing gets a lot right and it’s important for
Strategic Corporal
A popular concept while I was in the Marines was the
The strategic corporal is the notion that leadership in complex, rapidly evolving mission environments devolves lower and lower down the chain of command to better exploit time-critical information into the decision making process, ultimately landing on the corporal, the lowest ranking non-commissioned officer, typically commanding a fire team of 4 individuals or a squad of 12 individuals (three fireteams)
My experience in the Marines confirmed that this is an effective approach for navigating dynamic environments. With that, it requires the following throughout the organization:
. Unfortunately an industry of agile practitioners and consultants created new rigid frameworks that they could easily pitch and sell to companies. Where it got off the rails for me was when teams essentially outsourced key elements of their work to distinct new roles like scrum masters which only increased complexity. The most effective teams I’ve worked on did not hire new agile/scrum roles. Instead, the product, eng, ux and solutions teams adopted the principles through our practices as part of their role.