The Shiny Tool Problem is Costing Your MSP Money

If you run an MSP or work as a trusted technology advisor, you’ve been in this situation. A client calls you excited about a tool they saw at a conference or heard about from a peer. They want it. They can’t really tell you why. They just know they want it.

It’s an easy trap to fall into, and honestly, it’s getting worse. The market is flooded with new tools, new platforms, and especially new AI solutions. Everyone is getting pitched constantly. And most of the time, the buying decision happens before the most important question ever gets asked: what problem are we actually solving?

I’ve been spending time doing outsourced CIO/CTO work lately, and I’m seeing this pattern up close. Businesses chasing shiny tools instead of thinking clearly about their needs first. Let’s talk about how to do this better.

Start With the Problem, Not the Product

Before you open a browser tab or sit through a demo, you need to be able to state the problem you’re solving clearly. If you can’t do that, you’re not ready to evaluate solutions yet.

This means defining two things: your business requirements and your security requirements. These are not the same thing and both matter. A tool might solve the business problem perfectly and introduce unacceptable security risk. A tool might check every security box and be a nightmare to operationalize.

When you’re sitting in the vCIO or vCTO seat, your job is to represent the client’s interests, not the vendor’s pitch deck. That means doing the work to understand what’s actually broken or missing before you start looking at what’s available.

Weigh Tools Against Requirements, Not Hype

Once you have your requirements documented, now you can actually look at tools. The process here is straightforward: list your requirements, then score tools against them. Features that don’t map to a requirement are noise, not value.

Watch out for scope creep during evaluation. “Oh, but it also does X” is how you end up paying for capabilities you’ll never use. This is where the list you built before the demos started comes in handy.

One thing worth flagging here: AI tools are currently the fastest-growing source of hype-driven buying in the market. We’ll dig into that specifically in a bit, but the same framework applies there too. Requirements first, tools second, always.

A tool that solves 80% of your core requirements cleanly beats a tool that dazzles you and covers 60% of what you actually need.

MSP Stack vs. Client Recommendation

If you’re an MSP, you’re evaluating tools in two distinct contexts. They have different criteria. Mixing them up is a common mistake.

When a tool is going into your stack, the questions are operational. Can your team actually use this consistently? What does support look like, because you are now tier-one support for every client on this product. How does it affect your COGS? Is it replacing something or adding to your cost structure? Does it scale across your client base or is it a one-off solution for a single situation?

When you’re recommending a tool directly to a client, the criteria shift. Can you sell it and make margin on it? Distribution matters here, whether that’s direct from the vendor, through a distributor, or a referral arrangement. Can your team support it, or are you creating risk by recommending something you don’t know well? And honestly, does it fit their requirements, or does it fit your preference?

The criteria for “great tool for my stack” and “great tool to recommend to a client” overlap, but they are not the same list. Know which evaluation you’re doing before you start.

The 3:1 Rule: Before adding or swapping a tool in your stack, it should either generate $3 in revenue for every $1 spent, or save $3 in labor for every $1 spent in a demonstrable way. If you can’t make that math work on paper before you buy, the tool is probably not worth it. This one rule will do more to protect your gross margin from tool sprawl than any annual audit.

AI Deserves a Special Conversation

Everything covered above applies to AI tools. The discipline just has to be higher because the hype is louder right now than anything I’ve seen in a long time.

Here’s the honest truth about most SMBs: they don’t have an AI problem. They have a process problem that AI might be able to help with, if you take the time to define it properly first. Before you recommend any AI solution, start with use cases, not tools. What does someone on that team do repetitively that costs significant time or introduces consistent errors? That’s where you start.

Then ask whether AI is actually the right answer. Sometimes it is. But sometimes the right answer is a better workflow, a better integration between existing tools, or a better-trained employee. AI is a powerful option, not an automatic one.

If AI does turn out to be the right answer, the requirements process matters even more than usual. The landscape is changing fast, and making a disciplined buying decision now saves you from a painful migration six months later.

The Bottom Line

Good product decisions aren’t about knowing every tool on the market. They’re about knowing the problem well enough that the right tool becomes obvious.

That’s the value you bring as a trusted advisor. Whether you’re an MSP owner, a vCIO, or a business owner trying to make smart technology investments, the process is the same. Define the problem. Document the requirements. Score tools against those requirements. Understand how you make money on what you recommend.

The businesses that get this right spend less, implement faster, and get more out of every tool in their stack.