Why CIOs Really Buy SaaS Products, With CIOs of Box, Zuora and Symantec

Four CIOs explain why they use the SaaS products their own companies sell. They call it dog-fooding: IT becomes the first, most demanding customer, feeding real product feedback to engineering while building credibility with buyers. The practice uncovers hidden operational gaps and ties engineering, operations, and sales together.
Chapters
Wendy made it! Yes! Well, this is exciting. We are going to have a conversation here, an authentic, as he mentioned, and genuine conversation with my friends who are subscription CIOs, my personal friends as well as Zora friends, on the power of investing in your own technology. I'm Alvina Antar, CIO at Zora, and this is a topic that I'm extremely passionate about. And I'm excited all of you care about it because you're here. And I know that Paul, Sheila, and Wendy care about it as well and are driving those initiatives within their organization. So I would like to first start with Sheila. Sheila, if you could talk about how critical this is, you know, in terms of the overall initiative in your organization and, you know, the influence that has. In your product strategy?
[Speaker:WENDY] Yeah, so thank you for that. So first of all, as the CIO for Symantec— come join us, Wendy— as the CIO for Symantec, a security company, we all need security products. It's a hot topic of the jour right now. So the ability though that I look at IT in our environment is that we are the petri dish or the sandbox of which we can go test and use all our products and services. And that does really 3 things. One is we're able to give some real direct feedback to our engineering organization right away. So if it's an alpha or beta or production, we can give that kind of feedback right away. Two is they get to see it in a real live production environment. So not to insult any engineer in the organization, but engineers, we create these widgets and these products. But what happens is you really want to see how it's tested in the ecosystem, how it works upstream and downstream. And we can provide that environment that the engineers can actually see and test. And then finally, we actually write white papers about our experience, about our deployment. The good, the bad, the ugly, what we learned, tips and tricks, et cetera, of all of our deployment. So that our sales team— that's on the Symantec.com website— but the sales team can actually use that to go talk to their customers. So I really think it's a three-prong approach where it's engineering, IT, and sales all come together.
That's wonderful. Paul, can you please talk about how you not only introduce yourself, but also just share your comment about if you left Box, you don't know how you'd live without Box.
Yeah. And that's not a shameless plug. That's the truth. I think part of extending on what Sheila said, when you believe in your own product, which you should— you shouldn't be at the company if you don't— part of your responsibility is to actually really use your product. To as great extent as possible. And the more you use it, the more you should be using it. And that's what we found, is that we're now at a level of usage where we're able to convey that to our external customers and prospects and things like that. But to Sheeta's point, I think being customer zero is really, really important. I think the fact that you should be your first and best reference support customers is one thing. But also you need to be able to share externally in the broader community how your products, your services fit into the reference architecture that we're all building, the reference architectures that we're all building today. It's not just about our individual products, it's about how do our products work with Symantec, how do they work with Nutanix. It's about a reference architecture that's very interoperable And it's not just about our product. It's about how do we interoperate with others as well. That's something we can bring because that's how we run our business today.
Powerful. Very powerful. Wendy, I just think about my initial engagement with Nutanix, and it was through this. It was— I was meeting with the head of engineering as they were assessing Zora, and they wanted to talk to the CIO at Zora and ask me a ton of questions on how I use my own product. Now I'm not going to make stuff up. I'm going to share, I'm going to demo our own internal implementation. I'm going to tell them best practices, design principles, all of that. And that was my first interaction with Nutanix. And it was before you joined. But it was amazing because we had an instant connection. Because I knew in that conversation that Nutanix, it wasn't that they were just looking at Zora for their product, but they also wanted to understand our culture. And that Nutanix was, your culture was all about using your own product. And so if you could please talk about that because I thought that was something that was an instant connection as we engaged as dual customers.
Definitely. Well, first of all, I have some really cute shoes that I was gonna wear. They're in my bag. But she showed up. Let everybody know. It's all about the shoes. I just wanted you to know I have excellent taste. It's just not reflected here.
But Sheila has always the best results in every demo.
You do.
You do. That's what I'm looking around and going like, oh God. So yeah, at Nutanix, there's a certain humility that comes from being the CIO in a technology company. Where everyone who works there, all the engineering folks, kind of run circles around me technically with some of the details of our technology. So using our own product and loving and relishing and operating with our own product, right? First of all, it's a way for me just professionally to connect with the rest of the company, to be a part of the business of the company. And then also, you know, I'm not in sales, I can't fake it. So being genuine about what works and what doesn't work. And I think the biggest gift that, you know, the engineering team brings to me is they're listening to my requirements and responding. But then on my side as well, I can bring some operational realities to them and I can, you know, I can think of a few times where we had a great product, but migrating to it required the movement of data and no one had thought about moving data. And so it's sort of those operational realities and just being able to have that connection and be, yeah, customer zero, which sometimes is kind of funny, right? Like, not even—
I'm paying you all.
Not even customer one, but zero. But yeah, just— bringing that operational realness, then I can authentically speak with someone like the folks here on the stage, any of you, and share my experience. And it's believable because it's true, not because it's marketing.
[Speaker:KATHY MCMULLEN] Can you share more about that, any of you, about this whole concept of being a referenceable customer and how just you have relationships with a large community of CIOs, and, you know, your expertise in technology that— in which is targeted for CIOs is critical. And if you can share more about that.
Well, I think it's— in some ways, one of the things that we're able to do— I agree with Wendy. Being a CIO in a technology company can have its own challenges in the fact there's typically no shortage of advice. How you can do your job better.
We know that.
But what we do get to bring is the outside-in view, that external perspective back into your own company, whether that's through the professional communities of feedback. Feedback is a gift, whether you like what you hear or you don't like what you hear, it's a gift nonetheless. The fact that you can get unsolicited feedback, or even solicited feedback, that's open and honest from other CIOs or IT leaders in the technical, in the tech community, because at the end of the day, CIOs prefer to talk to CIOs than maybe they do to a salesperson or something. So we're able to bring that outside-in view, bring that community feedback into our own organizations to make us better. And that's a very valuable set of data that we were able to bring in.
Well, I'd say yes, and I'd also add that The CIO community is really collegial. And I don't think that if you're not— and the reason is because the bottom line is our jobs are super hard. I mean, you look at all the things that come at us any given day. You get everything from infrastructure to apps to mobility to security. I mean, it just goes on and on. So what we do is we tend to lean on each other to say, what are you doing? What does that work? What have you found about this? And not that we're sharing any kind of trade secrets or anything like that, but it really just is about what is your experience? And what are you doing. And the second that we're not credible about that, or the second that we're not honest about what we know, then you lose that credibility with your colleagues and peers outside of your company. So that's one. The second that I think is super important is, again, we're the practitioners in the organization. We're the operators. We're the one that's operating and running the company, right? So when all of a sudden you have something that's not working as good as it needs to work, or it's breaking something else, We have to be the voice in the company to say, "You know, the product's fantastic, but if you tweak this or fix that or adjust to that, it would work better." And at the end of the day, I think the engineering organization likes that feedback. I mean, it's hard sometimes, but they really do want to make their product better and work in their ecosystem. So the program I mentioned earlier, we actually call it Customer One. And it's a program that ties together engineering, IT, and the sales organization. And what we've evolved to now, which I think is fascinating, is not only the engineers will work with the alpha and beta stages of the product, but we're actually taking the product managers and actually helping them sit with us, or in some cases do it themselves, to actually implement it. Because what a great learning that is to actually, again, implement it in a really tough and complex ecosystem. So we're taking that to the next level too, which also has huge learnings. And again, What I found is that they not only learn about their product and how it's working and running, but we're able to just make the product better because of course when they go to sell it downstream, then some of those kinks are turned out.
What about your engagement with EBCs and just the impact that that has in the organization?
Yeah, so an EBC is our Executive Briefing Center. So what happens is the sales team brings in a lot of our customers. And we're asked to come in and talk about the role of what we're seeing around the whole plethora of the whole portfolio of, say, security and our security products. And so customers will be in various stages of that, but you're being on that presentation and explaining how you deploy it, what you're seeing, what you're using. And again, I worked at Cisco prior to Symantec, so 8.5 years with Cisco. And you're asked to make sure and tell the whole truth about what you're seeing. You have to talk about the things that we're working on. I've given the feedback to the engineering team on this piece of roadmap. But you have to be that always honest, always transparent, always completely upfront about all that we're seeing in our environments. And that goes a long way with that connection to the customers.
Wendy, can you talk about what you were mentioning around the difference between engineering and the operational excellence aspect to it?
Yeah, definitely. It's just like Sheila was saying as well, in a way we track that whole lifecycle of a prospect to a customer, right? We'll spend time in those EBCs talking about our product, talking about our technology and our experience, but we've also been customer zero. We're out there first just trying to bring some operational realities. Talking about this data movement thing, my company has a hypervisor. And I don't know how technical the audience is, but we have a hypervisor. [FOREIGN LANGUAGE] Okay, good.
Yay.
And it comes with our product. It's free, but we weren't using it because we had just recently released it and we just weren't using it. And so I came on board and found out, oh my goodness, we're not using this thing. I'm going to migrate over to our free hypervisor and save some money. Well, it turns out that there genuinely was no way to move the data. So I couldn't consume my company's own free product because the guys who had developed it sort of had this assumption that, well, you'd start from scratch. You go out and buy something new, but in fact, being an operating organization, we're not starting from scratch. And so, I had this wonderful moment, I sat in a sales meeting and they were saying, "Wow, you know, adoption of this thing is so low. We don't know why, it's such a great product, it's got all the features on the list." Well, the reason why is there was no bridge. There was no way to get to that island. And so, just, you know, spoke with the engineering teams, and, you know, God bless them, they said, um, oh, well, we, we've had this like data mover tool that's almost developed absolutely like another, you know, week of development. Um, we didn't know anybody wanted it. We could finish that up. Of course, it took 3 weeks of development, but still, in 3 weeks of development, we had the data mover tool that allowed me to consume the free hypervisor. And so it's, it's that That sort of thing that now I will tell you, I love the free hypervisor, right? And so now I'm an advocate for that product. I always was an advocate for the technical bits and bytes, but adding that next layer in and then being able to come back to our customer advisory board at the end of that lifecycle and say, you know, when they're saying, yeah, but we don't know how we could even use this thing, I could say, ah, we built the bridge, and they all know what I'm talking about. Whereas that feedback was just not making its way back to the organization. So it's frankly a much more important and sort of essential role, yet super simple, than what I was imagining when I wasn't working for technology companies.
Yeah, I mean, I think about, you know, you talked about the intersection of engineering, Sales and IT. And I remember you talking about how this program is actually reported out to your board.
Yes.
I'm wanting all of you, for those CEOs or leaders who— of technology companies that are actually selling to CIOs, I know there's many out here in this conference specifically. How strategic of a program should that be internally, is the question, and where does it start? How did it start, and who sponsored it? Who is your executive sponsor?
Yeah, well, I think, I mean, I think there's, we all experience, before I was at Box, I was at HP, and prior to that, I was at VMware, and in every case, one of the biggest challenges that I've seen when it comes to selling your capabilities or services or whatever they might be is not actually often the technology side of things. I'm gonna get to the sponsor thing, 'cause it ties in. It really needs to be a program. It really needs to be an investment in a program, whether you call it box on box, HP on HP, VMware on VMware, Symantec on Symantec, whatever it might be.
Some people call it eating your own dog food.
Dog food, drinking your own champagne, right?
Drinking your own champagne.
It really is, because here's the reality. Technology is an enabler at the end of the day. In fact, in the most part, technologies outpace and outstrip the ability for most organizations to actually keep up. And so the biggest challenges of technology is typically the adoption, the change management, and in some cases organizational change management. You know, you may be implementing capabilities that disrupt— back to the operational aspects of things. And all too often, unless you're actually in the trenches working through these things, A sales team, an account executive team, or even a marketing team doesn't have that entrenched understanding of what it actually takes to deploy, implement, run, manage, operate. If it doesn't become a program, that feedback that makes you much more credible in helping your customers to not only just buy your services, but also to implement, run, manage. Which is most critical for a SaaS product. Most critical. That's how most organizations, or not most organizations, most technology fails, not because it can't do what you expect it to do, it's how do you get value from it, how do you get the value out of technology, and that's what we can bring as long as internally you do have that sponsorship to go really make that happen.
What level of sponsorship? You know, obviously it's not a pet project. Is it just any program? You know, what level of—
No, it's a C—
of cross-functional sponsorship is required to truly have the level of impact? And does the program ever end?
Well, so I guess I would say on that is I think it's kind of crazy to call it a program. To me, as a CIO of an organization of a high-tech company, I have a deep responsibility to make sure the product is as good as it possibly can be before it goes out the door. That's my job. And so to say that it's for the board or for a sponsor or it's a program all imply that it's not as important as it is. It's in our DNA. In fact, our newest leader of our engineering organization is inviting the IT service owners. So if it's set for an endpoint product or a DLP product or gateway, any of our products, we're inviting the right service owner in the middle of the product reviews on a weekly basis. So you talk about near real-time feedback right then and there. The person that runs it is sitting in the room. So I think that's where I think it gets the juice that you need it to do and has the effect that you want it to have is when it isn't just a monthly thing or a report out, but it really is in the DNA of the company. The other thing I'd comment too on as well is it's not just about the technology. We buy a ton of software from a lot of companies. I can tell you what companies I like to buy from and which ones I don't like to buy from and what their ELAs look like and their licensing structure and their models. And some of those are great and some of those aren't advantageous to us. So we have that view of what companies you want to work with because of their licensing and business model and which ones we want to do business with because they have our interest at heart versus the ones that are just trying to make the almighty dollar. So it's not just the technology we can give input into but the actual business model as well.
Yeah, at Nutanix, the CEO in particular is very interested in this. And we're— yes, there is a program, a customer success program. And there are leaders of various aspects of it. And as the CIO, that's a big role that I have to play as well. But just like Sheila was saying, Jason M. Lemkin, we do have sort of lines of development, and in each of those product lines there are IT people, leaders in my team, who are providing direct input into those areas and using the product and iterating and all of those things. So that feedback is really important. And then we have developed metrics that we track internally as key KPIs that we actually report to our board. So, things like a metric that I track called first-time right. When a product is delivered to me from any vendor, I track if it's right the first time. And I report that back. And so in a way, that's a report card on the engineering organization, the QA organization, build and release engineering, all those things. as well as a report card on my team in terms of how we ingest and how we use. We use that same metric, like you're saying, for other vendors as well. Whether or not they acknowledge it, it is still something that we track and we remember. If their percentage, if it's a low number, I don't want to do business with that vendor again, unless I'm on purpose doing we're doing something speculative, if we're experimenting together, that's a very different situation. But, you know, I'm an executive in the company. It's a publicly traded company. I have a fiduciary responsibility. I have a technical and operational responsibility. And that's job one. So if our product isn't good and it's not working for us, then I'm not— I'm not meeting those other responsibilities either. And so those things are— it's a balance. I take it really deadly serious. You know, they're sometimes a little afraid when I walk in the room, right? But at the same time, you know, it all comes from a good place. And I think that's what we know, right? We're all coming from a place of caring about our company and our employees and our customers and shareholders.
And I mean, you know, the level of investment in terms of building real expertise in all the products that your companies serve, it takes an investment, right? I mean, it definitely takes an investment with the rest of your portfolio and the rest of the entire organization that you're looking to run. And so, you know, how do you balance that investment to— because it is part of your DNA and because it's a strategic initiative, how do you balance that level of investment, you know, to be able to provide feedback to product early on? Do you sense— do you find challenges in continuing the level of investment that's required as new projects come in, new products come in through acquisition?
It's a good question, and I think that if you break it down to trading off your budget to this or something else, then I think it is missing the importance to the value of— and back to Sheetal's point, I don't think it's a program that you sort of report out on. It's a way of operating, it's a way of thinking, right? It should be ingrained in the way that you run your organization. But I think that what we have done, and I've certainly done this in the past, is that if your company is serious about this, it takes a different set of investments that are outside of what your baseline, what it takes to run your IT operations and your organization and normal business capability investments. Because if you start to compete, then you may be trading off against something that has potential tremendous upside to the company. Selling your capabilities. And I think the other thing that also gets caught up a little bit in here, which I think is also very valuable, is that it's a great way for your own internal sort of IT organization to get connected with other IT organizations. We often connect, we get asked a lot, how do you think about IT at Box? And Box, as in our usage is a part of that, but it's more broader than that. We all deal with a lot of the same complexities and challenges as one another. And the advantage of connecting our own IT teams is that we all learn best practices from each other as well. And you can only do that if you are a strong user of your own product.
Yeah, I mean, I remember when I first talked to Mullen, Yen, about SaaStr. And, you know, mentioned and spoke with Jane from Zora about this session, I was thinking about topics. And obviously, this is a topic that I'm extremely passionate about. And I was thinking, what other CIOs are super passionate about believing in their product and actually love their product and love their company? I mean, if you don't love the product that your company builds, then What are you doing there, right? I mean, we have to truly love and invest in the product to make it better and evolve your company, the entire organization. And I thought about CIOs that I knew, and it was really through this. It was the way that I knew each and every one of you is through engagement in using our own product. And so it's a reflection of the power of not only the impact it has on the organization, but the impact it has on you personally as a leader in building relationships across the world, right? If you could please share what the impact it has on each of you personally.
So I think I'm going to answer that one and go back to your other question too. I've kind of set up the IT organization as a service owner organization, so each of my leaders are owned— they own a service end-to-end. So let's talk about mobility. So if they own the mobility service, they own the deployment of devices, the security of the devices, the optimization of the device end-to-end. If there's help tickets about the device, something's going on, and I mean devices, it's your mobile or maybe even your laptops, and you're calling the help desk or the help desk, that all those costs go to your service because if there is a lot of calls to your help desk, there's something wrong with your service. So they own the whole service. So when you asked earlier, how do you allocate time? Well, we just— I'm going to link that— how do you allocate the time and the investment with both an acquisition. So we recently acquired this company called SkyCure. And it is absolutely the best— and this is a sales plug— it is the best mobile— mobile— set mobile security endpoint product I've ever seen.
I did it. I did. Oh, did you do it?
Okay, good. Fantastic. Behind the scenes, you can actually have all your data applications and everything secured. So the service owner—
SkyCure?
No, it's SEP Mobile now. So SEP Mobile, Semantics Endpoint Protection Mobile. And what happens is the service owner got ahead of the SkyCure integration, and they own that service. So they were like, OK, well, what we were using wasn't great. So let's look at this. And within— literally, I'm not kidding— within 3 weeks, we had 8,000 employees employees deployed. Yeah, so one, it was that simple and easy to do, and two, it was why not? If you can have that extra level of security and all that, they're making their service better, they're optimizing their service, and of course we're using our own product. So that's a really important point. And when you have that kind of expectation of the service owners across the organization and they're bubbling it up and they're using the product and/or— I've had examples where it isn't working as effectively as you want it to. But they're giving the feedback back to the engineering organization. It just makes it all better. Yeah.
Yeah, and I'll add, I mean, an example of this behind-the-scenes thing is we were preparing for today and we had a call and you were sort of telling that story and I was like, I got to find this thing. That sounds good. That sounds good. So we also, we do share it. We do have that relationship. I wouldn't say we're, it's not a secret cabal, we don't get together in a treehouse. Treehouse handshakes. Although that would be cool, I don't know why we never do that. But we definitely begin to trust each other and I think that's a genuine benefit also as a feedback mechanism to the companies where we work as well. We can say, you know, hey, I don't think that would fly. If it wouldn't work with me, it wouldn't work with people I know, then we're providing that, that level of feedback.
Thank you all so much. Um, you know, this is, this is just a really powerful topic, and I couldn't have asked for a better panel to, to share it with.
Thank you all.
Thank you. Thank you. I'm so glad you made it.
More from Jason

Why Your Next Hire Should Report to an AI, Tragedy Apps, and Too Many AI SDRs? | The Agents #004

Our Agents Drove Our Salesforce Bill Up 80%, Marketo Hates Agents, and We Stealth-Churned Off Notion

Managing 20+ AI Agents: Lazy Agents, Our $500K AI Bill, Stealth Churn & the Death of 60% Solutions







