Emma Sleep is a mattress manufacturer company based in Germany since 2015. They operate all around Europe with offices in the US, Germany, Portugal, Mexico, and China.
They focus on improving what a mattress can do to improve people’s sleep by applying technology. With that goal in mind, their current portfolio has been evolving from manufacturing physical products like mattresses or furniture related to the sleep environment to more advanced and tech-influenced products like Smart mattresses connected to your phone. In 2021, after extensive research and testing, Emma Sleep decided to move to the next level: to build their app to improve people’s sleep in a more personalized way.
Our mission lasted for 11 months, from September 2021 until August 2022.
In September 2021, Emma reached out to Baytech BV to validate, guide the development, and launch a subscription MVP. As a part of its current strategy, Emma Sleep wanted to expand its footprint in the App environment to ensure a competitive advantage and give 360º sleep aid to its customers (mattresses, furniture, online support).
Our mission consisted of four big stages:
Along the path, we supported Emma on other missions like upskilling the future Product Manager for the app.
Emma Sleep collaborated with a few service providers to gather qualitative and quantitative data. Once we got onboarded on the project, we started by clarifying the user personas, we wanted to focus our attention on using the existing qualitative data. Their goals, pain points, and motivators define the feature set for the MVP.
One of the most challenging parts was to define what problems were out of scope. As part of Emma’s vision, they wanted to build an app that could support people’s sleep, but the hardest question was to define in what way.
To overcome that challenge and decide what problems we want to focus we:
Once we got the problems and the users narrowed down, we were ready to start with part two, Features for the MVP.
Emma Sleep ran Design Sprints with a third party to get a possible prototype to test. This is understandable; it’s a popular/hyped method sold by many agencies. It’s often used as an entry point to upsell development services. Unfortunately, that prototype started with ideation space and big untested assumptions. Once we knew the exact problems we wanted to solve, we could filter the features proposed on that prototype and start with the hypotheses.
For the Hypotheses behind each feature, we did an exercise to cluster hypotheses and filtered what to test and what not. And for deciding what to include in the MVP, we used the Matrix User Importance Vs. Effort of implementation.
.png)
.png)
Now that we’ve got the feature set we wanted to test to solve the defined problems, we mapped the User Journey, Trigger, Action, Reward, Investment (TARI), and content growth loops. Thanks to that, we could spot possible synergies and problems.
.png)
As a part of the exercise, we also aid the client in improving the Business Model planned for the app. Supporting them when necessary on details for the Smoke tests to decide the price or providing them with some papers and conversations with our internal experts to define aspects of the Business model.
Problems defined, and Features for those defined. Now we just needed to decide how to build the MVP. The goal was to build quickly and cheaply.
We considered some options in the table to test the assumptions. You don’t need a complex MVP to test value and user interest. But one of the team’s ambitions was to give a similar experience to what the user would have with a real app. We ****decided to use a User Experience Vs. Tech Effort and time/cost. No-code won.
We then appraised no-code tools, and the in-house Engineering Manager gave a lot of valuable input and feedback. We also consulted the who was supporting the client part-time.
Features were clear; the challenge was to decide on the app design. We worked closely with the client’s external Product Designer, who worked part-time. We supported them by providing a study on 7 other vendors’ functionalities (Sleep Tracker, Pillow, Rise, Better Sleep, Sleepzy, Sleep Center, and Sleep Score). We also looked at best practices for B2C trackers and coaching apps. The Engineering Manager advised on the constraints of the No-Code tools. This helped speed up the decision and design process. And get super fast buy-in from stakeholders on design.
.png)
We’ve also created a Flow in Miro, so the Engineering Manager, external Product Designer, and stakeholders could better understand the interactions between the User and the app and have a map of what we’re planning to do.
We decided on the metrics and used the AARRR (Acquisition, Activation, Retention, Referral, Revenue) aka Pirate Metrics Framework, as it works well for this type of B2C product.
To gather quantitative data to validate the hypotheses behind the MVP, we decided to implement Mixpanel. We chose it over Amplitude as it’s easier to grasp for people less familiar with an analytics tool (our client stakeholders) and has a decent freemium model (which does tend to get expensive when you scale). It was great for this phase and this use case.
Once we launched the MVP, we decided to run weekly interviews with active users to understand their behavior better. We also interviewed churning users to understand their pains and motivations behind stopping. After this exercise, we started clustering problems to get inputs for a future second iteration.
.png)
Solving people’s sleep with an app requires long-term usage. Thus, we decided to run a workshop to implement gamification elements for the future app. With that, we aimed to increase future user engagement and stabilize it.
.png)
3 months later, we were ready for a Post-MVP analysis that could help us to understand better if the problem was defined and the solution designed where a success. For the debrief, we ran several sessions where we reviewed qualitative data and quantitative data.
.png)
Several sessions later, we achieved validation from upper management to continue with a second iteration of the app based on the numbers we achieved. In this next step, we could invest more resources in technology and team so that we could get the best V1 for our users.
One of the big challenges for this app was user retention. They would need to be very strict about using the app in the long run, to see improvements.
Thanks to the work we put in during the Problem Definition and Solution Definition space, we implemented elements that could drive future retention.
With the MVP validated, we needed to find a quick but effective way to set the cornerstones for the future app. For this, we decided to run an On-site Workshop where we would use Lean Inception to define the future: product vision, user problem, business goals, key metrics, personas, value proposition, etc.
While we were offboarding and handing over to an in-house Product Manager, we also:
Notable outcomes we've delivered in our 11 months:
💡 Launched a No-code MVP successfully.
💡 Got market and user validation through qualitative and quantitative data.
💡 Up-skilled their future PM with sharing sessions and mentoring.
💡 Launched GDPR-compliant user behavior tracking using a self-Defined a solid Discovery process for their future iterations.
💡 Guided and established a healthy delivery process for the Native app.
.svg){kind=small}
