“The only way to win is to learn faster than anyone else.” — Eric Ries, The Lean Startup
Fast-follow learning with search intent
After a product launch, you will likely be crossing your fingers hoping you got everything right — marketing, the signup flow, the upgrade flow, etc. But it’s much more valuable to obsessively find the things you got wrong.
Learning about and fixing these things will let you improve the product you inevitably built imperfectly the first time around. And uncovering them quickly means less time with a suboptimal product in the field and focusing your team on the most important fixes.
If you’ve built your product with a search bar, like CommandBar, you’ll start generating search logs from the moment you open the user floodgates. As we’ll discuss, in these logs you can discover search intent: what users are trying to do inside your product. In the days and weeks after a product launch, search intent gives you insight into two critical pieces of information you can use to fast-follow:
- Missing features
- User confusion
Help ShineSpot launch its new platform
In this article, we’ll take as an example the launch of a fictional new product called ShineSpot, an app for car wash businesses to manage their operations.
ShineSpot is launching its product for the first time.
What are deadends?
Deadends are searches that don’t end in a successful end-state (in CommandBar terms, an “execution”). Note that these are distinct from searches that produce no results. An unsuccessful search means the user didn’t find what they were looking for, not that they didn’t find any matches.
Terminology confusion
When you build a product, you have to create a vocabulary. If you’re building an API, you have to name all of your endpoints. If you’re building an application, you similarly have to name all the actions that a user can take in your product, from page names to CTAs.
Terminology done right helps users build a mental model of your app and how they can use it. And snappy terminology can also be great for product marketing. GitHub Copilot is a great example of a well-named feature - it's designed to help you code better, not replace you.
However, when you first launch your product, all your users will by definition be unfamiliar with your terminology. There will be a difference between how they conceptualize how they want to use your product and what you have called it.
For example, ShineSpot needs to describe the different pillars of its product:
- Branch Management = view key metrics about your branches
- Equipment = monitor the performance of your car wash equipment
- Supplies = check stock of key supplies like soap
But it turns out that previous car wash software apps had a dedicated page for “Restocking”. When new ShineSpot users fire up their app for the first time, they click around and search in CommandBar to find this section.
ShineSpot can see this gap in deadend data. As they scroll through their deadends, they see a semantic cluster around “Restocking” — terms like “restock”, “reorder”, “restock page”, etc.
As you spot synonyms like this, you can add them as synonyms in CommandBar so that searches for those terms will lead users to the right results.
Note that synonyms aren’t a replacement for a good product vocabulary. You’ll likely refer to your vocabulary words many times — across the app, in the help documentation, or in tutorials. To make sure users don’t rely too heavily on synonyms, CommandBar will always show the primary name of the command above synonyms in its results hierarchy.
A corollary of this is that you should pay attention to scenarios where a synonym dominates a command title. If this happens, you might even consider changing the name of the page or feature to map to how your users think about it. It is especially important to do this early after a launch, so users don’t get stuck on old terminology.
Discover missing features
When you launch a new product, you inevitably make prioritization decisions about what features to include in the v1 release and which to lazy load. Some of these decisions you will inevitably get wrong: features you thought you could lazy load will actually be demanded by your users. This usually happens because:
- (1) You attract different users than you expected.
- (2) Your users use the product differently than you expected.
Missing features are one of the most common discoveries hidden in deadend data. Users will often turn to search when they can’t immediately see their goal action in your app. You can then use their searches to pinpoint which features users want: either features that you know you needed to build or totally new ones you hadn’t thought of.
This feedback loop is especially important to cultivate soon after a launch. If your product is missing a critical feature, you’ll want to add it right away so you can meet users' needs, and ultimately convert and retain them.
We recommend the following loop:
- After launch, review your deadends daily.
- Identify missing features.
- Build the highest-priority missing features. Of course, this may not be straightforward. You may need to do further research, including user interviews, to fully spec out the feature the deadend suggested. In this sense, deadends are like shadows of a Platonic ideal feature.
- Alert users who searched for the feature (perhaps using a synonym) that you’ve shipped the feature.
This last step is especially valuable. You know exactly who is interested in this feature, so you can jumpstart adoption by marketing directly to those users. You can of course do this in the opposite direction too: whenever you build a feature, search your deadends to see if any users had indicated a desire for that feature via their deadends.
What about user interviews?
Deadends are not a substitute for user interviews. Instead, think of them as an extremely cheap and fast precursor. As noted above, some deadends will point to extremely obvious next steps: like a missing integration or a close synonym. Some won’t: deadends might indicate that users are trying to use your app for an entirely different use case than you imagined, requiring you to understand the use case in more depth than a few word fragments can provide.
As a result, deadends allow you to focus the aperture of user research. You can make obvious improvements fast without the lead time required to source research candidates, develop an interview plan, and summarize findings. For the less clear deadends, you can focus your research on adding resolution to make your next step clear.
If you want to chat with us about how to make the most of your search intent data, book some time today.
