Alarmy woke you up for 9 years—now it helps you sleep

The story of shipping a "sleep well" feature in just 3 months

The Sleep Sound Launch Story (1): How did we ship it so fast?

0. Why Sleep Sounds out of nowhere...?

Some Alarmy users suffer from insomnia. Naturally, the harder it is to fall asleep, the harder it is to wake up in the morning. So while their characteristics are quite different from naturally heavy sleepers, they both share the exact same problem of struggling to wake up reliably—and they've been using Alarmy to solve it.

From DelightRoom's perspective, apart from number growth (increasing subscription and ad revenue), we were also thinking about expanding our value delivery: moving beyond just reliably waking users up, to waking them up feeling refreshed and invigorated. Rather than just haphazardly tacking on any random feature, we brainstormed ways to organically broaden our touchpoints with existing users. Ultimately, we decided to take our first step with a feature that helps them get a sufficient quantity and quality of sleep.

"Users fall asleep comfortably and wake up feeling refreshed!"

For Alarmy, which has functioned as the best alarm app for the past 9 years, I thought this might be the biggest change since the company was founded. That goes for the product itself, and for the users who have been using it. "A feature like this is suddenly added?" They might be confused, or they might be thrilled. Actually, our iOS app did have some simple sleep-inducing music for a while. We occasionally received positive feedback about it from users, so we felt more confident that they would be happy, and we kicked off the product planning.

And exactly 3 months later, Sleep Sounds was released to the world. I want to do a retrospective on what the Sleep Sound TF (Task Force) went through to deliver this value in just 3 months.

The Sleep Sound Launch Story (1): How did we ship it so fast?
The Sleep Sound Launch Story (2): What should we have been careful about when shipping so fast?

1. Narrowing down the problem to solve (What Why)

So, what kind of product specs should we draw up? We had a lot we wanted to do. But we needed to figure out what we had to do first.

1–1. First, we narrowed down the target user. Whose problems are we going to solve?

• All users who want to wake up feeling refreshed

• Users who want to wake up feeling refreshed but have trouble falling asleep

• Users who want to wake up feeling refreshed, have trouble falling asleep, and are already using sleep sounds somewhere else

The idea was to narrow it down to a target group large enough to make an impact, and then gradually expand from there.

We could have jumped straight to step 2, but depending on what problems they face, it could lead to far too many solutions (adjusting light brightness, blocking phone usage, sleep scents, sleep music, bed temperature, room temperature/humidity, showering, preventing late meals, etc...). We decided to be more razor-sharp and start by solving the problems experienced by users who are already using sleep sounds. Just like how Alarmy didn't offer a dozen wake-up solutions at first, but rather started sharp with "missions" to capture the hearts of early users.

1–2. Among the problems faced by our narrowed-down target users, we also narrowed down the specific problem to solve

Even if we just list out the problems our target users face, there are a ton.

According to our preliminary research, most target users were using YouTube, and they shared common problems. Among them were problems that were too technically difficult or too complicated in terms of product planning, where trying to solve them would likely take over half a year. Considering the impact of solving each problem versus the difficulty of doing so, we narrowed it down to exactly two problems.

• Users have a hard time finding sleep sounds that suit them.

• Users have a hard time falling asleep comfortably while playing sleep sounds.

Therefore, our target user story was narrowed down as follows:

"Users easily find sleep sounds that suit them and fall asleep comfortably."

2. Whittling down the solutions (How)

As always, the solution starts with defining the problem. Why is it hard for them to find sleep sounds? Why is it hard to fall asleep comfortably? Depending on how you define that "Why?", even with a sufficiently narrowed problem, the number of possible solutions at the ideation stage can multiply endlessly. So we broadly defined the problem as follows, and the solutions naturally fell out from there.

2–1. Users have a hard time finding sleep sounds that suit them.

Why is it hard to find?

• Because the content found on YouTube just isn't very good quality.

• Because the content on YouTube is okay, but it doesn't quite fit their personal taste.

Since we heard there are misleading thumbnails just to drive up view counts, this was basically a problem we could solve by filtering and sourcing only high-quality content. On top of that, we decided to tackle the issue of catering to personal taste via "Recommended Content." We didn't have first-party data yet, so we'd provide recommendations based on third-party data (view count, subscriber count, etc.) for now, and upgrade the recommendation logic later. Also, to make finding tasteful content easier, we wanted to provide a highly discoverable UI. There were other solutions like manual search or a favorites feature, but among the various behavioral patterns users exhibit during discovery, we decided to organize the content by "Categories," as it's the most fundamental.

2–2. Users have a hard time falling asleep comfortably while playing sleep sounds.

Why is it hard to fall asleep?

