[How to]Help your users get more value out of your product
Your paying customers want to get utmost value from your product. Don’t make them beg.
Some weeks back, my sister and I were discussing our plans for the day and she shared that she’d be heading to the bank to get her bank statement.
“Statement?” I echoed, somewhat surprised.
It turned out that she didn’t know that she could get a bank statement -signed and stamped from her mobile banking app. A visit to the bank wasn’t necessary.
This incident reminded me of my first job, where in addition to owning the marketing function, I managed enterprise accounts.
Our primary goal was retention and cross-selling. To achieve this, I reviewed the activities on their accounts weekly and had monthly meetings with the contact person to offer advice, collect feedback or walk them through new features.
It was in my role as an account manager that I realized that most users don’t know the full breadth/functionality/capability of your product. This would have been okay because users choose your product to solve a specific pain and sometimes, the full breadth of your product is not really that useful in solving this pain point.
The problem, however, is that the features they neglect are those that directly impact their ability to solve their most pressing problems.
The implication of this is that, if it’s a PLG product, they’ll churn after some time. If it’s an enterprise product, the users will report to the buyer and after some time, they’ll cancel their subscription.
To retain hard-won users, you have to think of an unobtrusive way to continuously educate customers about what they can do with your product [and this goes beyond the occasional feature release email]. The purpose of today’s newsletter is to show you how I attempted to do it.
Are your users content with the features they’re familiar with or are they simply ignorant?
In the last section, I shared a short story of my account management experience. What I missed out was that users frequently contacted me to ask me if they could do a number of things on the platform.
While I was happy to assist them, I noticed that it wasn’t scalable. As our customer base grew, it was increasingly difficult for our lean team to hop on quick calls to answer user’s questions. To solve this, I proposed we build a knowledge base. This only solved support issues but didn’t address the major problem: feature adoption.
Now, it might be tempting to say “Well, customers will definitely not use all of a product features” and I agree 100%. After all, that’s why we have pricing plans. But if customers are not using key features that help them accomplish a primary job, then there’s a problem.
The best way to explain it using project management software Trello.
Trello’s primary feature is managing tasks using cards. Now imagine that after adding new features like adding subtasks, assigning tasks to team members and adding due dates, less than 1% of customers use it, then it’s reason for alarm. Why?
These features are critical in ensuring users solve their primary pain point: managing their projects efficiently. Now compare it to another Trello feature, adding cover images to boards. If no one ever uses it, it’s no cause for alarm. Why? Because it is inconsequential in helping users manage their projects.
Here’s how to use the jobs-to-be-done framework [JTBD] to determine if you have a feature adoption problem [primarily caused because users don’t know these exist].
Contentment or ignorance?: Using the JTBD framework to decide
The JTBD framework posits that customers have this major objective or goal they’d like to achieve. This goal is independent of your product [and your competitors] even though it has the ability to help them achieve this desired outcome.
For instance, if you sell customer experience software, your customer’s goal is most likely to resolve support issues.
After you’ve determined what’s the singular most important thing your customers want to achieve [remember, independent of your product], you begin to think of “Needs”.
Needs here refer to steps that ladder up to the achievement of your primary goal. Again, needs exist independent of your solution but they are the logical order or steps that have to occur for the customer to achieve their goals.
Before I continue, I’d like to explain Jobs and Needs using an example from John Kalbach’s book, The Jobs to be Done Playbook.
Going back to the example I cited earlier [remember: Jobs: Resolve support issues] the needs will be:
Help customers resolve issues on their own
Get colleagues to help me resolve support issues
Reduce the time spent typing out responses to common support requests.
Now, if your product has features that help customers meet these needs and they aren’t using it, then it is not a case of contentment [we are happy with the features we are currently using. We don’t need all the extra stuff]. It’s a case of ignorance - customers don’t know these features exist. It’s your responsibility to find a way to let customers know these features exist*
So for me, here are two ways I knew that we had an ignorance problem:
Customers were unaware of new features. When I introduce them to the latest features, their eyes light up and they’re excited to try it out.
I received feature requests for functionalities that were on the platform.
*Please be careful. This is not a call to bombard your users with product [feature] education emails. This is critical if your product has a lot of features. To maintain balance/provide value, identify the top two or three needs that will help your customers achieve their primary objective. Then introduce them to your product features that will help them meet each need.
Here’s an example below.
How I solved the problem
In addition to setting up a knowledge base so that users can resolve issues on their own, I started a product education newsletter.
Every week, I sent out a newsletter that highlighted a product feature. A typical newsletter will:
Introduce a feature
Share the problem it solves [with adequate context. If you want to learn more about context, check out my swipe file where I explained it using Crayon’s feature launch]
Show customers how to use it [we used screenshots mostly].
Caveat
I started this initiative when I was early into my career - less than two years. I didn’t know enough to apply jobs to be done framework to it. I simply selected features based on the questions customers asked during my monthly calls and the latest feature.
Here are other mistakes I made:
I didn’t track or measure. I had a good grasp of the problem. Where I fell short was in communicating how we would measure the success or impact of this initiative. Thinking of it now, I should have pushed hard for the team to install product analytics software so I could have an idea of what usage was before and after the program [Yeap. it’ll surprise you to know the number of startups that don’t have product analytics software]
I didn’t track the impact of the help articles and because of it, I lacked actionable data to use and make improvements. If I could go back in time to redo this, I’d start by asking other account managers about the average support requests they received in a week. Based on this, I’ll set a goal of the number I’d like to reduce it to.
This will help me prioritize the topics to cover first and afterwards, I’ll come up with a strategy to encourage customers to use the help articles [trust me, customers who have your phone numbers will be reluctant to solve the most basic issues themselves], monitor traffic to the page and article ratings.
P.S. A knowledge base is outside the scope of this article, especially as it relates to helping customers get maximum value from your product. However, I added it to buttress my point that for every initiative you begin, you need to define what exactly you’ll measure.
Inspiration
If you’re getting started and want to see how other companies are doing this, check out Miro and Clearbit.
When creating this, remember, that distribution is key. Creating it and leaving it on your website/blog will hardly make a difference. Think of the right format, length and distribution.