How We Turned Stress to a Product and Hit 1M Installs in 1 Year

15 min readApr 25, 2024

Happy Birthday, StressWatch!

A year ago today, we launched StressWatch, a journey that began during a particularly stressful time in my life. What started as a side project has evolved into a notable presence in the AppStore. Now, one year from its debut, StressWatch boasts nearly 1 million installs, and our original duo has expanded into an eight-member team.

This is the story of StressWatch.

How it all started

I was working as the Head of Product at a connected fitness startup, leading a team of approximately 30 people, including product managers, designers, and content curators spread across five different cities in China and the US. My responsibilities encompassed overseeing product strategy and delivery for the US operations, while simultaneously leading new product initiatives in both the China and US markets.

The demands of late-night calls, lengthy intercontinental flights, and extensive COVID-related travel quarantines — ranging from 14 to 21 days in a hotel upon each arrival in China — stretched me to my limits.

I can still recall this one sweltering summer day when I felt suffocated and breathless in the stifling New York City subway, my heart pounding alarmingly. Swamped by my work, I continued to push forward, neglecting my health.

Time for a change

The wake-up call came with my annual health check-up report. Around the same time, in early 2023, the company announced plans to downsize its US operations, but they needed me to ensure a smooth transition for an extra 2 months. I had always harbored the intention to start something of my own. It does not have to be something huge. Something modest that I could initiate on my own and tinker with on weekends. This shift in my full-time job created the opportunity I needed to begin exploring these aspirations.

Where to start

I was uncertain about where to begin, so I started discussing ideas with Patrick, a product designer who was on my team and was also impacted by the re-org. Together, we brainstormed potential products and areas of interest that we are both interested in and believed had growth potential.

We created a collaboration document titled “100 Bad Ideas”, and started throwing whatever ideas we can think of into it. We dug deep into every bits of our past life experience and crawl latest trends in tech trying to find that hidden brilliant idea.

Three weeks later, we had compiled nearly 30 ideas, ranging from small hardware gadgets and app concepts to student internship mentoring services and connected magic props. The document was a hodgepodge of everything, yet we struggled to decide which idea to pursue first. Some ideas were too niche, others presented significant technical challenges that were daunting for just the two of us. After another two weeks, our list expanded to 50 ideas, inching us closer to our goal of 100. But still no decision as of which one to pursure could be made.

I felt that we need to kick start with something first, anything that is manageable enough for us to have a quick win, even if it’s just a sense of completion. We needed a project small enough to help us navigate and become acquainted with the process of independently building and releasing an app. For me, it also meant brushing up on my coding skills; I hadn’t used Xcode in nearly a decade, and the last iOS code I wrote was in Objective-C, before the era of automatic memory management.

B Side — a nice little detour

B Side was the first idea that we worked on and the first product we launched. It is a vintage-style white noise player appina, designed to resemble a cassette player. We eventually picked the idea with the following criteria:

Feasibility: The product scope was small enough that we could launch it in less than four weeks. Anything longer posed a risk of delays
Personal Relevance: We were our own target audience. This direct connection meant we didn’t need to invest time and resources into understanding a new market. Relying on second-hand research reports could lead to misaligned product positioning, whereas we could immediately gauge if the product met our needs.
Validated Demand: There was a clear, proven need for the product, and we saw potential to enhance existing solutions through better design and a fresh approach.

We ran fast with it. While Patrick was plugging along on the design side during the holiday season, I had my Mac with me all the time and coded any spare moment throughout the day, in-flight, in between meetings. We also ventured out to capture sounds from various New York City locations like playgrounds and cafes, integrating these authentic sound effects into the white noise player.

Me coding in a bar in Shanghai while waiting for a friend

