Follow the Workflow: Product Strategy at ServiceNow

If you decide to pursue a Follow the Workflow (FTW) strategy, perhaps the most difficult decision is over which workflows to follow. There will be far more options than you can imagine, and each step needs to be carefully considered. We talked with Dave Wright, the Chief Innovation Officer at ServiceNow, about how they balance these tradeoffs. The highlights:

‍

1. The starting position is perhaps the most important: There is a tension that comes when your ambition is to become a platform. That first product has to be a visceral, real thing that solves a concrete problem. However, the better you get at solving the first problem, the tougher the transition will be when you jump to multi-product. To make your life easy, make sure the primitives that your first product is based on will naturally transition to platforms. For ServiceNow, it was about managing tasks and assets. 
2. Everyone needs an Eric Hemmer to help the customers: Eric was a scrappy generalist who was willing to lead customers to the next level. You need to make sure you have the right people as you start to expand, as they will set the DNA of the organization. If your employees believe you can be a platform, your customers will too. 
3. Follow a maturity model as customers grow: Just as ServiceNow followed customer demand to pull the product, they also followed customer growth. As a company scales, complexity increases exponentially, and the system requirements do too. The products you launch should track the customer's journey. 
4. Building platforms is about balancing trade-offs: How do you think about resourcing platform vs. product? This question is another way of thinking about the trade-off between bespoke flexibility and the power of standardization. Unfortunately, there are no universal answers, and this tradeoff shifts as you move down from the UI to the workflow to the data layer. The further you go, the more important standardization and taxonomy are.
5. Focus on creating the best experience, not just being first: If you want to transform something from a platform perspective, “you don’t have to create something new. You’ve just got to create something that’s so good that it far surpasses whatever someone had in the past.” Create something that’s Better Together!

‍

We hope you enjoy this first interview in our Follow the Workflow case study of ServiceNow.

‍

‍

Dave Y: Maybe, Dave, we can start with just a bit of your personal background because I think it’s always great to hear where you’re coming from.

‍

Dave W: Yeah, sure. I went down a different path to a lot of people. I left school at about 17, and ended up moving from Liverpool, where I was born, down to London. I got a job at London Electricity as a mainframe operator, and trained up to be a mainframe sys prog. I ended up working for a mainframe software monitoring company. I was with Campbell for a while, Boole & Babbage, a company called Maxent, and then in the mid ’90s I ended up at Peregrine Systems. 

‍

That’s where I first met Fred, the founder of ServiceNow. I was there from ’96 to 2002. Then we obviously had the whole Chapter 11 pain, HP, and went through an acquisition process. Fred went one way and started ServiceNow. I went via Mercury Interactive to VMware. I was at VMware for seven years as head of technology. Then I joined ServiceNow in 2011. I started off as an SVP of Solution Consultants, and then was Chief Strategy Officer for five years. I ended up Chief Innovation Officer for the last four years.

‍

Dave Y: That’s a heck of a run. Super impressive. Thank you for taking time today. In some ways, the origin, the initial landing place, from an application standpoint, was ITSM.

‍

Dave W: Right.

‍

Dave Y: It’s not surprising, given the Peregrine background, but as you reflect on it, what do you think are the advantages and disadvantages of starting there?

‍

Dave W: Let’s go back through the history a little bit. It didn’t actually start as ITSM. When Fred first came up with the company, he wanted a system that could manage any workflow across an enterprise—anything where you’re recording data, it’s being moved around an organization, [and] people are actioning that data, updating that data. He met with Pat Casey, who’s our CTO now, and they designed the original data model, the database structure orchestration engine. That was when the company was called Glidesoft. Then they went to try and go to market and get backing on that, and no one understood the concept. At the time when he was doing this, he’d been joined by three other guys. They were all ex-Peregrine as well, so at this point, all five of the people are ex-Peregrine.

‍

Fred actually had made a statement that he didn’t want to do ITSM again—that he’d done it once, and he didn’t want to go back to it. No one could understand the platform [they built], so they sat down and said, “This platform is for building service apps on. What can we do to show people the power of the platform?” They built a service management solution as a demo of what you could build on the platform. They only did that because they were all ex-Peregrine. If everyone had been ex-Siebel, they would have built a CRM system, or if they’d been ex-SAP, they would have built an ALP system. It just happened they were all ex-Peregrine.

