When you work on perfecting your product, you are probably looking at your metrics, your users behaviors, and identifying missing features that you may add to the backlog to eventually get them done and launched to improve your product’s performance. There also is a great deal of improving on tops of existing features, but let’s focus for a moment on new ones.
Here is a brief description of what most people do in order to add new stuff:
- You identify new customer pains to solve
- You correctly prioritize the backlog to make sure you are doing what’s more important
- You do an amazing job designing the feature, making it usable and validating it through user testing
And then you launch! Congratulations! A moment later… absolutely nothing has changed. Sales didn’t grow, usage or engagement didn’t skyrocket, conversion has not increased… not even your grandma called to congratulate you on the new launch.
Are you familiar with this scenario? I certainly am. So what happened? What can I possibly have done wrong?
That time I did not communicate my awesome new feature
What I have found after some of this heart-crushing experiences is that doing a great job at communicating a feature is as important as the feature itself.
Let me illustrate with an example:
I have worked for a while with tourism mobile applications. We were working with the team on launching a new product funnel to sell a service we still didn’t have in the app but represented a good share of sales for the company on the website, so it was a pretty big deal and we expected to raise sales in an important percentage for the app.
Our home page for some time was a search box to find certain products, but we had a (controversial?) “hamburger button” that, when tapped, extended a menu listing some other features that the application had, like post-sale support and tools to use during the trip.
So we went the easy way: added a new row to the menu displayed by the hamburger button to access this new feature. Of course, you see where this is going. But please try to imagine our perspective at the time: we were all the time accessing that menu and it looked pretty reasonable to put it there. We even run usability tests that showed that the users found our new flow! But seen in perspective our tests were absolutely biased by our scenario creation that told the user “how would you buy X?”… the users pretty easily found that X was not on the screen, then opened the menu, found the service and bought it.
But, what about the users that didn’t even know we were selling X now? What about the users that would not have our user testing team telling them to find X? We definitely needed them to know up front when opening the app that they can now buy the new service.
How do we identify feature communication issues?
I would say that from any user flow / behavior analysis you should notice the problem: no one is accessing / using your new feature. That’s the easiest and ultimate indication that you are miscommunicating it. In the previous example we easily saw that we didn’t have a content, pricing or conversion problem: users that actually went into the flow were finding it useful and buying, it was just that not enough users were not accessing it.
There may be more subtle cases though. For example, we launched a “favorite” feature with which users were able to add services to a “wishlist” to access them later. The feature was displayed basically in all result pages, so from the point of view of “page access”, users were right there. So when they were not using it, the question was: are they not seeing it or is it just not useful? For this type of scenarios you can follow up with better thought user testing, or directly ask a massive amount of users in surveys, or even if it is not complex try to change the feature communication running some A/B test and see if it changes behavior.
How can I do better?
I would love to help you avoid making the same mistake, but actually making a good communication of a feature is almost part of the feature design itself and it depends a lot on your product, your users, and what you are launching.
In any case, I will try to give 4 tips just to feel I’m useful 🙂
- Let the users now in their first contact with your site/app that you have something new
This is a no-brainer, but many times teams (as mine!) may make poor choices on where to place the announcement. Another example for this poor decision would be adding your news in the home: for many sites, this would be a bad idea since most of the users come through google searches to particular landing pages and don’t even visit the home.
- For some time, use some kind of “new” ribbon
When you add something to an already crowded page or menu, use something to highlight it. A new ribbon, some animation when the user first sees it or any sort of highlight that works for your product.
- Include in your design phase a step to think about how you will communicate it
What I have seen over and over (as my example with the mobile app) is that the team just did not consider communication in the feature design, so when you’re reaching a deadline and just want to release all your work, you choose the easiest way. Make you sure you think about communication in the design phase, and you will certainly avoid this problem.
- If possible, add some off-site or not-in-app communication
Also something you may see all the time with great products you are already using: whenever you have something big coming up, that would be valuable to the user, just let them know through an email or any other sort of contact you have with them. In my case, I have found for instance that mobile push notifications were extremely powerful (it was just like an invisible force made the user open the app and test the new feature whenever we sent them a push).
Beware of “the recipe”
Just as I said, you can’t write a “recipe” for effective feature communication, simply because of the humongous variety of products and features that can be launched. Even for your product do not expect that the communication that worked for a feature will work for the next one. The best you can do is plan each feature with its corresponding “best communication plan” (or at least the best the team can think off).
In another product I was working on with my team, a kind of CRM, we had B2B clients that logged in regularly to work with it. Since we were going to be launching a lot of new features and we were a very clever team, we created a “reusable” feature communication banner that through configuration we would be able to turn on and off and change the communication text.
One of the first features we communicated using it was an incredibly important invoice system change, that we needed to make sure everybody knew. So we turned the communication banner on with a nice text telling users about the change, and we keep displaying it for every login for 1 month. Very powerful, and impossible to miss. What we did not envision was that, as with regular promotion banners, users learned to ignore it. So the next feature we communicated using that tool was absolutely invisible for users, they stopped reading this piece of news that after the first login said nothing new to them and added no value.
Final thoughts on product communication
In the first paragraph, I kindly requested to focus on new features. The reason for that is that I believe most of the work you do on optimizing existing features is actually optimizing communication and usability!
Think for instance in A/B testing: when you are testing the color of the button, the position of your subscription box, or even the text of a call to action you are actually working on making it more “visible/usable” to the user hoping to increase conversion, engagement, etc.
Of course there is a lot of work improving other things like speed or processes automation and many other areas of your product, but if you are working on improving the front end of a digital product I would bet there is a lot of communication and usability involved.
I have said a lot about how useful and valuable I believe communication is. But certainly something else to consider is that it is usually cheap. Implementing a banner, or a “new” ribbon may be extremely easy for your development team. Not to mention sending an email or a push notification. So if new analyze its “standalone” ROI it should be very high, and on top of that, communication may be the cause of making your “expensive” feature a good investment or a terrible choice. So as good metric driven Product people we are, we should always consider making good use of it!