For many teams, launching a minimum viable product is approached as a beta test. You design and build the bare necessities from scratch, then iterate based on how users react. But what if you start with an in progress app and a user base that has been waiting two years for the launch?
Oh—and you have just a few months to make it happen.
That was our challenge as we worked with Sam Harris to design and develop Waking Up, a meditation course delivered through bite-sized content in an app. After his bestselling books and wildly popular podcast, Sam wanted to serve his audience in a new way.
We had some unique challenges from a development perspective, but as a whole, our main goal was delighting his patiently waiting audience. We knew that even an MVP version had to be exceptional, so that Waking Up was worth the wait.
With a 5 star rating in the App store from over 6,000 users, we were able to exceed some big expectations and learned valuable lessons along the way.
Defining the MVP experience
When I joined the project, our team had created great, new hi-fi designs to work with. But there were still a lot of choices to be made.
As we see it, there are a few ways to design a minimum viable product. You can try to build all of the features you want with minimal work, or you can release minimum features to maximize quality. We chose the latter.
The concern with delivering as much as possible is that it doesn’t allow design or development teams to do those things well. Compromises always have to be made somewhere in order to ship something quickly, and quality is too often the ingredient that gets left out.
On the other hand, minimizing features allows us to spend more time making each one successful. Building Waking Up wasn’t about doing what was viable, but about prioritizing features that would be loveable right away. Here’s how we did it.
Letting go of legacy
Starting with existing code, we could have approached the build in a few ways. The most obvious way would have been to simply build on top of what we already had. But as with many projects at MetaLab, we took a different path.
From the beginning, our team made the conscious decision not to get locked down by what we had or get attached to existing code. Instead, we approached each line of code as an opportunity to ask questions. This ensured that each feature and interaction was needed—and done exceptionally well. I was both writing and rewriting code, approaching any existing work with curiosity instead of attachment.
Adapting as needed
With a small team, we were also able to adapt our typical workflow. At MetaLab we work in sprints, which allows us to get user and client feedback quickly and test often. But with Waking Up, we had a small team who each knew the product particularly well. Instead of locking ourselves into the same sprint schedule, we’d start each week with a core goal and adapt as needed.
Going deep, not wide
Instead of thinking through the potential of each feature, we thought about how removing it would impact the app. If a feature could be removed without detracting from the experience, then it was removed. If a feature was essential to helping people accomplish their core goals, then we went deep into doing it well.
I was both writing and rewriting code, approaching any existing work with curiosity instead of attachment.
There are some great features that could be prioritized for later versions. Our goal was to ensure user's ability to listen to the lessons or daily meditations. It also would have taken much more time to have done it really well, and we only wanted to ship things that had been coded and designed incredibly well.
Instead, we focused on building out essential features like the media player. Users can now pause their lessons and pick them back on any device, download files, and meditate without disruption as it works in the background.
Going deep instead of wide allowed us to remain champions for the audience as developers.
Rewarding loyalty
Unlike other app launches, Waking Up was launching to two main user groups: existing supporters, and new fans who would discover Sam’s content for the first time. Sam wanted to acknowledge his existing supporters in a unique way by providing early access to the app and unlocking some of the paid content for them.
This was a challenge on the back end, but a non-negotiable for Sam. His supporters were part of the Waking Up community before the app even existed, and we needed to find a special way to welcome them home.
On the development side, this was both a challenge and opportunity. We didn’t want loyal fans to have to input a code, or take extra steps to create an account. To solve for this, we created two user flows and worked closely with Sam on content strategy to bring all the data together on the back end. Now, existing supporters will be recognized and given free access right away.
Launching an MVP is not about solving every problem. It’s about solving the right problems really well.
Designing a loveable MVP is within reach for any development team that stays focused on quality over quantity — even in a short timeline with legacy code.
If you’re ever faced with this challenge, here are our key takeaways:
- Align business goals and user needs
- Don’t get attached to code
- Focus on better features, not more
What I’m most proud of with Waking Up is that we kept things simple—even when that meant letting go of what we had. We could have hung on to some of the initial code and feature ideas, but that wouldn’t have honored the needs of Sam’s fan base.
can use today
