In this week's episode of the Enterprise Monetization Podcast, Sandeep Jain sits down with Zach Weinstein, Revenue Operations Lead at Middesk
Hi. Welcome to the 16th episode of “The Enterprise Monetization” podcast. And this is your host, Sandeep Jain. In this podcast, we invite thought leaders from enterprise monetization space that CPQ, billing, usage, so that you can learn about challenges, opportunities, and best practices in B2B enterprise monetization. Today, I'm super excited to invite somebody who I've worked with for now five, six months. His name is Zach Weinstein. Zach has deep expertise in the field of revenue operations. Currently, Zach leads revenue operations at Middesk. If you don't know what Middesk does, we'll have Zach, tell us more about that in a second. Prior to that, Zach did business operations at played. And before that Zach was doing Management Consulting at Oliver Wyman. We'll get to know from, Zach, how did he make this transition in a second? But it's a pleasure to invite you to this podcast, Zach. Welcome to the podcast.
Thank you, Sandeep. I'm excited to be here.
Awesome. So let's jump into this. Can you just provide our listeners a quick summary of your background? Like how you decided to go from management consulting to revenue operations? Honestly, I've never heard that. So I'm curious to know why you decided or how you decided to make the jump?
Originally born and raised in Toronto, and as Sandeep mentioned, was a consultant at Oliver Wyman, where I worked in Canada, US and Mexico, focused primarily on transportation and financial services clients, I was looking to join a fast growing company, in an exciting space, learn tons, increase ownership. And I really found that in the business operations team at Plaid. “Plaid is the financial infrastructure company powered many of the Fintech apps that we are also used to using today.” And within that business operations team, I focused on go to market, we call the go to market ops, or we didn't even explicitly call it revenue operations at the time. So I focused on top of funnel, which we thought of as marketing, partnerships and our sales development function. I thought of my KPI as maximizing pipeline in dollars and in count, when you can think of the overall goal of revenue operations I would say, is to maximize revenue, maximize bookings, maximize pipeline, all those things together. And I was leading a piece of that applied. After an amazing experience applied, I was there from 300 employees to 1000, through the fast growth through the crazy COVID times, I was looking to build a go to market operations, go to market ops function from the ground up. And I was lucky enough to find the great team at Middesk to do that, where I joined in 2021 to build out go to market ops.
Awesome. So let me ask you this thing. What is the difference between go to market ops and DevOps and sales ops from your perspective?
Yes, for sure. I think there's a lot of terms thrown around here. So sales ops started first where you had sales leaders who were amazing sellers, amazing people, managers who were looking for folks on our team to be more analytically minded, and help them run the analytics, the ops side of their business, then that transition kept growing over time, you had SAS businesses, where there was sales and customer success, sales and account management. And this term revenue operations started coming up. And in some cases that included marketing, and some cases it didn't. And it's been pretty fuzzy. But I advocate for this new term, I've made up here, called go to market ops, which I think of as holistically, you can think of a table here. So your columns could be marketing, sales, account management, and partnerships. And then horizontal to those columns is strategy. What should our goals be? What verticals do we go after? Second, “Pricing and deal desk.” What's our pricing model? What's our price approval levels? What's our deal by deal strategy for our largest deals? Third, “Analytics”, like how do we understand our performance, everything from headline metrics, like what we're booking, all the way to details, such as conversion metrics by channel. Fourth, “Ops in process.” So for example, how work together to create opportunities. And finally “Systems and tools”, those five horizontals against the four vertical areas within go to market is how I think about go to market ops as a whole.
Zach you are a true management consultant. Because I didn't send you this question in our pre questionnaire prep, and you're like, boom, boom. So it's just interesting to hear your structured parts on this topic.
I didn't structure it into three bullets.
There's inflation happening everywhere. So we'll go through. Cool. Actually, I should have started with this. Can you actually share a fun fact about yourself?
Yes, of course. This is usually my fun fact. So I'm an avid skier. I grew up skiing on a 700 foothill, so the only thing to do was go as fast as possible, because that was the fun thing to do on the East Coast. And then moving west. I've been on the West Coast now for six years, got into more and more off piste, or backcountry style skiing, and went heli skiing for the first time last year, which was quite an amazing experience. You're at the middle of nowhere, there's no cell service, which is a very good thing. And you're just there with the snow in a small group of fantastic skiers.
That must be an amazing experience to feel it. Just doing that thing. I've never done that before. I'm not even a skier. But this sounds really exciting by the way. Can you tell us a little bit more about “Middesk”? What Middesk does?
Yes, of course. So “Middesk” enables businesses to access any product or service to enable them to grow. And it's always hard to think of these b2b companies and what they're really doing. So I always try to use a consumer analogy. As consumers, we're used to onboarding to products like Robin Hood, they require our identity to be verified, they require a link of a bank account and that all happens easily, quickly, instantly, and you can be trading in five minutes. Businesses don't have that luxury. Middesk is the infrastructure to enable businesses to access services from b2b players, in a way that mirrors the consumer experience.
Understood. So like a business verification or business information is what you guys are providing through API's, I guess.
Yes, exactly. So our customers include Fintech’s, such as Plaid, blue vine, and Shopify. Plus, several large banks and lenders, we are backed by Sequoia, Excel, insight and canopy.
Well, that's quite a few good names out there, both in customers and investors. Cool. Let's jump into your specific role there Zach, like what's your specific role? How's your team structured? The copies that have new Epstein, and so on, so forth?
Yes, for sure. So revenue operations at “Middesk” is me plus one. And we're both focused, I think of it as a full stack. So I mentioned those five different horizontals, before strategy, pricing, analytics, operations and systems. And I think of organizing a go to market ops team, as across all of those four different parts of the business. So I focus on top of funnel, and my colleague focuses on bottom of funnel, so I'm doing marketing and partnerships, my colleague is doing sales and account management. This allows for alignment of me and my colleague to choose different leaders across the business, as well as two objectives. So again, similarly to my experience applied focus primarily on pipeline creation, whereas my colleague is focused more on bookings. And then, of course, there's no perfect line between. But this provides the right structure to maximize impact.
Got it. So before we go into your quote, to cash stack, can you just describe your business model? Like how many skews? What kind of business model you have? Is it like subscriptions, usage? Where do you sell? Is it a reseller lead? Actually, it's a sales lead, or resellers or self-serve, just so that we understand, what's the scope of what you're dealing with?
Yes, of course. So I fundamentally believe that we're only successful if our customers are successful, which is why I love usage based pricing and usage based models so much. So we employ a model that is primarily usage based with a minimum commits, and platform fees. To compensate for the use of awesome platform features we have, I'm happy to talk through that if that's of interest. And then the minimum commit shows that allows us to invest more in our customers and our relationship with them. And in exchange for lower unit rates that they receive to access our usage based products. We have about 20 usage based products across our three lines of business, which is verifications, underwriting and tax.
And how many channels do you sell through today?
So we primarily sell with a sales lead model. We do also get a number of referrals from a few great partners, but we're lucky enough to have, we have a reseller channel as well for integrated experiences. So for example, within a banking as a service, a bass company, mid serving b2bcustomers, Middesk is a piece of that experience. And that would be an example of an integrated resale.
And can you share, how many reps you have like selling?
Zach: So we've worked 15 folks across sales, development, sales, account management and partnerships that are customer and prospect facing in various stages of a sales cycle.
I want to actually double click on your usage based billing because it's a topic that people of course talk about, some experiment with it but looks like you guys, relative to your journey as a startup, you guys fully embraced it. So for people who are listening on this podcast and are thinking well, what pieces of knowledge we can understand from these things like minimum commit. And there's other things called like prepaid credits. So can you just talk about, if somebody wants to do usage billing for their businesses, or their business? How should they go about thinking operationalizing that?
That's a great question. So coming back to the philosophy, we want to reward the right behavior, or if you will, and we want to have a strong relationship, a growing relationship with our customers. So some companies get this wrong in some interesting ways, they will lean very heavily on commitments in terms of purchasing a block of usage, or there might be three levels of the products that come with a certain amount of usage. And if you exceed that, they shut you off. This is very strange behavior in my mind, because we're deciding that you're growing as a company, we want our customers to grow yet we're going to penalize you. Another example would be charging more for usage in excess of a commitment. You'll notice I didn't even use the word overage, I hate the word overage. Overage means success means our customers are using a product. They're loving the product, usage in excess of commitment is, our customers are going to pay for it. But that's the cheapest unit. We want at scale, each unit to be the cheapest. That's the strongest relationship customer we have and want to extend that commitment to them.
No, it does. I didn't think of overages as that. But that's an interesting point. But tell me about this thing of if I'm doing a minimum commit, is this minimum commit across like you said you have totally usage products. So as a customer, am I paying that minimum commit across all these products? Or is it like one by one? Do you take that commit at the beginning of the month? Do you take it at the end of the month? Is that end of the quarter? Like can you give a little bit more structure around that?
So I'll try to answer those two pieces. So one is across the different products. And the second one is around timing. So my view here is that you want to make customer friendly, reasonable decisions here. If you get to the end of the billing period, and you chose a model where you had a minimum commit per product, and a customer exceeds the minimum commit on one, buy a lot, but undershoots on another, the customer will inevitably ask you, so you're going to charge me overage because I went over well, I went under on one and over on the other. That doesn't make sense, because that's not treating us as a whole relationship. So we just need to embrace that. My view is a minimum commit applies across all of your usage products to treat customers as a whole, not as a buyer of ‘Product A’ or ‘Product B’.
It's a very interesting way of looking at that. I'm loving this. So tell me about the second one.
So in terms of timing of billing, today, we always have room for improvements. We are billing our minimum commits and our usage in arrears. This creates a simpler billing environment where whenever we send a bill, that bill contains one months of usage, therefore, one month of Rev rec in that single invoice, in the future, we'll likely move to a model where we build the minimum commit in advance. And then at the end of the month, we'll Bill usage in excess of that minimum commit in arrears. In addition to the following months min commit, this creates, obviously a better cash flow situation, especially in the current high interest rate environment, plus de risks trust, we would prefer to be in a situation with cash in hand, while the customer is using our product, rather than the reverse, where we're billing them for prior months usage, and they're already using next month, and they may not have paid their bill yet.
That's a great point again, Zach. Let's dive into your quote to cash stack, like what do you use for CRM, coding, billing and usage? Like what's your infrastructure?
So for CRM, we're using Salesforce for quoting, we're using monetize. Now, we've been a partner of Sandeep here for about six months now. On the billing and invoicing side, we're using Stripe and on the usage side, we do this in house. So we do those calculations in our product before sending the information to stripe, to execute the billing.
Can talk about your biggest challenges that you've seen in your quote to cash stack. And also, if you're doing it afresh for a new company, would you think differently in setting the stack and we will go to that later on. But let's talk about your current challenges.
So when I was at Plaid, I joined late enough that a CPQ was already in place. And I saw how valuable that was in anything we wanted to do, in changing our pricing model, in understanding our unit rates to do pricing analysis. To understand discounting we should give, to understand the document that was truly signed, is the one that was quoted. So we could automate our variable compensation for our account executives, for example. So I knew that I had to get a CPQ in place early now that we've had that in place for six months, we've solved many of the typical early company pitfalls, for example, products on order forms that we couldn't sell. This happens when there's an order form and AES typing something in, they have no bad faith, but they're typing something in that they think is sellable. Someone told them a sellable, it was in some dark, it used to be sellable, but may not be today. Second pricing models on order forms that we can't support. Third, extreme discounts. This is obvious, we should always understand the discounts we're giving. It doesn't mean that we should never discount heavily, but we should understand what decisions are being made. And finally, manual error by accounting and finance teams typing in rates. So when they're typing in rates from a flat signed file, you end up in a situation where it's easy to make a mistake, it's easy to move a decimal point, again, isn't anyone's fault. This is a manual process that you can solve by getting a CPQ in place, even if you don't yet have an automated connection between CPQ and billing.
So Zach, that's interesting. But one of the questions that I hear from most people is, when should I transition from manual quoting to a CPQ? Is it the number of reps? Is it a number of skews? Is it the fact whether your consumption based billing, what's the part there?
That's a great question. And I wish there was a perfect rule of once you hit this criteria you transition. But this is one of those where every company is a little bit different. There are four factors I keep in mind. So the more reps you have, even crossing four or five reps, your knowledge doesn't transfer as well between one person and another, you're onboarding folks quickly. And you'll want to have standardization in place to make them more efficient moving quicker. Second, “The more complicated your pricing model is, which really means usage, to be honest, the harder it is to quote that well to have price discounting controls against it, if all you’re running is a seed based model, it's kind of usage-ish, but you have a low number of units.” But if you're selling an API based product, and you have 1000s, 10,000, 100,000s units, getting your pricing and quoting rate is even more important early. Third is “How mature and variable your pricing model is, if you're changing your pricing model, every week, you're going from usage to block to upfront, you're not ready for a CPQ yet.” And finally, “The data quality expectations by yourleadership team and your VCs, your investors, the higher this is, the more important it is to get tooling in place and get out of documents.” Documents will only scale when to the point of how fast you can open them and look at them with your eyes. They're never going to adapt perfectly into a structured data.
Interesting, thanks for that, Zach. Also related point, what do you think or do you have any thoughts about having a CPQ system and a billing system that are different or from different vendors? Do you see any challenges with that? Do you have any thoughts on them being together? Any thoughts on that?
Yes, I do. I've been thinking more about this recently, and talking to colleagues and other companies. And what I increasingly find is, even when folks say that they are integrated, they have their quoting and billing integrated. They really mean at the slightest level, it's integrated. So as an example, what's the most important thing coming out of coding and billing? It's your bills, it's your invoices, it's your cash collection. And that's what they've solved for, for the set of products they're selling at that point. But there's still two major pitfalls. One is “A single source of truth on your contracts.” This sounds silly. But companies have trouble answering questions like how many customers do we have? When should we proactively reach out about a renewal? What is the end contract behavior? Is that a renewal automatically or does it cancel? And the second pitfall is enabling a stronger GTM motion based on the information. So if you have an integrated quoting and cash, quoting billing Cash System, you know, when usage is down, and you know, when usage is up, if usage is down, it could indicate churning contraction risks, maybe you want your account manager to pay more attention then, if usage is up, maybe that's an opportunity to upgrade a customer to another plan, or for using a new product they hadn't used before.
Anything about the discrepancy in the product catalog between the different systems? Because that's one of the things we have heard. It takes a lot of data wrangling or hiring professional services team to connect them, has that been your experience or what are your thoughts about that?
That's also a great question. I think the challenge with the product catalog is you can get whatever data wrangling and professional services, you want to connect those. But ultimately, if there are two systems that you have to press a new product in both of them and define how you're pricing them, how you're billing them, you're bound to have discrepancies. By having one catalog with one set of pricing structures against those, you're guaranteed to have anything that is on a close, that is in a contract, is available. So you can solve for this by having slow iteration on your pricing, you have a fixed set of products, you have one pricing model, but as soon as you want iteration there, this problem becomes unwieldy very quickly.
Thanks for that perspective, changing gears a little bit. What are the top priorities for you and your colleague in the next few quarters? What do you want to do?
I'll focus on a couple of priorities I have related to quote to cash and how to better use that information. I think that's probably most applicable to the audience of your podcast here. One is “Around automating approvals”. So this hasn't been a massive theme for us, because we have the bigger items solved for, we have the products defined, which is an approval already, we have the pricing structures defined, these are forced approvals, or validations that take place, because we have a quoting system in place. But there are additional approvals related to unit rates, related to having an address of all of your contacts, on your order form, things like that, that we want to get in place to make it experience our AES even faster. “Related to that, we're automating our document creation and signature process from our CPQ system to save our AEs time, and improve the data quality that we get”. And then third, I mentioned this to one of the prior questions using our usage billing data better. So today, we use it in some capacity to proactively alert on turn, to alert on usage going up and going down, but one that we're looking forward to is being able to predict revenue on a per customer basis, which sounds really simple, if you're on a pure usage based model. But if you have different types of usage products, for example, each time a product is called, that counts as one unit, you could have a product where only the first time it's called that counts as a unit. And each retrieval is free, or is at a discounted rate. You could have at hird type of product, which is subscription, by usage, meaning that you subscribe to a monitoring type service. And then until you unsubscribe, you're billed monthly for that subscription against an individual in our case of business you're monitoring. Using all of that information with them in commit to estimate what the revenue will be at the end of the month, is a really exciting opportunity for us to provide even more visibility to our entire team without waiting for end of month, plus a few days to close the books.
I love this last bit that you mentioned, it's very insightful, because it gives information on the pulse of your business. And that's a very interesting way to look at this. I love it. Zach, any advice or recommendation to the vendors in this space? Product managers who are listening on the call or engineers? How should they design things, systems differently, coming from your world as an operator?
So as I was looking at CPQ options for us, I mentioned earlier that I knew we needed to get something in place early to have the data quality that we have right now. I wanted to balance a few things. One is “Time to impact or time for us to launch”. Second, “The overhead both in terms of cost and time to manage at steady state.” Third was “Full features”. So what's the set of pricing models that can be accommodated, and fourth is “Our ability to iterate quickly.” Which is like saying buying for the long term, that's the theme of all of these, if we had high overhead, if we couldn't change our pricing model. If we couldn't change it quickly. I would not view that as a good long term decision. So those are the factors we looked at. And the other I'd call like user experience as a whole. And this is a trend that I'd say in B2B products. We increasingly expect that this is actually part of what Middesk offers our clients. We increasingly expect consumer level experiences from B2B products. Before when you used to pick up a B2B product. There were hours of training and their certifications and there's videos you watch. But that's not how we expect a consumer product to work. You pick up your iPhone and it just works. You know how it works, you drag on the screen. You don't need to watch a video about that. So the more that we vendors can build products that feel like that. The wording makes sense. There's in products guidance. There's no instructional videos, the better and more adoptable the product will be very quickly.
Awesome. This has been some interesting insights that you gave us, thank you fort hat. But before we let you go, is there any recommendation of a resource like a book or a blog or maybe a podcast that you heard that you would like to share with our listeners today?
Beyond this podcast, there's one article that I've reread probably every six months or so, called “Management Time”, who's got the monkey, it's this HBR article. It's about how it's easy to take on something because someone's asked you a question, asked you to look into something. And I think in terms of driving accountability in organizations, it's really important to think through, who has the responsibility for the next steps or pushing something forward, ultimate ownership of the thing. So you may be helping your colleagues, your colleagues may be helping you on something, you may be together helping a third party, but it's important to know who has the responsibility, or who's got the monkey in the context of this. So the monkey on your back, I think is how this article frames it. And to not accidentally adopt the monkey by saying, I'll look into that. And then everything stops while you're doing something. So I think this really resonated a lot with me, the idea that you got to be really clear about who has the ownership, who has the next steps, even if there's a piece being done by someone else.
I love this, does it tell you how to get the monkey off your back? Like does it provide some tips on reversing this? Jokes aside, this happens in organizations a lot, like you just pass some random work to your colleagues, just because, I find it frustrating sometimes. And it actually happened this morning with me, I was working with a vendor. And they're like, Sandeep, do this for us. And I was like, hang on, there is another way to look at this. And they agreed with that. So the monkey was coming on my back. And I was like, my god, this is work on my plate. And then I reverted back to them. And they agreed, actually. So it's very interesting that you talk about this, because there's a lot of random work being passed around. So does this article talk about who's got the monkey? Just give some tips on that?
Yes, I think it has “Two buckets of strategies”. One is how to never adopt the monkey, the strategy is around once you have the monkey that you should not have accidentally adopted, how tore readopt out the monkey. I'm probably using the word adopt here too much. Yes, I'll leave this for your listeners to check out after but, yes, I think there's some good strategies in the article.
I just love this. I'm actually going to share it with my team here at monetize now because I think this is such a critical topic. So thank you for sharing this. This is amazing. Zach once again, thank you for your time today. Loved having you on the show.
Awesome. Thank you, Sandeep. I really appreciate it.
