A broader view of how ServiceNow’s changing priorities are seen in the platform, and what can be done about it.
Introduction
Today’s article is a little different than most I write. My thoughts today are around business strategy and how they relate to how ServiceNow conducts business, rather than specific design consideration, or technical implementations. I wrote previously about some of the little things ServiceNow should do to improve the platform for customers and admins alike, and I also covered how ServiceNow started as a platform and then reacted to market forces to get into the IT Service Management space. Today I’m writing about larger, more strategic things I think they should at least be considering, from the obvious to the more esoteric. I’ll cover three areas I’ve thought about a lot in my 16 years working with the platform.
A Strong Foundation
One of my managers at ServiceNow liked to make sports analogies. One of them concerned doing something particularly complex or different: “You can’t execute a trick play if you don’t have your blocking right”. (This is an American football analogy.) Essentially he was saying you can try all the fancy tricks you want, but if you don’t have your fundamentals down, it’s going to be for naught. In the business world, this means getting the basics correct first: Be on time to meetings. Set and keep agendas. Deliver what you say you’re going to deliver. Be honest and consistent. In the ServiceNow platform, this means out-of-the-box is rock solid. It truly can be used “as-is” without concern or obvious need to change things.
Each time I’m working on a new implementation, and almost always on a newer release, I’m always surprised to find how many things are not rock solid. And some things are just flat-out wrong.
In my latest implementation, here’s a few things I found, just for illustrative purposes:
- The Number is still editable by admins. Which means on form load if that field takes focus, you could accidentally type something and save and your number would be gibberish. (Not to mention why would you ever change a Task Number manually?)
- The left nav is a mess and the ordering makes no sense. For example login or impersonate an itil user, and the Incident menu is below Content Taxonomy and Document Management. Why?
- A closed or canceled (inactive) Catalog Task is editable by itil-roled users, meaning a Task State can be set back to In Progress even though the related RITM and Request are closed and the requester has been notified of completion.
- Most if not all users can delete their Approvals, and non-admins can delete any Approval. Why? This has the high probability of breaking approval workflows.
- The Problem Priority lookup points to an empty matrix, so no Priority changes are done based on Impact and Urgency unless you populate it or re-point it.
These are very minor things, but they add up. And when I’m demo’ing “out of the box”, I have to explain them, diverting attention from the important things.
I suppose one could argue ServiceNow is leaving it this way so that implementers have something to do, or so that there are discussion points to have with customers, but I sincerely doubt this. I can’t see anyone in leadership making a decision to “keep things just a little off” so there’s implementation work to be had.
When I worked for ServiceNow Professional Services, our department created a baseline “Best Practice” instance that fixed these issues, and we it used as a clone source for new customer instances. Why isn’t this the actual Out of Box instance that ServiceNow provides?
Recommendation: ServiceNow should build a small Quality Control team to review existing products and new products before they are released. This team should include or at least be advised by actual implementers to review findings from the field. They should have carte blanche to clean up and fix the out-of-the-box for that more perfect baseline platform.
Application Flexibility
As ServiceNow has evolved, so have their products. One could argue for better or for worse. In the early days when the platform only really had ITSM applications running on it, the motto was generally “Keep It Simple (Stupid)”. The forms and workflows were meant to be as simple as possible to give customers, administrators and implementers flexibility to configure for their specific needs without “customization” fear. (Remember, this was the founders’ vision.) It’s one of the things early adopters loved about ServiceNow – the power of the platform combined with application flexibility. Because of this, implementations were much more “Sure we can do that!” instead of creative ways of saying “No”.
Updated and new product releases have seen their complexity grow. When I have customers asking if something can work a particular way, my mindset is from the early days when the answer was usually “sure”, with a discussion of cost/benefit. But the reality is when I dig in deeper, the follow-up answer often becomes “well, even if it’s possible, here’s why we shouldn’t do it”. ServiceNow’s pitch is that businesses should adopt their “best practices”. But if you’ve done OCM, you know this is easier said than done. And I’ve often argued that ServiceNow doesn’t hold patents on “best practices” for these application processes.
This article is not about getting into how this evolution took place, or technical specifics about it. Rather, what I want to suggest is that ServiceNow become much more modular about their products. What I mean by this is rather than getting a fully-baked, inflexible, end-to-end solution with each new application (product) install, what I’d like to see is a “baseline” product that is simple and configurable, and a series of add-ons for specific business needs. Things that can be installed and tried in non-production environments to see if they fit the business’s needs. This would allow businesses to adopt portions of ServiceNow’s “best practice” implementations as they fit, and configure the platform to their business needs as they see fit. (And the conversations around “staying out of the box” would be a lot less hand-wringy.)
Inventing the Future
My last section concerns an area I’ve been discussing for over 12 years. It concerns the influential 1997 business book “The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail” by Clayton Christensen. (If you haven’t read it or even heard of it, I highly recommend it. You can find the PDF online for free. At the least, read the first chapter – tells you everything you need to know about the theory.) The gist of the book is how companies seemingly at the top of their game are actually in the process of failing, while they are making the correct managerial decisions. It presents empirical evidence of the innovation value S-curve, and the reality that while one company is at the top of their value S-curve, another is starting theirs and will come to push the first company to the end of theirs.
I don’t mean to get into an academic discussion of managerial philosophy, nor a historical review of company rises and falls. Rather, I mean to suggest this: That right when ServiceNow was beginning to hit the peak of their powers, gaining a majority of market share and pushing older competitors to the end of their value S-Curve, is when they should have created an incubator of their best engineers to create the next version of ServiceNow. And of course I mean from the ground up, not the next Geographical name release. A version that incorporates:
- The latest underlying technologies (anyone for getting rid of Jelly???)
- All the lessons learned from building the previous versions
- All the fixes and updates
- A clean data model based on the previous two bullets
- A mechanism to easily migrate from the old version to the new
In other words, ServiceNow should be developing their own second innovation value S-curve, lest a competitor do it first or better. In my early days with ServiceNow professional services, I got to see some implementations of, and work with consultants in, Remedy. It was quite easy to see what a Frankenstein’s monster that product had become, as hundreds of rounds of updates, new and acquired products were layered in over years and years. It was impossible to recognize a clean baseline. Product expertise focused not on utilizing the platform in innovative ways, but rather knowing the tricky ins-and-outs around the chaos. These days I feel my ServiceNow expertise is skewing in the same direction.
Conclusion
ServiceNow has somewhere between 20 and 30 thousand employees, many of them intelligent and knowledgeable. It has a market cap (as of this writing) pushing $140B. Surely it could use some of these resources to build a better baseline, make the customer implementation experience smoother, faster and cheaper, and build things in a way that is truly innovative rather than the status quo.
