The Risks and Rewards of Delighting Users (or Attempting To)

Delighting users is incredibly hard. Most startups don’t even try. That results in boring (although occasionally effective and useful) web applications. Some startups try too hard and end up overloading their applications with flashy funkiness that doesn’t add any real value. They might get an A for effort, but they won’t keep users happy through a “shock and awe” campaign.

When you successfully delight users it’s magical. They love you, you love them, birds chirp beautiful music and the clouds literally part in the sky…

The rewards are immense. Loyal, rabid fans tweet shamelessly about how incredible you are, how valuable your web application is, and how successful your startup will be. Awesome stuff.

The interesting thing about delight is that it doesn’t have to be constant. Part of delight’s magic is surprise. Anticipation too.

Anticipation + Surprise = Delight

So you don’t need to delight someone with an “Aha!” moment every single time they use your web application. The experience overall has to be delightful, but there’s a difference between a satisfying, “Damn straight,” and a “Holy sweet mother of God that is amazing!” We’re talking about the latter here…

Digg used to delight a lot of people. Me included. I loved Digg back when this blog hit the front page 3 or 4 times within the space of a few months. It was insane. The traffic spikes were monumental. Server crashing. The spikes lasted two days at most, and very few people stuck around, but it was still awesome. Delightful in the truest sense of the word. (Valuable too, because a chunk of people did stay around, people linked over like crazy, SEO improved, etc.) Digg was delightful.

But then it stopped. Things changed. Doesn’t really matter why at this point, although their story is well-told and interesting. I think Sarah Lacy does a great job recounting that story in her post, RIP Digg. It’s less depressing than the title insinuates (and certainly not anti-Digg like a lot of what we’re seeing out there). The folks at Digg did some amazing things and I’m certain they will continue to. But one of the areas they failed was in delight. They stopped being delightful.

And that’s one of the biggest risks when it comes to delight. If you manage to find a way to provide an insane amount of delight (even in rare, short bursts – and in some cases, rare short bursts are better!) be very, very careful about taking that delight away. Or even changing it a bit. There may be legitimate reasons to change your product, which results in changing the delight factor, but it’s a huge risk. People are fickle. Blame the Internet (to a degree) for that. We move insanely quick, turning winners into losers in mere moments, moving with a powerful herd mentality. And your product goes from delight to downer.

It’s hard to recover from that. Add a second risk to the equation: Believing your own hype. That’s gotta be one of the single biggest killers of startups. Hype is often legitimately fuelled by delight. The more delight you create, the more hype you make. The more hype you make, the bigger your head gets. If your head gets too big, you can very quickly start making unreasonable, untethered assumptions and decisions. That can impact the overall perception of your startup as well as the quality of your product. And ultimately, affect the delight of your users and customers.

There are very few cases where you can argue against delighting users, or at least trying. But be careful just the same…


Interrupt Users to Increase their Adoption and Engagement

You want someone to use your product, then get in their face and force them to. I’ve made this argument before. One of the biggest challenges for any startup is engagement – acquiring users is hard, keeping them is usually much harder. And even when users say they love your product or think it adds value, it doesn’t always translate into significant usage and engagement. Why is that?

Generally people are enthusiastic and interested in trying new things, but they’re also lazy, comfortable, scared of change, and unmotivated. You can increase motivation by charging people – generally people will stay more engaged (at least for a bit longer) when they’ve increased their level of commitment. But for a lot of web startups charging out of the gate is unlikely.

Try interrupting users.

It’s something we’ve been talking about a lot at Year One Labs with our startups. How do you interrupt the daily activities of users in such a way that you become useful (and grow into a necessity) right at the very moment when the users actually need you?

Put another way: Your web application is going to require either a change of behavior or the creation of an entirely new behavior. Both are hard to do, and it’s foolhardy to assume people will change their behaviors easily. That kills a lot of startups. So how can you interrupt a user during a chain of behaviors they’re comfortable executing to slot yourself into that chain at the right place and right time?

There are some feedback loops that are effective. Social pressure is one. The more I see people using a certain product and/or talking about a certain product (this includes media, close friends, acquaintances, and others) the more likely I’ll try something a few more times at least. Email is another potential way of trying to increase engagement. But if you go deeper than that and inject yourself right into what people are already doing and interrupt them … it won’t really feel like an interruption, and it won’t feel like a bother … it will feel like you’re creating value at the exact moment when they need it, and you’re embedding yourself into users’ existing behaviors. Suddenly the change required, the leap of faith a person has to make in order to get value and stay engaged is greatly reduced.

Drill down into the use cases you think are right for your application. Write those down. Understand (or at least hypothesize) who is the right user who fits the use cases you’ve defined. Think: personas. Then figure out what those people are doing right now in and around the use cases you’ve defined. How are they solving or semi-solving the problems you’ve identified? What are they doing immediately before and after your relevant use cases? As you explore these ideas you may find opportunities to integrate with other applications and piggyback on their traction. You may find “sneaky” tactics for injecting yourself into people’s routines, which can greatly clarify your value proposition and minimize the demands you’re making on users.


Take Advantage of Users for Their Benefit and Yours

When you’ve got someone by the balls, squeeze.

Now think about your users and your web application. Are you squeezing ‘em?

Web applications typically do a very poor job of motivating users immediately after they sign up. Sign up for any web application you want and they generally drop you into a dashboard or timeline-like display with absolutely no clue what you’re supposed to do next. So you click around aimlessly, check a few things out, lose interest and leave. Now try getting that person back!

If you’re building a web application you need to show people what they’re supposed to do. Squeeze.

Once you’ve got someone into your web application and they start using it, they’re demonstrating a level of commitment. And considering most people only use a handful of applications a day, if they use your web application with any frequency (even early on) that commitment is pretty serious. So squeeze! Go for the ask and encourage (force?) your users to help you in some way. If your web application requires users to share things with others in order to increase usage and adoption then you have to ask them to share. More than that, you have to build the sharing functionality directly into the daily flow of your application’s use. Putting a “like” button somewhere doesn’t count. Get obsessed with viral loops and how you’re going to drive activity in your web application directly through its core feature set; directly through its core DNA. Laurent Kretz has a good article summarizing many of the tactics you can use in a social app for it to work. It shows you the extent to which you have to think about these things, test them and most importantly embed them directly into the daily flow of use for your application.

Just look how much effort retail stores go into when designing a location. And just think about all those little goodies they’re selling right at the cash register. Retail stores spend a lot of time on location design to maximize how much money they take from your wallet to put in theirs. Why should web applications be any different?

It’s better to beg for forgiveness than ask for permission. Mark Suster shares a great story about his own experience with that mantra. And I believe the same holds true with your users. Sure you don’t want to piss them off. And having them publicly complain about you is scary. And there are lines not worth crossing. But if you don’t take advantage of your users to your benefit and ultimately theirs (I’m not saying you should take advantage and not deliver the goods!) then you’re losing out.


Ben Yoskovitz
I'm VP Product at GoInstant.

I'm also a Founding Partner at Year One Labs, an early stage accelerator in Montreal. Previously I founded Standout Jobs (and sold it). MY BIO >>

Follow this blog via email

Advertisement
Startup Resources
A collection of posts I've written over time on key subjects:

Find Stuff
My Photos