I'm here with Rev Ops review with Art Harding, who's the COO of Tapcart. He was previously COO of People.AI, as well as SVP of GTM Strategy, Planning and Operations at New Relic, which is a mouthful. But in short, he is an expert of all things ops, RevOps and really scaling from earlier stage to large scale. He's seen both sides of the fence, whether you're large enterprise, trying to refine your tech stack and your rev ops function as well as a company that's in hypergrowth mode. Art, great to have you. I'm going to kick off and start with just an easy question, really easy. How have you seen tech stacks create drag on revenue? And I would love to hear just examples of that, whether that's earlier stage or later stage.

 

Art Harding:

I think first of all, Kate, thanks for having me. Great to chat with you again. And this is a topic we both find very interesting. We all initially go to logically of course, how does our back office tech stack business processes, technology and overall architecture and particularly the integrations impact our top line. But I actually think it kind of cuts both ways in terms of, it can certainly impact top line and revenue initiatives, but initially it will probably show up as inflated costs as you try to resist the impact to top line. No one's going to consciously let their back office tech hit the top line. At first you're going to throw resources at whatever inefficiencies or back office problems you have to just power through it and it may actually get you through a short-term hurdle or hump, but then later it will manifest itself even larger.

These types of problems don't get better with time. We'll often make the joke that tech debt or business process debt is not wine, it's more like milk. It doesn't just get better over time. And so what will happen is the way it will impact the business, I believe some of the big inflection points that are maybe obvious for those of us who work in the back office is either changes in your go-to market strategy, you're entering a new market, whether it's a specific vertical that may have different regulations, whether you're changing geographies domestic to international. You start entering into multicurrency, multi-language, maybe different ways of doing things outside of your business such as your partner ecosystem. Your partner strategy may look very different internationally than it does domestic. Or simply going up market. I had dinner with someone once who said going up market like growth is easy to order off the menu, but not everyone can choke it down when it actually shows up at the table.

We all like to say, oh, I'm going up market or I'm focused on enterprise. And that's not just the go-to-market strategy, it's a company strategy. Everyone goes up market, not just the sales and marketing team. Everyone from the legal department to your rev ops team to your technical architecture, certification, et cetera, compliance, everyone goes up market or everyone goes into fincer or everyone's going international. It impacts who's building your product and how you represent that at the end. I think to summarize that, it's really inflection points where you're either changing the market you're going after or you're moving from too. You're changing your pricing or your business model. You're going from straight subscription into consumption or you're releasing new products. Any of these business initiatives that are going to maybe change your motions or your buyer customer journey is where tech decisions that you made in the past, which could have been perfectly logical, urgent solutions to very near term problems.

You and I have talked about the early mindset of an early stage company about being focused on what maybe is most threatening to your business early on. And you start with this survival mode and then you have to transition into that thrive mode. And I think we make business process and technical decisions that are completely appropriate for the time and then we promise ourselves we're going to revisit it later or we're going to invest in this differently or we're going to make it better and then we just don't. And these decisions start to accumulate over time, 10 million, 50 million, 100 million, $200 million in ARR and you're still operating a business process that made complete sense at $5 million, but at 200, maybe the person who made those decisions isn't around. People are walking around, why do they do it? What were we thinking? And what you were thinking was completely appropriate, but you've been through a number of step transitions since then.

Kate McCullough:

I'm curious, you're COO of Tapcart right now, which is within the Shopify ecosystem. That's a big difference between people.ai or New Relic. How does the type of company influence it or is it sort of a universal principle that as you're scaling and changing your direction, regardless of the type of product, you're in a faceless inflection?

 

Art Harding:

Well, I think what's interesting, and I could talk forever about my new place, but if I try to answer the question I'd correlate that while Tapcart operates in the Shopify ecosystem, we're an app that customers can download from the Shopify marketplace and we work with businesses that have selected Shopify as a core platform and therefore we help them get more value out of that investment, et cetera. People.ai, while rev ops platform was part of the Salesforce ecosystem and New Relic was part of the cloud, AWS and Azure and Google Cloud ecosystems. And so it's very rare today that we have technology that exists on its own, not somehow either with a relationship of some kind, it might be a social media platform, it could be an infrastructure platform. And back to inflection points, there is inherent impact when your technology runs off of, feeds off of, or at least orbits around one of these platform planets.

 

