4 Common Gaps in Cross-functional Teams

Last year I wrote an article about the role of a product manager. It focuses on what the responsibilities of a PM are, and how you know if you’re doing what you need to do. It ends with this statement: “you figure out what the team needs, and you deliver that. If there are gaps in vision, strategy, execution, impact, communication, visibility, team culture, team capabilities, or anything else, you own them.”

At the end of the day, the role of a PM is getting a team to deliver the right product. So I thought it’d be useful to look at some of the most common gaps in cross-functional teams, and how to identify and address them. I’ve worked on some successful teams building successful products, yet none of them functioned flawlessly. Every one had some kind of dysfunction (at least one!). Most were minor dysfunctions, some more significant, but I’m confident that all of those teams could have been more effective had I done better as the product manager and leader of those teams.

In my experience, you can boil down most gaps in cross-functional team performance to 4 broad issues that I think every PM needs to be on the watch for:

1. Lack of a unified, motivating vision

2. Team members feel like consultants

3. Trust deficit

4. Failure to drive outcomes

I’ve learned the hard way on all of these at Google, and today much of the time I spend coaching PMs is helping them identify and deal with these 4 issues.

Two points before we dive in:

• These aren’t necessarily problems in your performance as a PM, but they are issues on your team and therefore opportunities to improve your team’s performance.
• When I say cross-functional team, I’m simply talking about the broad team responsible for the product’s success end-to-end. If you’re a product manager, you are leading a cross-functional team, whether it’s just you with 5 engineers and a designer, or 100 people across engineering, design, marketing, B.D., operations, etc. These issues are equally relevant in both situations, just on a different scale.

1. Lack of a unified, motivating vision

I joined Android Market in 2011. It was the first team I was joining as product lead, and I saw so much untapped potential for the product. I came in guns blazing, with lots of ideas and things I wanted to get done.

I found it was a constant uphill struggle to make those things happen. The cross-functional team had a set of largely independent factions, each with their own idea of what was a priority and what the product should look like. For example, in the storefront: The engineers were excited to build a personalization system, so the storefront would feel fresher and more relevant. The merchandising team wanted to curate the storefront to create a more premium, higher-quality feel. The team that managed developers was focused on ensuring that the best products saw great results.

These goals were not mutually contradictory, but there were no higher-level shared goals that tied them together, enabling teams to work together on specific projects. So it left me running around, fielding escalations and convincing each team, one-by-one, on each product decision, to get on board. I’m pretty willful and I can be pretty convincing, and we did make progress. But it felt like rolling a boulder uphill.

Eventually, in the context of some broader changes, I pulled together a new cross-functional leadership team. The first thing we did was go for a 2 day offsite focused on identifying a shared set of cultural principles and a single long-term vision for the product. I was terrified this would be a colossal waste of time, since I think 90% of mission exercises are time sinks that output a plaque you can put on the wall with a mission statement that everyone reads once, and they nod, and then they go back to whatever they were doing before.

I was surprised to find out that the vision we produced ended up being one of the most directly impactful things we ever did:

1. It laid out a set of shared goals as the foundation that teams used to guide lower-level decisions
2. It made each cross-functional area a stakeholder in that vision, and each lead an evangelist who told the same story to all of their team members
3. It led us very quickly to make a set of decisions to kill some projects and start others (including starting the project I’m working on now)

Some common symptoms of a vision gap include:

• Contentious prioritization. If you don’t have a shared understanding of what the macro goals and principles are across the team, you have no foundation to guide smaller scale decisions.
• Large course-corrections. If you don’t know where you’re trying to go, it’s hard to know if you’re taking steps in the right direction.
• Difficulty recruiting. I was surprised to hear from one of our engineering leads that the vision we put together was the best recruiting tool he ever had.
• Inadequate resourcing. The vision is a useful tool for aligning people in all directions, including upwards. If you struggle to get executive support, including funding, ask yourself first if understand the vision and care deeply about realizing it. If not, start there.

And some remedies:

• Build a vision as a team. This HBR article is the methodology we used. I like it because it’s very practical, specific, and focused on driving outcomes.
• Evangelize… & over & over. I felt like a broken record during the first few months of communicating the vision to the team, but it’s essential that everyone hears it multiple times and sees how it directly impacts the work they’re doing.

