Building a sticky product needs a "crawl, walk, run" tactic to succeed
Building a sticky product needs a "crawl, walk, run" tactic to succeed
"Everything Starts Out Looking Like a Toy" #108
Hi, I’m Greg 👋! I’ve written 100+ essays on product, data, and process for an idea or future product direction, often data between systems. What’s a key topic? System “handshakes”, the expectations for workflow, and the jobs we expect data to do.
Read more: What is Data Operations?
This week’s toy: A few #GoogleSheets for marketers that use GPT-3 models to make stuff easier, from remembering how to create Regex statements to building prompts from hashtags. We will soon be interacting in conversations with software, instead of just using features. Edition 108 of this newsletter is here - it’s August 29, 2022.
The Big Idea
A short long-form essay about data things
⚙️ Building a sticky product needs a "crawl, walk, run" tactic to succeed
When new users try out a product, they do not instinctively know how to achieve your goals. Even with great design, product adoption and documentation need to go hand-in-hand to ensure that new users identify how to get things done in a product and practice those skills until they become second nature.
One strategy to teach product basics is the “tell me, show me, let me try” approach. You might combine the tell and show aspects of a task by creating a screen capture video, but if someone doesn’t understand the building blocks of a task and the impact of making choices in your product, it will be hard for them to demonstrate mastery.
How do you measure learning?
The Kirkpatrick levels of learning is a helpful framework for considering the learning necessary to solidify product knowledge. This instructional design model, developed in the 1950s, classifies different levels of learning as follows:
Level 1: do they like the training - does the person have a positive assessment of the training activity?
Level 2: can they recall what they learned - after the training, does the person have the ability to recount the information correctly?
Level 3: can they apply their learning on the job - does the person gain the ability to apply the training in their job function?
Level 4: does it have a measurable result - does applying the training in context make a difference to the business?
Most training, documentation, or product adoption content never makes it beyond level 2 of Kirkpatrick’s framework, partly because applying something on the job is difficult to do when the training is only focused on orienting users to navigation or basic functions. Building competency in a product and measuring adoption is hard because adoption doesn’t necessarily correspond to success. If we think of success as identifying and validating the time to value for a specific task, one potential issue is matching the skill level needed with the steps required to achieve those skills.
Here’s an example: for a product that creates web pages, one of the first things someone would have to learn to customize the product would be to edit a finished page and save their changes under a new page name. Updating an existing page by updating a title or adding an image or updating text could easily give someone the feeling they had made a substantial change without a lot of actual work. There are many products where the ultimate goal is just to copy an existing template and make small changes.
Going beyond the basics
But what happens when the prospect wants to go beyond a template and really learn how a product gets stuff done? We need to teach them not only basic concepts but also the application of these ideas so that the prospect can “walk” or start doing things on their own. Creating a new item is different than customizing a template.
In our webpage editor example, this might mean building a new section on a page that doesn’t exist in the templates but is closely related. An intermediate user might be able to open an existing template and customize it, or start from scratch. “Walking” in this sense means mastering the concepts of the product enough to move beyond basic tasks.
The idea of “running” in the “crawl, walk, run” model is something else entirely. Succeeding in mastering a product really depends upon what the user wants to get out of the product and whether the product can deliver that outcome. A true expert can achieve any outcome in a product, or define why it cannot achieve the objective. In the example of our webpage editor, running might mean building a new template, or it might mean building a website from end to end. “Running” means fully self-sufficient and so comfortable with the world of the product that they can do whatever they want.
Documentation to support all levels
How can you possibly build documentation to support these things? A strategy I’ve found useful is to start with terms and definitions. What are the names of the features in the product, what do they do, and how can you find them?
Concepts are the next building blocks. What are the actions that you take with the terms and definitions in particular places in the product to get the result you want? Are there any dangerous things that you might do that will destroy data? Learning the key levers of the product will help you know how to create new ideas.
Finally, real-life scenarios put the concepts and terms into context. If you are able to take the equivalent of a word problem and execute those instructions in the product you are using all of these things on the road to product mastery.
What’s the takeaway? All prospects need the same things when they are new users. They need to understand where things are located, how they fit together, and how to apply them to get work done.
Links for Reading and Sharing
These are links that caught my 👀
1/ APIs are building blocks to platforms - The latest State of the API survey was released by Postman story, and a few things are quite clear. Organizations – particularly product and operations groups and SaaS product teams – are using APIs to bridge capabilities between platforms. And the teams that spend more time on APIs (and even more pronounced for those that are API-first) are getting outsized gains from this approach, according to Postman. One reason why this might be happening: 1lot easier and starting with handwriting.
2/ [x] get more done - if you’re familiar with note-taking and checklist apps, you might have a preferred format for keeping to-do lists, especially in a simple format possible in a code editor or text file. [x]it! is a plain-text file format for these checklists. What I like best about this format is that you can try it out without using the appropriate tooling, or augment your existing note-taking using this format.
3/ Should you use an AI copywriter? - There are a number of tools now that help with copywriting using machine learning or an AI process. Does it help or hinder your results? A survey of several tools suggests it’s too early to know, and that
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
Want more essays? Read on Data Operations or other writings at gregmeyer.com.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon