Former VP of Business Development at Unily
This executive has 15+ years experience in business development, sales and operations with a variety of digital media and software companies. He recently worked at cloud-based SaaS intranet platform Unily as a VP of Business Development, where he managed accounts from end-to-end covering prospecting, consultation and negotiation.Read moreView Profile Page
Disclaimer: This interview is for informational purposes only and should not be relied upon as a basis for investment decisions. In Practise is an independent publisher and all opinions expressed by guests are solely their own opinions and do not reflect the opinion of In Practise.
The whole intranet space wasn't as intriguing to me until it became quite clear that hybrid work, post-Covid, would be a lot more prevalent. So I started trying to get up to speed on the intranet space, how big corporates and not so big corporates interact with their intranet, and why they would turn to an intranet in a box product. You've had significant roles at Unily and LumApps.
It would be great to hear more about you, your experience, and how you saw the space evolve. I'm curious to hear your thoughts on intranets; they're calling them employee experience platforms now. What do you think about corporates needing or using intranets and using software on top? SharePoint has evolved a lot, with Modern being a whole lot better. What I understand is that it's become prettier, but it's still not a great tool if you're an internal communicator at a 5,000-person business; there are still many gaps that a LiveTiles or a LumApps, or a Unily could help you fill. We could take the conversation a number of ways, but I'd love to hear your experience, and we'll start from there.
Sure, let me give you a little overview of my background. I have been in digital software sales for 15 plus years. The majority of that has been in the mobile space, so a lot of focus on applications, but in the past several years, I've found myself in SaaS-based – and more specific to this conversation – SaaS-based intranet platforms. I was the AVP of business development for Unily and an enterprise account executive at LumApps. The roles were effectively the same even though the titles were different. I was responsible for prospecting, engaging, consulting, nurturing, and closing accounts that were typically enterprise agnostic in both instances and generally upwards of 5,000 plus employees, which is how they break those accounts out. Both companies target companies with lower employees, but I would focus primarily on the larger ones in terms of carving out accounts. The role was obviously a sales one, but this intranet space is such a long sale cycle, and the sale cycle could be anywhere from six to 12 months, depending on the size of the organization.
Why was it such a long sales cycle? Is that just the nature of trying to sell something that touches 5,000 different employees, that you need signoffs from 10 different departments instead of a software product that's only going to be used by the finance team, something like that?
I think that plays a big part in it, and you touched on something earlier, which was that, historically, the intranet was the realm of maybe internal comms. It was a one-way modality for pushing news out to the entire organization. It needed pretty basic functionality, so signoff was pretty straightforward. With the complex makeup of what an organization looks like today and the requirements that different departments have, an intranet now touches, like you said, multiple departments: IT, comms, HR, even the C-suite has a say in the matter. So getting buy-in is not something that happens like it would for your finance software or your project management software.
I'll also add that there's also a level of internal demand for the software. Typically at 5,000 plus employees and above, they already have something in place. That could be your existing SharePoint, that could be a custom-built solution, that could be another vendor. The question is, what is driving the purchase decision for a new intranet beyond what you already have. With that, comes due diligence regarding the pain points that we have across the organization. What are the budgets? The internal comms person might be the champion, but they're not always the best equipped to lead that initiative.
When you sell a product into a 5,000 to 10,000 employee business, the sales cycles are quite long, but in my understanding, the deployment cycles are also quite long sometimes for that scale of business. Is that right?
That can be correct. I guess, most typically, it is. Long is relative. The technical plumbing of the platform is usually pretty straightforward, whether it's weeks or a month or eight to 10 weeks. If the implementation is fairly straightforward, that technical piece is not what takes so much time. What can extend the length of the deployment from three to six to 12 months is the other components that go into preparing for a new intranet. That could be migration of old content into the system, integration of third-party software, governance plays a big role, and knowing what permission structure you want to set up for this new intranet. If the organization doesn't have that all mapped out before implementation, that can extend the timeline.
As you get to these quite large deployments, 5,000 plus employees, in my understanding, once you pick a vendor, they are generally quite sticky products because of the potential six-month rollout. Has that been your experience?
It goes without saying that if you spend six or 12 months on an implementation and the cost of the license, all of the brain damage that goes into implementation deployment, and getting your organization to buy into this, the last thing you want to do is a rip and replace. That goes for any software of that level, but because the worst thing you can do is buy a new intranet platform and have nobody use it, that particularly goes for intranet. There is an element of stickiness to these platforms so that, by nature, you have to really screw it up to get people to start looking at alternatives. Screwing up could be the product not doing what we want it to do, not integrating how we want it to, or costing too much money, perceptually.
When you think of integrations and what customers wanted, what do you think about Salesforce and Workday and others like that?
Those are pretty common ones; your HRIS systems, Workday, SalesForce. Look at the websites of all of the usual suspects that play here. They will all show the usual suspects of third-party software on their sites. You get a sense that if you're having discussions with large enterprises, they don't always have a clear idea of what these integrations should do. Still, they want to make sure that they've got their bases covered and their intranet can play nicely with the existing software stack of the enterprise.
There is also a level of table stakes of just being able to integrate with Microsoft or Google Workplace software. Again, that means different things to different vendors. Still, typical integrations are integrating with this piece of software. I'm displaying content, or I’m authenticating that a user has the license. I'm displaying certain types of content to that user via the intranet platform. It can be simple links that pass through, or they can even be iFrames, which are not really “true” integrations because it’s just displaying content within a frame. There is still a little bit of nuance there towards what it means to integrate third-party software. There are security implications on how you do it, and large enterprises typically have very specific requirements for the approach they want to take.
When you were competing for an account, was it most often that somebody was moving from a custom-coded solution to a third-party product vendor like a LumApps or Unily, or LiveTiles? Or did they not have anything, or were they transitioning from a competitor? LiveTiles points to a structural shift, or at least they used to in that there are X hundred thousand corporates that use SharePoint, and 90% of them have custom-coded intranets that are not as good as using a software product. Does that jive with your experience, or not really?
That's not my experience but take that with a grain of salt. I'm one account executive. I will say I came across a fair share of enterprises that do have something custom coded. If we dig a little bit deeper into that, I didn't come across any 5,000 plus employee organization that didn't have an intranet in place. They typically have done something custom. They very frequently will have been using SharePoint or something like Jive, which have been around for a long time. SharePoint is one of the most common intranets for reasons that you've pointed out. It's a bit clunky for internal comms people to use, and as you grow your organization larger, there are some limitations. You want things easier to use, and these limitations can typically be overcome by doing additional custom development.
That's the strength and weakness of something like the Microsoft platform, which is you can build sophisticated custom development types of SharePoint intranets that achieve what you're looking for, but the cost to get there can be significant. There are a bunch of studies that show what those costs are. If you go down the road of a custom-built SharePoint site – it sounds oxymoronic, but we often use that – it means you have a team of SharePoint developers that still need to maintain that platform. Does the cost of employing that support team for the platform and the people using it outweigh the SaaS-based turn-key intranet platform? The general trend that we would see, and hence the number of players in the space, is that the trend is towards buy versus build.
At least what LiveTiles would say is that when you get to a certain scale, there’s no such thing as just buy. You’re always doing some building, too, even with a software product. Would you say that’s true?
Yes, absolutely. With any of these platforms, the concept, at least the one that we would emphasize, is that your intranet shouldn't ever be a static platform. You should be testing what works, and you should constantly be adding to a platform, adjusting it. Just like any kind of lean methodology, you're seeing how particular users are using it. Then you should be able to adapt to it, not through custom development but through a platform that supports configuration or custom development. That's the benefit of an evergreen platform like any one of these vendors. They're constantly working on the platform, introducing new features, new integrations, and so on.