AI adoption starts with the customer problem

On October 3, I joined the technology panel at Wharton’s MBA for Executives 50th Anniversary & Reunion in Philadelphia. The reunion brought together more than 700 Wharton alumni from around the world. As a WEMBA Class 43 graduate, it was a meaningful setting for a conversation about what comes next.

We covered AI adoption, cultural and leadership shifts, governance, guardrails, trust, cost, a data-first approach, and working backwards from the customer. These are my personal reflections on the themes we discussed.

Start with the problem worth solving

The starting point I keep coming back to is the customer. What are they trying to get done? Where does the current experience break down? What would a better outcome look like?

That gives a team something concrete to work backwards from. Selecting an AI solution first and then searching for a problem makes it harder to judge whether the investment is useful. A clear problem also leaves room for a simpler answer: a better process, cleaner data, ordinary software, or a different division of work.

Before discussing models, I would want the team to describe the problem in language a customer would recognize and agree on how improvement will be measured.

Get the data foundations right

A data-first approach means understanding the information a decision depends on. Which source is authoritative? Is it current? Who can access it? Who is responsible when it is incomplete or wrong?

For example, an assistant helping someone understand a policy needs to distinguish the current approved version from an old draft. Retrieving more documents does not resolve that question on its own. The organization needs ownership, access rules, and a way to maintain the underlying information.

I would start with the data needed for one useful workflow, identify the gaps, and make those gaps part of the delivery plan.

Adoption is a leadership responsibility

Introducing AI changes expectations about how people produce, review, and accept work. Leaders need to make those expectations clear.

Who checks an AI-assisted result? What skills does that person need? How much time is available for review? What happens when someone finds a mistake or decides the tool is unsuitable for a task?

Culture matters in those everyday decisions. People need room to surface problems and challenge an output. A rollout should include support for learning and feedback from the people doing the work. Tool availability is only one part of adoption.

I explore those questions further in What changes when managers lead teams using AI?.

Make governance and guardrails concrete

Governance becomes useful when a team can explain who is accountable and where the system’s authority stops. Guardrails should turn that agreement into behavior the team can inspect.

Take an assistant preparing a customer communication. Permission to draft is different from permission to send. An instruction in a prompt can express the intention, but the application must enforce the action boundary. The team also needs a way to investigate what happened and recover from mistakes.

The Fieldbook guide to retaining constraints uses a deterministic simulation to make this distinction visible. Retaining an instruction helps preserve context; permissions independently constrain actions.

Build trust around a defined job

I find it more useful to ask whether a system can be trusted with a particular task, under stated conditions, than whether we trust AI in general.

Define a good result, test realistic cases, examine failures, and decide when a person should take over. Make the system’s limits understandable to the people relying on it. Trust should have something observable behind it: the quality of completed work, the handling of uncertainty, and the ability to correct an error.

Count the cost of the useful outcome

Model usage is one part of the bill. Integration, data preparation, repeated attempts, review, and ongoing operations belong in the decision too.

A cheaper response can still leave more work for the customer or the team. I would compare the total effort required to reach an accepted outcome against the current process. The Task Cost Calculator offers an illustrative starting point for thinking through model, tool, retry, and review costs.

The questions I would take into the next project

The panel brought together themes that teams often discuss separately. I would bring them into the same project conversation:

• What customer problem are we solving, and what would count as progress?
• Do we have the right data, with clear ownership and access?
• What will change for the people doing and reviewing the work?
• Which actions may the system take, and who remains accountable?
• How will we detect mistakes and decide when to involve a person?
• What does an accepted outcome cost, including the work around the model?

Thank you to the Wharton community and my fellow panelists for the conversation. These are the questions I want to keep exploring through Model Fieldnotes: what useful AI requires from the technology, the organization, and the people leading it.