‍

The inherent advantage to it, I think, was accidental. If you think the premise of the system is to manage service, then at that point in time, the only part of an organization that had a defined model for how to deliver service was probably IT. It was part of the organization that was used to defining how service was ingested, how it was measured, how it was delivered, how it was tracked. It did end up being a good basis, but it probably took seven years for people to really understand what the vision of the platform was when it was created.

‍

Dave Y: Yeah. I want to raise this idea of starting as a platform. It seems like that is foundational to the bigger story. You start where you know the problem, and you start where you know the solution.

‍

It’s a really interesting observation that IT was one of the first to build processes around service. ITSM was, and still is, a fairly small market. Peregrine was a relatively older company and product, with high switching costs—that’s what all of the buyout investors loved, and some of the other acquirers loved, but [it was] relatively long in the tooth. Is that a fertile ground to start this whole thing in? I know it was somewhat accidental, but in retrospect, was it a good place to start?

‍

Dave W: I think it was. I mean, there are pluses and minuses to it. The plus was, as you say, that it was a long-established system where people had gone all the way from IBM’s Infoman or mainframes through BMC, CA, HP, [or] Peregrine—all those products kind of doing roughly the same type of thing. It was an area of technology that I think was due for a refresh. It hadn’t been touched architecturally for at least a decade. Everyone was still on premises at that point. 

‍

The other thing that was different about the platform at that point was that it was a SaaS solution, as opposed to a platform that was deployed on-premises.

‍

I think the downside to doing something like this—and this is true for almost any company, but especially any company that has any kind of platform position—is you always end up being known for what you do first. No matter how much marketing you put in, Salesforce will always be the CRM company, and Oracle will always be the database company, and SAP will always be the ALP company. It’s been a real struggle for us to go to meetings and not have people go, “Oh, you’re the ITSM guys.” You always have that challenge of breaking out of the shell you’ve created for yourself.

‍

Dave Y: When you did start expanding beyond ITSM, it was within IT. Was that customer-led? Was it strategy-led? Was it sales-led? What was the nudge?

‍

Dave W: Initially, it was customer-led. I can’t remember the first customer, but I can remember the solutions consultant that started it. It was a guy called Eric Hemmer. Eric had started speaking to customers who were already ServiceNow customers and saying, “You know, if you wanted, you could take a copy of the IT incident module and modify it. Because it’s a platform, change the classifications, and you could use this for human resources requests. You could do HR case management with it.” He started to get more and more customers interested in this, and he was pushing the story, and people were finally understanding that service management could move outside of IT. 

‍

Employee, I’d say, was driven by customer; customer service, as a concept, was driven by strategy. That was the product team saying, “If we can do this for IT, if we can do it for employees, there is no reason why we couldn’t do it for customers, because this is specifically designed for service.” Once we had those kinds of beds out there, then it was easy to visualize the expansion. It was easy to say, “If you’re going to do three parts of the company, why not do the whole company? Why not look at global business services? Why not look at an enterprise service management model?” That was probably a little bit ahead of the thinking of customers at that point.

‍

Dave Y: Yeah, I love that. [As] you think about Eric, your talented SC that comes up with this, how do you foster that? How do you find people or processes to really pay attention to customer-led expansion?

‍

Dave W: I think some of it’s driven by the nature of the company. At that point, you’ve got to remember, the company is probably 400 people, maybe 500. It had a culture of innovation within it. You could still go and sit with a founder and run ideas past them. At that point, everyone was sharing ideas. If one person created a demo, they’d share that demo with everyone else. It allowed [the company] to expand initially, I’d say, without strategy. It was very much, there’s a demand and we can fulfill the demand, as opposed to saying, “This is the next step in the evolution.” The nice thing was, playing it backwards, we could always say “Yeah, this was always what we wanted to do with the product. We always wanted to manage any type of service.”

‍

