You just got the objective. Your CEO said something like "I want us doing something real with AI this year," gave you a budget, and made it part of your next review. Now you're staring at a blank page.
You're not an engineer. Every vendor wants to sell you a platform. Every article you find is either deeply technical or painfully vague. And the clock is ticking on a deliverable you didn't ask for.
Here's a different way to approach this — one that starts with what you already know about your business, not what you don't know about AI.
Start with the frustration, not the technology
Forget AI for a moment. Think about your operation.
What process makes your team groan every time it comes around? Where do smart, experienced people spend hours on work that doesn't require their judgment? What's the thing everyone knows is broken but nobody fixes because "that's just how it works"?
The best AI projects don't start with a technology evaluation. They start with a business problem people are emotionally tired of. The quarterly compliance review that eats three weeks. The event coordination that runs on spreadsheets and hope. The triage process where quality depends on who happens to read the ticket first.
Write down three processes that waste your team's time. Be specific. Not "we need better data management" but "we spend 15 hours a week reconciling these two spreadsheets" or "our quality team manually reviews 200 documents a quarter against a regulatory checklist." The more concrete, the better. That specificity is what turns a vague AI initiative into a project with measurable ROI.
Now dream bigger than you think you should
This is where most people go wrong. They constrain their imagination based on what they think software can do — and those assumptions are usually three to five years out of date.
My single best piece of advice: overestimate what's possible.
Want the system to read 200 pages of regulatory documents and produce a structured gap analysis in minutes instead of weeks? Ask for it. Want it to cross-reference three different data sources and flag anomalies a human reviewer would miss on page 47? Ask for it. Want a workflow that turns a two-day manual process into something that runs before your morning coffee? Ask for it.
You can always scale back. But if you start with modest expectations, you'll get a modest result — and modest results don't change anyone's mind about AI. They become shelfware. The projects that succeed are the ones where someone had the courage to say "what if we could do this?" and then found a partner who said "yes, and here's how."
Start with what you wish were possible, not what you assume is feasible.
Your people aren't the obstacle — they're the advantage
Here's the part nobody wants to talk about openly: everyone is scared.
Middle management hears "AI initiative" and wonders if they're automating themselves out of a job. Front-line staff see a new tool and assume it's the first step toward a layoff. This fear is rational — they've read the same headlines you have. And if you don't address it directly, it will kill your project faster than any technical challenge.
The truth is that the most powerful AI workflows don't replace human judgment — they amplify it. The human decides what matters, what's important, what the priorities are. The AI handles the tedious, repetitive, data-intensive work that was never a good use of anyone's expertise in the first place.
Think about it this way: nobody mourned the loss of hand-calculating spreadsheets when Excel came along. The people who learned to use the tool became more valuable, not less. They could analyze more data, find patterns faster, and spend their time on decisions instead of arithmetic. AI workflows work the same way — except the leap in capability is much larger.
Frame it to your team this way: "We're giving you a power tool, not a replacement." The people who embrace this become dramatically more effective. I've seen it in my own work — tasks that used to take days now take hours, not because the thinking got easier, but because the execution got faster. The judgment, the context, the institutional knowledge your people carry — that's irreplaceable. The manual labor surrounding it is not.
Your job as a leader is to make that distinction crystal clear before the project starts. Buy-in isn't something you get after launch. It's something you build before the first line of code is written.
The wish list exercise
Here's what I'd suggest instead of a formal requirements document or an RFP process.
Block 30 minutes on your calendar. Close your email. Open a blank document and write a wish list. No constraints. No "that's probably too hard." No filtering based on what you think technology can or can't do.
Just answer this: If I could wave a magic wand, what would I want this system to do?
Include the ambitious ideas. Include the ones someone told you were impossible two years ago. Include the thing you've been quietly thinking about but haven't said out loud because it sounds too good to be true.
Write down:
- The problem: What's happening today that wastes time or money?
- The dream state: What would it look like if it just... worked?
- The people: Who touches this process today, and what would their day look like instead?
- The stakes: What does this cost you annually in hours, errors, or missed opportunities?
Don't worry about technical feasibility. Don't worry about architecture or integration. Don't worry about whether it's "AI" or just better software. That's someone else's job to figure out.
Then find a partner who can look at that wish list and tell you honestly: this one's straightforward, this one's ambitious but doable, this one isn't ready yet, and this one — this one could transform how your team works.
That single conversation is worth more than six months of internal research, vendor demos, and committee meetings.
What a good first project looks like
Pick a problem that costs real money — $150,000 or more a year in labor, errors, or inefficiency. Something painful enough that success will be obvious, but not so mission-critical that everyone panics if you try something new.
Budget around $50,000 for the build. Expect to be running in production within 10 weeks. That's a real project with real ROI — small enough to succeed and large enough to prove the point to your organization.
The first project isn't just about solving one problem. It's about updating your organization's assumptions about what's possible and how fast it can happen. When your team sees a $150,000 annual pain point disappear in two months, the next conversation about AI gets a lot easier. Buy-in stops being something you have to manufacture — it becomes something people ask for.
You don't need all the answers
You don't need to understand transformer architectures or vector databases or retrieval-augmented generation. You don't need to evaluate fifteen vendors or attend three conferences or hire a data science team.
You need a problem worth solving and a partner who understands both the technology and how organizations actually adopt change. Someone who's been on your side of the table — who's led teams, managed budgets, navigated the politics of introducing new tools into established workflows — and who now builds the systems that solve these problems.
Send us your wish list. Seriously — a bullet-point email is fine. We'll tell you what's possible, honestly, not optimistically. Sometimes the answer is "not yet." But increasingly, the answer is "faster and cheaper than you think."