They're changing their business models, they're changing their interfaces, they're changing their APIs. And what is common is any of the companies that are in that ecosystem tend to look up to that platform provider for the way to do things. Salesforce has a way of doing things, Shopify has a way of doing things, and AWS has a way of doing things. And so if you're a smaller player in those larger ecosystems, the habits, tendencies, and behaviors of those larger players will actually matriculate in your organization. You're probably going to hire people with backgrounds from those companies. You're going to look up to those companies for best practices and recommendations. The recommendations Shopify may give to its ecosystem are very different from what AWS would give at New Relic. But I can tell you we have people come and go inside of these organizations from these ecosystems. And so it impacts how you do business, not just the technology that you're actually running.

 

Kate McCullough:

That totally makes sense. In that vein, going back to something you said, which is about the urgent versus long-term, I think that as humans we tend to get focused on the thing right in front of her face. We may not see that this fire in front of our face is a short-term one, it's not going to turn into a wildfire, but we tackle it anyway. Or we don't see the fire that will be a wildfire a year or two from now. We don't have that anticipation. I'm curious how you balance out that perspective of short-term versus long-term thinking, particularly with a tech stack. And I know from a founder perspective that you can architect the perfect process and labor it way too much when in fact you need to do the shortcut to get to the end. And there's choices that you make between these two things and it's just wisdom to choose. But I'm curious how you think about it from that perspective for a COO, CEO or RevOps leader, how do you weigh those two things?

 

Art Harding:

Sure. I would say there's two dimensions that weigh not just on myself, but a lot of folks who find themselves in the role of helping to arbitrate the decisions for what is often probably where an early-stage company grows up, which is this bias for action, natural sense of urgency, being aware of near term threats and opportunities because as your smaller, of course, your number one competitive advantage is your ability to move quickly. One of the things that I'm most aware of, I certainly don't want to rob a company, a leader or an individual of that natural tendency. It's a very powerful instrument in the orchestra as one of the analogies I'll often use with someone whose instrument is a bias for action or acting with urgency, right? And so it's neat to think that we're all going to become balanced leaders or operators or in this instance musicians, but in fact, we all probably either have a violin we love to take off on a solo or that triangle we like the bang in the back or whatever your role is in the symphony.

 

And I think it's important that if you think about there's classic matrix around prioritizing urgent versus important, the Eisenhower matrix in terms of is something urgent or important or is it important but not urgent? I don't think any of the quadrants around what's urgent or important, if you ever look at sorting your workload like that are more or less important. What's important is when and how much to operate in each square. There's periods of time where you absolutely should be indexed primarily on urgent important items. As an organization, I'm not talking about individual productivity, I'm talking about you're a leader of an organization, where do you want their energy? There are times where the urgent important matrix is where everyone should be. That bias for action, those quick moves, and to your point, just hacking through something when you know you're doing it, but you also know it's the right thing to do.

 

There are times where that's absolutely true, but there are costs for everything. There's trade-offs for everything. When you're hacking through that, the question that we have to ask ourselves is when and who is going to address this systemically before we start compounding these decisions over time? And an organization can actually get addicted to operating in this urgent important matrix. And as I'm talking with teams, I'll ask them, if we're constantly operating in the urgency box that we think everything's urgent and important, first of all, not everything's probably as important as we thought, which means we're also treating unimportant items as urgent. What's suffering? And what's suffering is the non-urgent important stuff, right? We can think about our personal life to a lot of analogies of things that we know are important, they're just not important today. We just keep kicking the can down the hill.

 

Enterprise architecture, enterprise integrations, and I often find it's when the business processes across departments or across platforms are probably your highest risk points because you don't just have to maintain the business process fit for your business. You don't just have to manage the technologies fit for your business process, but you also have to manage the integrations to other systems that as you grow, you may no longer have full control of. Where the lines of control and influence at a 50 to 100 person company start and end are very different than 1,000 to 2,000 person company. And so what was this nice, neat integrated package with centralized decision making authority now suddenly is distributed across three different departments with three different budgets. And somewhere along the way maybe we weren't maintaining some of those intersections. I think as we grow and scale, that's where the risk starts to manifest itself, where these decisions, where the funding and the investment was all within one department. And as you scale, the responsibilities not only get larger, but they can get more distant from each other.

 

