There is a conversation happening in almost every SaaS boardroom right now, and it goes something like this: we have a product with real capability, customers who want results, and a widening gap between the two. How do we close it?

The instinct is usually to look at sales, customer success, or product for the answer. Someone needs to define the use cases, build the plays, and drive adoption. Those teams are close to the customer. They have the relationships.

But there is a team already doing this work — quietly, methodically, and with a discipline most go-to-market functions haven't developed. That team is customer education.

When Yamini Rangan recently wrote about the gap between AI output and AI outcomes, she named something that extends well beyond AI. The challenge she described — customers who have access to powerful capabilities but haven't translated them into results — is the core problem customer education exists to solve.

A use case framework is supposed to bridge that gap. At its best, it gives customers a clear path from "I have this tool" to "I achieved this goal." It aligns internal teams around what customers are actually trying to accomplish. And it creates a shared language for measuring progress.

Where most use case frameworks break down is not in the strategy but in the translation. Someone defines the use cases at the product or GTM level, and then the work of helping customers actually get there gets distributed across teams with different incentives, different vocabularies, and different definitions of success. Education becomes an afterthought — something that happens after the framework is set rather than informing how it gets built.

Customer education teams design for behavior change. Every piece of content, every certification, every learning path starts with the same question: what does a customer need to be able to do, and what does success look like when they get there?

That is precisely the question a use case framework has to answer.

Where a product team might define a use case by the feature involved, and a CS team might define it by the renewal risk it mitigates, a CE team defines it by the customer goal it enables. That orientation — goal-first, outcome-anchored — is exactly what makes a use case framework durable and scalable.

CE teams also have something most GTM functions don't: a structured process for figuring out what customers actually need to learn in order to change their behavior. They conduct needs analyses. They sequence skill-building. They know which parts of a workflow confuse customers, where adoption tends to stall, and what signals indicate a customer has genuinely internalized a new way of working. That institutional knowledge is foundational to defining use cases that hold up in the real world.

1. Start with customer goals, not product capabilities

The first job is to define what customers are actually trying to accomplish — not what your product can do, but what outcomes customers hire your product to deliver. This requires cross-functional input: data from CS on where customers stall, research on why customers churn, interviews with customers who have achieved strong outcomes. CE teams are skilled at synthesizing this kind of input because curriculum development depends on it. From this, you identify a set of core customer goals. These become the anchors for every use case you build.

2. Map the capability-to-outcome path for each goal

For each customer goal, the CE team maps what a customer needs to know, believe, and be able to do in order to achieve it. This is not a feature checklist. It is a learning and behavior change map: what existing habits need to shift, what new workflows need to be adopted, what proficiency looks like at each stage. This mapping also surfaces which use cases are genuinely learnable at scale — and which ones are more complex than the initial framing suggested, before a lot of GTM energy gets invested.

3. Define what "achieved" looks like

One of the most common reasons use case frameworks lose momentum is that success is defined too vaguely. CE teams are practiced at writing measurable outcomes: not "customers are using the AI features" but "customers have completed their first AI-assisted campaign and reduced content production time by X." This precision gives CS a clearer handoff, gives product a cleaner signal, and gives customers a more compelling goal to work toward.

4. Build content and programming around the use case, not the product

Once the use case is defined and the outcome is clear, CE builds the learning architecture to support it. This is where the content library, certifications, and in-product guidance get organized around customer goals rather than product menus. The same use case framework that guides customer success conversations becomes the organizing logic for the academy.

5. Create a feedback loop back into the framework

Use cases are not static. Customer behavior evolves, the product changes, and what was a stretch goal eighteen months ago may now be table stakes. CE teams, because they are continuously developing and updating content, are well positioned to keep the use case framework current — flagging where customers are consistently succeeding, where they are consistently stuck, and where the framework itself needs to evolve.

Repositioning CE as the team that leads use case strategy is not just an org chart decision. It requires a few things to be true.

CE leadership needs a seat at the table when GTM strategy is set — not after the framework is handed down, but during the process of defining it. The function needs access to customer data beyond course completion rates: churn signals, expansion patterns, CS conversation themes. And the organization needs to treat customer learning outcomes as a business metric, not a program metric.

The companies making real progress on closing the gap between product capability and customer outcomes tend to have one thing in common. Someone, somewhere in the organization is asking not "how do we drive adoption of this feature" but "how do we help our customers actually get better at their jobs." In most cases, that person works in customer education. The opportunity is to give that orientation more organizational authority.

Learning by Design is written by Courtney Sembler. Courtney currently helps companies build scalable customer education programs. After spending over a decade scaling HubSpot Academy globally, she now explores the systems, strategies, and realities of workplace learning, leadership, and customer experience—the kind that drives retention, adoption, and revenue by design, not by accident. Published twice weekly with monthly deep dives. Connect with her on LinkedIn and subscribe to Learning by Design.