I’ve been thinking a lot recently about the purpose of a product and how to successfully fulfill it. When writing last year about “product market flex” (which is fluid) vs “product market fit” (which is static), I noted that there is sometimes a mismatch between your product’s capabilities and the maturity of the market.
So what do you do if you end up in this mismatch of capabilities and maturity?
Well, this is the heart of “product work” (which is done not only by PMs but Design, Engineering, GTM, etc).
There are 2 strategic levers a product team has when this mismatch arises:
Reduce the effort required by the user to get value
Increase the literacy level of your target user base
Basically, you have to make your solution easier to use to meet your user where they are OR your pipeline of prospective users has to arrive at your product with a higher literacy level. And you can think of that latter bucket as “teaching users your product”.
In the past, I’ve broken down the user’s product journey into 3 simple phases:
not activated (zero usage of your product)
activated (superficial usage of your product)
sophisticated (high-value usage of your product)
You obviously want as much of your user base to be Bucket 3, because Buckets 1 and 2 are future churn, albeit different flavors. Bucket 1 is failure to deploy, while Bucket 2 is failure to ROI.
So “teaching users your product” is a critical churn-prevention tactic. But in a recent conversation with a group of CPOs, I realized that I was treating “teaching users your product” as 1 big job, and in reality there are potentially 3 sub-jobs hiding behind it. When you teach your product, you actually teach 3 different dimensions:
the interface - the components, objects, and patterns that make up your product’s vocabulary, allowing user’s to navigate and explore on their own and upskill themselves over time
the domain - the language of the field in which your user’s operate, keeping in mind that some people will need only basic phrases to survive while others need to be fluent to accomplish their goals
the benefit - the actual ROI user’s get from using your product vs a competitor’s product or their legacy in-house solution or a manual hack; when you’re teaching folks a new way to do the same job, you have to sell them on the change being worth it
And when you think about these sub-jobs in the context of the entire product surface, you realize that for your product, in your market, for your users, teaching certain dimensions is easier / harder via certain surface areas. The usual universe of product surface can include the following:
user interface
documentation
professional services
partner ecosystem
champion community
templates and tutorials
I’m still mulling over how to apply this framework in my day-to-day, but some early thoughts that I’ve been considering:
it’s really hard to invent and establish a new interface, so user’s will likely want your interface to conform to all the other tools they’re familiar with (this is known as Jakob’s Law)
you need to know the domain knowledge aptitude of every user that enters your product, which is another way of saying a one-size-fits-all onboarding journey doesn’t work unless it’s a well established domain
if people understand the domain but your interface lets them down, they will fall back to tools they know (i.e. everything ends up in Excel)
if the benefit is disconnected from the user’s problems, then you will struggle to get adoption (i.e. IT department pushing security / compliance tools that users hate using but are forced to go along with)
As always, I’d also love to hear from readers about their lessons with teaching users their product - please chime in via comments👇 or join the chat via the Substack app.
And if you enjoyed this post, please consider subscribing.
further reading / references
I’ve written previously about Product Market Flex
Upskilling users to leverage your tool is work - you can read more about this “literacy tax” in Death & Taxes in B2B
Skip Step SaaS is a mental model for finding and eliminating steps that require effort from your user
In addition to teaching users your product, you also have to change the orientation and operations of a team to take advantage of the tool - this is something I’ve spoken about in New Toolkit, Old Mindset
“Learning Isn’t Tolerated” and “Everyone Walks First Mile” are reminders of how B2B software is being consumerized and user expectations are evolving
you can read about Jakob’s Law and many others in the Laws of UX
childish drawing / interpretation
What are your thoughts on using in-app guides like checklists, tooltips, banners etc for feature education?
I love the images! Who is creating them?