Interview: Jeff Wadholm, Vice President, Revenue Operations at Mindbody

Rory Brown: Jeff, obviously, it’s great to have you on Klog and the sales ops Interview Series. The first thing we’ll start out with is why don’t you tell people a little bit about who is Jeff Wadholm, and how did you get into the wonderful world of RevOps in the first place?

Jeff Wadholm: Thanks, Rory. Glad to be here. From a professional perspective, I landed into operations a bit by chance. I started my career in FP&A. I was a self-defined Excel nerd and I love the data, I love the analytics. I had sold unsuccessfully for a few years early in my career, which gives me credibility now to say I was a sales rep once. Anyway, I was in FP&A and I had a sales leader who said, “Hey, jump over here, and work in our side closer to the business.” Back when he asked that question, I wasn’t exactly sure what sales ops were, and RevOps wasn’t even a thing yet. That was 10, 12 years ago, and I’ve had just a great experience and journey since then.

Rory: And that has landed you at Mindbody today. Jeff, what we’re going to cover today is this big juicy project you’ve been working on. You’ve been overhauling your entire Salesforce, implementing CPQ, billing, new Marketo, all at once, and the angle that we talked about, which I think people are really going to be excited about is how we actually get the buy-in from the various stakeholders that are involved right from the top of the tree, right down to the users themselves, which I think is a fantastic topic.

To start things off, if we think about the project and its conception, there’s always that moment where you realise something had to be done and things had to be changed. Where do you start with working out who do I need to start planting seeds with and what does that look like?

Jeff: Enterprise system transformation like this happens in one or two ways – it’s either a push or a pull. You’re either getting pushed by someone, be it a PE firm, Board or a new C-suite, or it’s a pull through and IT, Ops leaders or a sales leaders say, “We got to start over.” I think the approach varies and tweaks a bit between those two, but most importantly, you’re essentially asking the business to open their wallet for potentially millions of dollars and you’re probably putting some business on hold. You’re going to put a throttle on the business in some short-term fashion.

I think that the learning for me in time have been that the way that we talk as Ops people on a day to day basis is not the way that we should talk when we’re selling our vision for these transformations and the value they bring.

The best example that I have, Rory, is around how you sell your vision to the CEO or the CFO or the CRO. I think the trap we fall into as Ops professionals is we say things like, “This will make our sales reps’ lives easier.” If I’m a CEO or CFO, what I hear is my sales reps will have more time to sit by the pool and spend less time closing deals. I think the vision for how we can transform our systems and gain the support of the C-suite has to come from “how do I help you grow this business”. Depending on where you are in the business life cycle, that could be one or two things; that could be how do I help you save costs and expenses? How do I help you scale revenue? In the Valhalla state of all things, great, how do I do both of those things? How can I help you scale revenue, sustainable growth, and reduce expenses?

That’s the language of the C-suite. That’s what they’re talking to with their board and their C-suite peers. They’re certainly not talking about how much time your sales reps or customer service agents are on the phone or how many buttons they have to click on an average Tuesday.

Rory: Brilliant. Presumably, in that scenario, as a revenue ops leader, you have to be pretty dialled into the metrics that your C-suites are really looking to drive and to hope to deliver at their next funding round critical financial event IP or whatever it might be, otherwise, the vision falls short, right?

Jeff: Yes. You’ll know quickly if you don’t have a seat at that table. I think the message to your executive support team has to be in line with the company goals and where they are today and where they’re going to be in the next 365 days because enterprise transformation like this doesn’t happen in a few weeks. It doesn’t come cheap, but most things that are cheap aren’t good. Again, to the point earlier, if you’re in cost-containment mode and you’re focusing on scaling EBITDA, you better come to your CFO and talk about how you believe that we can operate more effectively on lower personnel expense. If you’re talking to your CRO who’s got a huge number hanging over the head, you better talk about how you’re going to help them hit that number and not talk about the button clicks or the fancy dashboard you can build.

Rory: Brilliant. On that note, if people are reading this that are perhaps thinking of a big project, and maybe they don’t quite have that, but they need to if they’re going to make it stick. Any tips for them as to how you may start trying to weasel your way in there and actually get to be part of that conversation?

Jeff: My experience is that the vast majority of your senior leadership team would welcome that conversation. We would see that as intellectual curiosity. Sure, there may be a protective layer around the discussion that you have, but if you approach your leadership team with “Hey, I want to ensure that my proposal is aligned with our company vision in the short term, and aligned to our long-term goals”, my experience has been that most folks not only enjoy and welcome that but are happy to have it and want to support that. I’m always a fan of the direct candid approach.