2. Team members feel like consultants

Another thing that caught me by surprise upon joining the Android Market team was the relationship between the product-engineering team and our designers. On maps, I was used to sitting right next to my designer, with our user experience researcher a couple desks away, all sprinkled in with the engineers. On Android, the design team had their own studio — and in fact, a year into my time there, a large area of our building was walled off as a design lab, to which our badges wouldn’t even grant access.

The relationship between the product-eng team and the design team followed this pattern of being in separate spaces. The product-eng teams would talk, often organically, about product goals and priorities, and then we’d have twice weekly meetings with our designers, who were assigned a bunch of action items, and then they’d come back with mocks, and we’d review, and then they’d go back and make some changes, and so on. The PMs and engineers were always frustrated about the progress and number of iterations necessary, and the designers also had a consistent set of complaints:

1. Designers were always pulled into the process too late and not treated as product owners
2. Product quality was not prioritized highly enough
3. The design work didn’t feel that interesting, and they wanted to spend more time on concept work and defining the product direction

All of these, to me, are symptoms of a team operating in an agency model — as consultants rather than product owners. We hand specifications over the wall, and they come up with mocks to pass back over the wall.

Later we brought in a new design director, and he did two things early on:

1. Assign every PM + eng lead a corresponding design lead
2. Embed the designers and researchers directly with the product and engineering teams.

It’s had a real impact on how well the different functions work together. The designers are represented as product owners, they are much more present, they take part in organic conversations about the product, and they are trusted much more highly by the product & engineering teams — so they are able to influence things much more easily, at an earlier point, and much more credibly. And because they are involved earlier on, they are able to spend time on concept work that is highly aligned with the product goals and that influences the direction of the entire product.

Some common symptoms of consultant behavior include:

• Requests to join meetings. If people feel and are treated like owners, they will organically be involved early in the process and will not fear being left out.
• Organizing/talking functionally. If your meeting agenda includes things like “engineering updates” and “design updates,” you have a bunch of people thinking about their own work instead of the overall product. You want topics like “performance” and “user experience,” to which everyone can contribute.
• Focus on activities instead of outcomes. Consultants don’t care about feasibility, deadlines, or product goals the same way owners do. They focus on their own deliverables. Things end up falling between the cracks.
• Waterfall process/inflexibility. Teams where people are more focused on their own activity than the overall product goals tend to be less agile.

And some remedies:

• Spend more time together, organically. Co-locate, create more 1:1s and social time. People need to feel like a team.
• Focus on transparency & communication. Pushing out more information, especially early on, pulls people into the process and allows them to contribute and feel some agency over the whole product, not just their area. I find 1:1s and bi-weekly newsletters are good tools for this.
• Assign problems, not solutions. As General Patton said, “Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.”

3. Trust Deficit

For a few years I was in charge of the horizontal components of Google Play — core infrastructure, search & discovery, commerce, the store itself, etc. We had 6 vertical teams dependent on various components, and as is the nature of any horizontal component, we were always a bottleneck for someone.

As the team grew, this became an increasing challenge, and we were encouraged to add more and more process around our quarterly planning. create a formal “ask” process. Assign priorities to all asks. Create spreadsheets tracking asks. Provide formal responses and meetings to discuss. And so on. These demands for more process came from both the client teams and our own team. By the end, we had over 140 quarterly asks, and my team was telling me, “We can’t keep track of all of these or understand why they’re important. Let’s require a standardized one-pager for each of them.” Out of over 140 asks, we were able to say yes to less than 10.

No one was happy — not my team, and not our clients. And both teams wanted more process as a solution.

Eventually, I realized that the problem was not a lack of process. The problem was a lack of basic trust and dialogue. The client teams didn’t trust that we had their best intentions in mind and were capable of delivering. Our teams didn’t trust that the client teams were prioritizing the right things or that the asks were even necessary. And our teams were talking about line items rather than these more fundamental gaps.

