Trunal Bhanse: Michael, welcome to the show.
Michael Musselman: Thank you for having me. I'm excited for our discussion today.
Trunal: Let me start off with your time at Lacework. You were the first/sole owner of the partnerships mandate. What was the opportunity or need you identified that led you to pursue and build cloud partnerships specifically with the three hyperscalers?
Michael: Yeah, so I was hired at Lacework early. I was employee 68 and wasn't necessarily brought in to build a cloud partnership. I was brought in to start thinking about what we should do from a strategy perspective. What kind of partnerships should we have? Like a mix of business development, maybe tech alliances, right? A lot of software companies have other interactions with other independent software vendors. So, other ISVs. And so, that's kind of how it started.
We were a very early small sales team that was scaling processes really fast. I had a couple of sellers say, "Hey, can we sell in this marketplace thing?" And I was like, I don't know. Let me go figure that out. And, we would also, you know, we're the, the software was built on AWS and, and at a previous company, I didn't route while I ran a bunch of partnerships, business development, you know, tech alliances.
I didn't. We were also built on AWS, but I didn't realize this whole world of AWS partnerships and that. So, the natural answer is to look at where you're built and where you're driving consumption. And so it was, “I guess you joined the APN. I guess you list your marketplace listing. I guess you transact that way.” And it quickly snowballed very fast in the first year or two.
And then, you know, I also thought a lot about doing this and giving back to the community as I learned more. As I met more people and learned more, it was a good affirmation of the great work we were doing, but also of helping back to the community and, you know, sharing my experiences with others
Trunal: As a follow-up to that question, Michael, at what point did you start seeing that this cloud GTM route, setting the other marketplaces, is starting to become a really serious go-to-market pillar within your organization, either at Lacework or previously?
Michael: Yeah, so it's where the circle of truth is. I've been thinking a lot about this for the last four or five years. It's different, and the markets changed since then. But if I'm staring a CRO or a CEO straight in the face and they're going like – I want to do this, I expect this, and I expect that…. If I put a dollar in, how many dollars do I get back? It's not exactly a simple answer.
My team and many people who know me also know that I use many analogies. So, if I went outside into my backyard and planted an apple seed, right? I won't get apples tomorrow, and I won't get them next month. It needs sun and water, and I probably don't want the weeds to overgrow the plant, and there's a little seedling. And you know, the truth is, and maybe a year or two, I have a mature apple tree, and it gives me apples. But if you ask me, how many apples are you going to get in that first year's harvest? I can't predict that either. So, if you think about the same story and you equate it back to business and cloud go-to-market… There are a lot of little intricacies around co-build and co-sell, and a lot of the Cs are thrown around.
But it is really hard to forecast and predict that if I do this stuff here, I'm going to get this as an outcome. And as you can imagine, it's a pretty significant investment for any company to say, "My 68th employee will transition." But within a few hundred employees, that's a pretty significant investment to hire someone like me. I'm going to hire a team because there's a lot of stuff to do.
I think the answer is it's hard to predict that, but if you take it with the right assumptions, if you look at the cloud and the cloud go-to-market, maybe, different than what a lot of folks are familiar with their channel partner strategies, SIs or MSPs, those are pretty well-known things. There are pretty well-established leaders and industries. This is very different. It's very new. We kind of joked around and called it the next-generation channel, but it's just, you know, I think you put all of these in different buckets and as a business.
owner revenue leader, you just kind of have to think through all of this stuff. But I do believe, now that I’ve seen this a couple of times, that it is important. It's an important new channel route to market relationship partnership to any software business, depending on what you do and where your customers are, but it's not always going to be right for every business. And it might be better earlier or later, depending on a couple of the other scenarios that your company is faced with.
Trunal: And then, let’s say there’s an alliance leader who’s thinking of this strategy right now. They go to their leadership and say, “Hey, we should do this.” Then, the natural question that CROs and CEOs will ask is, “Hey, tell me about the ROI. Why should I invest in this channel versus in some other channel that I know will give me returns in a concrete fashion?” How do you convince them?
Because you and I know that it works. We’ve seen it multiple times. You just have to back it up. But how do you actually convince someone who has not done it before?
Michael: I think it's all around you. It'd be a hard conversation to fight now, just seeing your peers are. Even in the security domain, you've got Palo Alto, CrowdStrike, and Microsoft.
Last week, I was at Moscone in San Francisco. I come down the escalator, and I see a sea of security. There were thousands of vendors. Like, do I need all that? Do I even have these problems? Like it's a daunting thing. So, the natural thing is to like these big partners who are already in space.
Well, the good and the bad thing is that they're not always the most innovative—maybe the best—but it's a safe selection. The alternative is that even when I get to Lacework, Palo Alto already has a very mature channel and a very mature go-to-market.
They're in all the marketplaces. If you're the CEO or CRO, then you're like, “I kind of have to do this because if I'm not, what risk am I putting my revenue or my business to by not doing similar things to my number one or number two competitors?”
So, I think there's a forcing function to that. But purely from an ROI perspective… I do believe that it's not different, either. I think in a lot of channels and a lot of partnerships, you're going to get what you put into it. The more you put into it, the more you invest in it; you're very likely to get something out of it. And we can keep using the apple and the orchard analogy.
But I think in many relationships—like my early experiences with Lacework—their customers were already in the cloud. They already had committed spends with the cloud.
Trunal: By definition, cloud partnerships involve product and engineering lift to bake your solution into the cloud infrastructure, into the marketplaces. What was your role in facilitating this, and serving as that bridge between these two internal stakeholders? And what have you seen that has worked in the past to make these conversations easier?
Michael: That's a great question. I think there are a lot of nuances to give a complete answer, but I'll start in a couple of areas. So, I'll talk about AWS co-build or co-innovation.
My lesson learned is that if I'm thinking about one of the cloud service providers, there are two kinds of fiefdoms of power. There are the sales and revenue teams, but there are also the services and product teams that are building the things that the sellers sell.
Clearly, there's an interconnection in wanting to work with the sellers at AWS because we're selling into where their customers are. But the second thing is the service owners are building services that firstly, our backend technology uses number one, and secondly, they're also producing services that we may attach to, we may do security for, we may compete with, which is probably the case for most of us. And because of that, there's this frenemy situation, where I want to know them, and I want to do stuff with them.
I think Lacework’s time is a good example, where we wrote a case study with the EKS team because we secured EKS, we used EKS, and a lot of our customers used EKS. But I didn't do it like our customers using this service. I actually asked our engineering team if we could go write our SREs. “Let's go write a case study for AWS about how we use EKS and how EKS helped us move from our US instance to our European instance and our Australia instance, which we probably couldn't have done if we were still using our own managed Kubernetes service. We couldn't have done it as fast. We couldn't have done it as cheap.”
So I think, and in doing that, I was actually helping the EKS team be their hero, be their champion, and use us as an ISV example around how it helped expand our own business as a give-back. But then, in later stages, we would do security for EKS. So we were also close to that team about this. And many times, we would ask them, “Hey, you could make our platform better, but honestly, you could make your services better too. If we could see more behind the EKS management element—like, there's telemetry that you guys are managing, or some function in the open Kubernetes that we use—but you guys don't expose it yet.”
I think in many ways by getting close to these services teams, even on our backend, this actually actually helped build our partnership. Because while I have historically reported to the CRO and the revenue side of the business, all partnerships still have to be win-win and multifaceted.
And so, even if I absolutely want to change our revenue, help build pipeline or velocity, and build our marketplace presence… like these teams also will make our services better, make our customers happy.
Trunal: It is a combination of who you are and of you having the opportunity.
Michael: In the partner network for AWS, there are hundreds of thousands of ISVs and a hundred thousand partners. So, the last suggestion that I give to people is that there’s not just one planet. There are lots of them. So you're always competing with multiple ISVs. And because of that, you're not changing gravity. No matter how much I want Google or Microsoft or AWS to do something I want them to do, not gonna happen. I'm not changing gravity.
This is another mistake I see with many businesses. They say things like, “I would love for AWS to do something, bring me pipeline, introduce me to their customer. I want to meet the CEO of Clazar.” That's dumb. It's a dumb question because now I'm fighting gravity. I'm asking for things that are unnatural to physics.
In this case, how do you get what you want? That's the art. You need to think, “What are the natural mechanisms that I can use, not to reverse the polarity, reverse gravity, but to get the outcomes I want? But I'm not doing things that are going to fight gravity.”
Over time, you can build a great relationship with these CSPs, and you might be able to influence [roadmaps], or you can get a bunch of people together that help like, “Hey, we'd go faster if you did A, B and C.” But they're not going to do it on your timetable.
And I've seen AWS take a lot of feedback from me and actually build all of that stuff. Marketplace is a great example. The ACE portal is a great example. They love all that feedback from their partners and the service owners. They love that feedback from their customers, but it doesn't mean they're going to do it. And it doesn't mean they're going to do it when I want it.
Trunal: Michael, when you started at Lacework, the company was hosted on AWS and it made sense to begin your cloud partnership journey with the ecosystem you're built on. At what point did you go multi-cloud based on your experience?
Michael: It honestly depends. My first guidance to anyone listening is that you're going to need the information about where you are on this journey. If you're built in a cloud, that's probably the first cloud that you want to start partnering and exploring this journey with. ‘Cause remember I said consumption is important. If I'm not built on their cloud, I'm not really driving that consumption.
However, there are exceptions to this kind of rule or these laws of physics. Sometimes, we might solve a really important customer problem for a cloud service provider where I'm not built. We solve a really important gap in their product portfolio. So, there are opportunities to start to be a partner or to solve these end customer problems with your second cloud.
But make no mistake, the long tail of that is they're going to start to ask, ”How do you start to drive consumption in my cloud?” Sometimes, marketplaces or other benefits are gated by driving consumption. Or it just could be security, like, “Hey, we're really important security. And if your data is not in our cloud, then I can't trust or protect you the same way I would if your data is in our cloud.” So, sometimes, the go-to-market and the business development conversation can preclude that.
But I would go back to any founder and say, “If I were building a SaaS company today, I would be very cautious and consider how tightly I'm coupling into the cloud-native services.” If I can't detach that and run it on a multi-cloud strategy, you've got bigger problems to fry from day one.
You've got product market fit. You’ve got a lot of other things you need to do, but I would at least be cognizant of the fact that I may need to run my stack in a second, third, fourth, or fifth cloud in the future. And how would I architect my technology today to support that? Maybe 100% doesn't have to run in all the clouds, but part of it—where the data collectors are or whatever it is that you're building. So, I think that's important for any founder or the CTO. Just think about that because you're probably not thinking about that today.
Trunal: Michael, thank you so much for coming on the podcast today and sharing your wisdom. I thoroughly enjoyed it, and I'm sure the audience will enjoy it as well.
Michael: Yeah. Really appreciate it.
Also, getting into the marketplace isn't easy. You may not be ready for that. So, there are a lot of great companies that can help you register for co-sell. One or two deals are easy. But, what are you gonna do when you’ve got 2000, 3000 registrations a year at scale? And so there's a lot of companies out there that can help you, but obviously, I'm with you [Clazar].
But I would start thinking about that early because on your journey from building the partnership to scaling the partnership, it's a lot of work, and there are a couple of ways to solve it – people or technology. And I would encourage the technology.
.svg)
.svg)
.svg)