If you are in an environment where you don’t feel like that’s the case, there’s a groundswell of folks of how do you connect dots and how do you talk to your peer groups? How do you align with the product? How do you talk to your sales leaders and talk about their goals? What is the FP&A leader thinking about, and what are their MBOs tied to? My recommendation to almost anybody, especially if you’re in a leadership position in Ops and you don’t have that seat at the table, this is a great way to start that discussion and have this be the spearhead to having on-going dialogue at that level.

Rory: Excellent. This initial period, we’re getting buy-in from the exec team and it’s a big project. To what extent or in what way, would you expect that you might lean on, or perhaps involve the vendors in that process? Obviously, you’re governing the process, the cultural change, the human change, the workflow change, but your vendors are a big part of that, right?

Jeff: The way I think about that is if the team that designed the problem are now trying to design the solution, we will probably end up in a very similar place. Your vendors become critical in becoming that consultant that is there to support the fact that you’re ensuring you’re not going to create the same environment we’re coming from. It is less about how do they sell ROI, or how do they share the “shiny pennies”, but have them stand in that seat with you and say, “Hey, I’m going to stand here and make sure that Jeff doesn’t go down the same path that he went down before that got us to this situation.” Or even just say, “Hey, there’s credibility and validation. We work with some of the largest companies in the world and here are some of the benefits they’ve seen. “

That’s the approach that I think is required. I know the value of a third party unbiased opinion who’s an expert role, whether it’s CPQ or Salesforce integrations or whatever CRM selection you make, is critical to the success of the project. We all believe we can go solve world hunger on our own. If someone’s waking up every single day, thinking about nothing but deploying super killer “to cash systems”, we should let our ego step aside and bring those consultants to the table with us. That will help us on that vision as we make sure we deliver on our say/do ratios with the C-suite. If they say yes, those consultants will help you make it make it a success.

Rory: Brilliant. That’s fantastic. We move from this big vision, ‘get the C-suite involved’ idea and we have to be in tune with those people. As soon as you get the green light, like, ‘Okay. We’re going to do this,” what’s the next group of individuals? It could be several types of groups that need to start working into this project. What are the reasons behind that?

Jeff: Program management and project management are the first and foremost. The value of that foundation early in the project is critical. I think the mistake you can make is  to can go out and try to gain stakeholder buy-in before you have a program plan, before you have a project plan, before you have a “what’s in it for me and what’s expected of me”. The kiss of death when you’re trying to get your peer as a CS leader or an FP&A leader to buy into your vision and say, “Hey, come with me,” is if they say, “Okay, what does that mean?” you say, “Well, I’m not sure yet.”

Programme management, project management and expertise of that third party is position B as the second spot after you gain executive buy-in. Again, it builds a foundation and a roadmap. That doesn’t mean it won’t pivot. It doesn’t mean it’s not dynamic. The kiss of death is to not have your plan together before you go to market.

Rory: Awesome. You describe it like a sales process, but obviously it’s internally.

Jeff: Isn’t that great? We have to drink our own champagne.

Rory: You do.

Jeff: For those of us in ops and enablement, who talk about process and sales methodology, we’ve got to show value before we can talk about price before we can close the deal.

Rory: Nice. The plan’s in place and it looks solid. You’re probably starting to think at this point of going to go through implementation and testing and all this stuff. If we’re going to go through all that, the people are going to adopt it and use it. Thinking about all that, how did you start to work with these people? Are there systematic ways of doing that? You have peer groups, you have people that are champions. How does all that work?

Jeff: Too early is too early. There’s a right time for having the right people on the bus. There is a design phase. There’s a core team phase where you have got to work through who those players are. There is certainly an implementation phase. All throughout those phases, the importance of change management is critical, and with change management the earlier it starts, the more likelihood of success you have. That means, “Hey, I’m going to take you off the floor from doing your day job for eight hours a week. How do we prepare you for that? How do we build discretionary time in your calendars? How do we get you out of doing the same as last year, don’t redesign what you’ve already built, and how do you get that?” Weaving in change management through those different layers is a critical element that is often overlooked. We usually wait to deploy change management when we train the end-users. I believe there’s change management all throughout and that’s around expectation setting, what’s going to change.

Here’s the preview for everybody out there who’s never done this. The first 30, 60, or 90 days after go-live for a big project like this are going to suck. People are going to question what you did. They’re going to throw mud and it gets bumpier before it gets smoother. If you’re prepared for that, that change management, having that from end to end and expectation setting is critical and often overlooked.