• Because they have to sleep with the YouTube screen left on (if they aren't YouTube Premium users).

• Because they can't set a timer for it to turn off right around the time they fall asleep.

If we provided our own sleep sound content inside the app and offered a timer function, these problems would naturally go away. However, providing our own sleep sound content with a built-in video player is a product spec that clearly requires massive effort just at a glance. To commit to that spec, we needed a much higher level of confidence in the problem (e.g., proof that they absolutely wouldn't listen to sleep sounds without it).

Since we decided to implement this via the YouTube API to get user feedback fast, we had to comply with YouTube's policies, meaning users would still have to sleep with the screen on in Alarmy. So, we decided to provide a feature that makes it feel like the screen is off even when it's actually on (let's call it Sleep Mode). How do we make it feel like background playback? There were many directions for this too, but we basically narrowed it down to lowering the brightness and displaying the time. We weren't even entirely sure if users would actually feel the efficacy of the screen "being off" in that state, but we decided to get feedback on that after launch. We also judged the lack of a timer feature to be relatively lower in priority, so we scrapped it from the planning and moved forward.

We narrowed down the target users and the problem, and whittled down the solutions. Now, all we had to do was run.

The things we couldn't include in the initial spec were still floating in front of our eyes, but we left them for subsequent iterations and kicked off design and development.

3. Delivering the solution fast (Shipping)

Looking back, excluding the planning discussions mentioned above, the actual design and development took just over a month. When I reflect on how the members participating as an "alt" (side gig) were able to work so fast while continuing to perform their "main" squad duties, I noticed 4 characteristics.

3–1. Properly outsourcing manpower

Among our solutions, "filtering and sourcing only high-quality content" was something we could get moving on immediately without depending on internal contributors. Furthermore, this was an area that required the touch of an expert with real insight into sleep sounds. By collaborating with a renowned content PM in the industry, we were able to supply over 1,000 pieces of content incredibly fast.

3–2. Properly utilizing external APIs and libraries

As mentioned briefly above, rather than immediately building a built-in video player, we opted to implement the player in a webview utilizing external sources. Naturally, this meant we'd fetch YouTube content via API and use it as-is, establishing a rough architecture of Back-office ↔ Server ↔ Client ↔ YouTube Server.

Because it was an external API, compliance with their policies was critical, and we also needed a clear understanding of what we couldn't get from that API. Based on this, we were able to solidly lay down the internal API specs and user flow structures right from the beginning.

(The API itself wasn't flawless, so the implementation process was tougher than expected. Also, the UI/UX we created while complying with their policies might end up being a bigger detriment to user experience than anticipated. These are the very first things to check post-deployment!)

3–3. Properly collaborating

Since everyone had a separate squad they were active in as their "main character," figuring out how best to collaborate was a headache from the start. It's a bit ironic, but we judged that the more it's a side-gig, the more frequently we need to sync. If we didn't, it was obvious it would keep getting pushed down in priority. Especially since this was a totally new feature starting from zero, we figured the margin of error would blow up massively if we ever fell out of sync.

Also, for asynchronous syncing, we decided to annotate not just the user stories, but all the way down to detailed use cases directly on the screen designs. Rather than just describing the design goals of each screen, we detailed every possible use case that could occur there. To some extent, user stories are discussed in regular meetings, but detailed flows or edge cases often require syncing up while the actual work is in progress. We threw question marks at each other on Figma and filled in the use cases together. Everyone only had to look at a single document, and by looking at that document, we could all picture the exact same user flow in our heads.

3–4. Properly running a lengthy QA

We confidently defined the problem and came up with solutions, but since we were basically hammering this together out in the middle of nowhere, some of our judgments might have been wrong. Before getting graded directly by users, we took the approach of using it ourselves internally. Even if we hadn't baked in all the product specs, we periodically built the app and ran internal QA to gauge what was needed more and what was needed less. And the effect was incredible.

Among the features the YouTube API didn't provide was a 10-second skip forward/backward function, which we originally decided to exclude during planning. We excluded it because users could manually drag the progress bar to jump around the playback—meaning there was an alternative flow. But when we actually used it during internal QA, I found myself instinctively double-tapping to skip back 10 seconds. The fact that it didn't work was a much more critical gap in usability than we thought, and funnily enough, every single member spoke up with the same consensus: "We absolutely need the double-tap to skip forward and backward by 10 seconds."

By properly outsourcing, making good use of external APIs and libraries, establishing a suitable collaboration process, and doing plenty of internal QA, we were able to deliver the product in under a month.

Of course, for all this to be possible, the individual hard and soft skills related to planning, design, engineering, and QA must be given as a baseline.
(But do I even need to boast about Delighters' skills in that regard...)

Honestly, the story so far is quite literally just about the "launch." This is only the beginning, and there are many hurdles left to overcome.

We need to check if the problems defined initially are being solved as intended, and we need various optimizations for metric improvement based on funnel data and the voice of our users. Also, we need to expand our product specs to solve the problems that weren't included in our initial definition.

Nevertheless, I think it's highly meaningful that we managed to lay the groundwork for all of this in just 3 months, acting as side-gigs while everyone simultaneously handled their main duties. I couldn't cover everything above, but there was so much to take care of when creating something from nothing—setting target metrics, internal API design, event design, localization concerns, content DB management, etc. All the members really worked their tails off.

We succeeded in shipping quickly using the methods detailed in this post, but there are already a lot of things we wish we'd done better. And moving forward, when we look at the data representing actual user responses, I guarantee those lingering regrets about our past choices will only multiply.

The Sleep Sound Launch Story (2): What should we have been careful about when shipping so fast?

Let's catch up on that in the follow-up!