So, one quarter, I killed the entire ask process. I told my team instead to go schedule a meeting with each client team — before planning started — to understand their goals and priorities, and to share the goals and priorities for the shared components. We would use that conversation as the basis to come up with a quarterly plan that we thought best balanced all the competing needs, and then we’d have an open conversation about it.

It turned out that we were able to cut out 80% of the planning effort — and I think about 80% of the complaints. We accomplished about the same amount of work, but opening up that dialog created a foundation of trust in both directions that enabled us to work together productively.

Some common symptoms of a lack of trust include:

• Requests for more process. Process is often a kludge used to compensate for a lack of trust, alignment, and ability to resolve questions through dialogue.
• Org chart squabbles. No org chart is perfect, but peers who trust each other can manage pretty much any structure, and peers who don’t will constantly be asking for org changes and clearer definitions of who owns what.
• Negotiating terms. On a foundation of trust, a handshake deal can seal a high level agreement. Without it, you end up litigating every last detail. If you find yourself writing up a formal agreement between team members or with another team, you are probably compensating for a deeper issue.

And some remedies:

• Question process. If you constantly ask yourself why this meeting exists or why this process exists, you’ll find a lot of wasted time and effort, as well as some deeper issues to work on.
• Focus on intentions & capabilities. Trust has two parts, intentions and capabilities, and you need to establish both. See The Speed of Trust.
• Spend more time together, organically. Co-locate, create more 1:1s and social time. It’s easier to develop trust if you know someone as a person, not just a dependency.
• Make people feel heard. The best way to demonstrate your good intentions is to start by listening to the other person and show you understand and care about their goals, too.

4. Failure to drive outcomes

There is an important difference between executing and driving outcomes. Driving outcomes requires being focused on results and making them happen. Execution can just be activity. And you can do one without the other.

I had a team that produced a lot, that worked hard, that had a great attitude — but they executed without driving outcomes. They patted each other on the back for day-to-day accomplishments, but at the end of the day the product wasn’t good enough, and we never moved the needle on our key metrics. We failed to shift that culture, and at the end of the day we had to shake things up pretty dramatically.

It’s critical to have a team that not only has a shared vision, but also is focused on making that vision a reality. It takes a lot of will to drive results. Lots of obstacles will be thrown in your way. But teams that want to produce the right outcome above all else will fight through those obstacles to make things happen at the end of the day.

Symptoms of failing to drive outcomes include:

• You don’t ship. Always be shipping.
• Your KPIs don’t move. If you ship a product and don’t achieve the results you want, it’s the same outcome as not shipping at the end of the day.
• Activity vs outcome focus. A lot of teams will have quarterly goals that look like “launch feature X.” It’s important to reframe the goal as something like “drive growth of Xmm users with new feature X” or “increase CSAT by Y with new feature X.” Now you know what the point of X is, and the team can look at X even before shipping and decide whether they think it’s likely to drive the right outcome or not.

And some remedies:

• Get the right team. Some people are more driven by outcomes and others more driven by activities, and if you have a whole team focused on activities, it’s hard to change.
• Use OKRs. Google users the Objectives and Key Results methodology for quarterly and annual goal setting, and I’m a big fan. It’s important to use it correctly, though. Your key results must measure the outcome you want to drive, not the activity you’ll perform to try to drive it.
• View from 10,000ft and 10in. As a product manager, you need to look at things from 10,000ft so you can see all the puzzle pieces and make sure they fit together to create the product you want. You also need to see things from 10in — really get into the details and make execution happen. Most PMs have a natural inclination to one or the other, but the best PMs do both.

The One Sure-Fire Way to Diagnose Gaps

I sometimes get asked about how I approach identifying what a team needs. Who do you need to be as a PM? What is your role on the team? I point out some symptoms of the most common gaps above, but there’s also one sure-fire way to diagnose these gaps, and it’s quite simple. Just ask.

If you have 1:1s with your team members (and you should), it’s as easy as asking them: How are you doing? Any concerns? What does the team need? How can I make your life easier?

They won’t tell you, “We lack a foundation of mutual trust with team X, which is causing us to add all this additional process.” Getting to that diagnosis will require a bit of root-causing on your part. But they will generally be very willing to tell you straight up what the issues are, and what they need from you. And then at least you’ll know where to start.