Rory: Obviously, if we get into the psychology of it, we know that humans are much more likely to get on board or adopt something if they feel like they’ve been part of it, or they’ve had their ideas heard or they’ve contributed in some way. Does that play into the change management piece as well? Do you have ways of weaving that in there?

Jeff: 100%. The worst thing that we can get is the gift that someone else gave us, “Hey, here’s this new process and system.” Chunking up projects like this into functional tracks or following the customer journey, then bringing as many people in for both design elements, workflow reviews, and long before you’re training end-users, is a way to have success. The quote we love and we use in my teams is, “If you want to go fast, go alone, and if you want to go far, go together.” By bringing in more people into the project earlier on, with visibility and with input, I believe we can go further.

Rory: Awesome. Maybe if we take one of the levels that’s involved, let’s say senior leadership team, your CMO, your CRO, the other people at that level, do these people need to think through that lens as well, or do you automatically think, well, they’ve got the best interests at heart? They need this to work, so they’re just going to be on board anyway.

Jeff: We all wish it was that simple. The way you can best leverage that level, the CRO, the CMO, maybe the CTO, is via steering committee and on routine updates that have the right altitude. In most scenarios, they’re not as interested in what joystick moving looks like, or deep design workflow reviews.

Back to what we just discussed is having that combination top-down and a bottom-up approach. Top-down is not just direction from your CRO or your CMO but support, “Hey, we’re really excited about this. We have realistic expectations about what this is and isn’t.” Then if you have brought the team with you in the design, implementation, and testing phase, you’re going to build that critical mass of support across the enterprise. Plain and simply, they are the hardest things that you do in your career. But massive enterprise change can also be the most rewarding. I believe that that top-down, bottom-up combination is the right approach, and that’s how we can leverage that senior leadership group.

Rory: Fantastic. If we go to the other end to say to the sales folks themselves, who obviously then have got to then use it. We’ve got to capture data through them and if they don’t use it, then we’re stuffed. To what extent do you start to get those people involved if at all to feel like they’re part of it?

Jeff: Early, often, and a focus on “what’s in it for me”.

Rory: Awesome.

Jeff: Operations professionals can’t seem to help ourselves from granting that kiss of death of “imagine all the great data we’re going to get out of the system”. Or “Once you’re in this new tool, imagine all the cool dashboards that I’m going to be able to look at”. If I’m a sales rep, I’m just going to imagine the dashboards you’re going to judge me by, and imagine how you’re going to have this new visibility and micromanage my activity management.

For me I want to have them build and design a sales workflow that works for the realities. Operations professionals have a tendency to live in frameworks and frameworks don’t always work. Instead of just saying, “Well they will probably work around the system,” sit down and have a candid conversation with your sales team and say, “How do we work around what we’ve put together now? Let’s not build that, let’s build this together as you don’t have to do that.” I think that it breeds confidence. It breeds partnership and collaboration, but ultimately if you’re building a tool and a machine to grow the success of the organisation, that happens via your sales channel.

Let’s just get into the realities that are that we ask them how do you want to work and how do you want to push the buttons, but also keep those realistic expectations. It’s not the Iron Man movies where you just look into your glasses and everything happens. You’re still going to have to put your hands on the keyboard and get into your CRM and do that. We want to make that experience exactly what you want and how do we find that ground where ops can get the data where your CRM can get visibility. Where we can track leads as they go through the system, manage your pipeline and ultimately anchoring yourself on a really kick-ass customer experience and customer journey. If you keep that at the heart, it’s really hard to go wrong.

Rory: Fantastic. Coming on to the rollout, obviously there’s going to be the testing phase you described, and imagine you’re getting a lot of feedback and things are going wrong. As you said, the first 30, 60, 90 days, things might suck. What are some of the things you can do to keep the spirits high if you like, and the belief strong when that’s happening?

Jeff: My personal approach, Rory, is setting expectations early. If I can tell you 12 months in advance or 6 months in advance, that these first 30 days are going to be crummy, that’s going to take some of the sting off. One thing that I do, and I think it’s a mental shift, is there’s this elusive go-live date. We all put a date on our system and we’re going to go live. The mindset shift I like to do is I call that the starting line rather than the finish line. They say the finish line is on January 1st of next year and we’ll finish then. I believe that is the starting line. That is when a lot of the work starts. That’s when great things can happen. That’s when your new processes will kick off.