We ended up with a field SC team that was very dynamic. I think at that point in a company's evolution you end up in a place where you’re employing people who can do everything. Every SC that we had could also implement the solution, and probably had implemented it. They could program. They could code. They could create applications. Having the capability to do that means you’re not tied down. If a customer goes, “hey, could we do this?” you can look at it, consider the problem, and say yes or no based on whether you can do it. It allows you to be a lot more honest in the answers that you give, but you’re also not reliant on someone else having to produce the code.

‍

Dave Y: Awesome.

‍

Avanish: Dave, is it fair to say that it was also a matter of mindset? That whether it was Fred, you, Pat Casey, or others, you always thought “platform,” and that the folks you hired thought “platform,” and therefore were willing to make those experiments?

‍

Dave W: Yeah. I’ve said when I give my history to people before, when I first got the phone call to join ServiceNow, I didn’t show any interest in it. I didn’t want to go back to the world of ITSM. It was only speaking to Fred, [as] he explained the vision, that I realized that actually, yeah, this is a platform. 

‍

To go back to what you were saying earlier, Dave, ITSM was a relatively small market. I think Gartner were positioning it at about 1.5 billion. But as I’m sitting with Fred hearing the story, I’m thinking, there is no TAM for this because everything can be defined as a service. Every part of a company provides a service that’s consumed by something else. Otherwise, there’s no point in them existing. It was very hard to even visualize what the TAM was. I think having that mentality—and educating people that way when we brought them onboard—that this is a platform, and ITSM happens to be the first thing we’ve built on it, was what enabled a lot of this innovation to happen.

‍

Dave Y: That’s a great callout, Avanish. Switching gears is much more of a strategy or product-management driven expansion path. How did you pick the different areas? What factors played into those decisions?

‍

Dave W: I think the first thing is to look at what the platform is good at doing. A platform can be as flexible as you want, but it’s going to have something that it’s very good at sitting at its core. For us, the platform was exceptional at managing tasks and managing assets. If we looked at that as the core, then that allowed us to look at how we were going to expand out to separate areas. It’s very easy to extrapolate that out and say, “Well, you’re managing tasks. If a task comes from a person, that’s typically going to be some kind of request or an incident or an issue they’re dealing with. If that request comes from a machine, it’s the same process, but then you’re dealing with the world of event management.” Then it was easy to get into the world of events.

‍

When we started looking at service management, one of the key things to managing IT service was the concept of a configuration management database. That meant that we had to look at discovery technology. Once we started doing that, then we got into the world of IT operations management. We were expanding out IT by looking at service [and] operations, then customers would come and say, “We want to actually be able to manage IT projects. Could you do an IT business management wrapper that goes around it?” Then we started to see GRC. We saw all these things start to expand out.

‍

I suppose we then started looking at adjacency, initially, based around pure service requests. Who asks for things? Yes, people ask for things from IT. People ask for things from Human Resources. Customer Service asks for things. People ask for things off Legal. You could start to move out pretty rapidly, based on just looking at repetition of that one model.

‍

The nice thing about having a platform is that it’s all built on the same technology, so as you start to enhance the platform, you then enhance every offering that sits on top of it. One of the big challenges with a multi-product strategy, though, is the go-to-market side, because you have to be able to consume it within the company. When we initially looked at stuff, the engineering side was ahead of the game. We’d go, “Hey, can you build a product that would do this?” They’d look at it and go, “Yeah.” 

‍

We never asked, “Could we market that product? Have Sales got the skills to sell that product? Have we got access to the economic buyer for that product?” It was very easy to create something and then realize you didn’t have the skills to be able to consume it.

‍

Dave Y: There are so many threads to pull on in that statement. Before we get into the go-to-market—and the product strategy that aligns to the go-to-market, because I think that is a key area—can you spend a little bit of time on the how? How do you think about the minimal viable product? How do you test it? How do you think about false positives versus false negatives?

‍

Dave W: I suppose there are different ways that we do it from a software company perspective. Obviously, we’ve got product advisory councils, where there are customers advising on what [they want] you to do. But then you get into the challenge of iteration versus innovation. Customers are going to know how they’re pushing and using the product, and what features are going to be useful in the products. You’ve got to balance that out with the Steve Jobs or Henry Ford conversation [where] no one asked for what you provided; you just have to provide it. 

‍

