The Hidden Cost of Tool Sprawl
The average SMB now pays for 254 SaaS applications. The average enterprise: 473. Yet studies consistently show that 30–40% of those products are underutilized or completely unused within 12 months of purchase. The problem isn't that teams are buying bad software — it's that they're buying software for the wrong reasons, at the wrong time, without a framework for evaluation.
Over the past five years I've helped over 60 companies audit their software stacks. The patterns of waste are remarkably consistent. Here's the framework I now use before recommending any tool purchase.
The 5 Questions Framework
1. What specific problem does this solve — and do we have that problem today?
This sounds obvious but it's where most purchases go wrong. Teams buy tools for problems they anticipate having rather than problems they currently have. The result is a product that sits unused until the problem materializes — by which time the team has forgotten they have it, or the product has been cancelled.
The discipline here is to write down the specific, measurable problem in one sentence before evaluating any solution. "We need better project management" is not a problem statement. "Our engineering team misses sprint commitments 60% of the time because task dependencies aren't visible" is a problem statement. The specificity forces you to evaluate whether a product actually addresses the root cause.
2. What does the workflow look like after we adopt this product?
Most software demos show you the product in isolation. The critical question is how it fits into your existing workflow — and what changes when it does. Map the before and after: who does what, when, using which inputs and producing which outputs. If you can't articulate the post-adoption workflow clearly, you're not ready to buy.
Pay particular attention to integration points. A product that requires manual data export/import to connect with your existing stack will be abandoned within weeks. Integration isn't a nice-to-have; it's a prerequisite for adoption.
3. Who will own this product, and do they want it?
Every product needs an internal champion — someone who will configure it, train the team, troubleshoot issues, and advocate for its continued use. If you can't name that person before you buy, the product will drift into disuse regardless of its quality.
More importantly: does that person actually want this product? Tools imposed top-down on teams that didn't ask for them have a failure rate approaching 70% in my experience. The best predictor of adoption is whether the people who will use the product daily were involved in selecting it.
4. What does success look like in 90 days?
Define a specific, measurable success metric before you start the trial. Not "the team finds it useful" — that's unmeasurable. Something like: "Sprint commitment rate improves from 40% to 65%" or "Time spent on weekly reporting drops from 4 hours to 45 minutes." If you can't define success, you can't evaluate whether the product is delivering it.
Set a calendar reminder for 90 days post-adoption to review against this metric. If you're not hitting it, either the product isn't working or the adoption is insufficient — and you need to know which before renewing.
5. What's the exit cost if this doesn't work?
Every product purchase is a bet. Before you place that bet, understand the downside. How long is the contract? What happens to your data if you cancel? How hard is it to migrate to an alternative? How much institutional knowledge will be embedded in this product's proprietary format?
The products with the highest exit costs — those that store critical data in proprietary formats, require long contracts, or deeply embed into your workflow — deserve the most scrutiny before adoption. The ones with low exit costs (monthly contracts, open data formats, easy exports) can be evaluated more lightly because the cost of being wrong is low.
The Trial Protocol
Once you've answered these five questions and decided to evaluate a product, run a structured trial rather than an open-ended "let's try it and see." A good trial has: a defined duration (2–4 weeks), a specific use case to test, a small group of actual users (not just evaluators), and a clear decision criteria agreed in advance.
At the end of the trial, gather feedback from the users — not just the buyer. The people who will use the product daily have the most accurate signal on whether it will actually be adopted. Their enthusiasm (or lack of it) is more predictive than any feature checklist.
The One Rule That Saves the Most Money
If I had to reduce this entire framework to one rule, it would be: don't buy a product to solve a problem you don't yet have. The anticipatory purchase — "we'll need this when we scale" — is responsible for more wasted SaaS spend than any other pattern. Buy for today's problems. Revisit when the anticipated problem actually arrives. By then, the market will have better solutions anyway.
Share this article