If you’re setting expectations of, “Hey here are some of the pitfalls we can expect,” or even if nothing else, you can say, “I heard Jeff and Rory talking about it on Klog I think that that’s going to happen to us,” and start having those discussions early. It’s really going to bring down the temperature of the room and you can function them as the thermostat. The thermostat is a thing you can actually control the temperature with. Rather than being a thermometer and just saying, “Hey it’s really hot,” or even worse, being the mercury that actually goes up and down with the changing of the temperature. The goal of a program manager or a VP of RevOps in a project like this is to be that thermostat and control the temperature, allow for some tolerance, and know we’re going to have some bumpy times and keep our eyes on the horizon.

Rory: Awesome. On to the enablement side for this particular project, if you could maybe share one or two things that you did on the enablement side that worked really well, obviously there’s a ramp time, I guess, that you want people to get used to these and working back to normal working conditions or their new way of life.

Jeff: That’s right. A major success criteria that has to be in your program plan is how are we going to train all the users? How are we going to recreate those user stories? How are we going to produce content that’s in a form that people want to consume? Here’s the preview. Nobody wants to look in a 200-page Word document anymore. They want to watch a three-minute YouTube video that mirrors social media and TikTok and LinkedIn or wherever they are. Nobody wants to read the user manual. I think the role of enablement is to create a training and education program. There’s a healthy balance of creating some testing program that can help just validate understanding. It clearly can’t be punitive.

I believe the value of enablement through the project is that sanity test. “Hey, does this feel right? Are we keeping the customer experience at the heart of what we’re doing? Is this actually how sales move the joysticks? Is this really what the transition into post-sale looks like into the CS world? How does the lead really flow through there? I think you can use your enablement as a voice of the go-to-market business.

Rory: I love that comment. I reckon so many people get that wrong. Think about the modern workforce, particularly in sales, a majority of those people are going to be millennials.

Jeff: You got it. They’re not looking at 200-page Word documents, it’s Twitter. It’s 180 characters. It’s a 30-second TikTok. That’s the life that we’re in. We’ve got to find a medium instead of long-winded job aids with screenshots that are outdated every 30 days. How do we pop out quick content that’s video-based, that’s audio-based? Do a podcast. How about that? Let’s talk about different ways that we can share content in a more modern media format.

Rory: That’s fantastic. Is it hard to maintain, because obviously, when you go back to the standard 300-page Word document, you get detail and process in there, whether anyone through the test of time actually ever followed everything that companies would roll out or not, probably not, but is it hard to keep the quality control when you’re putting shorter punchier content out there?

Jeff: Yes. I believe it comes down to your trust in your teams and your reps. An example where you’re going to re-platform Salesforce, maybe you’re moving from Classic to Lightning, maybe you’re going from Marketo to Eloqua or vice versa. Maybe you’re going to move from outreach to sales or Gong to Chorus, whatever it might be, there is a base knowledge there and your enablement team’s function is to train on that base core knowledge. The 200-page SOP document presumes everyone’s an idiot and that is just not the case.

In 2020, despite all the headwinds we’ve faced in our world, our people are in our systems, they’re in tools, they’re interfacing with modern UIs. The gap from where we were to where we’re going, we should focus on those critical change management areas. We should focus on those areas where, “Hey, if we screw up, there’s downstream implications,” and less about, “Hey, here’s how you create an account in your CRM.” That’s the SOP version. You can fly through that in a quick tutorial. That’s implied at this point. Everyone lives on their phone, they live on the internet, they live on the web. It doesn’t matter where they are. We’re in a multimedia world.

Rory: Brilliant. Moving towards the last stages of the project, this might be something you’ve not done for this particular project yet, but I’m sure you’ve done in the past. There’s two parts to this question. How do you start to measure what success is, whether will it be qualitative or quantitative? The second part to that question is actually what you should have covered before is, where do you start to consider what success will look like?

Jeff: Actually, it does tie into what we talked about earlier. You must have those phases of executive buy-in early and then into program management, then selling the vision to your peer group and finally to the people who are going to move the joysticks. As we talked about bringing more people involved early, before design, before implementation, before testing, I think that event is the right place to build your success criteria and to let each one of those tracks build their own success criteria and then run that by the steering committee.