There’s a mix of incremental innovation that sits on top of what customers want. There are whole separate divisions of the company—NowX is a great example—that are given free range to go out and build whatever they want and not have to deal with sustained engineering. There’s what we get from outbound product management—looking at what’s happening in the industry. There are also people like the folks on my team, who are looking at the  industry trends affecting things, because there are quite often trends out there that are going to have some fundamental effect on us in the future, that might well drive different types of innovation that you look at as well. 

‍

What we tend to do is, we build a new product. We’ll ask customers to become lighthouse customers, which typically happens during the development phase—they’ll not just be the first users of the product, but they will help give advice around that development stage. Then we start to go to market with it. If the lighthouse customers are viable, we potentially do a beta release or a soft launch, getting out there with a select number of customers. Eventually it graduates into a business unit and becomes a fully-fledged product. 

‍

You also have to be willing to fail products, or decide that’s not the direction to go in. That goes all the way back to Avanish’s point before, around having a culture of innovation. You’ve got to be happy with the idea that you’ll fail, because otherwise no one’s going to try anything. Failure is a key part of it as well.

‍

Dave Y: Yeah.

‍

Dave W: What did I miss? You were talking about false positives. Yeah, you can get a lot of weird false positives, especially if you look at how you package what you sell. Quite often, if you sell things in a bundle, unless you’re actually doing the analysis of what people are using, as opposed to what people are buying… 

‍

We did have products where we were thinking, everyone’s buying this! But you realize they’re actually buying it for another component that sits in the bundle. One of the things we’ve had to look at recently is how we actually use intelligence across the platform to understand what people are using to proactively highlight, “You’ve bought this, but you could be getting more value from it.” That was where the Impact product range came from.

‍

We’ve had false positives where we’ve misunderstood why people are buying things. We’ve equally had false starts where we thought we could build a product in an area, and then we either couldn’t sell to that area, or the product was slightly ahead of its time, or the product just wasn’t going to do what we thought it was going to do.

‍

Dave Y: Have you had any notable false negatives? Where it just all clicked on, say, the third time?

‍

Dave W: What do you mean, where we’d try to do something and it hadn’t worked?

‍

Dave Y: Yeah.

‍

Dave W: I wouldn’t say it just clicked, but a good example of that would be IoT. When we looked at managing IoT devices, we went out and created a product called Connected Operations. Connected Operations was very much focused on being able to take real-time data from IoT assets, process that data, and effectively start to create a digital twin of those assets. We just didn’t get traction with it. It was a struggle for the sales team to understand how to position it; it was a different model than people were used to within the ServiceNow platform. We end-of-life’d that after a while—but once we end-of-life’d it was, people still wanted to be able to manage connected assets. They started to look at alternate ways of using things like event managements, or being able to use different asset classes within the same DB. We actually started to re-create that out of the core platform.

‍

That was something that launched, failed, and then kind of got reborn. Now, we do still see people coming to us asking, “How are we going to manage these connected assets?” It hasn’t taken off as a major business line in the same way we think about employee or customer, but I could see it happening in the future.

‍

Dave Y: Yeah. Avanish, were you about to jump in there?

‍

Avanish: When Dave touched on the multi-product frameworks… One question that often comes up in investor [and] board conversations is resourcing. How do you resource when it’s kind of experimental? You mentioned NowX. What’s a resourcing model for something like that, versus more run-rate business?

‍

Dave W: I’d have to find out CJ’s split on investment, on how he does engineering, but I’m sure he processes it somewhere along the line of current release, future release, and second horizon, and focuses around 10% of the development resources on what would be seen as second horizon. That could be anything from having NowX as a group, to also looking at the advanced technology group—people that are looking at AI functionality within the platform, or potentially looking at new technologies that would sit within the platform. That’s kind of the split that we do. It’s around 10% on that second horizon.

‍

Avanish: That’s great.

‍

Dave Y: So, we’ve talked a little bit about the strategy. We’ve talked a little bit about the launch. I think what you were hitting on is how to enable the sales team, and the mindset of how a customer might consume the various products. As you go from one to two to three to ten, in some ways you have to have a maturity model: the customers buy this product at this point. It seems very specific about which products are “land” and which are “expand.” How did you guys think about that? Maybe start within IT.

