The Work Before Enablement

I've come to think of enablement as less about teaching people what to do and more about understanding what is getting in their way.

It's easy to jump straight into creating content. Creating a course, a PowerPoint deck; it feels like progress. But those things only help if they address the problem people are actually facing.

Before building anything, I want to understand where the friction is.

Where are things breaking down?

Before building content, you first need to understand where things are breaking down. Sometimes the problem is knowledge. But often it's something else. It could be unclear messaging, a broken process, competing priorities, or friction in the product itself.

That's why I don't think of enablement as simply filling knowledge gaps. The work is figuring out what is preventing people from succeeding and then finding a way to remove that friction.

If you solve the wrong problem, even the best training won't change the outcome.

1. Start with the problem, not the content.

It's tempting to jump straight into creating content. But content is usually the last step, not the first. The first step is listening.

Talk to sellers, product managers, customer success, and customers. I need to understand what is getting in the way.

2. Design for behavior, not consumption.

Success is not someone finishing a course. The real measure of success is whether someone's behavior changes.

Maybe they are now able to explain the value of a product more clearly. Maybe they can now handle difficult questions with more confidence. The point is that something about how they approach their work should be different.

If the behavior doesn't change, it doesn't matter how polished the course content was.

3. Measure outcomes, not activity.

Attendance and completion rates are easy to report, but they are rarely the metrics that matter. I care more about whether onboarding gets faster, conversations get better, or teams feel more confident in front of customers. Those are harder to measure, but they're much closer to the reason enablement exists in the first place.

For me, that's where good enablement starts to look a little different.