The technology was never the hard part
By Scott Steinberg
A major study released last summer found that roughly 95% of enterprise generative AI pilots never deliver a measurable return. That’s not because of the technology, which continues to grow by leaps and bounds. Rather, most AI pilots fail because of the unfamiliarity of these efforts and internal resistance to change.
“Implementing AI in a business where you have to deal with staff dynamics, competing incentives and priorities is a mix of art, science and creative problem-solving,” says Pablo Landa, a faculty associate in operations at Kellogg and co-founder of the Applied AI Lab.
Getting new technology and new processes to stick inside a large organization has always been hard, and AI has only rendered it more complicated. Use cases, data and political or operating environments often differ widely from one company to the next.
“What we’re teaching is how to deliver that technology’s value for a business. It's not just about throwing money at AI subscriptions to say we’re using AI.”
With Anthropic, OpenAI and Microsoft having each launched applied deployment teams in recent months, and private equity firms and consultancies now hiring similar roles, industry leaders themselves recognize that great technology does not deploy itself. But almost no one is training for this function.
The new Applied AI Lab is built to close that gap. This fall, what began as a student-run initiative inside the Kellogg AI Club becomes a formal 10-week course co-taught by Landa and Benjamin Grant, clinical associate professor of operations. In it, small cross-functional teams scope, build and ship a working AI product for a company partner. Over the past two years, Kellogg students have built 28 AI products for company partners, and every company the lab has worked with has come back to work with it again.
“What we're teaching is how to deliver that technology's value for a business,” Grant says. “It’s not just about throwing money at AI subscriptions to say we’re using AI.”
The symptom is not the problem
The discipline the lab is built around starts by recognizing where expenses have moved.
“The cost of building software is going toward zero, but the cost of building the wrong thing and having to maintain it is going the opposite way,” Landa says.
That’s why the Applied AI Lab separates building from building the right thing. Students begin creating from week one and iterate constantly on projects. But their first task is simply to identify what the real problem is. Partners almost always arrive with a solution already in mind: an AI CRM, a recruiting agent, a tool they read about. But behind each ask there’s usually a recognized symptom and a hidden constraint yet to be identified. The team’s job is to find the second, which means mapping the workflow, interviewing staff, vetting data sources and putting a hard dollar figure on what the problem costs today.
The obvious answer is usually the wrong one. “It’s rare that we get into one of these engagements and the problem that partners came to us initially for is the problem that we actually ended up solving,” Landa says. “Once you start interviewing colleagues of the person that reached out, you see that the bottleneck is actually elsewhere.” Case in point: Last quarter one team discovered midway through working that the problem it had been assigned wasn’t worth solving at all, pivoted and shipped an entirely different solution.
Earning the next layer of access
Only once the client has agreed, concretely, on what a good, measurable result looks like does a team start building. What goes in front of the partner first is deliberately rough and early, because a prototype generates information no further round of questions can: watching a client react to something real is the fastest way to learn what “good” means to them. Running underneath all of it is the concept that the course is really organized around. AI implementation inside a company, Landa argues, is a series of credibility transactions. You don't get to build until you can credibly diagnose the problem. You don't get to scale the work until you can credibly build. And the solution doesn't outlast the initial limited-time engagement until you can credibly show that it will scale.
In practice that means someone must be convinced at every step, and who that someone is depends on the company. It might be an IT manager who controls access to the data. It might be a chief financial officer who wants to know what a solution costs. It might be a chief product officer weighing it against everything else her team could be doing. Understanding which door you’re standing in front of, and what evidence opens it, is paramount.
Students discover this quickly. Three separate teams came to Landa near the middle of last quarter with the same complaint: They’d scoped the problem, interviewed the partner, had a solution taking shape and then the IT manager wouldn’t provide crucial system access. “Welcome to Applied AI,” he recalls telling them. “This is the case for everyone trying to implement AI in a business. We must earn the right to the next level of approvals.”
What the course teaches isn’t just persistence. It’s the importance of providing hard proof and evidence. Teams build evaluation suites and cost analyses alongside the solutions themselves, so they can show sponsors what any given tool does, how often it succeeds and what it costs to run. The discipline underneath it all is using data to de-risk change for the partner.
Making the work outlive the engagement
The primary measure of success is corporate adoption, and adoption is decided after the students leave. So, the course’s closing stretch centers on documentation, making a business case and providing a handoff built for someone who was never in the room: An internal owner with the ability to keep developing, running and evolving the solution. “You can build the best solution in the world,” Landa says. “But if it doesn't get adopted, your work did not drive a successful outcome.”
“The cost of building software is going toward zero, but the cost of building the wrong thing and having to maintain it is going the opposite way.”
Student output is judged on its merits. One team built an agent that drafted the business cases a sales team had been assembling by hand for hours every week, pulling public sources, CRM records, transcripts and email into a single PDF. Another built an MCP server for a chief product officer whose customers wanted their own AI tools connected to his platform's data, delivering the working prototype alongside the architecture recommendation and the security analysis behind it.
A third worked with a VP of legal who was spending hours reviewing standard NDAs that did not need her review at all. The team built a one-click workflow that generated each document with the client's details already filled in and then filed it in the right place on the shared drive, fixing a second problem they had uncovered along the way. At the final presentation the VP told the team what she had said to her own staff the moment she saw it: “Can we build this for everything else?”
Who it's for
Each team of students contains three roles: A strategist who drives the partner relationship and keeps the engagement on track; an AI product manager who owns problem definition and product direction; and a technical product manager, or forward-deployed engineer, who owns technical execution. On a team this small, everyone builds the product and hones different skills. “You need to have some understanding of operations, some understanding of consulting, some understanding of AI and technical abilities and also have a builder’s mindset,” Landa says.
Grant argues that the technical bar has moved. “Domain-specific knowledge is as, if not more, important than being able to utilize a coding agent to deliver.” The rest is “navigating the personalities and different roles within an organization.”
Project diversity
The lab is deliberately open to all fields. This quarter drew more than 20 project submissions from 20 organizations, ranging from publicly traded software firms to private equity funds to VC-backed healthcare companies. “We’re agnostic to the industry or type of firm that we work with,” Grant says, “We actually want that type of diversity.”
The instructors are explicit that companies that feel behind are the point, not the problem. “It is a great opportunity for you to first see from a real-world engagement how these things work in practice,” Landa says. The door is also open to alumni offering sponsorship or mentorship.
Companies and alumni can submit a project request form or email the Applied AI Lab's instructors: Pablo Landa or Benjamin Grant.