If you’re a service provider interested in participating in the Cloud IaaS Magic Quadrant process (see the call for vendors), I’d like to recommend a number of my previous blog posts.
Foundational Gartner research notes on cloud IaaS. Recommended reading to understand our thinking on the market.
Having cloud-enabled technology != Having a cloud. Critical for understanding what we do and don’t consider cloud IaaS to be.
AR contacts for a Magic Quadrant should read everything. An explanation of why it’s critical to read every word of every communication received during the MQ process.
The process of a Magic Quadrant. Understanding a little bit about how MQs get put together.
Vendors, Magic Quadrants, and client status. Appropriate use of communications channels during the MQ process.
The art of the customer reference. Tips on how to choose reference customers.
It’s that time of the year again, a little bit early — we’re trying to refresh the Cloud IaaS Magic Quadrant on a nine-month cycle rather than a yearly cycle, reflecting the faster pace of the market.
A pre-qualification survey, intended to gather quantitative metrics and information about each provider’s service, will be going out very soon.
If you are a cloud IaaS provider, and you did not receive the 2012 survey, and you would like to receive the 2013 survey, please email Michele dot Severance at Gartner dot com to request to be added to the contact list. You must be authorized to speak for your company. Please note we cannot work with PR firms for the Magic Quadrant; if you are a PR agency and you think that your client should be participating, you should get in touch with your client and have your client contact Michele.
If you did receive the 2012 survey, you should be receiving email from Michele within the next few days, requesting that you confirm that you’re the right contact or passing it on to the correct contact to do so.
If you’re unsure whether you’re a cloud IaaS provider by this MQ’s definitions, consider the following:
- Are you selling a service? (That means you’re not selling hardware or software.)
- Are you offering compute, storage, and network resources? (You can’t be, say, just a cloud storage provider.)
- Is your offering fully standardized? (It’s identical for every customer, not a reference architecture that you customize.)
- Can customers self-service? (Once approved as customers, they can go to your portal and push buttons to immediately, with zero human intervention, obtain/destroy/configure/manage their infrastructure resources. Managed services can be optional.)
- Can you meter by the hour? (You can either sell by the hour, or you can offer monthly capacity where usage is metered hourly. Having to take a VM for a full month is hosting, not IaaS.)
- Do you have at least one multi-tenant cloud IaaS offering? (Customers must share a capacity pool for the offering to be considered multi-tenant.)
- Do you consider your competition to be offerings such as Amazon EC2, Verizon Terremark’s Enterprise Cloud, or CSC’s CloudCompute? (If not, you’re probaly confused about what cloud IaaS is.)
Please note that receiving a survey does not in any way indicate that we believe that your company is likely to qualify; we simply allow surveys to go to all interested parties (assuming that theyâre not obviously wrong fits, like software companies without an IaaS offering).
The status for this Magic Quadrant will be periodically updated on its status page.
Gartner will soon be starting the process of updating our Magic Quadrant for Managed Hosting, currently targeted for publication in Q1 of 2013. This is the update to the Magic Quadrant for Managed Hosting that was published in March 2012 of this year; a free reprint is available. If you consider yourself to be an enterprise-class managed hosting provider, capable of providing fully-managed services for complex, mission-critical websites, this is your Magic Quadrant. (Note that this is a distinct market from data center outsourcing.)
The previous Magic Quadrant was global. However, because regional requirements differ, and many excellent managed hosting providers are not global, we have decided to replace the global Magic Quadrant with three regional Magic Quadrants — one each for North America, Pan-Europe, and Asia-Pacific, published in that order. Each MQ will have its own inclusion criteria and evaluation criteria.
I will be leading the overall global effort, and Gartner’s analysts that cover Managed Hosting will be doing these MQs as a global team, although each regional MQ will have a region-specific lead author. We are going to do a single global data collection effort and set of briefings, though, to reduce the level of effort needed by the service provider AR teams.
Doug Toombs will be the lead author for the North American MQ and will be assisting me in running the global effort. If you are not already following his blog or his Twitter (@DougToombs), I strongly encourage you to do so.
We will imminently be kicking off the process for this set of MQs. If you were not on last year’s Magic Quadrant for Managed Hosting, and you would like to receive a pre-qualification survey, please contact Doug Toombs at Douglas dot Toombs at Gartner dot com. Please note that we allow any service provider to participate in the survey process; reception of a survey does not indicate in any way that we feel that your company is qualified to be in the MQ.
Many people confuse “using a hardware and software stack that potentially enables a cloud” with “cloud infrastructure as a service”. Analyst firms haven’t necessarily done a good job with drawing the distinction, either — there are plenty of (hopefully non-Gartner) analysts who use “IaaS” interchangeably to describe the technology stack and the service itself.
The technology stack — typically an integrated system (such as a Vblock) plus a cloud management platform (such as vCloud Director), although it could be anything, like whitebox servers + Nexenta storage + Arista switches + OpenStack — is what Gartner is now dubbing “cloud-enabled system infrastructure” (CESI). This is admittedly naming-by-committee, but it parallels our use of “cloud-enabled application platform” which is the technology-stack corollary for PaaS.
Why is it important to make a distinction between CESI and IaaS? Because while CESI can be used to deliver IaaS, there are many services that can be delivered on top of a CESI that are not IaaS. Gartner’s cloud definitions are pretty strict, and one of the cores of our IaaS definition is that IaaS is self-service — you can optionally layer managed services on top, but the customer has to have full control to obtain and remove resources in a fully self-service, fully-automated way. Not only are many of the services that can be delivered on CESI not IaaS, they’re not actually cloud services — cloud requires not only self-service, but also scalability, elasticity, and metering by use, for instance.
Why does this distinction matter? Because there are a significant number of service providers in the market today who offer a service on top of a CESI and call it “cloud IaaS”, when it’s neither cloud nor IaaS, and it misleads customers into thinking that they are getting the technical and/or business benefits of going to the cloud and going to IaaS.
I’ve written two research notes that I’m hoping will cut through some of the market confusion. (Links are Gartner clients only, sorry.)
The first, Technology Overview for Cloud-Enabled System Infrastructure, is an overview of how we define CESI and how it is not merely a virtualization environment — it encompasses compute, storage, and network capabilities; it is automated, scalable, elastic, near-real-time on-demand; and it exposes self-service interfaces. It discusses the range of cloud-enabled infrastructure services from those that are merely cloud-facilitated (using the CESI as an efficient infrastructure platform, without exposing it to the customer via self-service), to those that are fully cloud-native (CESI fully exposed to customer via self-service that is routinely used), and gives examples of the services along this spectrum; for instance, IBM’s SCE+ is cloud-enabled data center outsourcing, not IaaS, in our parlance. Finally, it disusses the distinction between global-class CESI architectures (think Amazon Web Services) and enterprise-class architectures (think Vblock + vCD), and how to build a CESI.
The second, Don’t Be Fooled By Offerings Falsely Masquerading as Cloud Infrastructure as a Service, is a note that is intended to help IT buyers figure out what they’re really buying when they are assessing something that the vendor is claiming is IaaS. It focuses on a handful of principles: Beware of common “cloudwashing” claims; ensure that what you’re buying delivers promised technical and business benefits; identify your requirements and look at competing providers before purchasing a solution that requires a contractual commitment; favor providers who have better cloud infrastructure roadmaps.
The four most common “cloudwashing” claims for infrastructure services:
- “It uses virtualization, so it’s a cloud.”
- “It’s being delivered on a Vblock, so it’s a cloud.”
- “We use vCloud Director, so it’s a cloud.”
- “You can buy it through a portal, so it’s a cloud.”
I apologize for introducing more jargon into an already jargon-heavy corner of the market, but I think these distinctions are critical: You can have a technology stack that potentially enables you to deliver cloud IaaS… and use it to deliver something that is neither cloud nor IaaS. Cloud infrastructure as a technology platform is separate and distinct from cloud infrastructure as a service; the technical construct and the service construct are two different things.
I’ve been reading the social media reactions to my recent note on OpenStack, “Don’t Let OpenStack Hype Distort Your Selection of a Cloud Management Platform in 2012” (that’s a client link; a free public reprint without the executive summary is also available), and wanted to respond to some comments that are more centered on the research process and publication process than on the report itself. So, here are a number of general assertions:
Gartner doesn’t do commissioned research. Ever. Repeat: Gartner, unlike almost every other analyst firm, doesn’t do commissioned resesarch — ever. Most analyst firms will do “joint research” or “commissioned whitepapers” or the like — research where a vendor is paying for the note to be written. About a decade ago, Gartner stopped this practice, because management felt it could be seen as compromising neutrality. No vendor paid for that OpenStack note to be written, directly or indirectly. Considering that most of the world’s largest IT vendors are significant participants in OpenStack, and plenty of small ones are as well, and a bunch of them are undoubtedly unhappy about the publication of that note, if Gartner’s interests were oriented around vendors, we certainly wouldn’t have published research practically guaranteed to upset a lot of vendors.
Gartner earns the overwhelming majority of its revenue from IT buyers. About 80% of Gartner’s revenues come from our IT buyer clients (we call them “end-users”). We don’t shill for vendors, ever, because our bread-and-butter comes from IT buyers, who trust us for neutral advice. Analysts are interested in helping our end-user clients make the technology decisions that are best for their business. We also want to help vendors (including those who are involved with free or commercial open-source) succeed in better serving end-users — which often means that we will be critical of vendor efforts. Our clients are asking about OpenStack, and every example of hype in that note comes directly from client interactions. I wrote that note because the volume of OpenStack queries from clients was ramping up, and we needed written research to address it.
Gartner analysts are not compensated on commissions of any sort. Many other analyst firms have incentives for analysts that are tied to revenue or publicity — be quoted in the press X times, sell reports, sell consulting, sell strategy days with vendors, etc. Gartner doesn’t do any of that, and hasn’t for about a decade. Our job, as Gartner analysts, is to try to offer the best advice we can to our clients. Sometimes, of course, we will be wrong, but we try hard. It’s not an academic exercise; our end-user clients have business outcomes that ride on their technology decisions.
Gartner doesn’t dislike open source. As a collective entity, Gartner tends to be cautious in its stances, as our end-user clients tend to be mid-market and enterprise IT executives who are fairly risk-averse; our analysis of all solutions, including OSS, tends to be from that perspective. But we write extensively about open source; we have analysts devoted to the topic, plus everyone covers the OSS relevant to their own coverage. We consider OSS a business strategy like anything else. In fact, we’ve been particularly vocal about how we feel that cloud is driving OSS adoption across a broad spectrum of solutions, and advocates that an IT organization’s adoption of cloud is a great time to consider replacing proprietary tech with OSS. (You’ll note that a whole section of the report predicts OpenStack’s eventual success, by the way, so it’s not like this a prediction of doom, just an observation of present stumbling-blocks on the road to maturity.)
Gartner research notes are Gartner opinion, not an individual analyst’s opinion. Everything that Gartner publishes as a research note (excluding things like blog posts, which we consider off-the-clock, personal time and not a corporate activity) undergoes a peer review process. While notes do slip through the cracks (i.e., get published without sufficiently broad or deep review), our internal processes require analysts to get review from everyone who touches a coverage area. My OpenStack note was very broadly peer reviewed — by other analysts who cover cloud infrastructure, cloud management platforms, and open source software, as well as a bunch of related areas that OpenStack touches. (As a result of that review, the original note almost quadrupled in size, split into one note on OSS CMPs in general, and one note on OpenStack itself.) I also asked for our Ombudsman’s office, which deals with vendor complaints, to review the note to make sure that it seemed fair, balanced, and free of inflammatory language, and they (and my manager) also asked questions about potentially controversial sections, in order to ensure they were backed by facts. Among other things, these processes are intended to ensure that individual analyst bias is eliminated to as large an extent as possible. That process is part of why Gartner’s opinions often sound highly conservative, but when we take a stance, it is usually neither casual nor one analyst’s opinion.
The publication of this note was not a shock to the vendors involved. Most of the vendors were aware that this note was coming; it was a work in progress over the summer. Rackspace, as the owner of OpenStack at the time that this was placed in the publication pipeline, was entitled to a formal review and discussion prior to its publication (as we do for any research that covers a vendor’s product in a substantive way). I had spoken to many of the other vendors in advance of its publication, letting them know it was coming (although since it was pre-Foundation they did not have advance review). The evolving OpenStack opinions of myself and other Gartner analysts have long been known to the vendors.
It would have been easier not to write anything. I have been closely following OpenStack since its inception, and I have worked with many of the OpenStack vendors since the early days of the project. I have a genuine interest in seeing them, and OpenStack, succeed, and I hope that the people that I and other analysts have dealt with know that. Many individuals have confided in me, and other Gartner analysts, about the difficulties they were having with the OpenStack effort. We value these relationships, and the trust they represent, and we want to see these people and their companies succeed. I was acutely careful to not betray any individual confidences when writing that report, ensuring that any concerns surfaced by the vendors had been said by multiple people and organizations, so that there would be no tracebacks. I am aware, however, that I aired everyone’s collective dirty laundry in public. I hope that making the conversation public will help the community rally around some collective goals that will make OpenStack mainstream adoption possible. (I think Rackspace’s open letter implicitly acknowledges the issues that I raised, and I highly encourage paying attention to its principles.)
You will see other Gartner analysts be more active in OpenStack coverage. I originally picked up OpenStack coverage because I have covered Rackspace for the last decade, and in its early days it was mostly a CMP for service providers. Enterprise adoption has begun, and so its primary home for coverage is going to be our CMP analysts (folks like Alessandro Perilli, Donna Scott, and Ronni Colville), although those of us who cover cloud IaaS (especially myself, Kyle Hilgendorf, and Doug Toombs) will continue to provide coverage from a service provider perspective. Indeed, our coverage of OSS CMPs (CloudStack, Eucalyptus, OpenNebula, etc.) has been ramping up substantially of late. We’re early in the market, and you can expect to see us track the maturation of these solutions.
I’m writing this blog post for vendors who are in Magic Quadrants or who are hoping to be in Magic Quadrants, as well as the Gartner account executives (AEs) who have such vendors as clients and prospects. It’s in lieu of having to send an email blast to a lot of people; since it’s more generic than just my own Magic Quadrants, here it is for the world.
So, to sum up:
Whether or not a vendor is a Gartner client has no bearing on whether they are on a Magic Quadrant, or how they are rated. Vendors should therefore refrain from attempting to use pressure tactics on Gartner AEs, and Gartner AEs should be careful to avoid even the appearance of impropriety in dealing with vendors in a Magic Quadrant context. Vendors should conduct Magic Quadrant communications directly, using the contact information they were given.
And here’s the deeper dive:
Vendors, you’ve been given contact info for a reason. Please use it. As part of the process, every vendor being considered for an MQ is given points of contact — generally an admin coordinator as well as one or more of the analysts involved in the MQ. You’re told who you should go to if you have questions or issues — often the coordinator, lead analyst, or some specific analyst designated as your point of contact (POC). You should communicate directly with the POC. Do not go through your Gartner AE, other analysts that you deal with, or otherwise attempt to have a third party relay your concerns. Also, communicate via the contact you designated as the responsible party within your organization; we cannot, for instance, work with your PR firm. Gartner has a strict process that governs MQ-related communications; we ask that you do this so that we can ensure that all conversations are documented, and that your message is clearly and directly heard.
Yes, we mean it. Please contact us with questions and issues. If you’ve read everything available to you (the official communications, the Gartner documentation on how MQs work, any URLs you were given, and so on), and it doesn’t answer your question, please reach out to us. If you have an issue, please let us know. The analyst is the authoritative source. Anything you hear from anyone else isn’t. Gartner AEs don’t have any kind of privileged knowledge about the process, so don’t depend on them for information.
A vendor’s client relationship is of no relevance. The analysts do not care if a vendor is a client, how big of a client they are, whether they’re going to buy reprints if they get a certain placement, will become a client if they’re included on the MQ, or about any other attempt to throw their weight around. Vendors who try to do so are likely to be laughed at. Gartner AEs who try to advocate on behalf of their clients will annoy the analyst, and if it doesn’t cease, strongly risk having the analyst complain about them to the Ombudsman. In general, analysts prefer not to even know about what issues an AE might be having that may in some way be impacted by the MQ. It may even backfire, as the analyst’s desire to avoid any appearance of impropriety may lead to much closer scrutiny of any positive statements made about that vendor.
In short: Vendors shouldn’t try to go through Gartner Sales to communicate with the analysts involved in a Magic Quadrant. The right way to do this is direct, via the designated contacts. I know it’s natural to go to someone whom you may feel is better able to plead your case or tell you how they think you can best deal with the analyst, but please avoid the urge, unless you really just want a sounding board and not a relay. If you want to talk, get in touch.
This is part 2 of a two-part post. The first part contains general tips for Magic Quadrant briefings, applicable to any vendor regardless of how much contact they’ve had with the analyst. This second part divides the tips by that level of contact.
Richard Stiennon’s UP and to the RIGHT, which provides advice about the Magic Quadrants, stresses that preparation for this process is really a continuous thing — not a massive effort that’s just focused upon the evaluation period itself. I agree very strongly with that advice.
Nevertheless, even AR professionals — indeed, even AR professionals who are part of big teams at big vendors — often don’t do that long-term prep work. Consequently, there are really three types of vendors that enter into this process — vendors that the analyst is already deeply familiar with and where the vendor and analyst maintain regular contact (no client relationship necessary, can just be through briefings), vendors that the analyst has had some contact with but doesn’t speak to regularly, and vendors that the analyst doesn’t really know.
Tips for Vendors the Analyst is in Frequent Contact With
In general, if you have regular contact with the analyst — at least once, if not several times, a quarter — a briefing like this shouldn’t contain any surprises. It’s an opportunity to pull everything together in a unified way and back up your statements with data — to turn what might have been a disjointed set of updates and conversations, over the course of a year, into one unified picture.
Hit the highlights. Use the beginning of the briefing as a way to summarize your accomplishments over the course of the year, and refresh the analyst’s memory on things you consider particularly important. You may want to lay out your achievements in a quarter-by-quarter way in the slide deck, for easy reference.
Provide information that hasn’t been covered in previous briefings. Make sure you remember to mention your general corporate achievements. Customer satisfaction, changes to your channel and partnership model, financial accomplishments, and other general initiatives are examples of things you might want to touch on.
Focus on the future. Lay out where you see your business going. If you can do so on a quarter-by-quarter basis (which you may want to stipulate is under an NDA), do so.
Tips for Vendors the Analyst Knows, Without Frequent Contact
If the analyst knows you pretty well, but you haven’t been in regular contact — the analyst hasn’t gotten consistently briefed on updates, or been asked for input on future plans — not only do you want to present the big picture, but you want to make sure that they haven’t missed anything. Your briefing is going to look much like the briefing of a vendor who has been in frequent contact, but with a couple of additional points:
Tell a clear story. When you go through the highlights of your year, explain how what you’ve done and what you’re planning fits into a coherent vision of the market, where you see yourself going, and how it contributes to your unique value proposition.
Have plenty of supplemental material. Because the analyst might not have seen all the announcements, it’s particularly important that you ensure that your slide deck has an appendix that summarizes everything. Link to the press release or more detailed product description, if need be.
Tips for Vendors the Analyst Doesn’t Really Know
Sometimes, you just won’t know the analyst very well. Maybe you’re a new vendor to the space, or previously been too small to draw attention from the analyst. Maybe this space isn’t a big focus for you. Maybe you’ve briefed the analyst once a year or so, but don’t really stay in touch. Whatever the case, the analyst doesn’t know you well, and therefore you’re going to spend your briefing building a case from the ground up.
Clearly articulate who you are. Start the briefing with your elevator pitch. This is your business and differentiation in a handful of sentences that occupy less than two minutes. The analyst is trying to figure out how to summarize you in a nutshell. Your best chance of controlling that message is to (credibly) assert a summary yourself. Put your company history and salient facts on an appendix to the slides, for later perusal. Up front, just have your core pitch and any metrics that support it.
Pare your story to the bare essentials. Spend the most time talking about whatever it is that is your differentiation. (Example: If you know your product isn’t significantly differentiated but for whatever reason they love you in emerging markets, sweep through describing your product by comparing it to a common baseline in your market, and conceding that’s not where you differentiate, then focus on your emerging markets story in detail.) If your differentiation is in your product/service and not in your general business, focus on that — you can assume the analyst knows what the common baseline is, so you can gloss over that baseline in a few sentences (you can have more detail on your slides if need be) and then move on to talking about how you’re unique.
Be customer-centric. Explain the profile of your customers and their use cases, and make it clear why they typically choose you. Resist the urge to focus on brand-name logos, especially if those aren’t typical or aren’t your normal use case. Logo slides are nice, but they’re even better if the logos are divided by use case or some other organizing function that makes it clear what won you the deal.
Ensure you talk about your go-to-market strategy. Specifically, explain how you sell and market your product/service. Even if this isn’t especially exciting, spend at least a slide talking about how you’re creating market awareness of your company and product/service, and how you actually get it into the hands of prospects and win those deals.
Provide a deep appendix to your slide deck. You should feel free to put as much supplemental material as you think would be useful into an appendix or separate slide deck for the analyst’s later perusal. Everything from executive bios to a deep dive on your product can go here. If it’s in your presentation for investors, or part of your standard pitch to customers, it can probably go in the deck.
Three years ago, I wrote a blog post called “What Makes for an Effective MQ Briefing?” This is a follow-up, with my thoughts somewhat more organized.
For AR and PR people, before you do anything else, if you have not read it, get and read Richard Stiennon’s UP and to the RIGHT. I cannot recommend it enough; Richard has seen the process as both a Gartner analyst and as a vendor, and it is chock full of good tips. It will help you understand the process, how the analysts think, and how you can best present yourselves.
This is part 1 of a two-part post contains the general tips. The next post contains tips that are applicable specifically to each of the three types of vendors. Every single one of these tips comes with one or more horror stories that I can tell you about past Magic Quadrant briefings. What seems obvious often isn’t.
Pick the right presenters. You don’t need your most senior executives on the phone. You do need people who can present well, who thoroughly know the source material, and can answer whatever questions arise. Ensure that your presenters will have a good clear phone connection (use of cellphones or speakerphones should be strongly discouraged), and a quiet environment. If possible, choose presenters that speak fluent English and do not have accents that are difficult to understand — even if that requires using someone more junior and simply having the expert or executive on hand to take questions. You may even want to choose presenters that speak relatively quickly, if you feel time-crunched.
Send the presentation in advance. Ensure that you have emailed a copy of the presentation deck, in PowerPoint format, a day in advance of the briefing, to the administrative coordinator (who can take care of distributing it to the analysts). Be prepared to quickly resend it to anyone who has not received it. Do not send PDFs; analysts like to take notes on the slides. If you’re relying on a web conference, make sure that you still send the slides in advance — and get set up on it ahead of time and use a single PC to drive the whole presentation so you don’t waste time and possibly run into technical difficulties switching from screen to screen.
Be on time, and don’t waste time. Make sure that your dial-in number is distributed to everyone who needs to be on the call. Dial into the bridge early if need be. Have someone available to wrangle your executives if they’re running late. Have a backup presenter if you have an executive who’s notorious for not making meetings on time. Do not waste time making introductions. A presenter can briefly state their name and functional role (“I’m Joe Smith, and I run our support organization”) before starting their portion of the presentation. If you think your executive bios are important, include them as an appendix to your slides. Do not spend time having analysts introduce themselves; there are bios for them on Gartner’s website, and they will state their names when they ask questions.
Watch the clock. In a Magic Quadrant briefing, you typically have one hour to present your thoughts. Analysts are almost always scheduled back to back, so you will not have one minute extra to present, and may in fact have several minutes less if for some reason the analysts are held up from a previous meeting. Also, you want to have some time left for questions, so you should target a 45-minute presentation. If you think you have too many slides, you probably do. Rehearse to make sure you can get through your material in 45 minutes, if need be. Do not expect to be given the opportunity to do another briefing if you fail to finish in your allotted hour.
When an analyst prods you along, move on. One or more of the analysts may cut you short and ask you to move to the next slide or even skip a few slides. Listen to this and move on. By the time someone has gotten to the point of cutting you off, the analysts, who are almost certainly in an IM conversation with each other, have all already agreed that what you are saying is collectively useless to them, and that this part of the presentation is dull beyond enduring. If you think that there’s a really important point somewhere in what you’re saying, make it and move on. Or incorporate it into some other part of your presentation. Do not keep plodding along.
Focus on this particular Magic Quadrant’s market. If you have a broad solutions portfolio, that’s great, but remember that the analysts, and this Magic Quadrant, will be focused on something specific. The broader solutions portfolio can be worth mentioning, especially if it allows you to deliver higher-value and directly-relevant highly-integrated solutions, but not at the expense of focus on this Magic Quadrant’s topic. That topic should always be front-and-center. If you’re finding yourself wanting to instead talk about this somewhat-related market that you think you’re much stronger in, don’t — re-focus on the core topic.
Don’t talk about the market in general. Any analyst involved in a Magic Quadrant is, at least in theory, an expert on the market. They don’t want or need to hear about it. The only exception might be if you serve some specialized niche that the analyst does not often come into contact with. Your perspective on the market should be made clear by the specific actions that your company has taken, and will take in the future; you can explain your rationale for those decisions when you go through them, without doing a big up-front thing about the market.
Focus on your differentiation. The analysts want to know what you think makes you different, not just from the market leaders, but from your closest competitors. They want to know who you’re locked in bloody-knuckled combat each day, and why you win or lose those deals. But focus on explaining what you do well and where you intend to be superior in the future — don’t waste time badmouthing your competitors.
Be concrete and incorporate metrics whenever possible. Analysts hear broad directional statements all the time, and are usually unimpressed by them; they’re interested in the specifics of what you’ve done and what you’re going to do. Analysts love numbers. Their lives are full of vendors making grandiose claims, so they like to see evidence whenever possible. (For instance, are you claiming that your customers are much happier this year than last year? Show last year and this year’s NPS scores, ticket closure times, whatever — concrete evidence.) You don’t need to read the metrics. Just make the general point (“customer satisfaction has increased greatly in the last year, as our NPS scores show”), and have the metrics on the slides so the analysts can dive into them later. You can request that the metrics be kept under NDA if need be.
Disclose your future roadmap. A one-year or two-year roadmap, especially one that’s quarter-by-quarter, is going to make a much bigger impression than a general statement about aspirations. If you have to state that part of the briefing is under NDA, that’s fine; the analysts will still factor that information into the rating, implicitly. You may have great things planned, but if the analysts don’t know about them, you’ll get zero credit for those things when they consider your vision.
Something for analyst relations folks and the PR firms that help them, to take note of when participating in a Magic Quadrant:
Read every communication that you’re sent, in its entirety.
One might think this would be a simple thing, but multiple years of experience have shown that this is not the case. Granted, sometimes these communications are long, but they are long because they contain lots of information. The information is not gratuitous; it is information that you need to know.
Many vendor AR folks have told me that these communications essentially fall into the TL;DR category — they’re only glanced through. I recognize that it is only human to skim long emails, and even more human to skim through lengthy Word documents. I am resigned to the fact that you may completely ignore even the things that are in boldface type, especially if they’re in the middle of the message or at the bottom. I also recognize that it is only human to ask questions, rather than spending the time to read what you are sent.
But I must also point out that for many vendors, the Magic Quadrant is viewed as a high-stakes exercise that will consume a tremendous number of hours of your time and the time of your executives. You do yourself a disservice if you do not read every single word of every single communication that’s sent to you with regard to the Magic Quadrant. You don’t have to do so instantly, but you probably want to carefully read what you’re sent within a business day — and to take the time to mark deadlines on your calendar, add contacts to your address book, and so forth.
Gartner tries very hard, through the prescribed form-letter formats that it requires that analysts use for Magic Quadrant communications, to make sure that you get all the information that you need. It is true that we generally err on the side of providing too much detail, rather than being overly succinct. This is because we generally try to anticipate the questions that you are going to ask. Also, sometimes we are constrained by the form letter, which requires that we provide certain information in a certain format, which might not be the most concise possible approach.
Many of the analysts try to deal with your collective reluctance to read by making use of boldface and colorful text to highlight critical information, and in longer communications, to put a summary up-front so it’s instantly in front of you. However, in the end, glancing through the highlights and the summary is often not sufficient. There’s simply no substitute for reading everything.
To make sure that you do not drop critical communications into your spam folder, ensure that you whitelist the admin coordinator at Gartner (who will usually be your point of contact and will send out most of the official communications), along with each of the analysts involved in the Magic Quadrant. Analysts don’t do general email blasts. You should even consider just whitelisting gartner.com email addresses.
By the way, if you can spare the time, you also want to read the research that’s been published by the analysts who will be involved in the process, and more broadly, about your market. Some of the analysts blog, so looking through their postings may be helpful as well. Again, it’s time-consuming, but if Magic Quadrant placement is important to your company, it can give you a good idea of what the analysts will care about in their evaluation.
In the course of my career at Gartner, and my pre-Gartner life as an engineering director who spent giant piles of money on purchasing technology that was often very early-stage, I have spoken to an awful lot of customer references. I’m about to soon dive into the reference-a-thon that a Magic Quadrant represents (we call as many as 5 references per vendor), and it’s leading me to think about what makes for a good or a bad reference, from my personal perspective. So, here are some thoughts, targeted at vendors and service providers.
Make sure your references like you. Nothing will create a worse impression than a reference that isn’t happy with you, and hasn’t been happy with you for some time. It’s fine for a reference to currently be having a transient problem, or even to have experienced some kind of disaster — that sometimes even makes for good stories about how good your support has been during the crisis. But a reference that isn’t a promoter is hugely problematic, because not only does it create a negative impression, it makes it clear that you have failed to keep track of this customer’s sentiment, and to communicate internally about it, to the point where you’re using an unhappy customer as a key reference. You should get in touch with your references on a regular basis to make sure they’re still delighted with you.
Your references should be engaged customers. Engaged customers know why they chose you (and can talk about the competition they looked at and why your solution was the best fit for them), have an opinion on their ongoing use of your product and service, and are passionate enough about it to talk about the good and the bad, what you do well and what they’d like you to improve. Customers who are just, yeah, we selected these guys and it all works okay — fine, you’ve checked the box on “you haven’t actively sucked”, but they’ve really said nothing interesting. This can be fine if you’re just offering a reference to a prospective customer (who wants to make sure that you’ve done an implementation similar to the one he’s contemplating and that it went fine), but it’s deadly in an analyst reference (because the analyst is interested in getting a first-hand picture of what it’s like to deal with you and your product/service, and someone who is neither enthused nor analytical makes for a deathly-dull and not very useful reference).
Your references should be targeted. If you are offering a reference customer to a prospect, the reference should be as similar to that prospect as possible, in terms of solution, industry, approach, and role (likely in that order). If you are offering references to an analyst, they should represent a spread of customers — different use cases, industries, and length of time they’ve been customers (from new implementations to long-term customers).
Your references should be representative. If you’re dealing with an individual customer, your references should be as close to that customer’s expected implementation as possible, even if that is exotic. But if you’re dealing with an analyst, the references should be representative of typical use cases, implementations, and customer types. If you choose to offer some more exotic outliers, great, but make sure the analyst knows that they’re not typical of your customer base. You don’t want to give the analyst the wrong impression about who you normally serve.
Your reference list should be periodically refreshed. You want references that are still actively engaged with you, and represent the current state of your business, in terms of version deployed, use case, and experience with your company. While long-term customers are sometimes nice to talk to (especially in a space where customers sign very long contracts, like 7-year outsourcing deals), for products, or for services bought on shorter contracts, current references are very important. If you are offering references to an analyst, especially in the context of a yearly process like a Magic Quadrant, do not repeat references from year to year; not only will the analyst prefer to talk to someone new, but he will wonder why you can’t easily produce new reference customers.
Ignore client relationships with analyst firms. When offering references to analysts, don’t worry about whether or not a reference has a client relationship with their firm. Reference interviews are typically conducted under NDA, and as far as I know across all research firms, without any regard to client status. Even if an analyst helped a client through the process that resulted in your being selected, he might not have gotten any feedback from the client about what has happened since. Even if the analyst has an ongoing relationship with that client, it’s usually in the context of inquiry, where the analyst, constrained by the 30-minute timeslot and the client’s specific questions, rarely gets to satisfy his curiosity. Reference interviews are very different, and the analyst conducting the interview might not be the same one as previously helped the client.
Consider supplementing references with a customer list. A list of customer logos and, if possible, a one-sentence description of their use case, can be extremely helpful for getting a better general understanding of who you serve, and what they use you for. If providing this list to an analyst, it can usually be done under an NDA.