‍

Dave W: From an IT perspective, you can model it around a CMM model. You can look at whereabouts someone is on a maturity curve. For us, ITSM is a given. Anyone who’s running an IT department has to have a way to process that work coming in. Initially, it was people looking to say, “How do I manage my assets within the data center?” Over the last 10 years, it’s become, “How do I manage my assets in the cloud?”

‍

Then you’ve got to look at how people want to manage infrastructure. If someone’s got a level of maturity where, for example, they’ve got control over all their assets, then you can ask, “How would you apply those assets to the service they support?” You can start to look at concepts like service mapping. Other people will say, “If I can map out my infrastructure to know what supports my business-critical services, then I can start to be proactive about that service management and do much better risk calculations around things like change.” Then you get the next group, where they’re saying, “I’ve moved beyond this. Now I’m in the world of dev ops, and I’m looking to do AI ops. How do I start to integrate artificial intelligence to be able to predict events, or understand what the impact is of things that I’m building?” A lot of it you can start to do by looking at the size of the company and how much data they’ve got, because that’s going to dictate the complexity of what you need to create—or even dictate whether it’s possible to build an artificial intelligence model based on the amount of data that they’ve got. That’s where you go from an IT perspective. 

‍

The interesting thing is, when you go into every other segment, it’s kind of the same. This is one of the great things about having a multi-line platform-type solution. If you can make sure your adjacencies all match something that’s replicable from a business perspective, you can keep on iterating on it. If you’re going to have some form of case management, or some form of request system, every part of an organization is going to be doing work for people. People are going to be asking for work. Therefore, you can do incident or case management for any division in the company. That’s a good multi-stream proposition straightaway.

‍

You can take all those principles we talked about before and apply those as well. I could go to Human Resources and not just offer them human resources service delivery, but I could ask, “How do you manage ideation? How do you understand what people want? How do you look at what you’re going to focus on next year? When you’ve decided how you’re going to manage your portfolio, how do you then prioritize the projects? How do you manage the projects? How do you introduce things like continuous service delivery? How do you support it when it’s out there?” 

‍

I can take all these best practices that have sat in other divisions and apply those to customer service. A traditional customer service model would be something like, I get an issue, I need to fix the issue and make the customer as happy as possible. But if you started to apply traditional service models to that, the next stage would be, once we’ve got the issue, now we need to start doing correlation. We need to look for root cause analysis. Then we need to do proactive or preventative management around this happening. 

‍

You tend to be able to expand the offering based on the knowledge that you’ve got, which is a very different model than just saying we’re going to go into five distinct areas and not have any overlap around the process.

‍

Dave Y: Back to your prior comment, where perhaps IT was out ahead in terms of creating institutionalized processes around some of these things—it’s a maturity model where you actually can lead the maturity model in other functions.

‍

Dave W: Right.

‍

Dave Y: To switch gears from the product to the platform, this is obviously an area that is great for both you and Avanish to comment on. Do you think this concept of follow-the-workflow as a multi-product company works if you didn’t start as an infrastructure company?

‍

Dave W: Yes. Like I said, I think infrastructure did give us the IT advantage. But now, whenever I go to a customer, the customer is consolidating platforms. They’re not necessarily looking for one platform, but four or five platforms that are going to run their business. 

‍

I think it’s the alignment to a specific C-suite within the business that seems to allow the expansion of things. You saw it happen with the world of ARP, where they were very close to finance, but most ARP companies then started to look at how they could expand into the world of human resources. Or Workday, [that] would be another example [of] looking at the relationship between financial services and human resources, but going the other way. People do often start in one buying center and then expand into an adjacency based on what they’ve done.

‍

I think infrastructure gave us an interesting advantage. Let’s imagine a Salesforce conversation. If you join a company, not everyone will be a user of Salesforce. The sales team might be, the marketing team might be. The interesting thing that I think perhaps we stumbled across by accident was, when you join a company, everyone has access immediately to some kind of IT request system. It’s ubiquitous. That allowed us to get into that space a lot quicker than if we hadn’t been in the world of infrastructure. Maybe it gave us a leg up, but I don’t think it’s essential.

‍

