What If a Designer Suddenly Gets Confused While Designing a New Feature?

Check if it's PMF Expansion

Alarmy has developed various features to make sure users wake up. Developing the Multiple Missions feature—allowing heavy sleepers who need more than just one wake-up mission to set several missions for a single alarm—was quite memorable. More recently, we built a Prevent Power Off feature for heavy sleepers who intentionally turn off their phones before going to bed.

Since about a year ago, we’ve been gradually releasing sleep-related features on Alarmy, starting with Sleep Sounds to help users fall asleep, aiming to expand our sleep journey. The Alarmy team had been running at full speed developing new features to wake people up effectively, as well as new features to help them sleep better. However, at some point, we started experiencing alignment issues among teammates when working on these new features.

A Confused Designer

When a PO registers a problem definition as a PBI (Product Backlog Item), the designer and the PO start putting together the product spec. Usually, if the PO provided the problem definition and a solution, the designer would work with the PO to figure out how to implement that solution. Product spec alignment on implementation methods used to always go smoothly, but unlike before, a disconnect started emerging between the PO and the designer. Design prototyping took much longer than expected and had to be redone repeatedly. Several new features went through endless cycles of design and usability testing, leading to continuous decisions to delay feature launches. After going through this process multiple times, designers started feeling that something was off.

It happens when the new feature is in a new domain

This rarely happened with new features aimed at waking users up effectively. But whenever we worked on new features within the sleep journey or post-wake-up journey, alignment issues inevitably arose among teammates, or the work took significantly longer than anticipated. Also, this often included cases that started from a solution deemed necessary for the business, rather than at the fundamental problem level.

We had different target users in mind

With our expansion into new domains, the scope of users Alarmy primarily handles had widened. Everyone understood that users experiencing sleep issues were using Alarmy to sleep better and wake up better. However, when it came to specifying the users' problem situations or needs, everyone had slightly different ideas in mind.

There are various ways to implement a solution

Solutions to solve the problem were proposed in broad and expansive ways, leaving a wide range of open possibilities for how to implement them within Alarmy's context. Everyone struggled to choose just one implementation method to move forward with, mostly because, as stakeholders, no one felt entirely confident in any single direction. Even when the designer brought in various designs, stakeholders had divided opinions. Everyone’s viewpoint made sense, which led to endless, circular discussions.

Clues Found During the Discussions

During a retrospective on these continuous failures, the designer pitched a thought to the PO: these tasks didn't feel like work aimed at feature implementation, but rather some form of preliminary phase. The designer shared that this felt like a prerequisite task for implementation, and that we needed to break the work down into PBIs so this preliminary work could actually lead to implementation. Even so, the question of why we needed this prerequisite work remained. We felt there was a hidden issue beyond just finding a more appropriate implementation method. The PO, who had been pondering this with us, shared an article, saying it perfectly described our situation.

Product Work Beyond Product Market Fit

This article posted on Reforge explained that once any product moves past the 0-to-1 phase and finds product-market fit, work can be categorized into four types. The part that caught our eye was the concept of "Product Market Fit Expansion." The PMF Expansion type of work involves researching and validating new market extensions for an already stable product. It was a new type of work where discussion and validation itself was the actual work. The most important part of this article was the following:

Expanding Product Market Fit. Is Not About New Features

Expanding product market fit is not about building new features

Yes, exactly this—we had been mistakenly treating this validation work as new feature development.

We were making the mistake of trying to build features by thinking about implementation first in the new domain of sleep that we were expanding into. We were moving purely out of habit, assuming it was just about creating a new feature like we always did. We were pushing ourselves to somehow ship features out in an unvalidated, vast open ocean, feeling the pressure to produce results.

I can't even count how many times the PO and I slapped our foreheads while reading this article. It was the moment it became completely clear why we were experiencing these issues.

Right, Alarmy's broadened domain meant expanding into a new market!!

Redefining Alarmy's User Roadmap

The Alarmy team realized that to expand into new markets, we lacked not only product-market fit but also a concrete definition of potential customers who actually have the problem. While everyone had a similar user group in mind, we started to understand why everyone’s detailed implementation ideas were slightly different: the implementation method changes depending on how you structure user needs and the product roadmap.

Amidst all this, what made me feel like the Alarmy team was truly well-aligned was that while the teammates were holding these retrospectives and discussions, our CEO was uncannily redefining the core target and resetting the product roadmap in the background. Right as we proposed a new work format through retrospectives at the working level, the CEO shared the newly redefined roadmap, beautifully resolving all this confusion.

Alarmy is sprinting toward the goal of expanding the journey from sleep to wake-up to post-wake-up, and within that, we have embarked on the new task of finding product-market fit in new markets.

The Road to Product Market Fit Expansion

And just like that, a new type of work was established within the Alarmy team. We are formalizing this process as a preliminary step where the goal isn't implementation itself, but rather deciding whether or not to proceed with a task—a process driven by extensive discussion and validation. Designers no longer have to feel anxious when an implementation outcome isn't finalized. We can now discuss various ideas with a sense of security, focus purely on the users, and brainstorm a wide array of implementation methods.

Moving away from the vague assumption that finding PMF only happens in the early stages of a product, Alarmy designers can now understand this new type of work and fully immerse themselves in discovering new markets. Beyond sleep, which is already underway to some extent, it looks like various validations will take place to uncover new journeys post-wake-up. While various trials and validations are important, what's even more crucial is designing a natural experience where these new journeys blend seamlessly into the existing Alarmy journey in context. Ultimately, I believe this will help us craft narratives for diverse users about why it absolutely has to be Alarmy.