TL;DR
- Kickoff your tool investigation and selection by first writing it all down: what kind of jobs is the tool for, what the budget range is, who needs seats, what it has to connect to, and what could disqualify it.
- Check what the company already owns. Another team may have a tool that covers your workflow, or a feature nobody ever switched on.
- Build the team: the budget approver, the workflow owner, the people who run the systems it plugs into, anyone whose tool overlaps, and the functions that can block the purchase.
- Read the online complaints as carefully as the ratings. The complaints tell you what you’ll be dealing with after purchase.
- Test with your own messy data and your own permissions model.
- Buy short-term where you can, do vendor and contract diligence before you commit, and keep track of the entire process, including who authorized which decisions.
Introduction
In the old days, which somehow means 2023 and before, people who worked with me often thought I had an unhealthy tool obsession.
They weren’t wrong about the obsession. But it actually has proven to be a huge asset for me. That obsession is one of the reasons I became so good at competitive intelligence, tool research, and solution evaluation.
The paradox of choice keeps getting more extreme. None of this scares or overwhelms me though because this obsession means I frequently go window shopping, and record my discoveries and learnings for a rainy day (i.e. in my tool directory).
Unfortunately, for most companies the paradox of choice becomes more overwhelming than ever, with an invisible pile of tools with unclear ownership, overlapping use cases, and weak return on investment (ROI). This is known as tool sprawl.
What is tool sprawl?
Zylo’s 2025 SaaS Management Index found that organizations waste an average of $21M a year on unused Software as a Service (SaaS) licenses, a 14.2% increase year over year. Zylo also puts 70% of SaaS spend with lines of business, against IT’s 26.1%, which explains the first number. When most buying happens outside the one function that can see the whole stack, five teams buy five tools for one job and nobody reconciles them.
Tool sprawl is exactly that problem: what happens when teams keep adding software without a clean view of what already exists, what overlaps, what’s still used, what’s integrated, and what should be retired.
CIO’s Tech Talk community found that 95% of respondents were planning to consolidate vendors in the next 12 months, with 83% citing moderate to high pressure to do so. What IT executives are saying about vendor consolidation | CIO
So when you need to choose a tool, or recommend one, how do you avoid feeding the tool-sprawl machine and still help your team work better? Let's get into it.
One important caveat before the steps: this is not always a clean, sequential process. Some steps will happen in parallel, and your company may have an official procurement, security, finance, or legal process that changes the order, adds gates, or requires you to document things in a specific way. The point is to make sure each question gets answered before the decision becomes expensive to reverse.
Step 1: Define the goals of your tool search & get to know the landscape
Start with the work you’re trying to change.
What’s broken? What’s slow? What’s being done manually? What information keeps getting copied from one system into another? What are people solving with side documents, Slack messages, spreadsheets, screenshots, exports, and the ten other tiny workarounds that usually mean a workflow has outgrown the system around it?
Write that down first.
Then write the job in plain language. The actual job. The thing the tool needs to make easier, faster, safer, or more measurable.
For most tool searches, I’d define ten things before I talk to anyone selling anything:
- Job to be done (JTBD)
- Business need
- Total cost
- Customer success and support
- Team size and permissions
- Scaling
- Integrations and APIs
- Compliance and risk
- Ownership and adoption
- Team expertise
The question behind each one, and why it matters, is in the whitepaper.
Start a spreadsheet
You're not going to finish this work before you start the next step. Steps will overlap and you'll need a place that is organized and updated on a rolling basis. Start a spreadsheet and add your requirements and tools as you work.
Now learn the landscape
Look around. Window shop. Read the websites. Check the comparison pages. Look at the promises vendors repeat until they start sounding normal. Keep translating everything back into your own words: does this solve the problem I wrote down?
What could actually answer the problem?
Categories are vendor language. They’re useful for finding tools, but they don’t map neatly to the work people are actually trying to do.
Put every serious option against the same problem, the same must-haves, the same integration requirements, the same ownership question, and the same risk constraints.
For a marketing or content team, some problems might look like this:
- Customers can’t find accurate answers
- Sales uses outdated content
- Teams duplicate research
- Marketing needs campaign visibility
- Product updates don’t reach users
The tools you're checking depends on the workflow of course. If two tools from different categories solve the same problem, compare them. If two tools from the same category solve different problems, then they aren't really alternatives after all.
The “all-in-one” promise usually breaks down here.
I’ve come to the conclusion that the true all-in-one tool doesn’t exist. Not really. The promise that one platform will solve tool sprawl by replacing everything else is mostly marketing.
Requirements you have to pay attention to
Ask whether the tool fits into the system you already have, and whether your team has the resources to make that fit work. Resources could be the budget to hire an external team, available in-house manpower, or simpler integrations. And those are just some of the possibilities. Integrations belong in the must-haves.
“We’ll build the connector later” is how tools move to the graveyard fast (but you keep paying for them anyway).
You'll also need to track information that isn't always publicly available. Remember to ask about these points when you meet with the Sales reps for each tool:
- Customer success and customer support. Check whether the vendor will help you implement, troubleshoot, train users, and resolve issues quickly. Bad support turns a good tool into a liability.
- Ease of use. Pick a tool your team can learn fast. A powerful tool with a confusing interface still creates adoption risk.
- Analytics. Look for clear reports on ROI, traffic, adoption, conversion, or the metric that proves the tool is doing its job.
Step 2: Investigate what already exists
Businesses have to enable flexibility, because different teams do different work. But flexibility doesn’t mean every team starts from zero. Adding is politically easy and structurally expensive. Every addition means more integration work, more access management, more renewal tracking, and more places for the same information to diverge.
If you’re a Director, Manager, team lead, product marketing manager (PMM), technical writer, customer success manager (CSM), marketer, analyst, designer, or anyone else trying to solve a local team problem, check what already exists:
- what your own team has
- what adjacent teams use
- whether another function entirely already has a tool that could also serve your team
Start with a lightweight investigation:
- Search your internal wiki, intranet, shared drive, and project management tool for anything you already pay for that might solve this.
- Ask IT, Operations, Finance, or RevOps whether the company already pays for something adjacent.
- Check whether a tool you already have covers this through a feature nobody ever switched on.
- Pull the existing contracts, renewal dates, approved vendor lists, and security review rules.
- Name who owns each of those tools today, and who would own a new one after purchase if your team stopped using it.
Organizations are wasting an average of $21M annually on unused SaaS licenses, a 14.2% increase year-over-year.
When I needed to choose an in-app communication widget for a product at one organization, I already knew our customer success tool offered a feature in the same competitive area. I didn’t think it fulfilled our defined requirements, but it still belonged in the comparison. Existing vendors don’t automatically win, but they do get evaluated before you add another vendor, another contract, and another tool your team has to maintain.
Step 3: Build the team that makes the decision with you
You’re not going to make this call alone.
Somebody controls the budget. Somebody owns the workflow. Somebody owns the system this has to plug into. Somebody may own a tool that already overlaps with the one you want to buy. Somebody in Security, Legal, Privacy, Finance, Procurement, or IT may need to approve the purchase before anyone signs anything.
Bring those people in now. I usually think about five groups:
- The approver. Controls the budget line. Give them the cost, what it replaces, and what happens if you do nothing.
- The owner. Owns the workflow, team, or outcome the tool is supposed to improve. If that isn’t you, they need to be part of the decision before the shortlist gets serious.
- The system and integration people. This includes the system owner, the integrators, internal tech support, and anyone responsible for keeping connected tools working after launch. They can tell you whether the integration is real, supported, secure, and something the company can maintain.
- The overlapping-tool owners. These are the people who own adjacent or competing tools already inside the company. Bring them in before you buy something their stack can already do, almost do, or should replace.
- The required approvers. Security, Legal, Privacy, Finance, Procurement, IT, and any other function that can block the purchase or restrict how you use the tool. They are not obstacles. They are constraints you need early.
Before you finish this step, write down who needs to be involved, what each person has to answer, and where their input matters in the process. A decision with four silent participants has no owner, and in twelve months whoever happens to be in the room will handle the renewal. My recommendation: use a RACI for guidance.
Step 4: Read the ratings and the complaints
Read the complaints and you learn what kind of pain you’re buying.
Ratings are useful, but only if you separate praise from pain. A high average score can hide the exact failure mode that matters to your team.
Look for complaints about support quality, implementation friction, reporting gaps, renewal process, export limits, and whether the product works once real permissions, messy data, and cross-functional ownership enter the picture.
Step 5: Meet the vendors
By the time you reach this step, you probably already have a shortlist and you should only be setting up meetings with about three vendors for your top three choices. If you're not sure about an already existing internal tool, then that vendor should be one of the ones you meet with.
Bring your requirements to the call, along with the people from your team who are relevant. Your system owner will catch things in a demo that you won't, and the required approvers can rule something out on the spot instead of after you've committed.
Step 6: Test with your own data
Your work is real. Demo data isn’t.
Test before you choose, using your own content, permissions model, naming conventions, data quality, and at least one person who wasn’t in the buying room. Real data makes the test harder to fake, because your team will notice the weird fields, missing context, and permission problems the demo never had to handle.
Run the trial with data that you actually would be working on:
- Import a real messy file.
- Connect the system it has to integrate with.
- Ask a non-admin user to complete the workflow.
- Check whether permissions behave the way your organization needs.
- Export the data and see what comes out.
- Break the workflow on purpose and see how hard recovery is.
A tool that only works under ideal conditions will create work for the team later.
Step 7: Buy a month before you buy forever
Where you can, sign up for a single month first and commit once the tool proves it belongs.
Monthly pricing can be worth the premium while the decision is still open. You keep your exit cheap, and you avoid the psychological trap of making a tool work because the annual contract already started.
This is also where the final vendor and contract diligence belongs. Before you ask for budget, commit to an annual plan, or send anything into procurement, check:
- Vendor viability. Who owns the company, how it’s funded, and whether the product you’re buying is still on the roadmap. Ask directly what happens to your data if somebody acquires them.
- Security posture. Ask for the current SOC 2 or ISO 27001 report, the subprocessor list, and the breach notification terms. Read the subprocessor list, because your data may move through more companies than the one on the invoice.
- Data and AI terms. Where your data is stored, who can access it, and whether the vendor trains models on your content. For an AI tool, get that answer in writing in the contract.
- Exit terms. Auto-renewal windows, notice periods, price escalators, and what you actually get back when you export. Ask for a sample export file before you sign.
- References. Talk to a customer at your size, in your market, and ask them what went wrong.
Key takeaways
The real takeaway is simple: don’t let the market, the demo, or the loudest stakeholder define the problem for you.
Every step here exists to keep that definition in your hands, from the moment you write the job down to the moment somebody signs. The vendor will happily do the defining for you, and the version they hand back will fit their product.
