Juan Gabarro is former VP, Head of Digital Product, Product Management, and Product Marketing at Planet Fitness. He began his career as an analyst at athenahealth (then a startup) and found a passion for all things digital, including product management, during his time at Digitas. After getting his MBA at Harvard Business School, Juan worked as a strategy consultant at OC&C Strategy Consultants and Innosight. Before his most recent role at Planet Fitness, he led product marketing, pricing, and sales at Zipcar.
In our conversation, Juan talks about how product leadership should drive vertical alignment, but the product team itself should help drive cross-functional alignment. He discusses common blockers when trying to align teams across the organization, and shares how he likes to think about these impediments conceptually to overcome them. Juan also shares the importance of training PMs to document the rationale behind decisions as they are made.
It’s hard to distill down to a few principles, simply because context is everything when it comes to alignment. When I think about my own experiences, these things vary greatly depending on the individual personalities and agendas you’re dealing with.
The first thing I’d emphasize is to make sure you understand what alignment means at your company. Does alignment mean leadership is supportive in principle? Does it mean that leadership will agree with your decisions? This can be really important in a consensus-driven organization. Or, does alignment mean that this strategy is now part of the plan and the organization now has resources to support it?
Sometimes, you’ll get what you think is alignment. People may even explicitly declare that they are aligned together, but later on, you find out you don’t have what you need or there’s a change in direction. Every company needs to determine if what it has is actually alignment, and if it isn’t, it needs to decide what to rally behind. One option is outcomes and how they’re measured, and another could be timelines.
Yes — I like to make sure that there’s vertical (or top-down) alignment as well as cross-functional alignment. Usually, you’re aligning product development goals and priorities with company goals first, going cross-functional after, and then moving into team-level organization.
To make this successful, it’s hard to overstate how important communication and documentation are. In terms of aligning the true day-to-day of the team, product development processes and team structures aren’t static, or they rarely are static for very long.
When I first got to Planet Fitness, the development teams were organized around web development, app development, services, and data. This is reasonable, and it might be an optimal process depending on what you’re building and how you want to do it. But, at some point, we wanted to switch to squads. This led to all sorts of questions: What’s a squad? How are we defining that? How big are they? Who’s going to be on them? How are we going to test it out?
If you just throw something like that out there, people will hear about it and may get stressed. Keep people informed so they don’t hear things through the grapevine and panic. This is where communication is really key.
If you’re building a product management team or trying to institute some new processes, one challenge to keep in mind is that there are executives who are going to stand to lose control or influence. In particular, if prioritization is based on the loudest voice or most senior person in the room and you want to shift to a more rigorous data-driven prioritization process, you have to be ready for some people to lose out in that.
Fear of change is definitely real as well. Say you’ve got alignment, you’ve done a great job pulling executive leadership together and rallying around some really important portfolio-level decisions. You’ve got your very explicit priorities and have a roadmap, but then, some time goes by and someone says, “We really need this thing.” Well, everything is already prioritized, so now what? This is common, and the issue with change is that you have to anticipate that that’s going to happen.
That’s something I wish I’d been more mindful of in the past. A lot of times, in practice, you’re responding to blockers as they come up, but it’s helpful to take a step back and think about it a little more conceptually.
I like to deal with it head-on. There are instances when some cross-functional stakeholders may not be able to change their planning processes. If this is the case, you may need to develop some workarounds, including reserving some capacity for the expected but unknown.
For example, say you’re certain that marketing doesn’t quite know what they’re going to need yet for a certain campaign that’s nine months out. You probably know they’re going to need something, even if you don’t know exactly what that something is. What can the team agree is reasonable in supporting this campaign? If you get there and marketing actually doesn’t need much, great. If so, at least you’ll be ready for it. Otherwise, you have to make the trade-off clear and may need a little bit of peer pressure to avoid shifting priorities.
For sure. And I don’t mean this in a bad way — I’ve had fantastic cross-functional colleagues that I had to invest a good amount of time to ensure alignment with. I’d also emphasize that vertical alignment, which I mentioned earlier, is just as important as cross-functional alignment.
Product leadership should be driving vertical alignment, whereas I find that I need to leverage my own product team for cross-functional alignment. This is because a lot of times, depending on how the team is organized, your product managers are working directly with key stakeholders. They’re on the front lines dealing with things like scope creep or reprioritization.
The obvious principle here is to understand the stakeholder agendas that you have to reconcile to get alignment. You’re soliciting input, receiving requests, and understanding what they need. But you’re also communicating back to them in terms of how priorities are shaking out. One thing I learned the hard way is to do that as early as possible and then revisit it as frequently as possible.
The tricky part is making sure it is a dialogue. If you send over an email to operations and say, “Hey, there’s going to be this new change that’s going to affect how people transact with a business. We need the staff to be trained on it — please have this ready by such and such date,” that’s not a great way of ensuring alignment. You want them to be involved in developing the requirements and providing input.
When you get to the visual design, you’re running that by branding and marketing. You can run the wireframes by stakeholders. Even though you’re not necessarily asking for their input on UI, you’re trying to surface any concerns as early as possible. One aspect of this that’s particularly challenging is making sure that you are framing the input you want so that you don’t get a whole bunch of feedback you can’t incorporate.
In general, if they request something and it’s not going to get prioritized, you need to let them know that as soon as possible. It’s also important to reinforce why decisions were made. Train your PMs to document the rationale behind decisions and be ready to play that back.
I’ve definitely been in situations where my roadmap was derailed by a poor quarter of company performance. The optics of staying the course versus appearing responsive and nimble can lead to short-term decision-making, but if you really need to respond to a change in market conditions, you should. It ends up becoming a cross-functional discussion about priorities and the cost and benefit of those trade-offs.
There are a few universal attributes I look for, as well as some that I think are very particular to managing or building zero-to-one products. The first is an ownership mindset. This extends beyond product management — I actually look for this in product marketing as well.
For the product management role to create more value for the organization, it needs to be a pretty robust role. With that, comes high accountability. The PM shouldn’t perform all the work, but they’re accountable for making sure the work gets done and to the standard that they have set. It’s a slightly neurotic mindset, but PMs need to be obsessed with having all their ducks in a row.
Another important attribute is relationship building, which falls into soft skills. I look for someone who can form high-respect and high-trust relationships. Ideally, this is someone who can recognize other people’s strengths. Their influence is based less on pressure and more on shared respect.
I believe that a little bit of both is good for anyone. If you have the opportunity to work at a great product organization where you’re going to be given challenging responsibilities and learn best practices, go for it! But I’ve had a lot of informal product management roles, and in these, I learned a lot of different things that shaped me into a better manager and leader. You can have the best formal training in the world, but if you only come out of it with one way of approaching product development, you’re only going to be effective in places that can repeat that approach.
The transformation part can mean so many things. I’ve been in companies that didn’t think they were going through digital transformation but were. There are different types of transformation, namely customer-facing transformation versus internal transformation.
Customer-facing transformation is where your customers are going to have a digital experience that they did not have before. It’s going to change the way they transact with your company. That sounds drastic, but internal transformations can also be as big and impactful.
The advice I’d have to anyone going through a digital transformation is to remember that patience is short, but timelines for transformation are long. This means you’re going to need to do a lot of ongoing evangelism and advocacy. In fact, you also want to get people greedy about the transformation. I’d rather have people impatient to deliver that transformation than lose interest in it completely. I found that a great way to develop a little bit of that greediness is to get some quicker wins that are demonstrable. It’s an effective way to rally people behind the initiative and see that enthusiasm develop.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
As the name alludes to, the way you frame a product significantly changes the way your audience receives it.
A Pareto chart combines a bar chart with a line chart to visually represent the Pareto Principle (80/20 rule).
Brad Ferringo talks about how he helped develop modern “earconography” — sound language that creates context-driven audio notifications.
Without a clear prioritization strategy, your team will struggle to tackle competing demands and can end up confused and misaligned.