![636110236250565651-1646795078_post-it-note-Large[1]](https://theproductguy.files.wordpress.com/2017/09/636110236250565651-1646795078_post-it-note-large1.jpg "636110236250565651-1646795078_post-it-note-Large[1]")
Guest Post by: David Parmelee, Digital Strategy Consultant
As you study the people who use your product or might use it, patterns start to emerge. A marketer or market researcher may view patterns in terms of demographics and buying activity. A user researcher or other UX practitioner may group users by patterns in their behavior, both inside and outside your product.
Whether you consider your user base in light of market research or user research, both of these kinds of researchers use the patterns they discover to form personas.
User personas stand in for users throughout the design of your product. Each one has at least one goal and at least one pain point. Using a distinction from About Face, these goals could relate to their lives, the ends they accomplish in working with your product, or their experiences and feelings using your product. Realistically, they would have one or two life goals, around three end goals, and at least one experience goal.
Why bring this up?
Your users do not all have the same goals or the same pain points. Therefore, they would not use your product’s new features – or decide to engage with them – based on the same motivations.
Using personas to drive engagement
![personas-HEM-Blog-2[1]](https://theproductguy.files.wordpress.com/2017/09/personas-hem-blog-21.jpg "personas-HEM-Blog-2[1]")
The main questions to ask when you evaluate a new feature’s relevance to each persona are these:
1. Will this feature help this persona accomplish her goals, not just mine?
2. Will this feature help this persona alleviate her pain points, not just mine?
If a persona says no to both questions, users like her won’t care about this feature, even if you consider it your magnum opus or your product’s big differentiator.
Sad but true.
So don’t bother people like that persona about that new feature. Instead, tell them about the features that would cause them to say yes to those questions.
You’ll get more engagement that way.
Segmentation and automation
You might think that telling users about new features is all or nothing.
That might be how you’ve implemented it today.
If you have only one email list and your product doesn’t keep track of key differences between the users, you’ll have to implement it that way.
By having separate email lists or segments within your list, you can see where your real customers fit according to your personas. It also validates how accurate your personas are and lets you know if any are extra or missing.
You can send everyone on your main list a 1-question survey for self-selection to build those lists if you don’t want to do it yourself. Then email the smaller lists separately with content that is more relevant to them.
Continuous integration in deployment can involve feature flagging. You might be testing a new feature with a subset of your users, as Facebook frequently does in their experiments. In that sense, letting users know about a feature that they won’t see will just confuse them.
Users of your product have opted into receiving communications about it if your Terms of Use permit it. But they shouldn’t receive the same message about your new feature.
![Trivialpursuit-pie_3138286c[1]](https://theproductguy.files.wordpress.com/2017/09/trivialpursuit-pie_3138286c1.jpg "Trivialpursuit-pie_3138286c[1]")
First, it would be irrelevant to many of them. Your users are not a monolithic group, where each one of them is just “the user”. They have different needs and goals, and they use different parts of your product.
Second, sending everyone the same message means you’ll leave some of the engagement with your announcement on the table – even for the groups of people who would use the new feature.
Which message is more effective?
-
“Our app is now integrated with [Maps App X]”?
-
Or “We saw that you look at a lot of [Metro stations] when you use [Our App Name Here]. Now, you can get directions to [these Metro stations] faster in [Our App Name Here] because we’ve added directions from [Maps App X]. Check out how this can [persona goal: save you time exploring our city]!”?
Your product’s mailing list should use marketing automation to onboard and retain users. MailChimp and Drip both provide this.
Drip works differently because you only have one list, but you can set up workflows and rules to send subscribers specific campaigns within it. You could easily send users a campaign for a feature if they have visited a related area of your website or app.
Getting a slice of your users to listen
Persona fit is just one way to determine who would benefit most from a new feature. But it is theoretical, and no method is entirely foolproof. What other options do you have?
Listen to users’ feature requests
Anyone who requested the new feature you are building has at least thought about the problem that it solves. If you use a voting system (like Aha) to decide on new features to create, you can notify people that the status of a feature idea they voted for has changed.
Analyze patterns of use
Analytics tools may tell you which features of your product a user has used. Identify features in your product that help people accomplish similar goals to your new feature. People who have used these features may be good candidates to engage with the new feature.
You are not limited to only telling people about new features from inside your product. You can use email to notify inactive users who have used a related feature, provided they have not opted out of emails from you.
Consider which plans are best
According to Intercom, SaaS businesses can use new features as a great chance to upsell more expensive plans. If there’s a compelling reason why someone with a particular plan should upgrade to the next one up, tell them.
Use their words, not your own
A trick of great copywriting is listening. By saying your users’ words back to them, you show that you understand their problem, which led to the new feature you created. So reiterate the problem that your new feature solves, and articulate a benefit that they will find relevant.
Beware of too much noise
Don’t tell your users about new features too often. Give them a break between notifications so that they will seem more important.
![Annoying-noise-001[1]](https://theproductguy.files.wordpress.com/2017/09/annoying-noise-0011.jpg "Annoying-noise-001[1]")
This is like visual design: one item that stands by itself and is large looks important. A bunch of items that are the same size in a cluster or which are cluttered on the page won’t receive a lot of individual attention.
Make extra effort to connect on an individual level
Paul Graham tells startups, “Do things that don’t scale.” One thing that does not scale is sending personalized messages to your users. “Personalization” does not just mean an |*FNAME*| mail merge tag. Make a meaningful connection that shows that you really understand your recipient.
Tying new features into onboarding
When you tell your users about a new feature, your call to action should link people directly to a tutorial or onboarding tips for using that feature.
But to Stephen P. Anderson and Samuel Hulick, the feature should not be the hero of the story. Your users should be.
If your feature was designed well, it focuses on a goal of one of your product’s primary or secondary personas. To convince people that they should use it, tie the feature (and its onboarding) into a goal that they want to achieve. It could be an end goal related to their task – or even an experience goal or a life goal.
Rather than treating your product’s onboarding like a feature that you only release once, revisit it periodically. Do new features that you introduce necessitate a fundamental shift in how new users need to get to know your product? Does your onboarding evolve as you understand your audience and their needs better?
![AAEAAQAAAAAAAAw9AAAAJDdmZmFjZjNmLTJkNDItNDliMi05ZDI2LWViYWEwNGQxMTk3NA[1]](https://theproductguy.files.wordpress.com/2017/09/aaeaaqaaaaaaaaw9aaaajddmzmfjzjnmltjknditndlimi05zdi2lwviywewngqxmtk3na1.jpg "AAEAAQAAAAAAAAw9AAAAJDdmZmFjZjNmLTJkNDItNDliMi05ZDI2LWViYWEwNGQxMTk3NA[1]")
Reconsidering your onboarding may also give you ideas for refactoring the UI and the broader UX of your product, so that it becomes easier to learn and use. Instead of building a new feature in isolation, consider what people need to (or might) do before and after using that feature as they use it to accomplish their goals.
Telling users about new features
Release notes and email announcements are two traditional ways to tell users about new features. The following ways might be more effective.
Explainer videos
Some products use explainer videos to tell their users how to benefit from a new feature. This is more likely to work for a mobile app for consumers than for a desktop application for enterprise. Many organizations have IT policies which forbid their employees from watching videos over the internet while at work.
Landing pages
Features that address a significant pain point or a significant objection from new prospects should get their own landing page, following a Pain/Dream/Fix format. Include screenshots, videos, and sufficient copy to explain the benefits of the feature. Promote these new features in press releases and social media ads.
Webinars
Powerful features that go into a lot of depth are good subjects for a 20-30 minute webinar with a Q&A session.
A healthier organizational mindset for new and existing features
UserTesting recommends encouraging a research mindset in your organization or your client’s. In other words, consider new features to be a bad idea until your organization has researched the need for them and validated that the users will need them.
In this, let your personas be your guide.
But what if you could measure engagement with a new feature before you even design it?
Fake door idea validation involves creating a landing page to discuss an idea, buying ads on related keywords, and measuring how many users are interested in signing up. This strategy also works at the feature level. Create a stub in your product’s UI where a new feature would go, and measure how many people show interest in accessing that feature.
However, sometimes your best efforts at driving engagement in a new feature will not be good enough. Remove features that your users are not using, while being careful to not damage the user experience with other features. This saves you maintenance work, while also uncluttering your UI so that more of your users can discover better new features in the future.
Learn more about user research and designing from data
This article is adapted from content in UX for Development Shops: Declutter Your Interface, Design from Data, & Increase User Adoption & Retention. You may buy this ebook at https://davidp.io/ebook.
About David Parmelee
The Product Guy 