This article was taken from a presentation given at the Product Ops Summit in May 2022. Get the full talk on demand here.

My name is Gabby Peralta, Product Operations Manager at Tealium, and former Product Ops Lead at Sana Benefits. This article will focus on product operations and something that's very hard: change. More specifically, change management.

You'll learn about:

My role at Sana Benefits

Sana Benefits is a health insurance company that aims to make quality health care understandable, accessible, and affordable.

I fell into product operations, as I think most of us do. I originally come from a sales background, and prior to July 2019, I was working in sales for a technical staffing company. I then moved over to SkySlope, where I was a Customer Success Manager until the company saw a need for product and product operations, so I moved over into that role and started building up the team there.

I then joined Sana Benefits in August 2021 as our 1st Product Operations Person. My focus in the six months in the role was learning more about the organization and both the product and engineering teams.

Fast forward to January 2022, my focus was primarily on creating a product operations vision at Sana for 2022 and beyond. Currently, I am looking at leveling up product operations for the organization and using product operations and specifically change management to improve Sana and their product and engineering teams.

4 ways to successfully manage product operations

1. Drive continuous improvement within the Product & Engineering organization

This largely involves process changes and is a large part of my role. It requires meeting with both product and engineering organizations to define the metrics that should be tracked, as well as share best practices with both the product and engineering teams.

2. Establish and manage internal knowledge artifacts

This is all about onboarding material and creating and improving a bug board. Prior to my role at Sana, this involved developing customer feedback loops. These artifacts can look like a lot of different things, depending on where you're at.

3. Foster a culture of trust and engagement

This is so key in product operations. We are very fortunate at Sana to interact with each of our product managers, a large amount of the engineering team, as well as the leadership team of both organizations. In order to have effective change in product operations, your team has to trust you and be willing to engage with you.

4. Best current thinking (BCT)

Sana is a startup company, which means that we're constantly evolving and things are always changing. What we do today will definitely look different from what we do tomorrow, but we’re always using our best current thinking.

What is change management?

The Association of Change Management defines it as: “the practice of applying a structured approach to transition an organization from a current state to a future state to achieve expected benefits.”

Change management is a catch-all term for all the ways of preparing, supporting, and helping teams as well as individuals. Even entire organizations undergo change.

If you're in the product space, you know that your product and your teams can change. Change is happening all the time. Are you experiencing change? And how does that change make you feel? I've asked a lot of people this question. More often than not, people do not like change. Change is very hard, but that's not to be said that people can't undergo it.

3 components of effective change management

Now that we know the definition of change management, I find it helpful to break it into three different components:

1. Understand the change

This is where you identify the change characteristics. I like to start with the following questions:

  • What’s being changed?
  • Who's being impacted by the change?
  • What’s the scope of the change?
  • What are the positive and negative impacts of the change?

As you go through this list of questions, you'll start to uncover even more questions to ask, and at the end, you'll likely have a much better sense of the change and its intent.

2. Plan the change

This component also holds many questions, such as:

  • Who has to do their job differently?
  • How and why are we doing this change?
  • Why are we doing this change now?
  • How many changes are currently taking within the organization?
  • Who's going to champion the change?

Oftentimes there's a lot of change going on, so you want to make sure you're implementing the right changes at the right time. It's also helpful to find other champions who will help you with the change as well.

Throughout these three components, it's really important to think about your end users. In my case, this would be the product managers. What's in it for them with this change? You really need to take your employees and your co-workers into consideration as you go through the process.

3. Implement the change

When you're in the implementation phase, it's really important to provide clear steps and timelines for your team for the change; the team wants to know exactly what they're going to have to do for this change and when they're going to have to do it.

It helps to start very small with your changes as it can be really hard to make large changes all at once. Try to break them down into bite-sized changes and implement them in phases. So instead of changing an entire process in one week, break it down into four weeks.

As your team is going through the change, it's imperative to keep their feelings in mind. The success of the change relies heavily on how your team feels about it, and therefore how receptive they’re going to be in order to make it happen.

Fostering a culture of trust and engagement is key for change management; you want to be a trustworthy employee and you want to understand how your team is going to feel about the change before you make it.

Putting the 3 components into action

So now that you know about the three components of change management, I'm going to walk you through an example of a change that I recently implemented at Sana, which is the bug process.

We're still currently going through this process, and I think that's another important thing to point out with change management. Oftentimes you think the change might be complete because it went into effect. However, there are a lot of things you have to do to make sure that that change keeps happening and keeps moving forward.

Understand the change

What?

With each product, you get bugs and feedback from your customers. We didn't really have a bug process when I joined Sana. Customer success and member operations could all submit bugs, but there were no SLAs or anything on the bug boards. So these bugs often just sat there for weeks until they escalated up the chain and the customer didn't have access to care, or was running into some other issue.

Who?

When I joined the team, it was really important to understand exactly what needed to be changed about this process. It all came down to how our teams submit and handle bug requests. Once I understood what needed to be changed, I thought about who was going to be impacted. These were the internal teams such as product managers, engineers, customer success, sales, and member operations.

Scope?

