Kenneth Gonzalez on What the Magic Quadrant Gets Wrong About Buying ITSM

Share this blog via -
Kengon humans of support

Summarize this post with:

Humans of Support is our interview series featuring the people building and running customer support teams. We speak to people who’ve lived through endless escalations and multiple waves of technology change. 

In an AI-first era, human expertise and the perspective of veterans who have been there, done that help elevate, validate, and enrich support strategy. 

If you’re an agent, a leader, or anyone learning and growing in support right now, each episode of this series brings human wisdom that complements the AI-support playbook. 

For this episode, we’re talking to Kenneth Gonzalez, a speaker, advisor, and former Gartner analyst who has spent his career moving between three different chairs in the ITSM world: as an analyst covering the market for Gartner, as Head of Analyst Relations at Freshworks on the vendor side, and now as an independent advisor working directly with organizations on their support strategy. 

That rotation through analyst, vendor, and advisor seats shapes almost everything he has to say: that research is fundamentally a consensus process rather than gospel, that the Magic Quadrant is one input and not a shopping list, and that AI only pays off once you stop treating it as a tool and start treating it as a partner. 

Here’s the full interview with Kenneth Gonzalez below. 

You've seen ITSM from the analyst side at Gartner, the vendor side at Freshworks, and now as an independent advisor. How have those three perspectives changed how you think about what customers actually need from their service management tools?

Kengon humans of support

Anything I'm working with needs to help drive customer-centric insights. You can't start from the technology.

Kengon, a speaker, advisor, and former Gartner analyst

The thing I always come back to is that whatever I’m working on needs to help drive customer-centric insights, not start from the technology. A lot of the questions customers asked me at Gartner were about which tech to use, and I don’t have a problem with that question, or with customers using technology. But you can’t start there. 

If you don’t start from where the customer sits, technology choices can be neutral at best and detrimental at worst to how you actually manage and fulfill the relationship with the customer. 

Linked to that is psychological safety: empowering teams and setting an environment where people can challenge the status quo with respect and say what isn’t working. 

You've had a front-row seat to how ITSM vendors get evaluated and positioned by analysts. What do these frameworks and market reports get right about a product, and where do they miss what actually matters to the customer?

The consensus process helps make sure the guidance actually fits the body of work. What it can miss is why a customer should care.

Research is fundamentally a consensus process, both internal and external. It’s rare these days to find a really good report delivered by one person; you need other perspectives to round out the view. Firms also carry a body of work and an established set of viewpoints, so there’s a level of consistency customers come to expect. 

What analyst firms get right is tapping into customer sentiment and surfacing needs a single customer might not even realize they have. Once you’ve had thousands of customer conversations, you develop a way of listening that’s genuinely different from what any one person can come up with alone. That was the real eye-opener for me at Gartner, with over 4,000 customer interactions: it tuned my listening to how the whole market was moving, not just one customer’s problem. 

Where it can go wrong is being too focused on staying consistent with the existing body of research, to the point where you won’t say anything outside of your own established recommendations. That limits value realization. We’re all on a collective journey, and the analyst’s job is to help clarify where that journey is heading so customers aren’t taking too narrow a cut at their own decisions. 

If you hosted your own podcast on ITSM, what's the one topic or question that keeps coming up in your conversations that you think the industry should be paying more attention to?

If you're not comfortable asking why, you've stopped at technique and never gotten to strategy.

There are two areas that most ITSM conversation almost blindly overlooks. The first is critical thinking. Going to a class and learning about processes, artifacts, and data strategies is good, but it isn’t the be-all and end-all. Those are tools and techniques that should enable you to think critically about how to better serve your customers, and then decide which of those tools are actually relevant. That’s not just a technical consideration, it’s organizational, it’s a mission consideration, it’s strategic. 

The second is looking outside your own area for competencies and inspiration you wouldn’t normally think are relevant, and borrowing from them. If you go back to when the founding documents for ITIL were first put together, that was best practices collected and distilled from a number of different vendors. That process never should have stopped. We’re still doing a version of it today, but in a more limited way, and there’s a real shame in how much we could be drawing from that isn’t making it into the conversation. 

A lot of buyers look at the Magic Quadrant when shortlisting vendors. From your experience, how much should a buyer actually rely on it when choosing a platform?

Quite frankly, "this company's in the top right, so we should buy top right" is the stupidest thing I've ever heard.

First off, they shouldn’t rely on it. It should be one input among several, not “this company is in the top right, so we buy top right.” When I was talking with customers at Gartner, I’d caution them against that exact move, because a company in the top right might have a wonderful product that’s also way too big, too costly, and too complex for that particular organization, when something smaller and more cost-effective would actually be the right fit. 

The Magic Quadrant is meant to position who the players are from an organisational perspective and what their long-term viability looks like. Hold it as: who’s going to be in the race for the long term, and is that a bet you’re willing to place. If you want something more specific to features and functions, that’s what the Critical Capabilities guide is for: does this product actually do what you need it to do in order to fulfill your objectives. Other analyst firms do good work here too, but we need to get beyond “top right” thinking, because it isn’t serving anybody.

If you were to build your own ITSM tool tomorrow, what would you be sure to include, and what would you be okay to skip?

At the risk of being a bit provocative, I wouldn't build an ITSM tool at all. I think the context is too narrow.

