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.
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.
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.
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.
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.
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.
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:
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.
Some tips on how we've made remote work, work for over a decade.
Forget budgets and milestones. It was just us, the Pitch team, and a whole bunch of unconventional ideas. Read on to find out what happened next.
How “human” is human-centered design? We open up about vulnerability, mental health, and how embracing the messiness is critical to human-centered design.
In this edition of Ask MetaLab Anything, we chat about culture, how we make it work remotely, and why we take our "no assholes" policy so seriously.
We make interfaces for some of the world’s top companies. But we don’t all do it from the same office. Here’s how our distributed teams work together, apart.
For our first edition of Ask MetaLab Anything we connect the dots between research and design.
We helped Pitch give presentation tools a modern makeover. Here's what we learned about Figma in the process.
Think remote work is less than ideal? Here’s why you’re right (and so, so wrong).
In the second edition of our Ask MetaLab Anything, we share how our design and development teams work together.
What we learned from designing in three dimensions for the first time.
We're pulling back the curtain and answering all your questions about product design. Read on to learn how to send us your burning questions.
Life is way too short to miss out on the moments that matter. Here's how our MetaParents (I know, I know) make it all work.
Our highlight reel from 2019 is a little more...real than the rest. Read about what we learned about ourselves, our business, and doing better for our team.
We combined simple UX with sophisticated development to build the world’s first notarization platform—from scratch. Our Director of Engineering reveals the lessons learned along the way.
We recently gathered our entire team from around the globe in Whistler for our company summit. Here’s how Freya brought a remote team together to make Summit ’18 our best one yet.
Our CEO, Rich, works remotely from wherever in the world he may be. Here's why it works for us.
Research is our not-so-secret sauce to shipping great products. Here's everything you want to know about our research process.
If you're looking for a career in the wonderful world of product design, we have 5 tips for you. Let's get started!
We built a blog, our blog— from scratch. Here's why we did it and what we learned along the way.