Kate McCullough:

Do you think that's compounded by the emphasis on CLTV, meaning now it's about customer lifetime value much more than new logo. And I think that's the thing that VCs and PE firms are looking at is just how are you growing customer with an expansion motion? Arguably I think what I've been seeing in the market is that means that you really have to play well with other teams to create that customer journey because the customer journey may have, I don't know, usage pricing which pulls from the product. Suddenly product and ENG is involved in what was a sales and CS motion before. I'm curious what your thoughts are as sort of the evolution of the industry towards this more seamless customer journey. How is that breaking down this siloed decision making if I interpret that correctly?

 

Art Harding:

Yeah. I think it's interesting. We always talk about what the investment community is looking for or wants from a business. I think at the end of the day what they're looking for is the creation of value. And when economic times get challenging or there's a lot of variability into it, then retention and expansion of existing customers becomes the top priority. And when we have the ability to invest and be aggressive, acquisition becomes one. But I think at the end of the day, most investors that I look at are looking at not just the lifetime value of the customers but the lifetime value of your company. Are you making decisions that are going to continue to expose new addressable market or penetrate that addressable market? And of course we're all focused on customer acquisition costs and some of that, but the only thing more expensive than acquiring a customer would be losing them after you acquire them or building technology you had revenue plans for but fail to monetize because you didn't have a new product introduction or a go-to-market readiness mindset or even a commercial mindset of what it was going to take to bring a new investment to market and have you properly prepped your install base for this new technology that now is going to be an uplift or an add-on as your install base.

 

And I think that's one of the things that's easy to forget as an install base is something we become very proud of when we're acquiring it. But then as the company grows, it actually does have a gravitational pull on your roadmap and your responsibilities and your investments. And so it was something you so desperately wanted for a long time. Suddenly put some weight on the organization, now you actually have those customers and that install base is a responsibility as well as an opportunity. And I think back to when we talked about what can be some of the impact of some of these decisions, introducing a new pricing model and feathering that into the buyer and customer journey across the different functions can really be something where your business process and your technology around things as maybe obvious or front office as how you price and quote your products, which for sales or customer success team is part of their everyday life as they're landing, expanding and renewing customers.

 

Pricing and packaging is the end of the line for them, but for product teams, for rev op teams, for finance teams, for deal desk teams, for product managers, for everyone that's trying to take this huge investment in our product and bring it to market, how we actually quote, price, discount, manage not only is a cross-functional effort that is going to touch a couple of different systems along the way, it's also something that is 100% chance of changing. And it is a little surprising to see that the industry has evolved in so many different areas, but the conscious investment we make on pricing and packaging and when those decisions get made and how they flow through our systems of work to empower the people that are customer facing feels like a real opportunity that with many shared responsibilities across organizations, everyone knows it's important, but it's not squarely sitting in one person's desk.

 

If you think about a CFO, she may be looking at the margins and discount performance and a lot of really important financial metrics. Your customer success leader, support leaders are going to be exclusively focused on your install-based customers and their reaction to this change and how we're pricing and quoting. Your sales and marketing leader are going to be top of funnel thinking about how do we land customers with the right expectations and get the sales team equipped to anchor value that should be associated with this new pricing and packaging and not selling on the old value prop with the old pricing just because what we're used to. Now we have to first and foremost expand and change the value prop and then sell into it.

 

Kate McCullough:

This is so important to get products out to have that agility. And I would be curious, what's your tech stack maturity model? What are the inflection points where you need to reevaluate the tech stack or think very long-term about what you're putting in place, because I see a lot of short-term decisions without really looking at the business requirements two years or three years from now. And these are really sticky products. How do you think about that with companies? What are the definitive inflection points and how do you think about evaluation?

 

Art Harding:

The inflection points we covered earlier in terms of they tend to be obvious to the company that you're at an inflection point, we're going international, we're going up market, we're going into a specific, we're going to start selling to the federal government, we're going to go into healthcare, fincer, et cetera. Once people say it, I think there's an understanding you're about to go on a journey and I think there's typically a lot of energy around some of the front of house, front office work that needs to be done. We need to train our sales reps, we need to invest in different types of talent and parts of the business, et cetera. I think there's an acknowledgement around, hey, our tech stack is probably something we need to look at. And there may even be interest where people have seen demos or new technology or heard from a vendor of a roadmap.

 

The other part of the journey is, unless I've actually never seen this before, so I'm going to say you do have business process and technology and integration and data debt in your current tech stack. And so as you're moving from to or before you start moving from to and you want to evaluate your tech stack, an awareness of how much debt exists inside of those business processes and workflows is an important decision because you may not be transitioning your legacy way of doing things into a new system. You may actually be end of lifeing it and just putting a wrapper on it and declaring bankruptcy on that and migrating the data, of course, and your customers, but maybe you're just standing up a new way of doing things. Everyone presumes I have to take what I've been doing and immediately transition or upgrade it into the new way of doing things. The innovation and the technology is moving at such a quick pace that you may be at this inflection point where it makes sense to start rebuilding for the future. 

 

Kate McCullough:

Actually rip and replace.

 

Art Harding:

Yeah, exactly. And at the end of the day, it's the data in the backend that tells the story and the history of our customer relationships and data is very malleable that we can move, transform and take from one place and move it to another. I really think your data strategy is crucial to understand that data's going to be with you forever and you're going to want to keep it forever and it's going to need to migrate and evolve with you. And I think sometimes we think of it as an output of some of these software and systems instead of actually maybe the fuel that's driving and powering it. I think looking at your tech stack, I view the tech stack and the business process design as much more disposable and is going to evolve much more rapidly than your data strategy, which is going to be the framing and plumbing of your house. You can do anything you want with your house when you're remodeling as long as you leave the bathroom right where it is and you leave the kitchen right where it is and it's because of the plumbing that's in there.

 

Kate McCullough:

Yeah. That's a really interesting perspective and I think a lot of people wed the two. They think the tech and the data are the same and so they're really hesitant to pull the tech out. And yeah, it's going to be labor to move that data and there's going to be some amount of transformation that has to happen to fit into maybe a different data model and a new tech stack. But I think what it sounds like you're saying is it's really worth it if the business requirements demand that. And I'm just curious, is there a framework that you recommend for evaluating and advocating for your tools as you're going and looking at your data and saying, hey, these are the tools we need?

 

Art Harding:

Yeah. For those who've worked with me, they'll get a chuckle around, I have this long acronym, which is silly to say, and even sillier to write down, which is PPBPRRSTCC. It's got two P's, a BP, an RR, an ST, and a CC. There's a rumored rogue version of it called PPBPRRSTCCOO, which throws a couple O's at the end of it, which I'll get into the alternative version. But to simplify for anyone who may be listening to this or thinking about it, there's essentially three parts to this. And the first part is the PP is what's the purpose or the policy or the project or the program, use whatever double P's work for you. And it's not an implementation methodology, it's not supposed to be rocket science. I don't think the book would be more than five or six pages if we wrote one on it, but after 10 years of using it, I have yet to meet an operations team that doesn't sit up really quickly and say, okay, this is meaningful, I can use it.

 

And the purpose in using it is we're going to have to meet our internal customers and our stakeholders where they are and they don't have the time, patience or temperament to listen to everything that's going on back office. But for anyone who's building things, whether it's the data stack or the integrations or the software workflow layer, we know that the quality of the question or the quality of the request we get is going to dramatically improve or impact the speed with which we can act. If someone comes in and says, "Hey, I really want to improve discounting," that's one form of a request. Someone who says, "Hey, I want to move the discount approval thresholds from this role in our organization to this role in our organization because we see that deals at this title in our company are getting managed more effectively than this level."

 