5 weeks later, (yes, even though it was small, we still slipped by a week.) we had a working product. To make the vintage skeuomorphisum design look real, we added 6 different layers to our buttons(if you are young enough to remember that era), the button press sound effects, the delay during the light up animation. We polished every last detail to perfection. It’s a charming little app that I found irresistibly fun to fidget with. (B Side is still available on the AppStore; you can find it here: https://apps.apple.com/ng/app/b-side-white-noise/id1667406977)

We launched it on ProductHunt and our studio’s social channels, hoping purchases would come in. Initially, there was a modest spike in interest thanks to our friends and family. There was a tiny surge after our friends and families first tide. And after that, there was nothing. After the first week, we barely made enough money to buy a pack of ramen noodles. What went wrong?

Continue or pivot?

After making a few tweaks and adding more sounds, and promoting it on social media, we saw no significant change in sales after three weeks.

Until we started talking with some of our test users and found out that the only differentiation we had from alternative solutions is the vintage cassette player design. But the core value our users sought is the sound, its quality and variety, as well as customization options like multiple sound tracks at the same time and some even mentioned spatial sound effects. Shall we continue? or end it and move onto the next idea on our “100 Bad Ideas” list?

The biggest mistake: we spent too much time crafting the finest details before reaching PMF (Product Market Fit).

The quick win: we successfully launched a functioning app. Patrick and I navigated the initial collaboration on design and development.

While at the same time, during the time that I got burnt out at my job, I started to use a couple of stress monitor apps. These apps were all using HRV from Apple Health as their source data and notify users when their stress level changes. HRV data is captured by Apple Watch every 2–4 hours during the day. I was fascinated by the fact that for a couple of weeks, I always received high stress level alert during 4–5 pm. The later half of each work day was usually the time that I felt most physically and mentally challenged.

As we struggled to expand B Side, the idea for an improved stress tracker app seemed to tick all our boxes according to our original criteria:

Feasibility: Reading heart rate data from Healthkit, re-calculate using a different formula does not seem to be too daunting of a tech job. (I was wrong until 2 weeks prior to launch day)
Personal Relevance: We are users ourselves and proven needs. I was very much a workaholic. And the scary thing is that I was not aware that I was burning out at work. Stress reminders was particularly helpful at least for myself. I would love to have something with a better design.
Proven Demand: Stress management was gaining traction on social media. Existing alternatives were overly data-centric, lacked intuitive interactions, and none offered great localization.
Design Impact: Design could help. My life is already filled with deadlines, OKRs, numbers, targets. I just don’t want another number. I would love something that is soft, upbeat , and cute to give me a tap on the wrist to remind me to slow down when my stress level gets high.

And in addition, we’ve noticed

Trending Topic: Stress management was gaining traction on social media.
Automated Data Logging: The Apple Watch automatically logs data, removing the need for manual entry.
Customization Appeal: Users enjoy customizing their Apple Watches with complications that enhance the aesthetic of the watch face.
Hardware Utilization: Users intend to make something out of their Apple Watch. Apple Watch is a great piece of hardware, but it needs great software to make good use of data captured. Apple’s Health app offers the only basic functionalities (they probably will stay that way to attract more developers to join their eco-system) StressWatch could be something complimentary.

Convinced that this was the right problem for us to tackle, we decided to shift our focus to developing StressWatch.

Meet StressWatch

What we achieved

Patrick and I juggled multiple roles while developing the product — handling design, coding, user recruitment, and crafting social media posts. We dedicated evenings and weekends to this project for three months. Three months post-launch, our efforts paid off with significant engagement: 65M impressions, 513K AppStore page views, 142K installs, and 8K daily active users.

What we did differently this time building StressWatch (aka lessons learnt)

Tech validation always comes first and done thorough
Continuous value validation
Don’t launch your product without an audience

Lessons learnt #1 Tech validation comes first and done thorough

While Patrick was working on the conceptual design of the key visual. I was head down with getting to understand the underlying theory of HRV and its relationship with stress. 10 espresso shots and a dozen papers later, I thought I crack the secret formula. And spent another day created our first tech demo.

Everything went well until 2 weeks prior to our launch. I was in the midst of finalizing the Apple Watch app when I discovered a discrepancy in the HRV level ratings between the iPhone and the Apple Watch. The Apple Watch only stores a limited amount of beat-to-beat heart rate data, but we needed data from the past 30 days to establish accurate HRV baseline ratings. This discrepancy necessitated a major restructuring of the Apple Watch app to enable data syncing with the iPhone app. I also had to create additional settings screens to help remind users and facilitate the data synchronization process.

During the research phase, the tech demo I developed focused solely on data retrieval and rating calculation, and I neglected to create a demo for the Apple Watch. This oversight resulted in an additional week of work when I had to make significant changes; these were so critical to the core experience that they nearly jeopardized the entire project. Even recently, a small number of users are still having issues syncing data between iPhone and Apple Watch. It’s crucial to have a working demo that validates the core technical components essential for supporting the key features. Early investment in thorough testing and validation is minor compared to the cost and impact of addressing major flaws discovered later in development.

Lessons learnt #2 Continuous value validation

Prototype, Learn, Change, and Repeat — Building a product is essentially testing a hypothesis. It’s crucial to question everything, accept that mistakes are part of the process, and gather insights along the way to inform subsequent tests.

We hypothesized that stress is a trending topic, particularly in East Asian cultures, but that there wasn’t a tool to remind us of our fluctuating stress levels. More than another numerical score, we needed a visual that was soft and spoke to the heart, like a trusted friend ready to offer comfort when stress levels rose.

As we developed our product, we engaged our users in multiple validation rounds to fine-tune our value proposition:

Round 1 — Visual Preference Test, the first round of test to make sure our design could convey the core design intention of a soft, upbeat and caring image and whether our target users could resonate with. Our initial design concept featured a night owl that constantly monitored the user and buzzed when stress levels increased. After presenting this concept to a group of our target users, predominantly women with high health awareness, their reactions were mostly negative. Comments like “I feel nervous when this owl stares at me” and “It reminds me of a horror movie” prompted us to rethink our approach. We aimed for a new design that conveyed warmth, softness, and tenderness. The revised concept introduced a bubbly character named Mr. Fizz, which visually represents the user’s stress level and changes its appearance as stress fluctuates. We presented both the original owl and Mr. Fizz to our test users side by side. The preference for Mr. Fizz over the owl was overwhelmingly clear, guiding us to move forward with Mr. Fizz as the face of our application.

Round 2 — Tech demo validation. This stage focused on ensuring the algorithm functioned correctly and covered as many corner cases as possible. As previously noted, our initial testing here wasn’t as comprehensive as it needed to be, which nearly led to the discontinuation of the product.
Round 3 — Putting them altogether with alpha testers, the rubber hits the road phase that the design and tech needs to work together. This reminds me of when building hardware products during PVT (production validation testing) phase when the look and feel of the design side (DVT design validation testing) merges with the nuts and bolts of the engineering side (EVT engineering validation testing). For our case, it’s much simpler. This is the phase where glitches and bugs can be discovered and addressed.
Round 4 — Public beta to prepare for the hype during launch.
Iteration 1 — Post launch Apple Watch app update. We had our first iteration 3 months after the launch with an overhaul of our Apple Watch app, introduced Mr Fizz to the watch faces where users can add it as their watch face complications as well as highlighting Mr. Fizz as the key visual inside the watch app. Our initial assumption that users have the need to decorate the watch face was proven true after we collected scores of feedback on social and AppStore ratings. Featured by AppStore in August, 2023.

Lessons learnt #3 Don’t ship first, build an audience first

Become friends with your users, build a community before shipping product

We actively involved users who participated in our validation tests in our core user group throughout the product development process. We kept this growing community informed about the latest updates, the challenges we faced, upcoming releases, and the science behind HRV and stress. This group, although small at about 200 members, became our dedicated fan base.

In return, they provided invaluable feedback, pointing out glitches in the design and issues they encountered while using the app. One user, who is also a product manager, went as far as to write a four-page review detailing potential improvements for the product. This kind of engagement proved essential in refining and enhancing our offering.

When we completed our first public beta test, we started an activation champaign in the group. For beta testers, if you could share your story using StressWatch on social and can collect more than 5 likes, you can have an activation code of life time free access. Here’s the tick of downloads after post launch.

Building a community before launching a product would help you gather first hand feedback of your user, cold start or maybe even build a bit of hype during launch. Building a community before launching a product not only allows for firsthand feedback from users but also helps overcome the initial inertia at launch and can even generate some pre-launch excitement.

Built for Growth — From day 1, we focused on how to market StressWatch effectively. How our social post and website should look like? What are the Key selling points, differentiators, hero user cases that we can highlight? We kept answers to these questions at the back of our head. What’s the user value of the feature? how can we sell it? are the questions we keep on asking ourselves when making key product decisions later during the iteration process. They kept informing us along the way when we designed and developed StressWatch. They became our guiding principles when making product decisions.

Build in Public —After completing the technical prototype, we launched a social media account on a platform called “RED.” We began sharing content about stress, the link between HRV and stress, and also started recruiting for a closed alpha test while building anticipation for our initial release. Initially, we were uncertain about filling our alpha test slots, but our concerns were quickly alleviated when our first screener survey received over 500 responses within 30 minutes of posting. We kept sharing with our community to-be-released testflight versions, latest product updates, and even some of our struggles, and hearing from our users gave us early and continuous feedback. By sharing the journey of creating and iterating on StressWatch openly, we build trust with our users. We have created 10 different user chat groups on WeChat to continuously engage with our users.

StressWatch v2.0

StressWatch v2.0 is now available! We’ve introduced the Actions tab, which highlights key biomarkers that could influence your HRV and stress levels. We’ve also added support for English and Japanese. Give it a try and share your thoughts with us!

Gratitude

A heartfelt thank you to all our friends and family for their incredible support. I reached out to many of my friends who own an Apple Watch to test our product. Your patience and feedback have been invaluable. Our group of early adopters was wonderfully supportive (and courageous) in trying out our preliminary version of the product, providing us with numerous test cases that helped us identify and fix several significant bugs before launch.

I am also immensely grateful for the support and opportunities provided by FITURE when I was just starting out. Their backing allowed me to bring StressWatch to life as a side project.

About 100 Bad Ideas

“100 Bad Ideas” is the name of the online document we used to compile our product ideas when we first began. While brainstorming the name for our studio, a friend stopped by, glanced at our screen, and pointed out that our studio’s name was already there: “100 Bad Ideas”!

Yes, we will keep trying out our next bad ideas. And we promise you that these ideas will be made real to solve a meaningful problem with beautifully crafted products no matter of its form.