'Customer-Centric'—Who Are Our Customers, Really?

Satisfying 50% vs. Wowing 1% of Customers

Many products emphasize the 'customer.' A lot of companies set "Customer-driven," "User-centric," or similar keywords as their core values and claim, "We put our customers first." But who exactly is this 'customer' we're talking about? I myself am a user of the products I build, so does that mean I can just make whatever I want? Or, if we conduct customer interviews and reflect the results in our product, does that automatically make it a 'customer-centric' product?

When discussing customer-centricity, one thing we must always remember is that "customers are not a monolith." The spectrum of users who use our product is incredibly broad. We have die-hard fans, but we also have customers on the verge of churning because they're disappointed. There are users who occasionally drop in to use just a fraction of our features, and those who use our product in ways we never even intended. With such a diverse customer base, who exactly should we be building our product for?

To phrase the question a bit differently:

• Should we build the product for the 'average' user vs. the '1% core user'?

• If you had to choose between satisfying 50% of users vs. wowing 1% of users, which would be the better choice?

A lot of companies answer this question by choosing the 'average' user. They add features that the general user base wants and market to a broader audience in a larger market. If there's a feature 10,000 users want and another that only 100 users want, building the former feels like the safe bet. Targeting 'average' users to create a generalized product that anyone can use seems logical at first glance. But is it really?

One of the most impressive things I noticed during my three-month onboarding after joining DelightRoom was how sharply the Alarmy service targets its 1% core users. Alarmy’s mission is to "Wake people up, fully and completely." In practice, the process of setting the product roadmap or making decisions on major features is strongly tied to this mission, and throughout this process, the 1% core users are kept right at the center of our decision-making.

Case #1. If you turn off your phone while the alarm is ringing and go back to sleep, whose fault is it?

