Internal Enablement

Launch checklists existed long before anyone called this internal enablement. They just covered what the product needed in order to leave the building. Someone tracked whether the code was deployed and whether the help article was written, but whether the people selling the product and the people answering tickets knew what had changed belonged to nobody.

The gap always showed up in front of a customer. Two weeks after Pagedeck shipped per-document permissions, Sofia told a prospect in the middle of a contract review that the product didn't support it yet. Permissions were the condition that prospect cared most about, and the meeting ended with them saying they'd take another look at a competitor. That same week more than ten support tickets asked about the feature, and every reply was some version of "let me check and get back to you." A feature that took two months to build was treated as nonexistent at the moment of sale.

Internal enablement is what happens when that gap gets a name, an owner, and a date. It starts as one line added to the launch checklist, the list of things that have to be finished before a release goes out: can sales and support explain this feature?

The work moves through five steps — write down what changed, translate it into something worth saying to a customer, attach answers to the questions that will come, deliver it in a real session, and check that people can actually say it out loud.

1. A change summary. One page covering what changed and how. The screen before and after, which pricing plans are affected, and the date it takes effect. Handing over the engineering spec instead leaves the reader to dig out their own talking points.
2. The customer-language version. Write down which customer's problem this solves. Not "we now support per-document permissions" but "for the teams who asked whether legal and sales could share a document library without seeing each other's files, the answer is now yes." The first is a feature list. The second is a sentence someone can say in a meeting.
3. Expected questions and answers. Does the price go up, what happens to settings that are already configured, when can customers start using it. Questions nobody can answer yet get written down as unanswered, with the name of the person to ask. Unlike a frequently asked questions (FAQ) page, which customers read, this list stays internal.
4. The session itself. Thirty minutes or so, with the real screen on display rather than a slide being read aloud.
5. The check. Ask one or two attendees to explain the feature on the spot while someone plays the customer and asks questions, and watch for the point where the answer stalls. Skip this step and attendance becomes the completion signal.

After that, put the material somewhere search will find it and include that address in the announcement. Three weeks later people go looking for the document, not for what they remember.

The product marketing manager (PMM) usually runs it. Positioning and launch communication already belong to that role, so the content is largely in hand. The product manager who built the feature supplies the substance, and sales and support sit on the receiving side.

The two receiving teams need different things. Sales wants language for people who haven't bought yet: which kind of customer to raise this with first, and where the feature fits into the objection handling material that answers the reasons prospects give for saying no. Most of it ends up in the sales playbook. Support wants answers for people already using the product — where the setting moved to, and what happens to configurations that exist today.

Timing lands one to two weeks before release. Any earlier and the feature changes again, so the session runs twice. Any later and there's no time to build answers to the questions the session surfaces.

How much effort goes in follows the launch tier, the grade that sorts releases by how loudly they get announced. Enablement uses the same grades. The top tier gets its own session, written material, and the check. The middle tier gets twenty minutes bolted onto a standing meeting plus a one-page question sheet. The bottom tier gets a link to the release notes. Book a session for every release and people start skipping the invitations, and then the session that matters is half empty.

"This one's tier 1 and enablement isn't scheduled. I'll grab thirty minutes on Thursday."

A release the team decided to treat as big is missing one of its preparation items.

"I'll bring it up with customers once I've had enablement."

Not ready to answer yet, so the feature stays out of sales conversations until then.

"Support has had it, sales hasn't. Who takes the questions if they come in?"

Only one of the two teams is prepared, so it isn't settled where incoming questions should go.

At Pagedeck the enablement date gets set in the same meeting where Mia confirms the launch tier, two weeks out. Mia drafts the change summary and the question list, and Sofia reads it and corrects her: that question never actually comes up, this one does instead.

One time the check at the end produced a question nobody could answer — whether customers on the current plan could use the feature at all. The material said it was limited to the higher plan, but when and on what terms existing customers would need to upgrade was blank. There were four days before release, which was enough time to write the answer. Shipped as it was, the question would have first come up during a contract negotiation.

The most common mistake is counting an announcement as enablement. The change went into the company channel, so it was communicated — and from the poster's side that feels true, because the information really did go out. But a channel post reaches whoever was reading the channel at that moment, and even people who read it are some distance from being able to answer a customer's question. Let it stand and the same questions come back to the product team for the next two or three weeks.

Aiming only at sales is the other one. The word enablement suggests sales collateral, which makes the narrowing easy. In practice more questions about a new feature come from people already using the product than from people who haven't bought, so leaving support out stretches ticket response times the day after launch.