An operator can take that level of precision on the PP, which is what are you trying to get done, the project or the program, our ability to architect the next layer, which is the BP, which is the business process, and think about the RR, which is the roles and responsibilities, those first three steps in the first bucket is what are we trying to accomplish, how's it going to work and who's going to do what? And while cloud platforms and SaaS software have allowed us to move much more quickly, in general, people's patience and appetite for sitting in the, what are we trying to do, how's it going to work and who's going to do what is pretty low. What people want to do is start installing software and seeing demos and workflows and the cloud and SaaS software has allowed us to do that very quickly.

 

We like to skip the first step and say, we want to improve discounting, let's buy this really cool tool I found for deal desk that'll help manage approvals and workflows. And then everyone's like, yeah, and I just saw a demo and it's mostly what I want, so let's get it. The vendor's articulating, there's not a lot of maintenance with this. And it could be enablement software, it could be any of the things. I'm just picking on deal desks as a use case here. But the second step in this long acronym is about the systems and tools and the communication collaboration. And what I find is we have such an itch, such a bias for action that we want to see a demo, we want to buy the tool and we want to put it in. Systems and tools. Then as you go to collaborate with stakeholders or actually communicate to your company through enablement, through policy design, et cetera, you have to go back to that first step.

 

What were we trying to accomplish again and who's going to do what and how is this going to work? And I don't think that the first step of business process design and roles and responsibility needs to be a multi quarter, multi-year journey of pain and suffering. Just some focus time without your alerts going off, without seeing demos, without the vendor in your ear. Just sitting down and saying, okay, what are we trying to accomplish? How is this going to work and who's going to do what? If you bring to any enterprise architect or any enablement or communications leader those three things, this is what we're trying to do, this is how it's going to work, and this is going to do what, not only is the quality of the technology and architecture you implement going to be better, but your enablement, the guidance that you're going to give people, how your peers is all going to improve.

 

And then I talked about the rogue version of PPBPRRSTCCOO, which is the double O, which is ongoing operations. It's one thing to think about your project or your program, think about your business process design, think about your roles and responsibilities. Then we put our systems and tools in place, we do our communication collaboration, and a lot of times we think we've stuck the landing when in fact that's usually actually the beginning of your journey. Now you have ongoing operations, which is the OO. And that acronym has been built with just wonderful operating teams that I've worked with over the years where we've talked about when projects went well, when we evolved with the business, when we made smart investments, what did we get right? And it was universally you deposited a solid B to an A minus minimum in each of those categories before you spent money and started touching technology. And if you skip any of those steps, you may get the sugar fix of acting quickly in that bias reaction. It'll feel good in the moment, but you're going to pay for it later. You've signed up for some debt that you're going to have to manage and either evolve out of or pay for later.

 

Kate McCullough:

Yeah. I think that starting with first principles and also if you pick the right tool, it should more or less be able to do whatever you want it to do. It's just a matter of do you have the blueprint of what you want it to do? Are you clear within your business across all of those stakeholders? And a lot of people aren't clear. They have a very siloed view of what they want to get done and sales focused or maybe they forgot about CS or they haven't really mapped the journey. And so the tool will do what it tells you to do, and if you give it the wrong instructions, you're going to get the weird outcome. One final question, which is, okay. You've done this process and you don't have a rev ops educated executive to get budget from or get approval from. How do you go and make the case, and let's say it's a rip and replace, you're saying, "Hey, there's new innovation on the market that we need to put in place, we need to move our data over there and here's everything I found." How do you make that case with two execs who are like, oh my gosh, that price tag, I don't like it or that seems like a lot of effort?

 

Art Harding:

This is where back-office folks get to see and feel what it's like to be in sales. When you're in sales, you have to meet your prospects or your, actually not just sales, customer success, anyone who's on the front lines of the buyer and customer journey knows a lot of what I'm about to say as table stakes for what they do day in, day out in the field. But it's funny how many of us drop all of these skill sets and mindsets when we're working internally, which is if you're in revenue operations or you're in IT or you're in tech, you probably spend a good portion of your time and emotion managing the fact that people don't get what it is you do. Like our plumbers and electricians, we rarely call them to thank them for how the lights and water are flowing day in, day out.

 