When the morning alarm rings, most users turn it off and get out of bed. But heavy sleepers might turn off the alarm and fall right back asleep. (Sometimes they don't even remember turning it off in the first place!) With Alarmy, you have to complete a wake-up mission to dismiss the alarm, which prevents you from subconsciously turning it off and going back to sleep.

So, how do users cheat when the alarm is ringing (and they really don't want to do the Alarmy wake-up mission) and just want to sleep more? Some simply power off their phones entirely. (And they often don't even remember doing *that*, haha.) If you went to sleep trusting Alarmy to fully and completely wake you up, but you woke up to find you'd (subconsciously?) turned off your phone, slept in, and ended up late... whose fault is it? An ordinary company would think the product's job is done here. We built the alarm app and the wake-up mission feature; if the user goes out of their way to turn off their phone and go back to sleep, isn't that on them? What more could we possibly do for a 1% outlier user?

But to Alarmy, this user isn't an outlier—they are our 1% core user. This user is the 1% who genuinely struggles to wake up fully and completely in the morning, and Alarmy is building a product specifically to solve that problem. So Alarmy created a 'Prevent phone turn-off' feature. It was tricky to implement because it required forcibly intercepting the system dialogue, and it wasn't a feature that the majority of 'average' users necessarily needed, but we decided it would be incredibly meaningful for our 1% core users. (In fact, 'Please make it impossible to turn off the phone while the alarm is ringing!' and 'Please make it impossible to delete the app while the alarm is ringing!' are very common VOC requests we get.)

Unfortunately, with the Android OS 12 update, our implementation method for the prevent turn-off feature conflicted with Android's policies, so we've had to temporarily hide the feature. However, after stubbornly searching for a way around it, we'll soon be releasing a new version of the Android prevent phone turn-off feature! (Actually, an Alarmy user who absolutely loved this feature even gave us an idea on how to implement it!) Anyway, coming soon...

Case #2. What if preventing phone turn-off is technically impossible?

To implement the prevent phone turn-off feature, you need to be able to control the system dialogue behavior, which is technically impossible on iOS. We were constantly getting requests for the prevent turn-off feature from iOS users, but as the company building the product, we couldn't just invent a feature that overrides OS policies.

An ordinary(?) company would assume the product's role ends there. If it's blocked at the OS level and impossible to build, what more can we do? Furthermore, turning off the phone during an alarm is clearly an intentional action by the user—so it's not our fault! Right?

But Alarmy didn't focus on the technical constraint that 'controlling system dialogue is impossible'; we focused on solving the 'problem of turning off the phone while the alarm rings to sleep more.' Is there any way, using some other method, to solve this very real problem our 1% core users are experiencing?

The answer Alarmy found was to let users set their own penalties for the act of turning off their phones when the alarm rings. If it's technically impossible for Alarmy to solve the problem directly, why not help the users solve it themselves? With this mindset, we launched the iOS version of the prevent phone turn-off feature. If you use this feature, you set a self-imposed fine for failing to dismiss the alarm properly, and whenever an abnormal dismissal pattern is detected, the fine is actually charged to your linked card. (We even built a thoughtful process where you get a one-day grace period before the fine is charged, during which you can submit a defense to get the fine waived, haha.)

It's a weird(?) feature where you don't get any special rewards for not cheating, but you have to pay a fine if you do. Astonishingly, over 5,000 users have voluntarily signed up, registered their cards for penalty payments, set their own fines, and are actively using the prevent phone turn-off feature.

While 5,000 isn't a small number, considering Alarmy's DAU is over 2 million, it's less than 1% of our user base. You might wonder, "Do you really need to go that far for a minority(?) of users?" We saw it the opposite way: because this feature is absolutely essential for our 1% core users, we judged that it was worth investing the time and effort. (In reality, we poured quite a lot of resources into completing this feature! I heard the behind-the-scenes story from the PO in charge, and it was a continuous series of "We're really going this far??" haha.)

Case #3. How hard should the emergency dismiss mode be?

The wake-up mission I personally use is 'Take a Picture.' I have it set so the alarm turns off when I take a photo of my water purifier. So when the alarm goes off, I sprint to the kitchen water purifier, take the picture to complete the mission, and start my morning with a glass of water. But what if you're in a situation where you can't take the picture? For example, what if you went on a trip and forgot to change your mission, so you have to take a picture of the water purifier back home just to turn off your alarm?

To turn off the alarm in such emergencies(?), Alarmy has an emergency dismiss mode. It's basically a workaround to turn off the alarm through a different method if you find yourself unable to take your registered photo. The problem is that there are users who use the emergency dismiss mode to cheat. Without fail, there are users who, instead of doing their set mission (which usually requires getting out of bed and moving somewhere for photo or barcode missions), just lie in bed, use the emergency dismiss mode to kill the alarm, and fall back asleep.

If someone cheats like this, skips their mission, goes back to sleep, and ends up late for work... whose fault is it? Primarily, you could say it's the user's fault, but again, Alarmy doesn't give up on these 1% core users who struggle so much to wake up that they'll even resort to cheating. Haha. So, we needed to block cheating via the emergency dismiss mode as much as possible, ensuring these folks can actually wake up.

To prevent cheating through the emergency dismiss mode, Alarmy's emergency dismiss difficulty is set incredibly high. In emergency dismiss mode, you have to tap 4 randomly prompted tiles a whopping 500 times to turn off the alarm. Wouldn't even the users who intended to cheat wake up halfway through tapping the screen that much? (Legend has it that when it first launched, you had to tap it 1,000 times!)

Implementing such harsh conditions for emergency dismiss successfully reduced cheating, but it also heavily inconvenienced users expecting a normal(?) emergency dismiss scenario. "I'm not home right now so I can't take my mission photo, but you're telling me I have to tap my screen 500 times to turn off the alarm? I'm already fully awake..." Complaints from frustrated users slowly started trickling into our VOC.

Taking user feedback into account, we tweaked the difficulty slightly and released a new version. We reduced the tap count to 100 but increased the number of tiles to 9 so it wouldn't feel too easy. How did users react to this version?

While there were certainly users satisfied with the easier emergency dismiss difficulty, Alarmy's 1% core users expressed dissatisfaction with the lowered challenge. They argued that because it wasn't hard enough, they ended up using the emergency dismiss mode as a cheat to avoid doing their missions. We could have decided to wrap it up there, since more people were happy with the easier difficulty and cheating is ultimately the individual user's responsibility... but, as always, we couldn't just give up on these core users. Could we find a better alternative?

The second revision went like this: we kept the 100-tap count but increased the number of tiles to 25, and we strengthened the penalty so that the tap count increases proportionally the more you use the emergency dismiss mode. (For instance, if you use emergency dismiss mode once, it'll require 200 taps the second time.) It was a way to solve the problems our 1% core users face as effectively as possible while still accommodating the usability of light users. In reality, after deploying this update, the VOC regarding emergency dismiss difficulty dropped significantly.

Case #4. Hell-difficulty missions, do we really need to go this far?

If you hate moving your body in the morning but want to snap your mind fully awake, I recommend the high-difficulty Typing mission. Trying to accurately type out tongue twisters like "Sally sells seashells by the seashore" while your alarm blares guarantees you'll wake up.

Or, you can wake up and get your head straight by solving Hell mode Math problems, or tackling extreme-difficulty Memory games. (If you still manage to turn off the alarm and sleep after this, you are truly a master of mental arithmetic...) If you're someone who prefers physical movement, you can set a Squat mission with a generously high number of reps.

Before joining DelightRoom, while poking around the Alarmy service, I remember thinking: why go out of your way to create such extreme(?) mission options? Isn't that too much? But after joining, understanding the company's vision and mission, and reviewing the product spec histories of our existing features one by one, I fully grasped why these Hell-difficulty missions were necessary. I learned that Alarmy has been building a service that wows its 1% core users, and by solving the problems encountered along that journey one by one, we've managed to satisfy the remaining 99% of users as well. Come to think of it, a great example of this is actually preserved in our meeting room names.

To shout "customer-centricity" from the rooftops, you need a deep understanding of who your customers are and what crucial problems they are genuinely experiencing. Wouldn't a product that sharply solves a problem its clear target users desperately want fixed have a much higher chance of success than a product that just adequately solves problems broadly experienced by general users?

Because if you can wow 1% of your customers, you can satisfy 50% of them—but the reverse is impossible!