Growing Beyond a Viable Product to a Lovable One

Not an MVP, but an MLP

MVPs for Fast Hypothesis Testing

When you think of a high-performing startup, what comes to mind?
You probably picture a team that quickly ships and grows by defining sharp problems and solutions within a set sprint. They rapidly test hypotheses by implementing the minimum scope of features to discover user needs. The Alarmy team was exactly the same. Thanks to our culture of hypothesis testing through rapid implementation, we’ve been able to grow while accumulating a ton of diverse experiences along the way.

From a Cute Little Alarm Journey to a Massive Sleep/Morning Journey

As a utility app, Alarmy has historically grown by focusing purely on the alarm itself. The primary virtue in this cute little alarm setup journey was rapid feature implementation to validate our hypotheses. We drove growth through various experiments within a narrow scope, like brainstorming better ways to set an alarm or optimizing the checkout page.

Continuing its growth trajectory, Alarmy set its sights on a larger goal: evolving beyond just an alarm into a service that crafts a successful morning. New user journeys expanded before and after our core alarm setup experience, and we began designing new features. Users had to learn new functions beyond just setting an alarm and digest new information. A flood of information started pouring over them, creating a gap between what we wanted users to know and what they actually knew.
In particular, for users who were solely focused on the wake-up journey, the concept of a "sleep journey" was a completely unknown world. They didn't recognize why sleep was important for waking up, nor did they fully understand why sleep analysis was even necessary.

That’s when the problems began. Users started finding the features in our product difficult to use. And it wasn't just the users who were confused. Internally, our product specs started losing their clarity. Designing features that felt intuitive to users required much longer discussions than before, and teammates were left with a nagging feeling that we were missing something.

The Knowledge Gap in a Growing Product

This phenomenon the Alarmy team experienced—where a gap emerges between 사용자가 알고 있는 지식 and 제품이 이끌어 나가고자 하는 지식—is something we can all face when a product grows rapidly. As Jared Spool presented in "What Users Want," this disparity is referred to as the Knowledge Gap.

A knowledge gap is the distance between two points on a spectrum: current knowledge and target knowledge. Until now, we had been building features with only the target knowledge in mind. No matter how simple the interactions were designed to be, they were bound to be difficult for users without prior knowledge.
Alarmy’s core users are hyper-focused on waking up. In fact, they might be complete novices when it comes to sleep. They might not know why they need to use a bedtime reminder to secure enough sleep time, whether waking up during REM sleep makes them feel refreshed, or honestly, what on earth a REM sleep stage even is.
Recognizing this phenomenon forced the Alarmy team, who were so used to shipping features at breakneck speed, to hit the brakes.

Closing the Knowledge Gap and Growing With Our Users

If our previous focus was on rapid implementation, from here on out we needed to focus on ensuring users could keep up with our growing product without any knowledge gaps, even if it meant moving slower. Everyone started to realize that while focusing on identifying the user's real problems was a given (just as we'd always done), a lot more thought had to go into the process simultaneously. The Alarmy team has always been sincere about our users, but this time, we returned to our roots and began focusing on them all over again.

Strengthening Product Specs | Checking User Contexts, Needs, and Product Understanding

When designing product specs, we started detailing the user's context and needs around the problem much more thoroughly than before. Every teammate, regardless of their role, joined in the planning process with one mind to help flesh out the user persona.

Enhancing User Context Descriptions in the Spec Phase
To refine the target audience for a feature and define the essential scope of implementation, we began capturing the user's contextual background and weaving it into the product specs. We describe situations in detail—not just within the app, but outside of it as well. When it gets hard to describe things any further, we conduct user interviews to collect highly specific scenarios. The more precise our user descriptions became, the sharper our implementation strategies could be.

Target Audience's Product Proficiency and Understanding
After setting the target for a feature, we started evaluating what their in-product proficiency and prior knowledge needed to be. We began checking what kind of previous feature experience they needed to have within the product and what information they needed to know in order to use the new feature.

Step-by-Step Learning to Close the Knowledge Gap
Based on the target's product understanding and the impact of the problem, we started syncing on a roadmap for how the target would experience the ultimate value through specific steps. This naturally aligned everyone on the feature's final direction, and it became much easier to sequence the Product Backlog Items (PBIs).

Strengthening Validation | Usability Testing is a Must, Along With Various UX/UI Attempts to Close the Knowledge Gap

We also didn't forget that no matter how much we strengthened upfront planning, we couldn't neglect the validation phase. Based on our past experiences where new insights were continuously discovered during actual usability tests, internal testing became firmly established as an essential process. Designers found themselves iterating through tighter, more detailed design and validation cycles. As a result, we naturally secured internal time to mobilize various methods to aid user understanding. We started making more design attempts across interactions, graphics, and animations.

Our Team's Naturally Evolving Release Standards

There was a time when our internal engineering culture dictated that functional execution was the only standard for a release. Having learned many lessons while expanding as a service, the Alarmy team now knows that a release must be more than just implementation if we want to retain users. When launching a new feature, not only designers but also engineers actively discuss usability. We look at the product with the same level of passion—moving beyond just ensuring there are no functional bugs, to ensuring there are no flaws in the feature's ability to deliver value.

By focusing on the qualitative aspects of value delivery and satisfaction, we comfortably discuss even the subtle 'vibes' users might feel, paying closer attention to those qualitative details. Even after product implementation is complete, we take a 'maturation' period within the team. We briefly toss aside our roles as providers, immerse ourselves in the role of the user, and slowly reflect on whether we actually feel the value as real users. In this way, Alarmy's challenge to expand as a service has given us a clear operational direction: we must move beyond expected quality and strive for attractive, charming quality.

Ultimately, Moving Beyond a Viable Product (MVP) to a Lovable Product (MLP)

I believe that at every stage of a product's growth, the method for winning over users' hearts also changes. While Alarmy focused on baseline expected quality and determining the minimum viable scope in the past, our conversations have now expanded to the minimum scope required to satisfy value delivery. Today, the Alarmy team views our release standards not through the lens of 'is it minimally functional?' but 'is it minimally lovable?'

Fast delivery is important, but if it lacks value delivery, the product will just bloat meaninglessly. That said, we can't fall into the trap of obsessing over perfection for the sake of value delivery to the point where we never ship anything at all. We always have to find our own unique balance.

I'm sure many of you who have personally experienced explosive product growth have had similar experiences. If you'd like to share diverse stories with us, I'd really appreciate it if you reached out comfortably at bom@delightroom.com.
Or! If there are any designers out there who want to experience explosive growth and learn lessons together with us, please join DelightRoom :) We're always open to chatting about hiring opportunities!