Dave Y: I think of this tradeoff between your identity as an infrastructure company versus an application company. There’s the product market fit and time to market of an application, because you’re not building it for multiple use cases, versus the extensibility and flexibility. As you think about the different layers of the stack, about the UI, about the workflow and the business logic, then you actually think about the data model itself. Maybe take each one of those and talk about how flexible the UI has to be in order to accommodate someone who’s in HR versus IT, so on and so forth?

‍

Dave W: Yeah. When we started out, we didn’t have a lot of in-house design. We ended up going out and buying design companies, Digital Telepathy and Skydraft, to be able to get those designers in.

‍

You have to be pretty flexible, because no one classifies things the same way. Everyone’s got different assignments or work groups that they give things to; everyone’s got different categories that they assign things to. There are some things that are standard, but people want to be able to brand the UI so it feels like it belongs to the company. People want to be able to look at what the UI is like from an experience perspective to be able to use it. We have to give people the capability to configure the system however they want.

‍

 The bigger challenge, I think, around UI—I speak to friends like Troy Osman about this—is if every time you have to build a UI, you could build it from scratch, the rate at which you could move forward would be so much faster. But you’ve got to make sure that whatever you build allows people to upgrade from what they had in the past, and allows those customizations to be consumed as part of the upgrade as well. There are two routes that you go down. You [can] follow a Gmail philosophy, where it’s like, “This is what you’re getting. You won’t even know when you’ve upgraded, but we’re not allowing you to have flexibility around what it looks like.” Or [you can have] a system where you can go in and not just add and remove fields, but choose which widgets are being shown, the layout of forms, and what information density you want. 

‍

We do try and give people as much flexibility as possible. But if you give people enough rope, they’ll hang themselves. They’ll do unnatural things with the platform. I was joking with Pat Casey that what would be more useful when you provide flexibility would be to not give people a best practices guide, but give them a worst practices guide. [Laughter] And say, “You can do what you want, but these are the 10 things we really think you shouldn’t do.” [Laughs] That would keep people a lot safer. But it’s technology. If there’s a way to break it, people will find it.

‍

Dave Y: Yeah. Moving down a level to think about the workflow, in many ways one of the advantages of ServiceNow is this “reuse of request and fulfill” system. Is it right to say that, as you go into the workflow layer, there is a little bit more rigidity of what the workflow should look like?

‍

Dave W: Most people do have distinct or separate workflows that are relatively unique to their business. The interesting thing then is, if you think about that layer, you’ve got the business rules defining what happens and how something moves through a system. 

‍

The bigger challenge is when you go outside of one area and allow another area to start developing. For example, if you’re getting IT to build workflows, everyone in IT is normally fully aware of building logic, and most people can draw a workflow and indicate stop, start, processes, and decision triangles. But when you go and sell to Human Resources or Legal, it’s a different conversation. We also have to link that into the UI to be able to simplify how people could create workflows and orchestration. 

‍

Now it moves forward in AI and generative AI; now the big race is how to get outcome-based workflows, where you describe what you want and have the system define the best workflow to get that outcome. How do you go from text to workflow—describe what you want and have the workflow created? This is where it will get exciting over the next two or three years. 

‍

The other thing is, if you overcomplicate your platform, then IT becomes the bottleneck, because everyone’s relying on IT to deal with that complexity to give them features. You want to be able to abstract at least a layer of customization to a business-model level, that allows people to alter it without needing to go to IT.

‍

Dave Y: It’s really interesting. If you talk to some application companies, they see their view of the workflow as their IP. The best companies run on SAP. You created a much more flexible approach. Are there ways to combine the best of both worlds? You have third parties build on top of ServiceNow. Do you have pre-built workflows that try to fill that need?

‍

Dave W: We provide pre-built workflows out of the box that deal with all the standard things from an IT, employer, or a customer perspective—where we look at things like how we do employee onboarding, for example. We’ll provide standard workflows out of the box for that. We have customers and partners who build standard workflows for how they do things. It could be anything from how you onboard a clinician into a hospital through to how you manage medical assets or how you process insurance underwriting. Partners will come out and write these workflows and put them out there. I’d say most people only use them as a starting point. There are very few people that just take everything out of the box and say “This is the best workflow.”

