We hear so much above MVP (Minimum Viable Product), which is when a product is released to the market when it is deemed sufficient to satisfy early adopters.
A lot of the time sufficient just won’t cut it. In the mobile app space, the competitor is a quick swipe and install away. If your app doesn’t hit expectations, the opportunity to gain a lifelong customer is lost.
Enter the minimum loveable product, which has been described as: ‘The version of a new product that brings back the maximum amount of love from your early tribe members with the least effort.’
I love it.
Defining Loveable Scope
What makes your app delightful to use? Can it do one thing really well?
Answering these questions, I knew I wanted Eureka! Positive Affirmations to have a smooth experience:
- Pleasing design
- Smooth animations and transitions
- Quick to adopt
- No, or fast, onboarding
- User registration, only when required
- Quality auditory experience
- Realness for voice
- Seamless playing experience
So, yes, build something fast, but be honest with yourself as to which features and really necessary. Initially, I had planned for gamification and also my developer tempted me with a full-featured backend. But that would have 2x-3x development time. That’s a lot of work for something the user may not see.
Version 2 is your BFF
When dreaming up a project, it’s easy to get carried away with features. My creative side already has my app localised into 24 different languages with countless integrations. But my practical side needs to take over when determining product requirements. When you’re in a creative flow, keep it flowing. Write. Sketch. Dream. But remember: V2 (version 2) is your best friend.
V2 is also a mound of ‘nice to have’ or ‘maybe if we need to scale’ features. It acknowledges that the product is morphing and plotting forth. But it also allows the product to have some stillness and take a breath.
Here’s a list of features for Eureka! that got punted to V2:
- Easier/Flexible affirmations – Custom-built affirmations based on user persona
- Trigger/Campaign-based notifications (intercom?)
- Move user along the funnel based on actions taken/not taken
- Alexa and Google Home integration
- Standalone smart speaker applications
- Integration that allows the user to sync affirmations with mobile apps
- Ability to choose a custom voice from Google’s services
These would be great to have, but if Eureka! doesn’t get any traction, then it’s a waste of development time. The features above also don’t add to the core function. They are nice to have.
User Flow & Onboarding
I wanted the user to use my app fast. I don’t like long onboarding sequences, app tooltips, and user registration blockages.
If the user doesn’t have to register, then don’t make them. If the user needs onboarding, make it as quick and relevant as possible.
For Eureka!, I narrowed onboarding screens to:
- Intro Screen
- ‘Focus areas’ selection
- Notifications request
I am guessing that I will get mostly organic traffic in people searching for affirmations. So, they have some knowledge of what an affirmation is.
For the ‘focus areas’, I wanted to get the user playing relevant affirmations as quick as possible. Pre-selecting from a list will populate the user’s list after onboarding. Note: this is also not required. A user can skip, which will populate the list from all areas.
For notifications, I wanted to show the user the value of turning on notifications. In this case, they receive one of their affirmations in a push message. This should hopefully increase app adoption, which would boost overall numbers. This also allows permission to communicate via push messages for special occasions, like a time-limited deal (which should use respectfully).
After onboarding, the user is moved to their populated list. The ‘play’ action is important and will be recorded in analytics platforms. The play button is at the bottom of the screen, close to their active ‘play’ thumb, which is aimed to increase play rates.
The user can customize, explore, and play. But they are able to get an idea of the core function quickly.
Knowing Your Quality Threshold
There can seem like 1000 little decisions need to be made when making a product. One item I wanted to pay close attention to was the audio quality and function.
At this time, when creating Text-To-Speech applications for mobile apps you basically have 2 options:
- Use the built-in TTS capabilities of the mobile phone itself
- Use a cloud service that will return a playable audio file
Option #1 is an easier choice. Newer Android phones already have great voices to use on their platforms locally. The development time would also be very quick, as there was already a flutter package built to help. But, the experience for iOS was pretty terrible. For whatever reason, Cupertino hasn’t put a lot of effort into their native TTS. One can download new and better voices on iOS, but the process is difficult. Most users would keep the default voice, which is way below standard. See the example below.
Option #2 required the app to hit a cloud service, and download, store and stream that file. It’s a non-trivial amount of development time. But it would guarantee users on all platforms received a top voice and a better experience.
Building an MVP would have required me to choose #1. But looking back at my core requirements of a quality auditory experience, I choose #2. In order to love my product, I needed to love the audio experience.
What You Really Need to Launch?
It’s hard to release a product into the world. Getting real with yourself as to what you need to in order to launch your first version is difficult. You have to keep the core experience in mind, and you need to produce enough value or meaningful experience for the user to come back.
Be sure to nail the items that you promise, and move the rest to V2. After all, your users might have something to say about what they want in V2, and that feature that you needed to have at launch doesn’t look as important anymore.