The good, bad and ugly truths about purchasing technology in a demo-oriented world.

Photo by Emiliano Vittoriosi on Unsplash

Let’s set the stage. The demo stage.

You’re watching a vendor demo. It gives you a perspective of a world full of possibilities, endless optimism, and long weekends at the beach. Your world will be magical: if only you purchase the Infotramatical Elite Defender SaaS Platinum 6000 package. “Better everything, for only $X per month!”

Boom! PO issued. Sale made.

Get in the DeLorean and fast forward a year, and of the 80 life-changing features in the Infotramatic Elite Defender SaaS Platinum platform, your organization has deployed 20% of them, maybe. And it’s just an OK solution. And the only one that uses it is Jane in finance. And, and, and.. And, since that service didn’t hit the mark, the cycle starts over. Lather, rinse, repeat.

“But it looked so good in the demo….!”

If you’ve never had this experience, kudos to you. I know I sure have, and it’s rarely (if ever) been the technology that failed. Why is it different? Four reasons.

• When you watch vendor demos, they don’t tell you about the thousands of hours that go into developing the presentation. That slick demo doesn’t just magically appear out of thin air!
• Often, demo environments are curated to show the most favorable circumstances for a product, service or solution. Seldom does it reflect the real-world realities of corporate entropy, legacy systems, tribal knowledge and politics.
• They show you every feature under the sun, regardless if you have the capability to operationalize it. It’s equivalent to buying a $300,000 Ferrari, but not having the cash to afford the $2,000 oil changes.
• Finally, for technology that is end-user facing, buying the product doesn’t mean that anyone will actually use it. Maybe it’s knowledge, maybe it’s training, maybe it’s perceived value. Regardless, if there’s no adoption, why waste your time?

How do you avoid this situation?

By no means am I suggesting that you shouldn’t purchase technology, or that vendor demos are bad! Quite to the contrary. I believe that the skills needed to manage the solution, the processes and procedures needed to support it, and the clear expectations around what the solution will achieve, and when are clearly defined and understood, prior to a PO being issued. For BOTH parties.

We’ll break each of these down but I want to show you our Value Curve. Our team uses this with customers when we’re talking about realistic expectations regarding technology.

What’s the Value Curve?

In order to receive an ROI from a technology investment, you need to implement it in your organization. To realize a value, you’re going to need to dedicate time, money and resources internally. But, at this point, you’ve already made the purchase.

Back to our example of the 80 features in Infotramatic Elite Defender SaaS Platinum. If you can implement 50 of those features for $1,000 and the remaining 30 features for an additional $100,000, is that worth it? I don’t know, maybe, maybe not. But, these are the conversations you need to be having with your vendor and your leadership, and only after they’re established and understood, issue a PO.

The Value Curve starts when you’ve made the purchase and ends at some future point where you’ve realized “enough” value out of the solution. But, just like our Ferrari, the costs continue to accrue. Also, by the time you evolve an ecosystem around a technology to eke every last bit of value out of it, a simple project can evolve into a company-wide program office. Are you ready to support that? Are your non-technical peers?

As you purchase ANY technology, it’s important to determine your value curve for each product, service or solution you buy. By asking strategic questions up front and establishing tangible crawl-walk-run milestones, you can avoid the shelfware plague, or eternally languishing projects on the project docket.

How do I purchase IT solutions while leveraging the value curve?

Here are the critical questions and thought exercises that every customer needs to hold themselves and their vendors accountable to that go beyond what’s shown in a demo.

What business outcomes am I trying to achieve?

If you start off by asking for a list of features and picking and choosing outcomes based on available trinkets, You’re Gonna Have a Bad Time. I believe that you should be able to articulate the business outcomes for a technology project, irrespective of what vendor or technology you choose. Tech companies make awesome products that solve hard business challenges — however there is no guarantee that the problems they solve are the ones you have.

In demo land, the business outcomes are valid, but are they valid for your business?

