Product Management Skills - Articulating adoption risks
If your users don't use your solution, then it won't drive value no matter how good it is (with one exception).
As a product manager, you have to be able to articulate, separate, and define your risks - the potential negative effects of whatever you are trying to do. Articulating them helps you frame and compare them appropriately - ignoring low risks and mitigating higher ones.
These are the levers you use and the plates you balance as a product manager to create and deliver value.
If your users don’t use your solution, then it will never solve their pain, even if it fits their problem space perfectly. You’re not powerless - you can drive forward adoption in many ways, from raising awareness to simplifying configuration. Just make sure you actually want usage.
Adoption risk
Adoption risk is the risk that your users don’t use your solution.
If you go through the trouble and expense of doing discovery, finding a meaningful problem to solve, and then releasing something with great fit that still doesn’t get traction, you’ve suffered from the negative impact of adoption risk.
What are some of the contributors?
Your users aren’t aware of your solution
It’s difficult to start using or use
You don’t actually want adoption
Your users aren’t aware of your solution
While you may think of the product you work on 24/7, your users likely don’t. For most products, only the most dedicated power users are keeping up with release notes and change logs.
To fix awareness issues, you have to have an effective go-to-market motion. If you’re lucky enough to have product marketing peers, great! Support them with collateral, explanations, ahead-of-time information, and keep them coordinated and informed of changes and releases.
If you don’t, you should roll up your sleeves and work on getting some of the table stakes of awareness in place:
Actually release it. Hilariously, I’ve seen some product managers mistakenly believe they released their feature when they hadn’t. They would fret over the lack of adoption and usage and wonder what they did wrong with extreme anxiety. A quick check and I had to point out that they never actually took the steps to enable the feature for the users - oops! Don’t assume it is released to users - verify it.
Have some way in the product itself to communicate a new release. This could be a “What’s new?” section, a notification or indicator when the user logs in, a highlight that makes a new button or navigation item obvious, or some other element that tells the user “Hey, I’m new - look at me.”
Write a “quick start” guide and share it. Talk up your new feature, describe step-by-step how to quickly get started, and some frequently asked questions you can think about. If your product has a support knowledge base, you can make a section for new releases and point users to it.
Ensure your internal teams are aware. Write up an internal explanation, with screenshot or video, of what the feature is, how to use it, how it works, and what the value proposition is for your internal teams. You want key teams in your company to be aware it exists - Marketing, Support, Sales, Account Management, Solutions, etc. can all drive adoption, but only if they know about it and can confidently answer questions.
Tell your users. In user interviews, tell them about the release. Personally send users you’ve built relationships with a quick email. Do a new release email blast at whatever tempo is appropriate for your situation. Post on social media. If you know specific users have sent feedback in the past about the issue, tell them directly that you’ve solved their pain!
Gauge interest before even starting. The best way to mitigate adoption risk is to gauge user interest before you even embark. You can do surveys, customer interviews, feedback analysis, etc. I like to do fake-door tests, where I add a button as if the functionality existed, and then track how many users opt-in to being notified of when it releases.
Make sure your awareness strategy fits the cohort
If you know your users are aware, but they still aren’t using it, audit how difficult it is to get started. Actually use your product and click through the end-to-end experience both from the perspective of a new user as well as a returning user.
Audit the UX from a new user perspective
New users should have a different experience than users who have been around for a while. Their goals are different, the foundation of knowledge they have are different, and what you want them to do is different.
Make sure your feature is appropriately positioned for new users. You may even want to not show them a new feature just to avoid distracting them from doing the things that make them more effective and stickier.
Ask the question - is your new feature appropriate for a new user, or does it distract them from onboarding?
An example
I one worked on a product that leveraged a lot of onboarding modals. Every time a new feature was released, they would create a modal announcement for that feature that would show to all users. Great for awareness, plus you can track the user’s interaction with the modal.
The problem was they didn’t maintain their modals over time, and weren’t careful to remove older modals that were no longer relevant. As a result, a brand new user would start seeing a new modal every time they changed the page.
The announcement stack may have been 30 modals deep. Any new feature release announcement would get drowned out in a sea of modals announcing new features from yester-years.
Relevancy was also questionable. All of our features were new features from the perspective of a new user - did we really have to disrupt the new user with an announcement of a feature they have no context on in the moment they should be focusing on their account setup?
I had the modals removed and banned their usage.
Audit the UX from a returning user perspective
A returning user has a larger foundation of knowledge you can build on. They’ve already completed their account setup, they may be using the tool regularly or relatively frequently enough to be able to introduce new concept and features to them to make them more efficient or stickier.
They are likely used to using the tool the way they are using it. This means that there’s an inertia acting against change - they may not want to see changes, or they may not go to the place where changes are being made.
Getting things in front of these users, possibly with engrained habits, is really about adjusting their habits.
Put the entry point close to the problem it is going to solve.
If your new feature is about automatic merging of duplicate records, don’t put them in some settings page - returning users would almost never see it since they’ve already set up their account, an very few users regularly check a settings page. Instead, put it on the page with the list of records with duplicates and highlight it.
It doesn’t have to be where it lives all the time, you just want to have users start using it, and the best way is to put it where they are already habitually looking.
A banner that says “Duplicates found, do you want to automatically merge them? Yes / No” that’s directly on the place where duplicates exist is going to be way more effective than a “Remove duplicates” button hidden in a dusty settings page.
Make a drastic change to force intentional thought
Frequent users are used to how your product works. On some tools, they may be on auto-pilot mentally, knowing exactly where to click, where to type. If you’ve ever looked at your users navigating your application, you can see them moving their cursor to a place where they know a button will appear before it even appears.
This means even if you add a new feature, they may not see it at all if they are on auto-pilot. It’s the fastest way to complete the task of whatever it is they are doing.
In order to raise awareness to these users, you need to apply some friction to break their habits. Move a button from its typical location. Change their initial landing page. Offset a navigation item. Whatever gets them to pause and direct their focus on the application to identify what’s changed.
Yes, it will likely irritate them. However, if the benefit is higher than the cost, it can be extremely valuable to create a little disruption for a future long-term gain.
Note: make sure you’re actually delivering user value. Changing an application just to change it is annoying, and too many changes can harm user efficiency and retention. Like all things, it’s depends on what you are balancing and trying to achieve.
It’s difficult to start using or use.
If your feature requires complex setup to be maximally effective, it a friction that reduces the likelihood of it being used. If you are trying to address adoption risk, simplifying setup and configuration removes one extra drop-off point in user adoption. Even raising awareness that setup has to be done, and providing simple guiding documentation can help drive adoption.
Improve the UX
The simplest thing to do is to make sure the user experience is streamlined. Work closely with your designer and prioritize the user experience during development. Ease of use isn’t always about optimization or increasing user efficiency - some things require a minimum bar of usability to even get started. At least meet the bar.
Add sensible defaults
Identify a set of configurations that works for most people, and automatically set that up for accounts. If a large portion of your users don’t need to set anything up, then that’s better than all of your users having to set something up to use your feature.
If you don’t have sensible defaults, you can still add an initial example of what the tool could look like to demonstrate its value, either as empty-state or an example the user can later delete or modify. If users see what the end-state looks like, it might encourage them to go through the trouble of setting it up.
Effective defaults can drive adoption. I once created a customizable bulk email segmentation feature to allow admins to send email blasts to targeted subsets of their mailing list - donors across the country. Our customers were widely varied - from religious organizations to educational institutions to special interest non-profits across hundreds of industries. There was no one-size fits all default. We released, and we just saw crickets. Nobody really bothered to set it up or use it, sticking instead to their standard of using spreadsheets.
I knew the feature was valuable, so I decided to create a set of five lists for all customer accounts to get them started:
All donors
Top 10% of donors
Bottom 20% of donors
Donors who hadn’t donated in the past 3 months
Donors who had donated within 3 months
Having functional examples was like a spark that lit the fuse. The simplicity and power was immediately evident to our users. Once they used the existing lists to try out the segmentation feature, they started configuring it to suit their needs quite rapidly - first by editing the existing lists, and then making their own.
You could see in the instrumentation that the first thing most people did was to use an existing list, which led to configuration, which led to comfort setting up their own lists, deepening user adoption.
Set it up yourself
Something I see a lot of product managers shy away from is doing the work of setting up an account themselves.
Yes, it can be difficult and time consuming. But providing white-glove service can help drive adoption of your feature. At the end of the day - you generally want your feature to be effective, and you should what needs to be done to support that.
Working with your engineering partners is extremely valuable here - they may be able to write a script to automate the initial setup for many people, reducing a friction point in adoption. If you incorporate that into your release strategy, you can significantly reduce adoption risk.
Note: Be willing to do things that don’t scale. It might mean sitting down with the user yourself, or working with support on a process for them to set it up for the users. Painstaking, time-consuming, but it can be very effective. Do what makes the product successful.
You don’t actually want adoption
Product Managers should never consider immediate and sustained adoption of their feature as the primary goal by default. In some situations, it’s actually quite a big mistake to do.
They should always consider what appropriate user adoption looks like. In many situations, user adoption behaves counter-intuitively, and measures like Daily Active Users (DAU) aren’t appropriate.
The feature is naturally only used sporadically
Some product managers see an initial spike in user adoption and usage that rapidly fades. They get despondent as the DAU or WAU trends downward, disappointed at the fact it didn’t seem to have sticking power.
Maybe it didn’t, or maybe it is a tool that naturally has periodic or seasonal usage.
I once worked on a document management tool for large expenditures. Think a review and approval process for permission to move tens and hundreds of of millions of dollars at a time. Document approvals happened in the last two weeks of every quarter.
Before and after that, there was zero usage of the tool. Zero. A Product Manager who didn’t think about the periodicity of usage would think that it had zero sticking power if they were only looking at the initial usage.
You need to zoom out and consider the seasonality.
The feature is not meant to be used very often
Some features and functionality can’t be measured effectively by usage rates or be gauge on its success by adoption.
For example, think of an audit log feature intended to track activity across an account and display it to the user. In this case, the fact that the capability exists is what matters - adoption is a secondary concern, if at all.
In the few times it is used (such as when a company has to perform an investigation of usage or traffic), having the capability available when it is needed is what matters, not that it is used frequently. You may even wish for a world where it doesn’t have to be used at all.
The feature shouldn’t be used at all
Some features and functionality can’t be measured effectively by usage rates. It may even be an anti-goal for it to be used.
A clear example is a “cancel subscription” feature. You definitely don’t want to increase usage of it. Measuring success on an increase on the number of times an account is cancelled is obviously counter-productive. Adoption in this case is an anti-goal.
Note: obviously, you should still instrument such a feature and use it as a lagging indicator of customer satisfaction, and there’s plenty of things you actually can measure, such as effectiveness of subscription save attempts that prevents cancellation.
It’s not always clear-cut
In certain situations, adoption as a risk is less obvious. Think of a feature that lets users export and download their data as a CSV. You may need to balance competing interests, such as:
Your desire to keep data in-house to aid retention
vs.
The user’s desire in slicing and dicing data as they needYour desire to keep users inside of the product
vs.
The desire of users to connect with other platforms to increase their effectiveness when using your product
In these cases - is adoption desired? Is adoption not desired? What does that balance look like?
Only your context will dictate the answer. An internet blog post can’t tell you that.
Tidbit: high, regular usage of exports that aren’t from departing users might indicate a missing capability within your product that users are making up for in another system, or the desire to have your data in some other system that is a core part of their value stream (eg. a CRM). It’s a signal - use it to learn more.
Adoption risk can be addressed in many ways, an Product Managers should ensure they keep in mind that it’s not the end-all be-all. Premature attempts to address adoption risk can also waste time - contextually-appropriate balance is required. Sometimes it’s more valuable to wait and see if you actually experience adoption issues before attempting to address the risk - risks are, after all, merely probabilities.