When I started working in technology more than 20 years ago, I looked at products very differently than I do today.

My first tech jobs were at Staples and Best Buy, so I was around technology sales early. At that point in my career, I could absolutely be impressed by a slick interface, a flashy demo, or a feature that simply looked cool.

I was also loyal to certain brands. Once I decided I liked a company or product, I tended to defend it.

Then I got my first real IT job.

That was when I started learning the difference between selling technology and owning it.

A great demo does not automatically mean a great operational fit, and “turnkey” usually still requires planning, integration, testing, and somebody who understands how the pieces fit together.

Start With the Problem

A large part of my early IT career was spent in local government, where we did not always have the budget to purchase an enterprise product every time a problem needed solving.

Sometimes the assignment was basically:

“We need to do this. Figure it out.”

That environment pushed us toward open-source tools, community-supported software, and sometimes solutions we had to build or adapt ourselves.

It forced me to understand more than the interface. I had to think about how the product worked, how it would be supported, what happened when something failed, and whether we could realistically operate it long term.

That experience shaped one of the principles I still use today:

Do not start with the product. Start with the problem.

What are we trying to accomplish?

What is not working today?

What does a successful outcome actually look like?

I also want the people who perform the work involved in that conversation. They usually understand details and pain points that are easy to miss from outside the process.

Once the requirements are clear, then we can start researching products, talking with partners, and evaluating possible approaches.

There is a big difference between asking, “What can your product do?” and saying, “Here is the problem we are trying to solve. Show me how you would approach it.”

I prefer the second conversation.

You Are Buying More Than a Product

One of the hardest lessons I learned early in my career involved a storage platform we purchased for file services.

Within months of our purchase, the company behind the product ceased operations.

About a year later, we had an issue and needed support. We eventually reached the company that had acquired parts of the technology, but the path to support involved moving to its newer platform.

That was not the lifecycle we expected when we made the original purchase.

I ended up digging into the underlying operating system, researching the issue, and getting the system operational again myself.

We recovered, but the experience changed how I evaluate vendors.

You are not just buying technology.

You are entering a relationship with the company behind it.

Today I pay attention to reputation, support quality, transparency, pricing, roadmap, and how customers describe their experience after the sale.

One of my favorite questions is simple:

Can I talk to your customers?

Not just read a case study. Actually talk to somebody operating the product.

I once spoke with a customer reference supplied during an evaluation who strongly advised us not to move forward. They explained the problems they had experienced and the difficulty they had getting support.

That conversation told us more than another polished presentation would have.

Customer references are not perfect, and vendors naturally choose customers they expect to speak positively. But the conversations are still valuable, especially when you ask about implementation, limitations, support, upgrades, and what they would do differently.

Make It Prove Itself

I also believe strongly in a meaningful proof of concept.

A demo usually shows a product under favorable conditions.

I want to understand what happens with realistic requirements, representative workflows, and the people who will actually be responsible for using or supporting it.

When practical, comparing products against the same requirements can be extremely useful.

Earlier in my career, we evaluated an automated timekeeping system that looked promising on paper and integrated with systems we already used.

Then we tested real scenarios.

Once we got into the details of how employees actually recorded and managed their time, the workflow became much more rigid than we expected.

The integration technically worked.

The overall solution still was not a good fit.

That reinforced an important lesson:

Checking a requirement box does not necessarily mean you have solved the requirement.

The feature may exist, but usability, flexibility, administrative effort, or operational complexity can completely change its value.

Every Decision Has Tradeoffs

After enough years in IT, you stop expecting a perfect product.

One solution may provide better support but cost more.

Another may be easier to operate but offer fewer integrations.

A hosted platform may reduce infrastructure responsibility while also changing how much control you have over upgrades, data, or availability.

Those are not automatically good or bad decisions.

They are tradeoffs.

The job is to understand those tradeoffs well enough to decide which ones make sense for the organization.

That requires looking beyond the feature list.

Think About Ownership, Not Just Implementation

The questions also change depending on the technology.

With infrastructure, I pay close attention to support and service commitments.

If a contract includes a four-hour hardware replacement SLA, what exactly does that cover? Are there geographic limitations? What does escalation look like? Can failed drives be retained when security requirements call for it?

With software, I spend more time looking at licensing, integration, reporting, hosting options, availability commitments, administrative overhead, and long-term cost.

Regardless of the product, I want to know what ownership will look like.

Can the team manage it?

Can we troubleshoot it?

Can routine changes be handled internally?

How dependent will we be on vendor support?

And there is another question I think deserves more attention during an evaluation:

What is the exit strategy?

If the organization decides several years from now that the platform is no longer the right fit, what happens to the data? What does migration look like? Are there contractual or technical barriers to leaving?

It is much better to understand those answers before signing the contract than when you are already trying to move away.

Translate the Technology Into Business Value

Eventually, someone is going to ask:

Why should we spend money on this?

That is where technical teams have to translate capability into business outcomes.

Here is what we do today.

Here is where the current process creates cost, risk, or unnecessary effort.

Here is what the proposed solution changes.

Here is what the organization gains.

Sometimes that is direct cost savings.

Sometimes it is reducing risk, improving reliability, simplifying operations, or returning time to the team.

The technical details matter, but leadership should not have to figure out the business case themselves.

Helping make that connection is part of the job.

What Changed After 20 Years

I still like new technology.

I still see products and think, “That’s pretty cool.”

The difference is that “cool” is no longer enough.

Now I want to know whether it solves the right problem, fits the way people actually work, can be supported over its lifecycle, comes with tradeoffs we understand, and creates enough value to justify the investment.

Twenty years ago, the demo got my attention.

Today, I care much more about what happens after the demo.

Because the best technology is not necessarily the one with the most features.

It is the one that solves the problem, works in the real world, and still makes sense after the sales team leaves.