Back to resources

Setting Up a Product Team for Success

Product Team
Reorganization

2 July, 2021

Jennifer Agerton
Jennifer Agerton

Chief Product Officer at AirHelp

Jennifer Agerton, VP of Product at letgo, reflects on her efforts to scale up a product team and set it up for success through a threefold action of introducing a new structure, new roles, and new ways of working.

Problem

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.

Actions taken

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.

Lessons learned

  • 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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

(Re)Organizing Your Teams Using Domain-Driven Design

12 July

A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.

Alignment
Architecture
Scaling Team
Building A Team
Internal Communication
Reorganization
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty

How Product Marketing Can (and Should) Help Product Development

20 June

Pavel Safarik, Head of Product at ROI Hunter, discusses the frequently overlooked role of product marketing in getting high user adoption rates for your product.

Goal Setting
Product Team
Product
Different Skillsets
Cross-Functional Collaboration
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Technical Program Management at Apple Inc.

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

The Secret To Product Growth is Your People

6 April

Caz Brett, Director of Product at Steer73, shares her insights on scaling a product team by focussing on the people.

Alignment
Product Team
Scaling Team
Company Culture
Hiring
Caz Brett

Caz Brett

Director of Product Management at smartsheet