Setting Up a Product Team for Success
2 July, 2021
When I started that particular job, I found myself walking into a completely flat product organization. The teams were set up in squads, each owning their own piece of a product and doing their own thing. There was no alignment among the squads or sound rationale on how one thing was adding to the whole. Furthermore, there was no clear mapping to the strategy or anything else that could guide the team collectively in the common strategic direction.
On top of that, a single manager took care of the entire product design team, which numbered between 15 to 20 people. It was too many reports for one person to handle, and team members were often left without adequate support. Also, with the squad structure in place, I couldn’t see a clear leadership development path for ICs working in those squads.
I had my own assumptions about what could work and what couldn’t, but I suspended those until I learned more about the actual situation. I had a lot of one-on-ones with the people on the team, receiving great insights. Some of those insights confirmed my assumptions. For example, I learned that many people didn’t have one-on-one or development conversations for a long time and that no one knew what the strategy was. I listened with great care to their pain points and compared their concerns with my intuitive feelings about the team. I also extensively observed how squads were interacting, which allowed me to conclude that their roadmaps’ misalignment resulted from their siloed planning. Collaboration would never be mentioned until one squad would need something from the other, and those ad hoc requests were causing significant stress and unhappiness among team members.
I also wanted to better understand the business objectives, company strategic direction, and key focus areas before making any decision. I noticed that some of the key business objectives -- as told by founders -- were not moving forward. People were not aligning the pieces they were working on with the larger initiatives. Some of those initiatives transcended the capabilities of one squad to solve them. There was no higher-level thinking beyond a squad level on how to move these things forward.
After a month of thorough analysis, I did three things -- I introduced a new structure, new roles, and new ways of working.
In terms of structure, I organized squads into tribes that would correlate with three key business objectives. I grouped squads working on problems and services related to those business objectives (or strategic pillars) and clustered them into tribes working on the strategic higher-level goals. Once I established what our focus would be, I aligned the squads around that.
The new role I created was named a product tribe lead. It was giving my most senior product managers the remit to oversee the entire tribe. They would have a more strategic overview of three squads and would be responsible for moving the needle on the strategic objective. Tribe leads also became managers, so fewer ICs were now reporting to one manager, thus getting much more attention and having career conversations during their weekly one-on-ones. The new role also opened up an official leadership path for other managers to develop their line management skills along with strategic management ones.
I also created a new way of how we did our product planning process, emphasizing communication and alignment early on in the cycle. Coupled with the new structure and new role, the new way of working highlighted the importance of a bigger picture and encouraged collaboration with other stakeholders like Sales or Operations.
Finally, I had tribe leads join my efforts and help me promote the new structure and new way of working. We had multiple sessions with other product managers and tech leads to talk them through what we were doing, changes we were making, and why. Following on that, we also conducted multiple one-on-one conversations to collect feedback and address concerns because, for many people, it was a seismic change. I had enormous help from my product leaders, who also acted as major agents of change.
- Communicate frequently and explain things in different ways. I would bring the team together for a presentation, but I could still tell many were confused. So I did multiple messaging iterations to make it resonate with the people affected.
- By their nature, people tend to resist change. While I saw plenty of benefits -- including a formalized career path and the possibility of promotion -- people would still oppose the change. Though I was a new leader, I made myself accessible for their feedback. Some people were quite uncomfortable with change; they were concerned that they were not reporting to me anymore or that their visibility decreased. That helped me realize that some people misunderstood our intent and thought of it as meddling into their day-to-day work without many benefits to provide. If I haven’t been authentically open to feedback, I wouldn’t be able to understand their perspective and their concerns. Eventually, some of those changes wouldn’t take effect because I wouldn’t be aware of problems undermining our efforts.
- Though I have promoted senior PMs into more official leadership roles, people would still, by default, come to me for decisions. Without much thinking, I would do it until it occurred to me that I was circumventing the new leaders I had put in place. There is a term for that -- an accidental diminisher. I was accidentally diminishing the people I was trying to empower. I had to make a conscious effort and convey a message that the new leaders owned that scope and that the decision would sit with them. That was also a great leadership transition for me and an opportunity to change my own behavior.
- Be prepared to adapt and change things early on. For example, the first categorization of squads didn’t work out, but it made us rethink how we could regroup squads and with what kind of purpose. So we didn’t cement ourselves to a solution that wouldn’t work but were open to feedback and readjusted the tribe structure into something that would make more sense.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he identified the symptoms of his overworked product team and worked towards defining conflicting priorities.
Adi Purwanto Sujarwadi
VP of Product at Evermos
Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he diligently managed a product in one of the biggest eCommerce companies by being an individual contributor.
Adi Purwanto Sujarwadi
VP of Product at Evermos
James Engelbert, Head of Product at BT, shares his deep understanding of the traits of a successful product manager and how to get aligned with the organization’s path to success.
Head of Product at BT
James Engelbert, Head of Product at BT, recalls when he had to battle imposter syndrome when managing a new team.
Head of Product at BT
Prasad Gupte, Director of Product at Babbel, shares how he drove innovation through structure, collaboration, and autonomy.
Director of Product at Babbel
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.