The No BS AI Consulting Playbook

I’ve been in rooms where a team spent three weeks defining the “guiding principles” for an AI strategy before writing a single line of code. I’ve sat through workshops where every session ended with more questions than answers, and the deliverable was a PowerPoint deck that nobody opened after the meeting. I’ve watched companies burn through discovery phases like a GameBoy burns through AA batteries — fast, steady, and with nothing to show for it.

If you’re a business owner who’s talked to AI consultants and walked away with a beautiful roadmap and zero working software, I understand your frustration. That’s not consulting. That’s billing.

Here’s how I approach AI consulting differently.

The Problem with “Discovery-First” AI Projects

There’s a consulting pattern so common it has its own ecosystem of complaints. It goes like this: lengthy discovery phase, requirements gathering, stakeholder workshops, architecture diagrams, a findings readout, a recommendations document, and then — maybe, eventually — a proposal for actual work. By the time you get to building anything, you’ve spent 20% of your budget learning things you could have learned by building.

I’m not saying discovery is worthless. I’m saying that in AI projects specifically, the discovery and the building are often the same thing. You don’t fully understand what an AI can do for your specific data, your specific workflow, and your specific edge cases until you start building with your actual data and workflow.

The endless discovery trap is especially pernicious in AI work because AI is genuinely unfamiliar territory for most business owners. That unfamiliarity makes it feel like you need to understand everything before you can decide anything. And there are consultants who will happily charge you to sit in that uncertainty indefinitely.

Start With the Pain, Not the Technology

The first question I ask every client isn’t “what do you want AI to do?” It’s “what’s breaking right now, and what does that cost you?”

That’s a different question. The first question invites a wish list. The second one points at something real — a process that’s slow, a task that eats time, a data problem that keeps causing downstream headaches. That’s where the AI ROI lives, and that’s where AI implementation projects should start.

There’s a pattern I’ve seen in the companies that get real value from AI early: they don’t start with the most ambitious thing they can imagine. They start with the most painful thing that’s also relatively contained. A clear input, a clear output, a clear definition of what “better” looks like. Those are the wins that build organizational confidence and generate the budget for the harder problems.

The companies that start with “we want AI everywhere” tend to end up with AI nowhere, because no project ever gets small enough and focused enough to actually ship.

How Vertical Slices Get AI Projects Shipped

Here’s the mental model I keep coming back to: the vertical slice.

A vertical slice is a thin, end-to-end implementation of a system that’s actually functional. Not a proof-of-concept with fake data. Not a prototype that only handles the easy cases. A real thing that does one job, with your real data, connected to your real systems, deployed somewhere you can actually use it.

It’s different from how a lot of technical projects get built — where you do all the data work first, then all the ML work, then all the integration work, and only at the end do you have something that connects. That approach feels organized but it delays the moment of truth: does this actually solve the problem?

A vertical slice gets you to that moment of truth as fast as possible. Build the smallest version that does the actual job end-to-end. Find out what breaks with real data. Iterate from there. Every AI implementation I’m proud of started exactly this way.

For AI consulting specifically, this means I’d rather ship a narrowly scoped AI workflow that handles 60% of your use case in week two than spend six weeks designing a comprehensive system that handles 100% of your use case in week twelve. The 60% solution teaches you what the other 40% actually needs. The six-week design process teaches you what you thought you needed before you saw what the AI can actually do.

What “Done” Actually Means

One of the failure modes I see most often in AI projects is fuzzy success criteria. Everyone agrees the project is about “improving customer service with AI” or “automating our data entry workflow,” but nobody nails down what improvement means in measurable terms before work starts.

This is where I get very specific, very early. Before I write a spec or scope a project, we agree on:

What does success look like in 30 days? Not “we’ll have made progress” — actual metrics. Response time reduced from X to Y. Hours of manual work reduced from A to B. Error rate below a threshold. Something you can put in a spreadsheet and point to.

What does failure look like? If this doesn’t work, how do we know? What’s the signal that tells us to stop and change direction rather than keep pushing on a broken approach?

What can’t change? Every business has constraints — compliance requirements, existing systems that can’t be touched, processes that are off-limits. I’d rather know those upfront than discover them mid-build.

Getting specific about success criteria feels slow and overly formal when you just want to start building. It isn’t. It’s the thing that makes every other decision faster, because you always have a way to evaluate “does this actually move us toward the goal?”

The Part Nobody Talks About: AI Project Management

Here’s a take that might be unpopular in engineering circles: in AI projects, project management matters more than model selection.

You can pick the perfect LLM and still fail if the project is scoped wrong, if success criteria are vague, if nobody owns the integration work, or if business stakeholders aren’t engaged enough to validate outputs. Conversely, I’ve seen projects succeed with perfectly average AI — the kind where someone sighs and says “well it’s not GPT-4, but okay” — because everything around the AI was sharp.

The AI is actually the least interesting part of most AI implementations. It’s the surrounding infrastructure — the data pipelines, the human-in-the-loop checkpoints, the output validation, the monitoring, the feedback loops — that determines whether the thing works in production or just works in the demo.

I spent time early in my career in environments where the expectation was that you just kept scoping until the requirements document was “complete.” I never saw a requirements document that was complete. I saw a lot of projects that ran long, over budget, and delivered something that loosely resembled what people had originally asked for.

The alternative is to care more about shipping the right thing than documenting the perfect thing. Minimum viable, actual production, real feedback, real iteration. That’s the playbook.

What This Looks Like With a Real Client

To make this concrete: a client comes to me with a customer support problem. Their team spends four to six hours a day manually reading, categorizing, and routing incoming support tickets. They want to know if AI can help.

Here’s the no-BS approach:

Week 1: Look at a sample of actual tickets. Understand the categories, the edge cases, the tickets that require human judgment vs. the ones that are mechanical. Define the success metric (let’s say: reduce manual triage time by 70% while maintaining 95% routing accuracy). Scope the smallest thing that tests the hypothesis.

Week 2-3: Build the classifier. Train it on real tickets. Not a general model — fine-tuned or prompt-engineered specifically for their categories. Test it against a holdout set of tickets. See where it fails.

Week 3-4: Connect it to their actual ticket system. Build the approval interface so tickets below a confidence threshold route to humans. Ship it to one support agent on a trial basis.

Week 5+: Measure against the success metric. Iterate on failure modes. Expand if the results justify it.

That’s a working AI system in a month that either proves the hypothesis or tells us what we got wrong. Not a deck. Not a roadmap. Software.

---

One honest meta-note: if you’re evaluating AI consultants right now, I’ve put together 10 questions worth asking any consultant before you sign anything — including the ones I’d expect you to ask me. Worth reading before any conversation.

And if the vertical slice approach resonates, there’s a follow-up post on why task decomposition and PM discipline matter more than coding in agentic AI projects — it goes deeper on the mechanics of how to actually define those slices well.

If you’re tired of AI consulting that keeps finding reasons to keep consulting instead of building, see how I scope and price AI projects — or let’s have a direct conversation about what you’re actually trying to solve. If I’m the right fit, you’ll know in 30 minutes.