‍

I had a really interesting conversation with a CIO from a bank. This was years ago, maybe 2016. They said, “Could you define a system with no process, and just run it for a while, then have AI analyze what was the most effective process?” And that became [the] workflow, which I think is a great idea. Not if it’s used by a bank, though. [Laughter] Maybe try it with a different industry first.

‍

Dave Y: Maybe lower stakes first, yeah. [Laughter]

‍

Dave W: But it is an interesting concept.

‍

Dave Y: Maybe you could spend a second here, because that is the investor narrative right now. There’s a viewpoint that applications are going away because AI is going to develop the workflow for basically free. It’s going to optimize the workflow. You guys have embraced AI fairly aggressively, and it adds a lot of value within your workflows. How do you think about five years from now? How does it change?

‍

Dave W: I don’t think it necessarily drives away application development. I think it might actually increase application development. I think it’ll do it in a way of being able to provide assistance, to some degree, and that assistance will be in two or three different flavors. I think it will probably enhance what you can do from a citizen development perspective. It’s a lot easier to walk someone through a list saying, “Hey, I can create these types of apps. What do you want?” than walking them through the process.

‍

Also, look at what the pro code developer can do. There’s a lot of boring, repetitive stuff that people don’t want to do. When we were at Knowledge this year, I watched Joe Davis on stage using a generative AI tool to generate code, and the audience went nuts for it. It wasn’t replacing him at that point. It was just getting him to the point where he didn’t want to deal with the easy part of the change. He wanted to be able to focus on the things that are more important. I think it will allow so-be-it matter experts to interface a lot better with developers, to be able to get things that are more business-orientated.

‍

I don’t see apps as being dead. I think apps will evolve. They might be slightly different than they were before; they may even end up being more modular than they were before, and AI strings those modules together.

‍

Dave Y: Yeah. I think ultimately, if you own the inputs and outputs and you take the action, you have a lot of good building blocks to actually have AI be a complement, not a substitute.

‍

Dave W: I completely agree.

‍

Dave Y: On the data taxonomy level, I have heard a lot of articulations to have that fairly structured, because then you can do things like benchmarking. You can have attributes that are productized, so on and so forth. How do you think about that layer?

‍

Dave W: When you look at the ERD diagram that ties everything together in the database structure, there are a lot of files that are common or ubiquitous across everything. All the information around users, locations, assets, facilities—they’re all things that are used by multiple applications. That is one of the benefits of a platform-based solution. You do have that single source of truth. It’s not like every application is going to build its own locations file. You’re going to know what locations you’ve got, and you keep them in one place. It cuts down your integrations. You only need one AD integration to be able to pull everything in, so you end up streamlining and reducing the amount of data that you’ve got.

‍

It allows you to do comparisons against not just similar-size companies, but even start to do industry comparisons. People do still add data fields to the structure, and they even add full tables if they’re potentially building custom applications—but the platform provides most of the features that you’re going to use from a data structure perspective. The bigger the customer gets, the more things get added to it, and we don’t limit what people can add to it. A lot of the time, you’ll see people copy an existing application and its table structure and rename it and use it somewhere else, as opposed to going in and hacking up an existing one. That keeps things clean for them for upgrades and stuff.

‍

It was funny, we were looking at how much data we ended up with on the system in maybe 2015. I remember doing a presentation and wondering how big the database was. We did an analysis, and it was about 26, 27 petabytes. I said to Pay Casey before the last event—because we hadn’t looked at it for like six years—what’s it up to now, from a data perspective? How much customer data is out there? He did the scan, and it came back [that] now it’s gone to 1.2 exabytes of data. So, so much data out there. 

‍

The interesting thing about data—and this is going to be one of the challenges of artificial intelligence, I think—is all that data is out there and could be used to create some amazing models. But where do you draw the line? Is Coca-Cola ever going to allow you to use its data to produce an AI model that makes Pepsi better than it was before? I was having a conversation with an analyst this morning around where we see distributed ledger technology coming in. Is this where people start to actually tag data with blockchain to prove where that came from to do the training? There’s a whole route you could go down with that.

‍

