THE STARTUP SHOW
Building an MVP
Your user is always right
So you have this idea for a startup. You’ve done a few user interviews and think there may be people out there who want your product.
Initially, you might build features that your users don’t want.
That’s ok. It’s part of the MVP process where the goal is to collect behavioral feedback on your product.
Are your users using your product? Why? Why not?
These are the questions that you will get to answer by seeing how your users react to your product.
A Common Mistake
The most common mistake is to go all-in and spend months developing your full product.
Founders who do this typically throw every potential product feature at users to then see what sticks and what doesn’t. I call this the “spray and pray” approach.
That’s wrong.
For just because you think your users will like a feature does not mean that they will.
Building every single potential product feature is also a significant expenditure of engineering resources and time.
So don’t build out every potential product feature that you can think of.
Iteration
Initially, you won’t know with certainty which of your potential product benefits to prioritize.
You may have an idea of what to prioritize, which is where you should start.
Start with 2–3 benefits that you want to offer with MVP, and come up with a couple of features that deliver those benefits. These benefits should be product benefits that you think your early adopters will care about the most.
Then, build iteratively, slowly adding to your product and evaluating every small addition based on how users like it.
Like a good chef, who knows the importance of tasting when cooking.
That way, you end up building what your users want, not what you want.
And if you think you know enough about your users already to build the full product, you’re wrong. For insights about pain-points are not the same as feedback on whether a feature that you have built delivers a benefit that addresses one or more of those pain-points. That feedback is how a user behaves in response to your product feature, which can be an attempt at delivering a benefit, but might not successfully do so.
In short, what you think your product’s feature set should be might be completely off the mark.
UI/UX
We’ve all heard it — your MVP doesn’t have to be perfect. It doesn’t have to do everything that your end product would do. It just has to be minimal.
That doesn’t mean your MVP should be poorly designed.
For your users, with their limited time and attention spans, will not tolerate excessive frivolousness in a product.
Which is why the UI/UX of your MVP is so important.
UI/UX built on features that offer benefits that you know your users care about. And not too many features lest you confuse or worse, frustrate, your users.
The purpose of an MVP is to test your understanding of your users by presenting them
your product’s value proposition without spending vast amounts of time and engineering resources because let’s face it — your 1st iteration is probably going to be in the wrong direction.
Your product’s value proposition are the benefits that ultimately solve the problem you’re trying to solve.
Your MVP is not your end-product, but a tool for understanding your users. With a product, you can have something tangible for your users to try
So I’m about to launch my MVP. It’s very bare bones (on the front end at least), and is very light on features. I think there are only three features.
Have I misunderstood the definition of an MVP?
I think not.
That’s because when it comes to building an MVP, your product’s UX should be as lightweight and as easy to understand as possible.
For the purpose of the 1st iteration of your MVP is to understand who your early adopters are.
Does Your MVP Have to Look Nice?
The answer is no.
In fact, I would caution against embellishing your MVP with nice fonts and graphics if doing so will take a lot of time and resources.
Embellishments distract. It attracts people for the wrong reasons. Attract early adopters who have a dire problem that needs solving. Don’t attract them because of your pretty product interface. Such feedback that’s low value at this stage.
An MVP doesn’t have to be perfect. It just has to offer some value to your target users.
And if it doesn’t, not all is lost.
Reconsider the assumptions you made about your users. Did you offer the wrong benefits with your MVP? Did you build the wrong features? Did you wrongly prioritize benefits? Constantly question your assumptions about your product’s benefits, about your users, and about whether you’re building the right features to deliver the benefits you want to deliver.
Your user is always right.
