How Optimizely Climbed the Customer Education Curve

I'm thrilled to share another guest post from Adam Avramescu, who is head of the Customer Education program at Optimizely, the world's leading experimentation platform. The Optimizely Customer Education program is called Optiverse, where customers learn about more than how to use the Optimizely product features, and includes a knowledge base, academy, academy live, community, and certification. I met Adam at the Learning DevCamp 2016, happy to meet someone in a conference full of training professionals who also focused on training customers vs. employees.

Part 1: The Fix-the-Knowledge Base Team

​Before Optimizely had a dedicated Customer Education role, most help content was written ad hoc by various roles in the organization. The “no frills” Zendesk Help Center wasn’t parallel in terms of scope or tone.
What started as a “fix the Knowledge Base” task force quickly matured into a dedicated Customer Education headcount.

I will be forever grateful to the early leaders at Optimizely who began recruiting for a dedicated Customer Education headcount at around 50 employees. Because they saw the need early, we evolved past the “fix-the-Knowledge Base” stage into a more mature function that serves as a competitive differentiator and scale engine for the broader Customer Success team.

End Content Poverty

Perhaps no surprise for a 3-year-old, 50-person company, our documentation was far from feature complete. The early Customer Education task force did some analysis of the product features and wrote basic documentation to fill in the gaps. This wasn’t necessarily every minor feature or setting, but the major components of the product.

The feature documentation also wasn’t in the greatest detail. Taking a lightweight approach here allowed us to avoid documentation bloat and add content based on questions that actual customers were asking, not every edge case we could imagine.

This approach evolved into our “80/20” principle of documentation: document the common features, issues, and practices that 80% of your customers will find relevant, and leave the 20% edge cases and specifics out.

---

"The support team members
were solving the
same issues repeatedly..." 

---

​Highlight the “Head” Issues

The original documentation had different tone based on which agent wrote the article -- great for personality, bad for consistency. The “FAQ” didn’t have the most frequently asked questions, but just random questions that people had asked (personal pet peeve).
​
We found the support team members were solving the same issues repeatedly, so we prioritized making the most common support questions and best practices easy to find. We asked our Strategy Consultants and Technical Account Managers what best practices they shared over and over, or what they found themselves teaching customers most often. We turned these issues into FAQs and articles.

At this point, we had an article for each major feature, and special articles for the most common questions, issues, and techniques.

Lights, Camera, Action

Written content is great, but video works better in many cases -- especially for visual workflows that users can replicate. We created short video content for the most common and most valuable in-product workflows. Video content has a higher production cost, but articles with video tended to receive higher ratings, and were easier to understand than stepwise instructions. Some of those videos endured for years after they were first created, especially the ones that were more conceptual vs. describing specific UI components.

A few things that I think made our videos particularly successful in the early going:

• The videos were short and sweet. None of the original videos passed 2-3 minutes in length, which also forced us to focus on the most important information.

• We invested in the production quality, using a professional-quality microphone and editing to take out unnecessary clicks and movements.
• We also used a more friendly, inviting tone for the voiceover, while still keeping the videos tight and scripted. For example, we started the videos with, “I’m going to show you how to…” and ended with, “Happy Testing!”
• We only made videos for content that needed videos. No abstract feature tours for their own sake; we kept videos focused on workflows and practices that weren’t intuitive in the product UI.

A Little Something Special

You can’t do everything well. (We didn’t, and still don’t.) But my strong opinion is that you should find at least one way to differentiate yourself, measure it, and invest in it as a differentiator. For us, there were two: videos and “This Article Will Help You” sections.

“This Article Will Help You” is a concept similar to learning objectives in the instructional design world. Learning objectives entice the learner to commit to a learning experience by telling what they’ll be able to do. For example, “create an Audience in Optimizely using targeting conditions” is a good, practical learning objective, because it describes something that a customer can actually do. “Understand how audiences work” is a bad learning objective because no one needs to understand this for its own sake.

We still use the “This Article Will Help You” section today, and receive good feedback from customers that it helps orient them within articles.

Define Success
​
The final thing we did in the early days: define success metrics based on discoverability and value, but that is a story for another day.