“Hey, here’s what we think good would look like, and here’s what we think the material change would be. Now, executive steer co, what do you think? Is this the right stuff for us to look at and measure? Is this aligned with your vision for the project and what’s next?” Set them early and write them in a hard pencil, not in pen, and know that that may shift, but I think if you have that early, that can be something you anchor to. “Hey, are we still pointing towards where we thought we were going to start?” Then as you get out post-go-live, I think you got to make sure you track it and check those boxes to make sure you’re tracking and you’re going to inevitably add new success criteria.

“Oh, we have new capabilities we didn’t think of.” Starting early is good because it helps with that motivation. As you mentioned earlier, that law that’s going to happen as some of the challenges come in the design, and this doesn’t work, and this integration isn’t talking, the API happens, you can still point to those success criteria, “Hey, we’re focused on this.”

Rory: Nicely put. I don’t know if you’re comfortable in sharing maybe one or two success metrics as an example of the stuff that you looked at.

Jeff: Your average RevOps team should be thinking about time and motion studies. How much time are we spending in administrative work for a marketing content designer, someone who’s doing lead management? How about an SDR, right? How many clicks? How many buttons? How many moves? How long does it take to configure a quote or an order? Average implementation times, call times, moving into the CS-Sat, I think you want to be materially moving the business forward.

If you’re focused on things that are inside of the project, like how fast the cart moves inside of your CPQ environment, you’re missing the point of us saying, “Hey, we want to be able to put more through the pipeline.” Expand the pipeline and make it bigger and not have people have more time to sit by the pool, but to be able to say, “Hey, CEO, when you have your board telling you you’ve got to grow by 25%, we’ve now built scale into the business where we can do that without needing to go hire 40 more reps or 20 more STRs or 30 more CS agents because we’ve built that into the plan.”

Rory: If I’m just thinking about this visually, would it be almost sensible to suggest if you looked at the funnel of your sales process and you compared it before project/ after project, what you should see if you have two bits of that funnel, you had time per workflow if you like, if we split this funnel into workflows, and you also have capacity, so how much can they actually handle with these new processes? Would that be a fair way to compare one with the other?

Jeff: Yes, I think it’s exactly right. You can look at the volume of leads that can go through your pipeline. You look at sales rep outcomes. Maybe this process doesn’t create bigger deals on its own, but it better increase the amount of deals that a rep can do in a month. You better see our net new sales going up every month into the future. Hopefully, if you’ve built CPQ pricing approval workflows, you could get those bigger deals, but maybe you don’t have elastic pricing, but you should be able to get more volume for the same customer journey.

Rory: Fantastic. Well this has been fantastic Jeff. Is there anything else you want to add?

Jeff: I do. The thing I’d love to share is there are some obvious pitfalls that people walk into, I have scar tissue from walking into them myself. The things I say are the most important about these projects, maybe it’s a big enterprise, maybe it’s through Salesforce, maybe just one piece of your tech stack is the data migration piece. But taking your data out of this system and putting it into the system can’t be overstated in its importance because you only get one shot at it. You can’t go back and fix that once your business is moving forward because by the time you know there’s a problem, you’ve already created a whole bunch of new data. The data migration component and validating that and bumping out against people you never would have thought to validate against, you should be going to accounting and billing and legal and sales and CS and product and saying, “Does this look right? Does this mapping work?” I think that’s really important.

A phrase that I love is complexity doesn’t scale. We all say that we’re special. We’re snowflakes. It’s different. Here’s the headline. When Salesforce designs CRM, they know what the best practices are. Change your business process to fit the system. Don’t change the system to fit your business process. That is the one scalable kiss of death. We can all fall into “Oh, we’re so unique,” change the process. It’s way easier than maintaining that system change for the lifetime of the system, which could be years into the future, probably in new versions, new iterations, that just all becomes much more streamlined. Keep it simple. Those are the two biggest pitfalls. I think if you can get ahead of those early, have those in mind throughout, you’d have a lot more success.

Rory: That last point is brilliant, even thinking about ourselves a little bit there.

Jeff: Every single company, it’s “We’re different. We’re special. They don’t know about our business process.”

Rory: Well, someone came up with a quote once, a chap that used to mentor me many years ago. He said that every business thinks that it’s different, but at the end of the day, when it comes to the critical financial event, they’re all trying to look exactly the same.

Jeff: You got it. Its for-profit, nonprofit, the end. The business models, you fall into one of them, and if you’re a for-profit company, we’re all doing the same thing. I say it’s cheeky. Of course, we’ve all got our things that are different from the standard, but to the extent, you can try to streamline as much as possible, keep it simple. Keeping it simple will scale into the future and complexity just doesn’t scale.

‍