Dorie Wallace is a strategic, client-focused leader with a passion for serving customers. She began her career in customer support at Blackbaud and, from there, moved into product management because of her deep product and market knowledge. Dorie finished her 21-year tenure at Blackbaud as Vice President, Customer Success before transitioning to Senior Director, Operational Excellence at Benefitfocus, a Voya Financial business. She is most recently former Vice President, Product Operations at Anthology, a technology company that serves the EdTech industry.
In our conversation, Dorie talks about the role of product operations as the “product managers of the product managers” — using data to provide an impartial perspective to PMs, thereby enabling them to spend time doing their job rather than creating their job. She shares her experience aligning an organization on an eight-figure initiative to migrate clients to a SaaS solution, as well as spearheading a new adoption program to address clients’ change management challenges.
Product management, for us, was about building a strategy and implementing it to market differentiated products and solutions. In product operations, we were a team built for a group of 100-120 product managers and 50 different products. Our role was to build out processes and solutions so that the product managers could spend time doing their jobs rather than creating their jobs.
For example, how do we do end-of-life? Well, a product manager doesn’t do end-of-life very regularly. So instead of having them figure it out from scratch, we built a toolkit to say, “Here are the 10 steps, here’s the plan to follow. And if it’s a big EOL program, we’ll partner with you and help you lead it throughout the organization.” It’s that kind of approach. We thought of ourselves as the product managers of the product managers.
A key thing to being a product manager is being able to lead by influence. Everything we do when we’re in product management or product operations, as a piece of the bigger product strategy organization, is through leading by influence. So collaboration and cross-functional collaboration are super important. For our organization, we had two key product strategies that were significant and cross-reaching enough that our team partnered with the VPs of product management, who were the executive sponsors. We managed the program across the entire company.
In this one example, it was also a corporate initiative — it was a migration effort on a product line that was responsible for about one-third of company revenue. We were moving a product from on-prem to a SaaS solution, and the progress was slower than the company wanted. The initiative was to drive adoption, and therefore retention of the SaaS solution to protect that revenue. And since it was focused on a specific product line, we partnered with the PMs, the VP of product management, and the VP of product development.
With every initiative and every strategy, you always have challenges. First of all, the company had just done a pretty decent merger, so there were cultural challenges there. But one of the biggest issues we had was ensuring alignment across the organization. This is where our role in program management and partnership with all the other leads came in. We recognized that we needed to make sure we were all on the same page, and it turns out that we were not in several areas.
There were valid reasons that people were going in different directions and that we weren’t aligned. Nothing was malicious, but the perception was that the product wasn’t ready for clients to move to it at the project kickoff. And perception is reality. We learned some processes were still in place that hindered us. We would never be successful with this project because of that.
For example, other folks in the organization had actually encouraged clients to stay on earlier versions — to not move to the full SaaS solution. It was like a punch to the gut to learn that. And while it was a corporate initiative, we couldn’t go in, lay the hammer down, and say, “Nope. You’re not doing that anymore.” At that point, it was about getting data and executive alignment to gain their support and trust, which enabled us to make those organizational changes.
The phrase I know the team was tired of hearing was, “We have to burn the ships.” You’ve got to eliminate the safety net of having the old version to rely on. That will, in part, force our organization to make the necessary decisions to drive the improvements needed to get to the migrations. Part of our approach was having to force our teams to get on board through implementing process changes. In part, it’s the stick, but you’ve got to use the carrots too, right? We asked, “What are your needs? What are your challenges?” We had to understand our team’s needs and solve them to build trust to drive these organizational changes.
In product operations, we can be that fresh perspective. We don’t have a horse in that race. We’re impartial. That, I think, gave us the freedom to dig in and ask more questions, and the right questions.
Dozens of problems were identified. In partnership with the teams, we completed a very detailed dive into the challenges blocking us from driving migration. We’ve all done the post-it note exercise. But in my experience, you do the Post-it, and you pick two or three things, and you go do it. We looked at every single one of the challenges — dozens of data points. We put together a pretty significant resource plan to get resources and funding from the executive committee to be able to do this. Ultimately, we were tightly partnered with each of those teams to create plans that would solve the challenges that were specific to them.
We sat down and went through all the data. We said, “Let’s go through these clients and talk through them, and look at examples of why they haven’t migrated.” First, we had to do a deep-dive data review, brainstorming, and listening sessions with a lot of open-ended questions. On the team, we had certified project management professionals who were really good at asking open-ended questions. It was important to get down to that root cause so that you’re not solving a symptom, you’re solving a root issue. When we were done with this plan, it was like a 100-plus-page PowerPoint presentation. We, of course, included an executive summary. This wasn’t just a $50,000 problem, this was an eight-figure problem. It had to be really well thought out and planned.
The product management team did a really great job of getting client feedback. They did focus groups on the design level, the development level, and the deployment level. They got the feedback, they adjusted, and managed the hell out of that roadmap to solve problems in the right order in terms of the urgency. I think within a year they had more than 20 percent of the clients involved in focus groups.
I’m a sucker for a closed-loop process. If I ask you for feedback, I need to tell you what I did with that feedback. The PMs did such a good job because they used the community to find users. They got qualitative and quantitative feedback from focus groups so that they could truly use data to determine the importance of features and how long it takes to develop them. And then they would post articles back to the community, saying, “Here’s what we did with your feedback.” It was awesome.
Combined with listening and talking to support and all the client-facing teams, our team had a really strong client idea portal. I’ve seen a lot of these, but they used it as a way of talking to clients. And our product operations team led the portal. That was something we tried to do with all the teams. We had different operational-level agreements (OLAs) and things to make sure it didn’t become a black hole of information. What made the biggest difference was using it as a communication tool, not just a one-way suggestion box.
This is one of the things I’m most proud of because I haven’t seen it done before. The adoption program we built created tools to address the change management challenges that happen with any software change. The people on my team went to conferences and talked to clients directly to learn about why clients weren’t migrating. Yes, there are product challenges and pricing challenges that deter clients from migrating, but a widespread problem was getting users to change. So the adoption program had nothing to do with the product itself, it was about helping users adopt and change the solution.We created this strategy and one of the leaders on my team made it successful.
People will always struggle with change, especially when it’s a significant change or on a tool they use every day. We had tons of tools within the company to help with the product side. But what we didn’t have and what we heard is they couldn’t get the rest of the organization to join in on the change. So we built an online portal that provided a ton of tools that made change management easier.
It doesn’t eliminate the need for change management completely. But we made all the things that power users, internal advocates, and whoever it is needed to get started and lead the change management easily. Like project calendars or PowerPoints that they could use to deliver training or email templates that they could use to gain executive buy-in. We put together a project plan that detailed the steps on how you want to migrate. We created a “product” of materials that were relative to the change management related to migrating. It wasn’t completely product agnostic, but it was everything they needed to be able to run the change management and the program of making this migration.
We knew that if this process was huge for a large organization, it could be like nine months’ worth of work. And because that’s overwhelming, some people would not even want to consider the idea of migrating tools. We really spent a lot of time making sure these were the exact tools they would need and could be editable and curated. Because we made them log in to get access to this, we would know what stage of the migration they were in. That way, we could focus it for them, like, “We know you’re at this stage, so here’s what you need next.”
This was really a group effort. The client success teams were the ones who talked to the clients to get them to migrate and helped them through the migration. Partnership there was super important. With the adoption tool, specifically the adoption portal, we sat in on calls with them and with their clients, so we could hear it directly. The CSMs were all individually creating these tools for their clients, so we leveraged all the stuff they had. No reason to start from scratch. We just rewrote it in a singular voice.
We were meeting with the directors of those teams several times a week. We made sure that we served them, as well as partnered with them. So we put data together for them. We were honoring their experience and their knowledge about the clients. And a lot of them were former clients, as customer success managers often are. We thought about them as our customers too. So when we created this online portal, they were right there with us.
As an example, in the idea portal that I mentioned earlier, we built a tool in the idea portal specifically for customer success managers. That way, when they were talking with a client, they could easily say, “75 percent of your ideas had already been implemented.” It served the CSMs. That was a key piece.
I am obsessed with the customer experience. My family grew up in the hospitality industry and owned restaurants — they had me bussing tables when I was 10. So it’s always about the customer. I think the more and more we get into technology and usage, the more we recognize that we are all customer service organizations that specialize in different areas. It’s too easy for customers to leave nowadays, so you have to think about the customer experience.
I think every person in every role in every company should talk to clients. When I had the VP of customer support role, I got all 30 leaders together and said, “All of you need to call five customers by the end of this week.” They were like, “Okay, we talk to customers every day.” I’m like, “No, you talk to escalations every day. Go call randomly five customers.” And then we used that information to create our support strategy.
And I have found client quotes to be invaluable in the executive buy-in process. You have to have the quantitative data too: the surveys and the usage. But if you can get the right quote that captures the right need or sentiment, you can change the world. I firmly believe that.
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?
Concept evaluation bridges the gap between what seems like an out-of-the-world idea and what users truly need.
Nick Ehle talks about minimizing dependencies by designing teams and organizations to be as empowered as possible.
Value-based pricing is about using the perceived value, also referred to as willingness-to-pay, to set the right price points for the product.
Carolina Devia Angarita about the importance of understanding who your customers are and what they’re thinking when they come to your site.