Graham Reed
Today, we’re going to talk about the wider impact of product operations on the business as a whole. In the last episode, we discussed product ops being a trusted partner to product leadership, but how far does this extend into other key areas of the organization like sales, marketing, delivery, support, customer success, the wider business, and the commercial side of the business as well?
Product operations enables product excellence
Graham Reed
How does the role of product operations support the product side of the business?
Antonia Landi
Product operations enables product excellence. The challenge is that by definition, we remove barriers to that product excellence. But what those barriers look like is different at every company.
Some of us might be doing very data-heavy work, some of us might be doing more coaching, and some of us might be working very closely with product leadership to make sure that this strategy sticks. But for me, broadly speaking, it's really about product excellence.
Product isn't done in a vacuum. It's not just product managers that build products. If it was just product managers, we wouldn't have an end product. We need people to build it, we need people to figure out how it’ll work, people to sell it, and people to support it once it’s out there.
How do we get all of those voices going in the same direction and make sure that ultimately we deliver value to our users in a way that benefits the business?
Diana Soler
In Europe, product operations is so well established. There are so many voices that contribute to the community in a meaningful way.
There are so few of us in North America, I can count us all on one hand. I live in Montreal, Canada, and I LinkedIn search product operations and there aren’t that many of us, but I guess that's a competitive advantage I have.
In my first product operations role, I reported to one of six directors of product management. I thought product operations was there to make the lives of product managers easier, but I know now how wrong that is.
Over time, I realized that I wasn’t having that impact or getting the traction or buy-in that I needed. I approached my boss's boss, the VP of Product Management, and said, “Hey, wouldn't the function of product operations have a much bigger impact if I reported it to the Head of Product? Here’s why.”
When he made the announcement, the rest of the directors of product management came to me and said, “We didn't know that you could help us. We didn't know that we could open our doors to you and you could come in and help the teams. What you've done here, please duplicate it here, here, and here.”
The first learning was that we must report to the Head of Product up to the product, and that’s common knowledge now. But in reality, what I've learned going into year three of product operations is that it's not just for the product teams.
I sit within the product organization, I report to the Chief Product Officer, and she leads seven product teams: engineering, software development, QA, design, product management, infrastructure, support, and product ops. And that’s truly how I can have a really big impact.
I work mostly with engineering and customer-facing teams, and right now we're working particularly closely with our professional services teams, which are the core users of our products because not only do customers purchase us for our software platform, but also for our managed service.
To summarize, it's there for the success of the product. It’s markets, the opportunity identification, and all the hands that play a role in the success of that product.
Graham Reed
I'm really glad you phrased it that way because this is something that I've said for a long time as well, that product operations is there to support the product function, not the product team directly.
It's a weird dichotomy because product ops is a very people-focused role. We want to help people, but actually, our role is there to support the product function, and in a SaaS business, that's basically the whole business.
If you're selling that product and that’s your primary asset, we’re there to help support that business in its dealings with the product itself, the product function, and how that product function operates.
Product management elevates product operations much higher than just saying we're there to support product managers in doing what they need to do. At the very least, it's everybody on the tech side of the business, and at most, all divisions across the business.
Rebecca Madro
Listening tours are essential to product ops success
Graham Reed
Where have you had the most success in terms of working with one particular function within the business?
Diana Soler
I've had the opportunity to do product operations in two companies. In both, I spent the first 90 days doing listening tours.
At Assent, I spoke to 70 individuals from not only within the product teams, but across the organization, and it was all about understanding the opportunities. I realized that most of the pain existed in collaboration and communication between the customer-facing team and the product team.
I've been here for just over a year and a half, and we’ve spent almost 60% of our initiatives on building that cohesion and collaboration.
For example, we've implemented a release readiness program, with the goal of ensuring the customer teams are well-equipped to talk about the changes in the product with users.
We had an interesting situation where there was a product change that didn't require software developer time and therefore didn't go through the normal process. Our professional services teams ended up not being ready, and again, they're the core user of the product.
So, we realized that there was something that we missed and went back and iterated. Iteration is really important when you're designing these processes.
Another example was feedback loops. We were really good at collecting feedback from the customer teams, but there was no way for us to analyze that.
So, what additional business data and customer data could we layer into the feedback that we were collecting that would help the product decision-makers make those prioritization decisions?
We didn't have a product usage tool to help us see the success of those things. So, we've now completed the cycle and we're in the change management phase where we're rolling it out, enabling teams, etc.
If you were to ask me, who are product ops’ biggest champions and advocates currently? It’s the cross-functional leaders, the head of customer success, the head of professional services, and the head of sales because we've alleviated a lot of the pain for them.
If you asked some of the product leaders how they feel, we've created a lot of work upfront for them, but they're yet to reap the benefits.
Antonia Landi
Listening tours are so central to setting yourself up for success when it comes to starting a new product ops role, and it's especially about looking beyond the limits of product and tech. It's actually going to meet those customer-facing teams.
I had an epiphany at my last full-time job before I became a freelancer, where I was speaking to people in sales and people in customer support, and just the fact that I was there representing product and actively listening to them was such a breath of fresh air for them.
The fact is that we can be those people who extend an olive branch and say that we'll get closer. It’ll no longer be people throwing stuff over the fence at each other, it’ll become a collaboration.
We had a case where our internal support teams were using an internal tool that we built to deliver service, and there were so many things that would take us two hours at most to fix in this internal tool. But it was always deprioritized because there was always such a strong focus on “actual” product work, things that’ll land in front of the eyes of the customers.
But once we realized that one team took half a day, we could actually make 30 people's lives so much easier.
Having a good relationship like that was so meaningful and helped to reestablish that trust, reestablish that relationship, and assure each other that we were here for each other.
We’re here to solve one common problem to reach a common goal, and product excellence is also how we deliver that service.
Diana Soler
Just to add, the listening tour isn’t a one-time thing. The approach of gathering that feedback via a listening tour is maybe one time, but you want to revalidate what you heard and see if you’re making any impact, improving, or alleviating some of this pain.
In Q3, based on the listening tour, we launched two surveys, one for inside the product team, and then one for the customer team. It was interesting because one of the questions we asked the product team members was, ‘How do you feel that you collaborate across the organization?’ And they said, ‘Great.’
Then we asked the customer team, ‘How do you feel product collaborates with you?’ They said, ‘It's not good. I don't feel heard.’
We presented back the results, and they said, “Now we have a baseline that we can improve against.”
We're about to launch it again in Q1. We took a bunch of their input and adjusted the survey. But now everybody looks at the same source of truth and can gain inspiration.
I've seen other product leaders and customer-facing team leaders build initiatives out of what they heard in the survey. So, it's revalidating and showcasing it once again, over and over. I speak to the cross-functional leaders at least once a month.
Bridging gaps and enhancing collaboration across departments
Graham Reed
How do you set yourselves up to be more objective and separated from product?
Antonia Landi
For me, the first 30 days are the most crucial because you want to maintain that impartiality.
I have a product management background, so sometimes my product brain wants to jump in when I see something. Maybe it’s suboptimal, but it’s also about training myself to be a conduit, more than a specific cog in the machine, and keeping that high-level overview.
In Europe, there are more of us, but most of us are teams of one or teams of very few. On one hand, that's good because, by definition, we have to protect our time and remain at a fairly high level to do anything meaningful. So, I think that's one way to keep that impartiality because we just have to. We can’t get stuck in the details.
It's also about making your mission clear and what you're there to do. Sometimes, I join an organization, and all of a sudden, I get product requests because I open that door and go, “Hey, I'm the person from product you can talk to. Let's be friends.”
And they say, “Fantastic. Here are 25 requirements. When can I see them in the product?”
So, managing that expectation and clarifying what exactly it is I'm there to help facilitate goes a long way.
Diana Soler
That’s completely accurate. I've been there. For me, it was more, “Oh, can you send me the latest roadmap?”
I don't have a product background. My career started in business development, and then it pivoted to customer success, then business ops, and then I got into product operations formally.
I’m incredibly empathetic to customer-facing teams, and I start with that when I introduce myself. I’m part of product, but my heart sits in customer success, and that’s allowed me to build those bridges a lot quicker.
I’m also very candid. I say, “I'm not here to advocate or speak on behalf of the product organization. I happen to sit within the product org, but I truly want to be that bridge.”
I also get an opportunity to explain product processes to some of the other customer-facing teams. I remember the first roadmap presentation that I heard at Assent. One of the leaders of the sales teams was sitting right behind me and they said, “Well, how hard could it be?”
I thought, They don't understand everything that happens in the back end.
So, I approached the VP of engineering, and I said, ”How would you feel about doing a section of the roadmap presentation where we talk about everything that goes on behind the scenes?”
Adding a button isn’t that hard in the minds of many people who don't understand what actually goes behind it. So, it's just finding those opportunities to connect the dots for both product and the commercial side.
Antonia Landi
Extending an education branch to other people is so vital. Oftentimes, when I do product ops work, I speak to really frustrated PMs who get inundated with requests from customer success, sales, etc., and they're just fending them off left and right because they don't arrive in a format that’s helpful.
These PMS usually go, “Oh, they don't know product. They don't know what they're talking about.” Well, have you told them how product works? Have you explained to them why it is that we need to scope each opportunity before we spend time on it?
It's so easy to dismiss people in other departments as not understanding what we're doing. Well, teach them. Tell them how to do it and take them on that journey with you, because only then can you say you’re product-led.
If you don't do product-led in a vacuum, that just doesn’t work. The whole organization needs to be on board with you.
Diana Soler
A core piece of that is building that empathy between teams. Put yourself in the shoes of someone else.
One of my favorite initiatives that we did in 2023, and that we're planning for 2024, is knowledge sessions. The goal was to bring a department to come and present to the product organization once a month.
There are a lot of people in the product org, so we started in the user journey. We started with business development, account executives, and then the whole journey through to ending with customer success. Then we moved on to some of the other supportive roles, like the rest of the enablement teams, etc.
It was incredible to hear the questions that were being asked in the sessions. They were one-hour sessions, the majority were 40-minute presentations and then a 20-minute Q&A, where these leaders would come and explain what they do. Many team members within product didn't even know some of these teams existed.
We saw the questions from the designers and product managers being asked to these other teams across the organization, and then afterward, we’d get a message that said, ‘Thank you so much for putting this together. We’re collaborating with them on this thing moving forward.’
In 2024, we're doing the reverse. We're going to do knowledge sessions in product that educate the rest of the organization. Knowledge like, “Did you know that there are seven teams? Did you know that when an escalation happens, this is how product support collaborates with QA and engineering to resolve it?”
Customer success managers need to know these things. They ask things like, “Why is it taking so long to resolve this escalation?” Well, because there are three teams that are involved, and they're also focused on these other 10 things.
Let's build that empathy and build those relationships.
Adam Bennett
The importance of a robust communication strategy
Graham Reed
I've worked a lot on communication, particularly between tech teams and the wider commercial business, and one element that I'm very positive about putting in place is this idea of sharing information that teams need.
Years ago, when I was in product management, I was very much about sharing everything and letting people unpick that. But we want to be sharing what we think people can consume, and be very mindful of what they're going to do with this. At what technical level are we explaining our product releases and the things that we're working on?
We want to share a version of what we're doing and how we're doing it to those commercial teams in a way that’s actually useful to them.
So, how transparent should we be?
Diana Soler
One of the other really exciting initiatives that I’ve gotten to work on was standardizing the use of Jira. Why? Because we needed to better communicate across the organization and outside of the organization.
We were working with 40 different Scrum teams, and they all used Jira slightly differently. So, we needed to standardize how they were using it because we decided we were going to introduce this higher-level Jira issue type that would describe the intended outcome. And then you have initiatives that roll up into that, and then the epics that roll up into that.
So, we decided that at the epic level, it's how we speak within the product organization, at the initiative level is how we speak across the organization to customer-facing teams, and then at the outcome levels, it’s how we speak to the external users.
Of course, you need the teams to use Jira in a similar fashion so that it all neatly rolls up. That was really useful because we helped define how you describe things in an initiative or at an outcome, which had to be a lot more non-tech person-centric. And it was more value-driven.
We took examples from companies that I think are excellent at this, like Pendo and how they communicate product releases, and Airbnb and how they communicate their product launches. They’re really easy to understand, and you don't have to be a tech person.
To me, those top two levels focus on that, and then the bottom ones are how we communicate inside the product teams. It was easy for us to then share as much as anybody wanted to. They could double-click if they were even more curious, or they could just stay at the high level.
We share everything. It's just up to them to decide. We do guide them, but it was getting the teams organized in a tool and then making it public and teaching them so that they could self-serve.
Antonia Landi
Having a solid communication strategy is such a strong pillar of most things I do in product ops. Communication has the ability to bust silos, and it has the ability to create silos.
I was once tasked with revamping a biweekly newsletter that the product teams were sending to everyone in the company, and I’d just recently joined the organization. I have a background in product and tech, but I couldn't understand it. It was so granular, it had so many company-specific abbreviations, and so many technical topics.
There was very little about what this meant for the customer, what this meant for the organization, and what this might mean for commercial teams. No wonder nobody was reading it. It was essentially useless.
But the teams very strongly felt that if I didn't tell them enough, they’d just come back and hound me with questions. If I don't write down everything I‘ve done in the last two weeks, how will people know about the great work my team has done?
Reducing that to the essentials, writing it in a way that was understandable for everybody, and making sure it sat in a location that was accessible to everybody completely transformed it. And people actually started collaborating.
It started opening up doors that were previously shut, and people started looking forward to hearing about what the product and tech team were doing. Up until that point, from the outside, it just looked like they were busy all of the time but nothing was being delivered.
It was about bringing people in and saying, “This is the complex work we’re doing. This is why it's really important that we do it. But also, this is why it's taking a long time.
Or, “These are experimentation results. We failed here, so we're going to try a different approach. There are so many iterations behind a feature before it ever gets released and we're not just doing nothing. We're doing real, actual meaningful work, and sometimes it doesn't work out. But that's okay because we learned a bunch of stuff about our users.”
Surfacing that was so important in helping people understand what folks in product and tech are actually going through.
Taylor Belchak
Diana Soler
I was recently asked to also lead the service enablement team. This is a very small team; there are five individuals who are responsible for the training and enablement of our professional services teams.
And because I’m now responsible for it, I've had to dig deep and understand how they’re currently working and accomplishing things.
There's one person on the team who's directly responsible for understanding the changes in the product and then updating all the processes and understanding how that impacts each role within the team. And I thought, Isn't that so cool? I didn't know that. I only know that now because I happen to lead that team. But I really wish that the product organization had known that.
So, now, how do we adopt the documentation to reflect that?
I remember one of the coolest things I saw when I was first learning about product management - some of the roles that were in the PRD would write use cases for each customer-facing team. It was very easy to find yourself and gather the information quickly.
You do sometimes need somebody to do that translation.
Antonia Landi
One of my passion projects is getting people to care about technical topics, especially when you have one or multiple platform teams. It's partly because they’re our ops cousins, so I really want to help highlight this kind of type of platform or DevOps work.
But what does this mean for the end user? Infrastructure changes aren't just infrastructure changes, they’re important because we can move faster and plug in new technologies.
What this means for the end user and the customer is such an important piece.
Should product ops be involved in decision-making?
Graham Reed
I'd like to move on to one other group that we haven’t addressed so far, which is the senior leadership and C-suite team. How and where does product ops support the C-suite and the rest of the senior leaders across the business?
Diana Soler
I'm really fortunate that I have a seat at the table. It makes a huge difference.
In terms of speaking with the C-suite, the various teams have slots. Senior leadership meets once a week, every week, for a significant amount of time, and then once every three weeks, it’s product’s time to present.
I have an opportunity to go speak and present directly to those individuals, instead of somebody doing it on my behalf, because nobody can speak as well as you can about what your team is responsible for. It’s been incredible to get the questions directly from our CEO.
For example, when I came in, I reimplemented Pendo. They’d had it since 2019, but they didn't really do anything with it. So, I came in and presented and said, “You thought Pendo was only for product analytics, but it’s so much more, and this is what we're doing with it. This is what you can expect in the next 6-12 months.”
To get them excited and have the CEO talk about Pendo and all that's going on was really powerful to also get the teams excited and adopt it and use it.
It's being able to speak directly with them and hear their frustrations and other challenging questions that come from them. It helps me in my leadership journey, but more importantly, it helps the mission of product operations and gets direct feedback from those who can influence the most.
Antonia Landi
Senior leadership needs process too. They're the folks that are tackling the strategy. They’re the people who need to hand over massive weekly and bi-weekly slide decks to their investors and justify what they've been doing with their money.
These are all opportunities in which we can help because we’re uniquely positioned. We’re impartial because we have a broader overview and we have fingers in so many pies. We’re also excellent facilitators.
One of the ways I love engaging senior leadership is by helping them refine the OKR process. I've seen very few companies that are happy with their OKR process, and the tension of being a senior leader and a facilitator, but also taking part in the conversation is almost a conflict of interest.
So, you need to have somebody who facilitates on a regular basis, and who can be very regimented with the communication and the planning, and then also play that role in disseminating this information to the wider team. That’s such a unique position to be in, and it's one of the things that I love the most.
Graham Reed
How much do you, should you, and could you advise? How much should you remain completely objective and just let those minds talk and think? Should you give your own opinions on this at all? Should you steer the conversation to some degree?
Antonia Landi
I'm quite strict in that I don’t make product decisions. I don’t advise. At most, I’ll coach if that need has been explicitly stated, or if I feel like a conversation is going off course. That's also part of being a good facilitator.
I’ll ask pointed questions, but ultimately, the decisions aren’t up to me. That’s also the difference between strategic product ops and being a product leader. They’re the best people to make that decision. I’m here to facilitate that conversation. Whatever comes out of it, it’s none of my business.
Diana Soler
I completely second everything that Antonia just said. I make sure that they’re looking at the information to help make those decisions, and I make it easy for them to access it. I make sure that they have enough time to consider it, evaluate it, and synthesize it.
I make sure that for product leadership, it's presented in a way that's cohesive and there aren’t too many words on the slide. I make it look the best that I can.
I don't have a say in the decision itself, I just make sure that there's a good cadence, that they're looking at the right information, and that we’re following through and communicating and disseminating the information down and across.
Graham Reed
A phrase that constantly comes up for me is playing devil's advocate. If I’m in a strategy session, I'll ask questions like, “Have we checked the data? Have we checked the usage of this area to see if it's up or down?” I'm not saying if we should or shouldn't do this, I'm just checking if this is something you’ve done.
I don’t care about what that data or analysis says because that's for the product people to look at, understand, interpret, and make decisions on. What I do care about is, “Have you looked at this and investigated it as part of your decision-making?”
Diana Soler
Depending on how the team is set up, product operations is uniquely positioned to have a broader horizon of the information.
For example, not only are we responsible for the product analytics and creating the reports and dashboards that the product managers submit, but the product managers are only looking at their slice of the product. With product operations, I have one person dedicated to all of that. So, they know all of it, as well as the qualitative feedback that we see from Pendo feedback.
On top of that, they're also out there looking at what the other customer insights are.
So, product operations is very uniquely positioned to get the information directly, package it, and actually submit the recommendations. If they go with it or not, that's fine, but we're the first layer. We're like the catch-all, and then we organize it, and then it goes packaged to the decision-makers. They don't have time to package it, synthesize it, and sort it.
Could I one day sit at the table and make a recommendation? Perhaps. Not right now, it's still too early. But maybe one day, yes.
How do you measure success in product operations?
Graham Reed
How do you measure success in product operations? How do you measure how happy somebody is from when you started, to where you are now?
Diana Soler
As I already shared, the first step is doing that listening tour. We then created the roadmap, evangelized the roadmap, and talked about it with everybody.
Then, in Q3, we designed the follow-up survey. I only spoke to about 70 people, but there were 600 people to speak with. So, in order to capture the voice of the rest of the team members, the survey was the best approach.
We took learnings from that, we adjusted the roadmap, we planned for 2024, and then we're relaunching it in Q1.
That also allowed us to build our OKRs for the team that roll up into the organizational group OKRs, and then that roll up into the corporate OKRs.
We kept it super simple. In year one, it was binary. It was yes or no, you did this or you didn't do this. I wanted at least one product manager, one designer, and one tech lead to access Pendo. Now, going into year two, I’ve said I want at least 50% of the product trio members to be accessing this data to send requests. I really need them to access this information.
It's been a crawl, walk, run situation, and we're getting better, but it's hard for something like operations to establish measurable key results.
Antonia Landi
I love that you called it crawl, walk, run because at the very beginning, even in product ops, there's very little precedent. There are very few established metrics, there are very few things that we can refer to and say, “Okay, this is how you measure product success. This is the industry standard, and we’ll just take this and implement this.”
We’re still figuring it out and we’ll be figuring it out for every new company that implements product operations.
One thing I personally like to do is measure specific initiatives. Going back to that newsletter I mentioned, I could track how many people had viewed the page, for example.
Sometimes you have to get a little bit more creative. But ultimately, there are always things you can measure, even if they might be imperfect the first time around. Even if the first year might be binary, it’s also a discovery process for all of us in product ops.
Graham Reed
We have to be creative in how we’re measuring ourselves. We come at this high level to say, “Are people happy with what we're doing?”
It’s not a simple thing to do. If it's an NPS score, that's the best-established one out there, and not just for product operations. But it's still not perfect.
We need to be more specific and take a little bit out of the product managers' playbook. What are our measures for success on a product, a feature, or a release? And actually looking at it that way.
A big area for me is communications. How many follow-up Slack messages were there after a release? I'm hoping that goes down because that shows that we're being more clear in our messaging.
How many people are reading our emails? How many people are clicking through to the pieces that we want them to? I think that the key is to look at specific projects and initiatives and measure those.
Antonia Landi
It's the change in behavior. We’re quite well versed in thinking about, what’s our users’ change in behavior? What's the outcome we want to achieve?
It's no different in product operations. What's the change in behavior that we want to see in or across our teams?
Celebrating successes and building trusting relationships
Graham Reed
What are your final thoughts on working with these wider teams?
Diana Soler
Product operations can be very disruptive. We're coming in to improve the environment and the systems around the teams that have a hand in the success of the product. We focus a lot on the pain, but we may not often focus on or celebrate the wins, and we want to preserve what's already working.
When I joined this company, there were a lot of things that were working super well, and we acknowledged it, but then we moved on to what wasn’t working well.
So, I’d advise individuals who are setting up product operations for the first time to celebrate and highlight what’s already working well and reassure leadership that you're going to preserve that. If anything, you're going to double down and make it better if possible. That's my first piece of advice.
The second piece of advice is when you're going out and listening to any team outside of product. Put yourself in their shoes, use language that they understand, and build that empathy and rapport because you're going to need them down the line.
When you're going to introduce something that’d be slightly more disruptive to their teams, you're going to want to have the trust of that leader to quickly roll it out or implement that change.
Adam Bennett
Antonia Landi
With organizations that are very siloed, there may be a lot of frustration on either side of the camp. I like to remind myself and remind others that that frustration didn't just come out of nowhere. People don't just close their doors for no good reason.
A big part of reopening these doors and reestablishing trust is understanding what happened before you joined a certain company or before you stepped into a product operations role.
Don't discount that this is change management, first of all, but this is about people trusting each other and realizing that we’re in the same boat. We’re not against each other, we don't have competing objectives, we actually have the same objective, and that is to deliver value to our users.
Product operations is a key role in teams today. Want to get certified in it? Our course Product Operations Certified provides students with an overview of the role so they can apply it to the teams they steward.
It's time to help product people do their best work. Take the course now.
