Strategy-first tooling
A dead-simple, spreadsheet-driven method I’ve used for 6+ years to evaluate new tools, avoid shiny distractions, and lead migrations with confidence (without wasting time, money, or trust).
Are you a free Data Gibberish Subscriber? Here’s what you’ve missed in the last month:
You stare at a stack that still runs. Jobs finish. Dashboards load. No fires.
But traffic climbs. New pipelines queue up. The week feels heavier than last week. Your gut says the current setup won’t carry the load much longer.
So you pull the laptop closer and write the goal in one plain sentence. What the business needs now. Not in ten years. In the next few quarters.
Then you open the sheet. The same one that saved your ass more times than you want to admit.
Tabs pop. You name the migration. You set constraints. Budget. Team skills. Data gravity. You promise yourself you will not chase trends. You will test needs.
And the room goes quiet. Questions change. No one asks why you want to change tools. They ask when you can show first results.
You feel it in your shoulders. Lighter. Clear. In control.
Here’s how this happens. (The exact prompt and spreadsheet are at the end of the article).
The rule: strategy before tools
Every engineer hits this at some point.
You hear whispers about a shiny new tool. Everyone on LinkedIn is raving about it. Someone drops it in Slack with the words “game changer.” And before you know it, you’re deep in their docs trying to justify why your next migration needs it.
Pause.
You need to start with the strategy. Not the tech. Not the logo. Not the damn trend.
Start with what you’re trying to solve. Get brutally clear about it. One business problem. One outcome that matters. Something like:
“Reduce pipeline cost by 30% over the next 6 months”
“Add audit-ready lineage for all sensitive datasets”
“Cut onboarding time for new analysts in half”
And keep the horizon short. 2–3 years is long enough. Anything beyond that is fan fiction.
Once you’ve got the problem, define the walls around it. Budget. Team experience. Existing contracts. Data volume. Support model. All the constraints you can’t wish away.
This is the filter. Tools don’t get through it unless they serve this strategy. Not the other way around.
Your job isn’t to mold the team to the tool.
It’s to pick the tool that fits the team’s mission.
Step 1: write ruthless requirements
This is where most tool evaluations fall apart.
People start with how they want to feel about a tool. “It should feel modern.” “It should have a sensible process.” Whatever that means.
That’s not helpful. That’s noise.
What you actually need is a list of requirements so specific, your future self can thank you when things break at 2am.
Write every single behavior you expect from the tool, down to the boring, brutal, non-negotiable details.
“Supports Git-based deploys with review flows”
“Column-level lineage viewable by data analysts”
“Backfills can run with retries and logs”
“SSO integration with Google”
“Cost under $3K/month at projected volume”
Include the obvious. Include the weird. Include the annoying little quirks that you know your team will ask about later.
You’re not writing this list for a product demo. You’re writing it for the PoC. For the real-life mess.
And don’t stop at features. Add the non-functional stuff too:
Support SLAs
API rate limits
Licensing model
Community size
Last release date
Split the list into three buckets:
Must-haves: If it fails here, it’s out.
Should-haves: You’ll work around it, but it stings.
Nice-to-haves: Pure bonus.
This list is your armor. Your receipt. The one thing that keeps marketing fluff from messing with your brain.
Step 2: use AI to scout the field fast
The old way looked like this:
You’d Google for hours.
Open fifteen tabs.
Scan a bunch of half-baked blog posts.
Compare tools based on which one had a better landing page or snarkier tagline.
That’s done now.
Here’s the new way:
Paste your requirements into a prompt and let AI be your intern.
A fast, tireless, slightly nerdy intern who reads all the docs so you don’t have to.
You tell it: