To Tease a Future Feature or Not to Tease?

Should we let users know about upcoming features? Can it make them angry if you tease them and then underdeliver?

Let's find out.

My Bad User Experience with Insurance

As I work in the Insurance business, I am quite demanding of the user experience of insurance products I use in my day-to-day life. I have life & health insurance with a monthly premium payment. One day, I decided to change the payment frequency to pay once per year.

On a policy details page in my customer portal, which looks quite fancy, by the way, there is a button labeled "Change Frequency."

Fine, I thought, now I can easily change the payment frequency, pay for an entire year, and won't have to bother with it for the next 12 months.

I clicked the button and received a pop-up with a message stating that the payment frequency change is not available at this time but will be available soon. I can send a paper application by mail. Traditional mail.

I don't know how it works in your country, but in Poland, visiting a post office is a significant source of stress. There are not many offices, and usually, there are many people, so there are not enough workers to serve everyone quickly. To use a "priority delivery" with confirmation, you should write the destination address on two applications. On paper, by your hands.

Even though I'm exaggerating the whole drama, if I have a choice between continuing to pay monthly or going to the post office, I choose the less stressful option.

So, for the next several months, while paying a fee, I opened the customer portal, clicked that button, and hoped it would finally work. Each time, I made a payment and left frustrated.

Ironically, I work on the Insurance platform, which supports such functionality. But that specific insurance carrier used another vendor.

After nine months and nine frustrating accidents, while writing this post, I clicked and realized that I can now finally change my payment frequency online. Thank you!

Now, let's review such a case from the Product Manager's perspective.

Product Manager's Perspective

You don't have an important and desirable feature, but it will be included in future releases.

What you can do:

Option A: Create a mock UI component that will notify a user about upcoming functionality.
Option B: Don't mention a feature at all until it's ready.
Option C: Find a way to notify a user about the absent but soon-coming functionality without mock UI components

The digital experience team, who worked on the customer portal with my insurance, decided to proceed with Option A and the mock button. That makes me unhappy as a user, as I am teased with something and don't get it immediately. A product team thought that teasing such functionality would have amazed users. And make them eager to get one.

That may work in some cases. However, in some conservative industries (and insurance is a conservative one), if users don't get what they see, they become unhappy.

For me, interaction with insurance is always anxious. I want to accomplish tasks effectively and return to my everyday life. That non-working button, which had been inactive for nine months, wasn't a disaster, but it was enough for me to write about in a post.

I have a practical explanation about that mock button. As the UI design for that screen was ready, it was decided to implement it entirely without some capabilities rather than proceed iteratively.

As a product manager, I totally understand that. Iterative work with UX design requires additional effort for close and continuous cooperation between product, engineering, and design teams. When UX designers act as third-party service providers, they complete their work and move on to another team or product. That might be the case here.

Considering Option B, certain future features are so essential that we want users to know we are actively working on them. Additionally, there may be workarounds, and we want users to be aware of them as well.

In my example, there is an option to satisfy my needs in an offline way. It was good that they offered that option. However, I would not have known about it if it hadn't been mentioned. Without that, my user journey might be broken.

So, absence may cause frustration as well as unfulfilled expectations.

Option C is in the middle. We need to inform users that the missing functionality will be available soon and provide alternative solutions in the meantime. But handle it more gently with UX means.

A piece of text placed in the right spot on the UI screen is a simple yet effective solution. One-time notification with a short message or a few lines on the screen.

Users do not read manuals, and they 100% are not interested in public roadmaps of features (which is a debatable practice).

In summary, there are several ways to inform users about missing features and potential workarounds. Just let UX designers figure that out for you. But after that, you still must deliver.

Another debatable question is whether we should provide a timeline for when a feature will be available. Or let users guess how long "soon" means: weeks, months, years.

The answer is NO. Because here, a half-truth is better than lying about deadlines. Next time, let's talk about the fragile art of non-commiting.