Dave Y: There are a lot of arguments that it’s really hard to put walls in front of proprietary data. You need a ledger. You need that step of tracking.

‍

I read in the 2022 Analyst Day, I believe 50% of your R&D goes into platform, which is incredible—[and] means you guys get an incredible amount of leverage. Avanish, I don’t know if you have any other questions, but I did have one final question to end on that I’d love to get your perspective on.

‍

Avanish: The only question I’d add is, Dave, you referred to the infrastructure data layer, the workflow, UX, and the flexibility that comes with that. On the flip side, you also referred to internal users, the application developers for ServiceNow—IT folks and inside customers, who are extending, complementing, expanding. And you’ve got partners, SIs and ISVs, building on top. How does your organization think about that? I think that can be another conflict point. How do you prioritize resourcing, and how do you prioritize functionality that may be more relevant to one group than the other?

‍

Dave W: When you look at how people develop apps, I don’t think there’s much differentiation between them. We give everyone the same capability. If you can build on the platform, it makes no difference if you’re a partner, an admin, or a developer. From a code perspective, if you wanted to, you could build yourself everything that we build and we sell. Obviously, if we do something like a new UI release or specific widgets that weren’t in a previous release, that’s something that you can’t necessarily do. But if you wanted to go in and build a better incident management module, there’s nothing in the system that stops you doing that. We develop on exactly the same code that our customers develop on.

‍

The challenge then becomes how you get awareness for what everyone’s doing. If you’ve got partners building something that might be competing with something you’re going to create, how do you deal with that? Or if you’re doing an acquisition in an area that means you’re going to start to build something that then competes, how do you deal with that? We do have a lot of arguments around exclusivity. We try and not give people exclusivity, but it is a challenge. You want to publish enough roadmap that people don’t trip themselves up, but you don’t want to publish so much roadmap that everyone sees what you’re doing for the next four years.

‍

Avanish: Yeah. That was a bit of a loaded question, since it was near and dear to my heart. Thinking that through, and about what you disclose, what you don’t disclose, how do you treat everybody as a first-class citizen—that’s pretty critical, right?

‍

Dave W: Yeah. You can’t discriminate, really.

‍

Avanish: Exactly.

‍

Dave Y: Hey, Dave, the goal of this interview in some ways is to inspire. Obviously, ServiceNow is not done, so it’s not a point of arrival, but it’s sure a heck of an example of what you can do. If you were sitting near a CEO, CTO, or chief product officer of an application company that wants to go on this journey, what’s [your] encouragement? [Laughs] I think earlier we described how you can do this, even if a company hasn’t started as an infrastructure company. What are the missives that you’d give them?

‍

Dave W: I think you have to create an innovation mindset within the company as to what it is you’re going to build. Then you can [potentially] build things that no one wants. I mean, the world’s full of people that build things that no one wants. You have to be able to have that innovation mindset, and that consumption mindset as well. You need to identify something that people want and need, that technology supports, and that there is a total addressable market for. 

‍

The thing I’d say to encourage anyone around this is… I’m going to use examples, because these are things that always come up. Whenever I meet a company, they say, “We want to be the Uber of this, or the Amazon of this.” All those companies that people talk about: Amazon, Airbnb, Peloton, Venmo, even Tesla to a degree; the interesting thing about all of them is they didn’t create anything new. You’ve always been able to go on holiday or pay a babysitter or order something through the mail for the last like 120 years. What they did was create an experience that was so good that you would rather use them than any other way of doing things.

‍

I would say, if you want to transform something, create something, and do something from a platform perspective, you haven’t got to create something new. You’ve just got to create something that’s so good that it far surpasses whatever someone had in the past. If you can focus on what that experience feels like to the people who are going to use the system, and you can give them a better experience than they had before, I think that’s the biggest driver of technology adoption that you can get anywhere.

‍

Dave Y: Awesome. Love it. Better together. You landed the point. [Laughter]

‍

This has been awesome, Dave. Really appreciate the time and just sharing the wisdom. It’s an amazing gift that you’re giving to folks that are much earlier on the journey.

‍

Dave W: It’s no problem. I appreciate the opportunity to talk.

‍

‍

Subscribe here to stay up to date with our latest content and events!

‍

BACK TO PCG HOME