What are my crawl-walk-run milestones? How do I achieve them, and on what timeline and for what cost?

Every technology has “low-hanging fruit” — the pieces of the solution that are easy to turn on. Tech 101. But, if your aspirations for a product set exceed the basic features, you need to clearly understand what you’re in for.

You should hold your vendors feet to the fire and make sure they can clearly articulate milestones, level of efforts, and MOST importantly, what you’re on the hook for delivering to them. Remember, no vendor can work in a vacuum.

Here’s an example in the security arena.

Micro-segmentation is all the rage right now. People want zero-trust data centers. Throw a stone and you’ll hit 17 vendors that sell “turn key, zero-trust microseg security ecosystems”. Let me break down a zero-trust datacenter project:

• Crawl: From a 30,000' view, tell me about the inter-dependencies in your data center. What applications do you have? How many? How do the apps map to the infrastructure? From a high-level policy perspective, what should talk to what? What shouldn’t talk to what? How much does this cost? $.

Hint: if you can’t answer these questions, they’re requirements for everything else, so all of a sudden, your project just went from $ to $$$$$, depending on the size of your environment.

• Walk: Forget microseg, let’s macro-seg. How are we going to put in place broad controls to either allow or prevent services? When something breaks, do we have the air cover from our leadership? Who is managing the on call when a once-a-month-but-business-critical batch job fails? Do we have the people with the right skill set to support this? Do they know what to do when there’s an issue? How much does this cost? Maybe $$$$? It gets fuzzier.
• Run: At this point, macro-seg evolves into its own program within the organization. There’s a steering committee, with representatives from the business, security, infrastructure and operations offering input and strategic direction. Applications are stack ranked by business criticality and risk. Micro-seg is enabled on an application-by-application business, and the people, process and technology are that much more critical. How much does this cost? At this point, it’s $$$$$+.

There’s no shortcuts: you can’t just skip to the Run phase. Well, ok, you can, but you need an unlimited budget and vast amounts of time. And then, it’s still a maybe.

In demo land for a microseg product, you see the fruit of getting to the Run stage. You don’t see the blood, sweat and tears that you need to invest to get you there.

Do I have the operational rigor to support the technology solution?

We all love new and shiny. When things are new, people are excited. That’s great, but what happens when the new car smell is gone? Do you have the people and processes in place to support the technology after the initial staff has turned over? Is there accountability for doing it correctly long after the project is off the books?

In a demo, you see outcomes, not care and feeding.

What does my organization need to do to generate end-user excitement and adoption?

If end-users use it, it’s a different animal. People go to their job and do their work — they don’t really care about how magical the Infotramatic Elite Defender SaaS Platinum is.

I’ve implemented a LOT of video conferencing in my career. A lot. The worst is when you go through all the time, effort and expense of implementing video conferencing or a collaboration tool and no one uses it. The organizations that get the most value are the ones that have an empowered leader demanding that people get on board, or fire and brimstone is coming. You know, the ole’ carrot and stick.

This isn’t about IT or a single organizational role getting on board, it’s about a cohesive approach. Small initiatives might not need that much, but larger ones absolutely do. Can you get the buy-in you need prior to starting a project?

In demo land, you see an organization where everyone has free time, is excited to have their daily routine rocked, and isn’t bothered in the slightest about being disrupted.

So is demo selling bad?

Not at all! Just recognize it for what it is: an aspiration. And that’s totally awesome! But the aspiration is probably not your reality.

For me, it all boils down to honesty and accountability. By keeping the Value Curve in mind, and framing your expectations with a crawl-walk-run approach, you can define realistic business outcomes prior to initiating a project. Take an honest look at yourself and your teams to make sure that you’re getting what you need out of it, and if you find yourself on shaky ground to take a pause and regroup and make sure you’re getting what you need to enjoy success.

Thanks for reading — as always, comments and feedback are highly appreciated.