It's when things go wrong is when we get the center or when someone wants to make a big change. The first thing I would start with is we have to remember in the back office while our careers and while our expertise and our interest is in the back office, enterprise architecture, certification, compliance, good governance, master data management, maintaining integrations, rationalization of tool stacks. For the front office people, they're our customer. We have to meet them where they're at and start with some concept of there's a lot of tools out there in terms of articulating value. I will often talk to a leader about, okay, so we're going international. Back when I worked at New Relic, we were going through this hypergrowth phase, we're expanding international, we were on a 10-year old CRM with Legacy and we're talking about the move to Lightning.

 

No one in the company really cared about the form factor of our CRM interface. What they did care about were things like multicurrency, they did care about acquiring companies, they did care about empowering our international teams to work quickly. And so I would work with the leaders to make sure I understood and could prioritize not only the things we wanted to do, but take a look at some of the projects we actually had done in the past and how those had performed and were they on time and were they on budget and were they meeting our expectations? And so those are the three things that I would index on my internal sales pitch when I'm talking to what I'm selling to one of my stakeholders. Kate, if I ran rev ops and you're the CRO or the CEO and you came to the R, I need and we need to do this.

 

You're going to tell me what you want and when you want it done. And you're probably not super interested in what it's going to take to get there. And so if I believe that this may require an investment or a timeline you're not expecting, I encourage revenue operators to first and foremost, make sure you understand the ask. Make sure that in this instance, Kate understands the ask. She may understand it at a level that while true is not actionable yet, right? And so I'm going to have to either with or without you figure out what the next level of detail is. More importantly, understand why it's important. All right. Kate just came in the office, says, we need to change pricing, that she doesn't like how we're quoting stuff to our customers and it's a mess and you just want it fixed by the end of the year as part of next year's annual planning, et cetera. It is my role as the revenue operator to sit in that ambiguity and ask you why is this important and is it all of our quotes? Does it include our renewal quotes?

 

What's driving this? What's the difference to the business in having this 30 days from now or 120 days from now because how we're going to solve the problem is going to be very different. And if you're talking about a large scale fork lift from two in terms of an operating platform or core business process, the value is going to need to be cross-functional and strong, meaning you're going to have multiple stakeholders that are going to incur costs and risk to maybe make this type of an upgrade when you're talking about cross-functional software. You're going to have to figure out what is the value to each of those stakeholders and get them to lean in what's in it for them. What finance may want, what product teams may want, what the sales team may want, what the CS team may want may be all very different, but for you as the operations or IT professional who are going to be leading this, you have to sell everyone.

 

You have to remind everyone not only what's in it for them, but what's in it for everybody because you're going to be arbitrating and balancing that. I really do think of it as a sales campaign and any of us who have sold know that what we're selling starts with the value of why are you doing this? Why do you want this flavor solution and why are we doing it now? The classic three why's, why anything, why your product? And then the why now. And I think as revenue operators and IT professionals in today's world, we need to think like product managers. We need to have roadmaps, and we need to understand the value of what we're bringing and we have to understand why it's important to our stakeholders. And then we have to hold the line just like a sales person would. Once you've anchored the value of your solution, you're not going to discount that.

 

And so internally, if we know what we're doing is worth tens of millions, hundreds of millions in dollars in terms of revenue or billions of dollars of market cap, you as the leader who's being asked to do this need to sit in that and have the courage to challenge the organization to make the investment to reap that reward. Of course, we all see the rewards we want, we see the expansion in revenue, we see the increase in our valuation and we want it. But do you, as the leader that's being asked to do this, can you sit in that discomfort and say, "Hey, I know how important this is, and I also understand how complex it is," right? You have to play both instruments and I tend to find when I'm working with people either earlier on in the company's lifecycle or their career, they just want to tell everyone how hard it is. Do you know how hard this is? Do you know how long this is going to take? Do you know we should have done this three years ago and no one's going to give you an award for the I told you so shirt. They just want to know when you can get it done, but you have to understand why it's important so that you can ensure the company connects with that investment.

 

Kate McCullough:

Yeah. There's so many different factors. I think it's even gotten even hairier with the fact that how many stakeholders are actually involved against this. But, Art, it was a pleasure to have you today. Thank you so much for the insight and continued conversation about this. Appreciate it.