Turning a One-Product Training Request into Foundational Education

What was actually asked for, and what the request missed

The team wanted a course on one tokenization product. The need underneath it was broader.

The global sales enablement team asked me to build a course to make sellers more confident pitching a specific tokenization product. Tokenization at the company spanned several products, and sellers were being asked to position them without a shared picture of how they fit together. Building exactly what was asked would have added one more product to that picture without clarifying it, and that would have shown up in their ability to close deals.

Finding the real need

A needs analysis found two related products and a missing foundation underneath both.

Before designing anything, I ran a needs analysis. Sellers needed to understand two products, because both enabled tokenization but served different purposes and audiences. They also lacked a solid grasp of how tokenization itself worked. Selling the products well meant understanding the concepts that made them worth buying, and that grounding was not there yet.

That left me with a choice: deliver what was asked, or push for what the analysis showed was needed. I took my findings to the stakeholders and made the case for expanding the scope to cover both products plus the foundational technology. Training on one product would have left sellers unclear on how the two related, and any product training without the technical grounding would have sat on a shaky base. The bigger scope was approved, with tight constraints.

The constraints

Two months, no subject matter expert, a global audience.

I had two months for design and development. No subject matter expert was available for the build, so I became one. I spent a full month working through dozens of materials, including product collateral, to teach myself the subject. I had to learn both products, each aimed at a different audience, and keep the training globally relevant so regional details would not trip anyone up. Explaining tokenization to a sales audience meant turning dense technical material into something they could use.

How I changed the build process

Three process changes that outlived the project.

Storyboarding in the authoring tool. I moved storyboarding into the authoring tool and stopped writing separate Word documents, which cut redundant steps and sped up development. I also built a tracker to manage content gaps and hold subject matter experts accountable once their input was available.

One place for all feedback. User acceptance testing, stakeholder reviews, and other channels produced over 200 feedback items, so I pulled them all into a single tool. My team and I could then spot patterns across every source and act on them quickly.

Building what did not exist. I worked with our business partners to find and interview an end user who had sold a tokenization product to a major client and turned it into a long-term relationship, which gave sellers a real example to follow. I built custom enablement diagrams mapping the sell-in paths for both products, so sellers could see when and how to position each one. The two products had grown up separately and used different words for overlapping ideas, so I wrote an editorial guide to keep the training on one vocabulary.

Throughout, I worked with a full-time learning experience designer, coordinated with our outsourced project management team, and brought in colleagues for learner-centered reviews. I hit every deadline while running multiple review cycles at once.

What I delivered

One online module covering the technology and both products.

I delivered an online training module that gave sellers a connected view of the company’s two tokenization solutions. It started with the foundational technology, explaining what tokenization is and what it lets businesses do. It covered both products in detail, including how each fits different business needs and when to lead with which. The enablement diagrams showed sellers the paths to engage clients, and the case study showed how a peer had closed a major deal. Custom graphics made hard concepts clear, the editorial guide kept terminology consistent, and a quiz checked that the material stuck.

Screens from the module, the enablement diagrams and the editorial guide are withheld under client confidentiality.

Results

400+ completions, NPS 69, 62% confidence increase.

Over 400 sellers completed the training across global markets, with an NPS of 69 (a satisfaction score on a scale of -100 to 100). Completion was required rather than voluntary, and the full target population was never reported back to me — so this is a count, not a completion rate.

Sellers answered the same confidence question before the training and after it, and the score rose 62%. That is what the measurement covered. The business case was about closing deals, and I had no line of sight into deal outcomes after launch, so pre/post confidence stands as the proxy for it rather than the result itself.

---

What learners said:

“This is super useful as a start to learn tokens, very informative and I understand the difference between the two products now.”

“It is a great training, I learned a lot and plan to apply this knowledge to existing conversations with clients.”

What the stakeholder said:

“Your dedication and collaboration have been instrumental to successfully launching this initiative. For the first time, it provides sellers and clients with a holistic view of tokenization. A big thank you for going above and beyond to make this happen!”

Named references are available on request; client agreements keep titles off the page.