Once I knew the what and the who, I thought about the scope of the change; who's work was going to be impacted, and by how much? Product and engineering workflows were going to be largely impacted, but the customer success or customer-facing teams would be less so.

Positive and negative impacts

Once I knew these three things, I thought about the positives and negatives of this change. For the positives, we were going to manage our bugs a lot better and we were going to learn more about the types of bugs that were coming through so we could be aware of similar issues, deploy, and fix them.

On the customer front, we would be able to respond to our customers quicker. When these bugs come through they can cause care-blocking issues so customers can’t get access to their health care, which is obviously a major problem.

The negative impacts were that if this change wasn’t made for the bug board then things would continue to fall through the cracks. Customers might become upset about their issues being unnoticed and unfixed.

Plan the change

Who?

When planning the change, take into consideration the people who have to do their jobs differently. Let’s focus on the product managers as an example. With the bug board process, product managers had to create an on-call rotation. This way, customers were now able to contact us from 7 AM - 7 PM CST.

As such, product managers now needed to be available one week at a time for this timeframe. This meant changes in work-life balance, and changes to their personal lives because they were now working from seven to seven instead of nine to five.

In addition, the bug board was an extra task that originally wasn't in their job description. So I was now asking the team to go into Asana, look at all the bugs that were coming through during the week, and make sure those bugs were getting to the right people to get fixed, and were also being prioritized within our team pods.

Internal customer-facing teams like customer success faced a change to the submission process. We started marking tickets on whether they were urgent, low impact, or if they could wait a couple of weeks to be dealt with.

Why?

When planning this change, you have to think about the why. What happens if we don't make this change? Why are we making this change?

On an extreme scale, we risk losing customers if we don't fix their problems. So we're making this change in order for our customers to have better access to their health care.

Why now?

Sana is very much continuing to grow, and as we grow, more and more things tend to go unnoticed. Putting this process in place allowed for the team to make sure that there was a manageable way to follow up on our bugs, have good insight into the things coming through, and that changes could be made for customers.

Champions?

You now need to think about who's going to champion this change. There are a lot of things that are changing: the rotation put into place, and product managers needing to be available once every couple of weeks during the new on-call rotation.

Still being fairly new to the team, asking some of the more senior product managers to be available from seven to seven was very daunting. I had come into the role and made a lot of changes from day one after listening to the team, but this was the first very large change. So I thought: who can I bring in to help me champion this change for the product team?

The solution was to bring in our chief product officer and make sure she spoke at the meetings to help put this change into place. For some of our other internal customer-facing teams, it was meeting with the director of customer success. And then down the line, it was meeting with the VP of engineering because implementing this process was now going to require the engineers' time.

I had to make sure that each director of each department and each manager knew that this change was coming and could help me explain why we were making this change. Providing all that information to these champions and having them relay it down to their teams was very important.

Implement the change

Once I understood and planned the change, it was time to implement the change.

Provide clear steps

I reached out to our product managers and scheduled one-on-one team meetings to let them know that the change was coming, that I was looking at this process, and to expect something in the next couple of weeks.

It’s important to ensure that you're giving your team enough time to get ready for the change that's coming through. You also need to evaluate the size of the change. This bug board change was fairly small in the grand scheme of other changes that we've made, so the team was only given a few weeks' notice. If larger changes are happening, you want to give your team a lot more time to prepare.

Allow for feedback

Once I provided clear steps and scheduled the one-on-one time, we had some product open-door sessions and many different meetings where I allowed an allotted time for feedback.

It’s really important to talk with everyone who's going to be impacted by the change to make sure that they're on the same page, that you answer their questions, and you're considering their feelings. You need to be that employee whisperer who’s really in touch with what's going on with your team to make the change a little easier on them.

If you can't talk with everyone in the organization, make sure that you're talking with the department heads or the managers of certain teams so they can relay those changes and explain what the impact will be.

The key to success in implementing change is allowing for feedback and being flexible. This isn’t just feedback on the process, but feedback on you and how you've implemented the change.

There were a lot of things that I specifically didn't think of in the process when implementing the bug board. For example, with the 7 AM - 7 PM on-call time, I didn’t even take into consideration that we have people on the West Coast. So at 7 AM CST, call time is 5 AM, which would be a major change for some people.

I wouldn’t have known about this had I not opened myself up to feedback and scheduled that time for the team to raise their concerns in the process. As soon as the team shared this feedback, we immediately implemented a change; You could have someone cover your two hours in the morning.

Provide positive reinforcement

Providing positive reinforcement along the way is really important, Share with the team how the change has been impactful. When our team is going through and fixing bugs, we let them know when that fix has really made a difference. Give positive feedback to the teams and encourage them to continue this process.

Overcome change management challenges

Following these three steps is going to be key to your success. Make sure that you understand the change, you're being the employee whisperer, and you're thinking about what's in it for your team when planning the change. And when you're implementing that change, really open yourself up to feedback.

We all face a lot of challenges in product operations. I would encourage you to talk to others in the space. Share what you're struggling with and ask for feedback. Chances are there are several others of us who are facing the same challenges.