The problem with caveats*

td;lr: 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?