MVP Definition – What is an MVP Product?
Now that agile development is over two decades old, a significant amount has been written around different philosophies for Minimum Viable Products, Minimum Lovable Products, and Minimum Releasable Products among many, many other conceptual variations of the first version of a product.
Not an expert on these terms? Don’t worry, we’ll help you understand them better and also discover what type of public release is right for you.
Minimum Viable Product (MVP):
The smallest thing we can test to enable one cycle of the build – measure – learn loop.
This is the lowest level of product sophistication and likely may appear unpolished.
However, this product is viable enough to provide the measurements and learnings that you need to continue development.
Minimum Lovable Product (MLP):
The MLP is a solid step above the MVP.
An MLP isn’t just usable by customers, it’s lovable.
It’s a product or a feature that they would talk to their friends about, one that they would use with a smile on their face.
If you care about how your new products impact your existing brand, aim higher for an MLP.
Minimum Releasable Product (MRP):
An MRP is another, often very big, a step above the MLP.
MRP is a more common concept at larger companies where a feature or product can’t simply be viable or loveable; it needs to be release-ready from the beginning.
For example, a new product or feature at Adobe needs to integrate into the Adobe ecosystem, offer the same single sign-on, and the same billing system. Even if an Adobe product is loveable, that’s not enough since they hold themselves to an MRP standard.
Your interpretation and use of each of these agile “best-practices” should depend on
- your industry,
- your company,
- your management,
- your team,
- and your own personal beliefs
Alpha releases should be to people who have willingly indicated that they like your products or company so much that they want to be first in line to test new things, even when your product is far from ready for prime-time.
While some Product Managers often think of Alpha populations as a group of semi-anonymous “users”, this population should always include anyone in your personal network that you think can provide valuable feedback.
This means: family, friends, former co-workers, former colleagues, and anyone else you think is up for the challenge.
Why a challenge?
Because at this point, you’re trying to gather feedback on a product that may or may not have enough value to truly be worth using.
Your Alpha population may have to push themselves to use the product enough to provide the critical feedback you and your team need.
The Alpha Community
Your Alpha population should feel like a community; a community that you can share half-formed ideas with and get honest feedback from.
It’s important that you respect and value this feedback whether you choose to act on it or not.
If a member of your Alpha population emails you on a Saturday night, email them back right away.
Great Alpha users are hard to find and they can often be the difference between the long-term success and failure of your product.
If you can expose 90% of the shortcomings of your product during the Alpha release, you’ll be in significantly better shape for the Beta and full releases.
An Alpha product typically is very rough around the edges.
While it *works*…
- it may not be supported in all planned use-cases.
- It may not have features that are very close to “core”.
- It may not be better than other alternatives in the market or even those alternatives offered by your own company.
This is ok.
You’re aiming with the Alpha release to learn about the usability, functionality, and features of what you’ve built, not its financial viability.
There are many acceptable Alpha product failures. “Acceptable” means that you shouldn’t worry if your product fails in these ways during the Alpha release:
- Missing non-core or auxiliary features
- Extra steps required for users to experience the product
- No lifecycle or triggered emails Vapor features (meaning non-active, but clicks/data/intent recorded)
“Unacceptable” Alpha product failures are unacceptable because they render your product unuseable.
Worse than that, these failures make it impossible to get accurate feedback from your Alpha population. Key unacceptable product failures include:
- Significant instability or downtime of the product
- Missing core features
- The product provides no additional value to users
Most Important Feedback in Alpha Release
Qualitative. Look for common stumbling blocks that your product causes with users.
Filter feedback that reflects features you already plan on building.
For example, if you hear from your Alpha release that your product really needs to post to more social networks than Facebook and you planned on adding more social networks in the Beta release, don’t be discouraged!
Instead, use this as an opportunity to collect even deeper feedback:
- What other social networks would you like to post to?
- How would you expect to add and remove posting destinations?
- Would you expect the experience posting to different social networks to differ from Facebook posting?
Also, it’s worth noting that not every product needs a formal Alpha population. There are a few cases where it might be ok to skip Alpha testing and move straight from internal testing to a Beta release:
- Your team completed very robust user testing in your build process
- A small startup without an Alpha testing base outside of friends and family
- Excessive time pressure from management
While this final reason is certainly understandable, be careful not to release a product before it provides value.
If you do, you run the risk of damaging your brand and distracting yourself and your team with an Alpha population that will be largely unhappy.
Beta releases should expose your product to a small percentage of non-opt-in customers.
As a Product Manager, the beta release is where it all gets very real.
It’s the first time where you truly get to see your product out in the “wild” with users who don’t have a selection bias, aren’t usually tolerant of any (perceived) missing features or bugs, and may not even be interested in providing you feedback.
Most Important Feedback in Beta Release
Quantitative. While qualitative feedback is still incredibly important at the Beta stage, the amount of qualitative feedback to sift through (reviews, comments, emails) may be overwhelming in a Beta release making it hard to digest.
Look at your stability metrics and your key performance indicators to determine success here.
Don´t know your KPI´s yet?
Don’t worry, here I will help you determine the most important metrics for your product.
Benefits of releasing early:
- Fast feedback
- Iterate quicker
- Talk with real users faster
- Collect quantitative data faster
Risks of releasing early:
- Reputation damage
- Customer churn
- PR release opportunity lost
- Product isn´t used enough to validate hypotheses
Company structure matters a lot when it comes to the timing of Beta releases.
If the structure of your company makes it difficult to make updates quickly (ex. intensive strategic planning, long release cycles), you will probably want to lean more towards an MRP, than an MVP.
If you can pivot and react to feedback quickly, lean toward an MVP, learn more, and move quickly.
Transforming Your MVP into a Full Product
Now it’s time to take your MVP to a “full-featured”, bona-fide product.
Wait, didn’t I do this with my beta release?
Not quite, although you may have gotten close, depending on what level of finish you chose (MVP/MLP/MRP).
First, in order to decide what should be included in your full-featured product, let’s start by evaluating the performance of your MVP.
Which features did customers LOVE?
How do you know customers loved these features?
Look for a wide range of feedback sources, including both qualitative and quantitative data.
Also, look for patterns deeper in your data.
Even if one feature looks universally popular, it’s likely there are sub-groups who used this feature obsessively and those who were less enthused about it.
By segmenting these groups, you’re also already helping your marketing efforts better understand the target customers.
What feature set does your current MVP have?
A feature or product can be used in many ways by customers.
Some products, while simple, are insanely addictive.
They are the first thought many people have in the morning and the last thought they have at night.
Other products, while certainly still successful, only fill a specific purpose in a person’s life.
Some features or products just aren’t addictive.
They serve a purpose at a point in time and aren’t incredibly useful after that purpose is accomplished.
For example, a cover photo builder for Facebook is a great feature for a Social Media Management product, but how often does a person need to change their cover photo?
Would someone really pay for that feature? Maybe, but you’ll have to work hard to make it addictive.
Which features did they HATE (or just not use)?
Now that we’re a little more educated on major feature categories, what features did your customers HATE in your MVP?
Keep in mind, a feature that isn’t used is even worse than a feature that gets negative feedback.
A feature that’s not used is either completely devoid of value, or you’re doing a very poor job of education your users. Regardless, this is a failure.
Conduct a Feature Audit
Imagine you just got back the above results from your analytics on your new Social Media Marketing MVP.
The blue bar is the percent of users that completed the action 1 time in the past month and the red bar is the percent of users that completed the action 3 times in the past month.
Where would you invest (feature-wise) for this MVP?
The cover photo feature’s initial usage appears to be incredibly strong.
Getting 90% of your users to do anything (even accept free money or free services) is incredibly hard.
However, it looks like the depth of this feature is not great; users seem to use this service once and then not again.
Scheduling posts starts much less strongly than cover photos, but interestingly, this feature persists in usage over time.
Almost all of the users trying this feature once use it at least three times.
This extremely high level of feature retention is also very rare.
At first, it also appears that both Contests and Facebook Ads seem to provide some value to users.
However, each captures a pretty small portion of usage from our customers. If I was presented with this feature audit from an MVP release, I would immediately shut down the contests and ads features.
Next, I would figure out how to sequence the cover photo and post scheduling features together to capture the incredible initial usage of the cover photo feature and the strong retention of the post scheduling feature.
But wait, why not keep the features you have built already?
Features, even the ones you’ve built already, have costs to maintain.
More features are not always better; in fact, they’re almost always worse.
First, these features strain your support team.
Take a quick minute and think up all of the ways the contests and ads features could break.
In the time it took you to read that sentence, I already have 5 different failure points for these two features.
Next, these low-usage features are a distraction to you or your team.
If your vision is to build the best post scheduling product, you and your team will naturally wonder: “Why then do we have this contests feature?”
Additionally, extra non-core features can negatively impact the feature you care about.
If you redesign your navigation UI, you’ll still have to include that secondary or tertiary feature, when there could likely be a better design focused around the core, popular feature only.
Finally, would you rather build basic enhancements for features that only 20% of users use or significant enhancements for a feature used by 75% of your users?
Remember that saying no is the most important job of the Product Manager.
After interpreting your MVP results, you have a huge opportunity to say no, keep you and/or your team focused, and place your product on a successful strategic path.
Chances are, even with a successful MVP like the one described earlier, you’ll end up with more questions than answers on the future of your product.
For that reason, you should treat your full product release as another great opportunity to validate a new, more significant, set of hypotheses.
If you validated that customers would sign up for the product and use it once with your MVP, now try to validate that they will pay for certain parts of the product.
If you determined that scheduling was the key feature in your MVP release as we saw in the data above, try to make that feature even deeper and stickier with your post-MVP product.
While an MVP is often the time when most learning occurs in product development, the post-MVP hypothesis validation is just as important for the long-term success of the product and your company.
What does software development in post-MVP look like?
After you’ve decided on the feature set you want to pursue your post-MVP product, what does development actually look like?
How is it this period different than the pre-MVP world where we moved fast and broke things?
Again, your focus will depend on the size of your company, but a post-MVP product certainly needs more stability.
Save yourself many, many, many future headaches by setting up plenty of upfront monitoring.
Additionally, from a technology perspective, you’ll want to simplify your product wherever you can to avoid maintenance problems in the future.
Have your development leads the search for hastily written MVP code to “refactor”.
Yes, refactoring may be one of the most frustrating words for a Product Manager to hear as it doesn’t tie directly to the user-facing output, this is the time to do it.
What should I be thinking about as the team is working?
As you or the team enters the post-MVP build cycle, it’s time to start thinking about marketing.
In a startup, the Product Manager as a CEO is responsible for the success of their product in all functions.
This implies that the Product Manager is also essential in the promotion of the full product release.
Post-MVP development isn’t about new features and functionality.
In addition to stability, you’ll likely need to build landing pages, onboarding experiences, upsells, referral programs, and establish your SEO strategy.
As a product gets more mature, the Product Manager spends a smaller and smaller time on actual product development.
Much more time is spent on marketing, bug fixes, and incremental feature improvements.
Meanwhile, a successful Product Manager finds opportunities for continued product development.
While it’s likely your team will be less excited about this work than the MVP build-out, it’s your role to motivate them and show them the importance of tackling these challenges.
What they’ve built so far is great, but
- it’s not sustainable,
- it’s not fully releasable,
- it’s not fully marketable.
This upcoming workshop will take the product and the team to a place where they aren’t waking up in the middle of the night worried about the product.
What is onboarding and why is it important?
Onboarding has been a complete game-changer with the digital products I’ve been a part of.
Unless you’ve built a highly intuitive product (and likely, even if you have), onboarding offers an incredible opportunity to collect information about your new customer, personalize their experience, and make them feel successful within minutes of product discovery.
Depending on your specific business, successful user onboarding can lead to
- step function increases in usage,
- decreases in churn,
- and increases in conversion rate
Five Commandments of Onboarding
- Set a goal for your user’s behavior
- Remind users how much better things will be with your product
- Show the “Emerald City”
- Use social proof
- Land a user softly in your product
If you’re already hooked, you can learn much more about onboarding here: www.useronboard.com
Samuel Hulick has put together some fantastic insights about what makes onboarding great and also what makes onboarding fail. Plus, he updates his site every couple of weeks with new onboarding teardowns. One of my personal favorites is how WordPress onboards new users.
How do I know I’ve reached a ready-to-release product?
Things you’ll find yourself saying:
- I’m not quite sure what the next feature we should build is
- We didn’t hear any customers mention that in our testing
- Are you sure we need translations for Norwegian?
What are some signs that you definitely aren’t ready to release?
Things you’ll find yourself saying:
- It doesn’t work great on Safari sometimes
- We aren’t sure why it crashes, but it doesn’t happen too often
- But no one uses that feature anyway, so not many people will notice
- We’ll add analytics after the release as a quick-follow
Releasing to everyone is scared.
The stakes are much higher than your Alpha and Beta MVP releases, financials actually matter, and the decisions of you and your team are now exposed to the world.
However, if you approach your full release as an opportunity to focus your product, test new hypotheses, and increase stability, you will be in great shape.