As a product leader, a key question that one regularly asks oneself is how to maximize the multiplier effect one can get from ones limited resources. Effective organization of ones team is key to making this happen.
Having learned the hard way, I can definitely speak about what NOT to do. I also have a perspective on team organization that has worked well for me. In this post, I will shed some perspective on the same.
First, some ground rules:
- Always organize your team as per passions/interests/strengths of the team members. Needless to say, there’s no fun in putting a square peg in a round hole.
- Keep revisiting the team organization every quarter. Discuss what is working/not working with your team members, peers (both x-functional peers as well as other PM leaders in the org), and leaders.
- Encourage PMs to be intrapreneurs. Optimize for learning and execution
Second, what does not usually work very well: Organizing PM team around engineering teams’ org structure.
This is a common theme I see repeated in many organizations. Organize as per org structure of eng teams: front end, back-end, data engineering etc. After all, engineering teams are often organized as per development functions. Organizing PMs for such teams latched to one or more of these teams is convenient. The PM gets his / her dedicated eng “scrum” teams, the end team feels they have a leader who can champion their initiatives with some product thinking, and everyone seems happy. Except often the end customer outcome.
The most common challenge with this method of organizing is that end-outcomes/experiences are often overlooked, and end-to-end (E2E) thinking is frequently missing.
Other challenges that I have seen with this approach:
1. Left hand does not speak to right hand / at least is not in sync – i.e coordination challenges between various teams that would comprise E2E experience
2. Lack of single owner for the entire experience causes ball to drop
3. Churn, Measuring product success, Product iterations
Finally, let me shed some perspective on what actually seems to work. In my view, organizing teams according to end-to-end customer outcomes or key customer personas is a great way of organizing the PM teams. After all, PMs are supposed to be voice of the customer/champions of the customer’s cause. By organizing PM teams in this manner, you now have a “throat to choke” towards the key outcomes you are looking to drive for your company/customer outcomes. Additionally, I recommend organizing the dev teams as squads (as per the Spotify squad framework). Here’s some information about the same:
I highly recommend working with your engineering leaders to organize your x-fcn dev/PM team to be organized in this manner.
My experience has shown that that having PMs focused on end-to-end outcomes and x-fcn dev teams organized in the Spotify squad framework really leads to:
1) improved productivity & less re-work,
2) strong customer outcomes by keeping the focus of the PM on value for end customer (ie to find and help build the right product)
I would love to hear what has worked for you and your team.