Databricks' Barry Dauber on why every project should start with impact, not AI

Barry Dauber runs Gen AI go-to-market at Databricks, which puts him in front of companies across the full spectrum of AI adoption, from the most AI-mature digital natives to companies still running a SQL server on a desktop under someone's desk. That volume of conversations is where his frameworks come from. He built a slide he pitches almost every other day, and it distills down to one rule: start with impact, not with AI.

The challenge

Barry describes a conversation he used to have constantly. He'd ask a company what they were actually trying to do, and hear back: no, no, you don't understand, we just have to have AI. That exchange is why he now runs a simple filter on every inbound request at Databricks. Before scoping any AI initiative, he asks for the metric it's meant to move and who owns that metric. If a team can't name both, the project isn't ready to be scoped, no matter how urgent it feels. Most requests fail this test.

I can talk about amazing AI capabilities and data capabilities and everything that Databricks does until we're blue in the face. But ultimately, who cares? What is the impact? What is the value?

Barry DauberVP of GenAI GTM, Databricks

The playbook

Five moves Barry uses to size, build, and govern an AI project once it clears that first filter.

• Classify the initiative first: Every AI request falls into one of three buckets, and each carries a different bar for ROI and timeline. Individual productivity covers existing tools like Glean, Claude Code, ChatGPT Enterprise, or Copilot. Operational efficiency means fitting agents into specific steps of a workflow you already run well, to cut time to resolution. Business reimagination means removing a constraint you've designed around for years to chase new revenue or a step change in cost. Classify before you scope anything.

• Reach for the simplest model that works: Most AI initiatives don't need a language model at all. Next-best-action and recommendation problems are frequently already solved by classical machine learning that's existed for 30 years. Reserve the LLM for the parts that genuinely need language understanding, and pair it with a deterministic model for the rest. Calling something Gen AI might unlock the budget, but it doesn't make it the right architecture.

• Fix the data before you build: You can't have AI without data. Feed the model your actual business context rather than generic training data, then test it against the goal before you ship it, the same acceptance testing software has always run before deployment. Skip this step and you get a vibe-coded app that's, at best, pretty good.

• Govern access for people and agents alike: Ask the same question for three different actors. Does this person have the right access to the right information at the right time? Does this agent? What about an agent acting on behalf of another agent or a human? Set read and write permissions by role, and tighten further for regulated data or public companies, where a leak carries real consequences.

• Plan the reskilling, not just the rollout: Process change is half the battle. Developing the people who have to run the new process is the harder, more important job. Don't hand a new process to the business as a mandate from IT. Reskill the employees already in seat, so adoption doesn't stall on a skill nobody has yet.

Episode highlights

• 00:53 - Revenue obsession starts with customer obsession in a consumption business

• 02:37 - The AI hype that keeps him up at night, and "start with impact, not with AI"

• 03:51 - The three buckets, and the Uber test for what reimagination actually means

• 07:06 - AI slop, and who is supposed to consume all of it

• 11:02 - Why people forget that LLMs are predicting the next token

• 12:49 - Data, evaluation, and the gates that vibe coding skipped

• 13:29 - Why people and process is the harder half of AI transformation

• 18:22 - Right person, right agent, right information, right time

• 23:02 - The contact us form he made worse on purpose

• 27:26 - Open versus closed models, and the switch from token maxing to value maxing

My two cents

About twenty minutes into this conversation, I heard myself say Barry's own line back to him, without realizing it: it's gotta start with impact. A few things stuck with me.

• Impact before technology: Our sales motion runs on the same test Barry describes. What's the metric this company is trying to move? What's the business problem they actually care about? If we can't answer both, the conversation isn't worth having. We can throw AI at a hundred different parts of a sales motion. Impact still has to come first.

• Some AI is just for the boardroom: Too many leaders reach for AI on problems that don't need it, often to check a box for the board. Checking that box doesn't answer the only question that matters: is it actually any better? Deploying AI on a process and improving that process are not the same thing.

• Remove the constraint and the process goes with it: The business transformations I'm most excited about are the ones where a technological constraint forced a process that never made sense to begin with. For fifteen years we sold purely on our sales team's capacity, not the buyer's, and told ourselves we were customer focused because of the product research we did. Nobody asked whether making someone fill out a form, wait days for a qualification call, then wait more days for an account executive, was actually the best experience. Remove the constraint, and the process it justified goes with it.