Adding a caveat is rarely the right thing to do when talking about your product*.

It starts of with a good intention: you love the new feature your team has built (or maybe an old feature that people aren’t aware of) and want to tell current and potential customers about this new benefit. Simply describing the feature seems a little flat. A conversation with Marketing adds extra qualifiers, such as ‘real-time’ or ‘guaranteed’ to help reassure your customers.

Suddenly your feature unravels – it’s not necessarily real-time. Or guaranteed. Edge-cases, legacy systems and real life get in the way. All of a sudden, you’re questioning whether to put it in your collateral at all. What just happened?

Creating uncertainty with enthusiasm
Unfortunately, by adding an adjective to your innocent feature – you created this problem. Most features aren’t meant to cover 100% of all possibilities.

By adding an adjective or two, you’ve forced yourself to qualify the feature:

  • When doesn’t it work?
  • Are there cases when a customer might see or receive something unexpected?
  • What happens if you’re offline?
  • Is this now misleading?
  • Should these cases be ironed out before you talk about it at all?!

It’s a headache – and incredibly easy to get yourself into. I’ve been caught several times where edge-cases and good intentions dilute the strong message into a limp conversation.


Be confident about your feature
Relax – it’s a good feature, isn’t it?! You did your research and listened to customer and stakeholder feedback before you built it? Sure, maybe you hit a bump in the development road along the way, dealt with a software limitation or two, but your feature still delivers real customer value, right? If so, relax and be confident about it.

That little asterisk sows a seed of uncertainty that customers have been trained to question. If it looks too good to be true, it usually is, etc.
As soon as you add that symbol – you’re admitting that your statement wasn’t actually 100% true (even if it’s in a small and insignificant way). That’s the death knell to good, simple “quick wins” and the way to create a behemoth of a feature, which caters for everyone but pleases no-one.

Lose the adjectives
Why does your feature have to be advertised as the best, fastest, largest, guaranteed or your money back? Your customers are intelligent and are capable of making up their own minds whether your service is valuable to them or not. Leave it to them. The best services don’t need to claim they are the best in their collateral – people know it to be true (and stick around to become loyal customers).

Wait for customer feedback before you mess with it
If customer’s are confused, they will tell you.
Don’t preempt a question by adding a string of limitations or restrictions. Let them find it out as they use your service. If it really annoys them, they’ll say so – if not, you’ve just saved your feature looking weak (and possibly adding unnecessary edge cases to your backlog). Do measure everything though – knowing where customers are struggling is always valuable.

As you can tell, I think there are very few real reasons why a claim requires a star after it – if you find yourself doing it, stop and think if your description reasonably describes most (not all) users, and if so – leave it off.
What do you think? Are there cases when using a caveat is acceptable? Do you get frustrated when you find an advertised feature/price unavailable to you and hidden behind a pesky star? Let me know your thoughts.

*caveat/disclaimer/footnote/qualifier/condition – same difference! Did make you look for the the footnote didn’t I? Now do you see how significant a little * can be?

For a long time, Apple have had a rather childish view of negative App store reviews: if it’s broken, fix it and release an update. Period.

This works perfectly, if the only feedback your customers provide is general feature requests. But what happens if you’ve fixed the bug? How do you let the customer know? If you’re Apple, they say the app update will be sufficient. Yeah, right.

What do you do if you had server issues? Or worse, if the feature a customer has complained about is already there?

Again, if you’re Apple – not a damn thing. This has made app reviews on iTunes a 2nd-class citizen to Google Play (and that’s not to mention how many fewer reviews happen on iTunes, due to their UI choices).

Apple have finally agreed to allow replies to reviews in latest iOS 10.3 beta. About time!

With Apple, as always, there is a catch. Fed up with the constant ‘rate our app’ prompts, Apple will now limit review prompts to three a year. Great idea in principle, but surely they could start with something softer? It might also dampen feedback if customers & developers feel they only have limited attempts to leave a review.

Another example of ‘Apple doing it their way’ is by creating a new Review API (which allows in-app ratings, but not feedback).  This seems like a simple plaster rather than fix the mess of the iTunes store.

5 ways app stores could get right

After several years of running apps on the app stores, I’ve learnt first-hand the cut-throat nature that is a bad review. Here’s five recommendations for how app stores could improve this further:

1. Change 5 stars to thumbs up/down – 90% of all ratings are either 1 or 5 anyway and this is easier to understand (and gather an opinion on).

2. If reviews include swearing they should be removed – I don’t give a **** if customers are frustrated, that’s not acceptable language and swearing never helps. No excuses.

3. Form a score that includes more than just reviews/rating. Customers have a huge power through reviews at the moment, but they aren’t a perfect measure of engagement or even customer satisfaction. Active use per month; number of uninstalls or even number of emoji’s used – find better success measures.

4. Manage app reviews like customer service. Add a ‘resolved’ flag and provide the abity to send a private message to the developer for a short period before posting.

5. Add profile pictures (photos of real people) to give even massive apps a personal/community feelung. Nothing wrong with putting a face to someone – just make it non-discramatory and safe.

I hope you like my list – what are your thoughts?