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.

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….!”

  • 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?

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?

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?

What business outcomes am I trying to achieve?

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?

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?

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

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

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?

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.

Data center/security/collab hack, CCIE #5026, focusing on automation, programmability, operational efficiency and getting rid of technical debt.