The first thing I’d build is something that captures the full enterprise context: not process and function, but what your organization is actually out to do, its mission, and then the fit of the tool within that context. 

Second is a genuine focus on customer need, both internal and external. I don’t care whether you call it a stakeholder or a customer, because at the end of the day IT serves people, and the real question is why someone needs your support so they can do their own thing and serve whoever their organization serves. That holds whether you’re public, private, or not-for-profit. 

Third is better situational awareness of how well you’re actually serving the people you’re out to serve, and the health of the components behind that, so you’re doing preventive maintenance rather than pure break-fix. 

Fourth is enabling better cross-functional collaboration. DevOps gets talked about constantly, and I dislike how the focus usually skews toward dev and away from ops, when they’re joined at the hip. You can’t develop something and not consider the people who’ll run it in production, and it isn’t just dev and ops, security’s in that mix too. 

The final thing is visibility into what actually matters to the organization and how well you’re doing at it, in a way that exposes and eliminates politics and turf wars. In the environment we’re in today, we can’t afford that anymore. My success has to enable your success, or you’re painting a target on your own back. 

Across 2006, 2016, and 2026, three decades, how has support changed at its core?

It's not the intention that's changed. It's getting people back to the point where they can fulfill their mission-essential tasks.

I don’t think it’s changed at its core. In 2006 we were resolving incidents, fulfilling requests, managing changes, looking for patterns, same as now. What’s changed is the technology layered on top to enable those outcomes, and for good reason. 

What’s really shifted is understanding that we’re not just fixing technology, we’re supporting people and enabling outcomes. Ironically, the more technology we put into support, the more important the human moments become. It’s not just about speed, it’s about taking people with you on a journey, however short that journey is. We have to remember why people contact the service desk in the first place: something has happened, or needs to happen, that’s stopping them from carrying out their business process. 

AI: boon or bane?

If an AI business case starts and finishes with headcount reduction, we've missed a huge opportunity.

Absolutely a boon, but only if we remember what we’re actually trying to do with it. It becomes a bane if we rush into adoption without a clear understanding of the problem we’re solving, and especially if the business case starts and finishes with how many people we can remove. 

We need to stop thinking about AI as a tool and start thinking about it as a partner. I’ve got a lot of knowledge and expertise as a long-term industry veteran, but if I think about large-scale data analysis, who’s better at it, AI or me? AI. Configuring products, performing maintenance? AI. That doesn’t invalidate what I already know. I’m bringing judgment, taste, relationships, and my collective knowledge. I’m more capable than before, not because I’m bionic, but because I’ve changed my relationship to AI from something to fear, or a tool to fully hand off, to an actual partner. 

Once that relationship shifts, the real questions become: what work is worth doing, what should our people be doing, and what should our agents or AI technologies do. Asking those questions rigorously keeps the focus on the value to the organization and how we’re fulfilling the mission, rather than “products cost what they cost, we’ll keep doing what we’re doing because it’s worked so far.” Anybody having that second conversation is setting themselves up to be made redundant.

Do you think AI will ever get advanced enough to fully replace human support agents?

People interact with people. Having competent, capable, empathetic people working the desk is never going to go out of style.

No, and the reason is that people interact with people. I’ll also say some people shouldn’t be interacting with people, that’s why the two-pizza rule exists, and there’s a bit of a historical view there. But as we move forward, the key skill employees need is relating to and addressing the needs of other humans. That’s not an AI thing. Even with IVRs and prompting technology getting better, it still introduces friction, and we want to minimize friction. 

One thing that needs addressing is how the stress of things breaking manifests in our current world, because people seem to have a lot less room to deal with it. Expectations are elevated and harder to manage. If you have people who are genuinely good at managing relationships and cultivating empathy, that “I really care” orientation rather than “what’s your employee ID,” it diffuses situations instead of letting people be abused by the customers they’re trying to support, which is what fuels burnout. This is a real opportunity to shift not just what it’s like to be an IT worker, but what it’s like for customers to interact with IT generally.

What's one ITSM trend today that's genuinely underrated?

Product management is the thing. It's not a small task to hold the whole network of factors that go into making something available to a customer.

Product management. Being able to effectively think like a product manager, and hold the whole network of factors that need to be considered to make something available to a customer, is not a small task. There’s a marketing component: understanding what customers need and how to price it. There’s product development: what needs to get built or acquired. There’s supply and logistics, operations, and a product management layer that rationalizes all of those legitimate inputs into what gets built now and a forward-looking roadmap for what gets built next. 

On top of that sit cost, performance, and budget considerations: how much of your budget can you realistically consume, and is it a good spend. All of those conversations fall under product management, because somebody ultimately has to be accountable to senior leadership for showing that the money and time invested translated into benefits the organization can see. That perspective is something I’m genuinely passionate about helping people wrap their arms around, and I think it’s almost totally missing from how most support organizations operate today. 

 

Humans of Support is real conversations with thought leaders in ITSM and support. If you're building or running an IT support team and have a story worth telling, we'd love to hear from you.

Table of Contents

Trusted by 7,000+ customers

Need assistance with Desk365? Get started with our articles in the Help Center!

Accordion Content

                   
Descriptive Image Text

Quick Overview of Desk365's Agent Bot and Support Bot for Microsoft Teams

Watch video

Getting Started with Desk365: Your Modern Helpdesk Ticketing System

Watch Video

Descriptive Text Here