Welcome back to my weekly newsletter. This is going to be a series of blogs covering how we came up with the idea of Calm Sleep, scaled it to over 700,000 users in less than a year with less than a $1,000 total investment. 🌱
I’m Akshay Pruthi, an entrepreneur who loves to build products from the ground up. Over the past 6 years, I have built multiple products from scratch and scaled them to millions of users. This is my attempt to share our most important lessons from building one of those apps: Calm Sleep. 🤗
Note - Calm Sleep is my side hustle that I started with Ankur Warikoo, Anurag Dalia, and a team of 3.
Every week I’m going to write about the different problems that we faced while building the app from the ground up. This week, I am going to cover how to decide what your MVP should look like, and how to go about launching it in a month.
After conducting thorough research on the idea, it was time to get our hands dirty. 🚀
I always get excited at this stage of the company; so many open problem statements to think through, prototyping, wireframing, coding. Urgh! Goosebumps!!
Gear up, this is going to be an interesting article. We are going to cover:
The problem areas that we need to solve.
What's the minimum you need to do with your product to solve the problems plaguing you?
How to navigate from ideating the MVP to building wireframes to high fidelity and finally shipping the product.
Let’s dive in! 🤓
What are we really solving? 🤔
It’s always good to document heavily at this stage. Why? It helps you in the journey that awaits you if you find yourself in murky waters somewhere down the line, looking for reasons that prompted this journey in the first place.
As the first step, we created a company strategy document. Here’s the template for it.
Let’s jump to the next question.
How to approach making your MVP? 👨💻
I remember getting on a call with Ankur where we discussed:
What was the ideal product we could think of?
An app that users can approach to get the desired content format (sleep sounds, stories, or meditation), and fall asleep.
What was the minimum we could start with to test our hypothesis?
The easiest and fastest way to test our hypothesis was to launch with sleep sounds as it was easy to find and cheaper to experiment with.
This forced us to think deeply about what our MVP should look like.
Key factors to decide on the MVP 🪜
Tech cost should be low [Developer time ~ 10-15 days to build]
Experimentation cost should be low [Even if we fail at this, we would have a plethora of learnings to help us to do a better job with the launch of sleep stories or meditation]
The impact visibility should be high [with fewer moving parts on the app, we will have higher visibility on what users are doing on the platform]
Note: I have seen many founders often strive for the perfect product, whatever that means. The arguments that they give to themselves:
“This is the most important feature for our app. Without this, users won’t like the app”
Or
“We need to have a perfect product to launch as it’s going to be the only chance”
Or
“Let’s just do this extra bit. It will help users do ABC”
The worst you can do to your product at this stage is launch all possible features at once. What this essentially does is:
Lowers the user learning experience.
Reduces the chances of success for multiple experiments.
Complicates the product.
Framework for MVP
I will try to touch upon the key aspects to take care of while building the MVP.
1: Aim for a Uni-Dimensional User Journey
While making the MVP, you should strive for a phenomenon that I like to call a “uni-dimensional user journey”. Think of the product like a story with an introduction, a body, and a conclusion.
For instance, Launch the app > Select the sound they want to play > Play the sound > Sleep > Collect feedback.
Benefits of creating a ‘uni-dimensional user journey’ during its infancy:
Helps users achieve their end goal quickly.
Attracts focused feedback.
Opens up room for experimentation
2: Create a Wireframe and Kick it Off With Your Dev Team
It’s always better to create a wireframe with pen paper and kicking it off with the development team to estimate the time it will take to build your ‘baby’. Personally, if my dev team claims that it is going to take over a month to build, I hit refresh and restart from Step 1. A sweet spot for your MVP should be around 15-20 days.
This is how our first MVP looked like which was built within 15 days.
If you want to play around with our first prototype, it’s here.
Back then, it seemed the simplest we could do to start with. Wait for my next blog where I will talk about how we made this simpler.
To facilitate this, I had an amazing lean team. Kudos to:
Ankur Warikoo: The man who gives us direction!
Rajan Dube: Currently in college, a design maestro. 🍥
Hiresh Pillay: Currently in school, the coding kingpin. 👨💻
Anurag Dalia: The usual suspect, my partner in almost every product I have built over the last 3 years. 🤝
Nagajuna Mullapudi: The data scientist who has always given us a reality check on where we stand at any given point in time. 📈
Concluding with the Final Checklist to Launch the MVP:
Document your company strategy doc.
Document your user stories and see if your user journey is uni-dimensional.
Create a rough prototype and collect feedback from within and outside the team
Iterate until you get it right and keep your experimentation cost to a minimum.
Start coding and avoid making any changes to the design once finalized.
We launched our MVP. But early signs were bad. We saw poor retention. What to do next? 😕
The same will be answered in my next article
How did we get our first 1000 users?
Our Day 1 retention was ~19%. What did we do?
What were the early bad signs?
What were the early good signs?
Until next time 😉
