How polished should an MVP be before launch?

This is where most people overthink things. It’s usually not about polish, but whether the core flow is clear enough to test. Did you define what the user should be able to do end-to-end before building?

This purely depends on what your product is, and who is the audience, or the target group.

I often feel that many people think of MVP as something unfinished, a demo, a clickable mockup. But that's not really the reality.

The MVP, especially in tech, should be a fraction of potential features that your product might end up having. But that little fraction, the MVP, should still be done in the best way possible, to attract as many people as possible.

That being said, this misconception on how you can release absolutely anything, a half broken product that will magically attract early adopters in my honest view, is simply wrong.

So to summarize, from my own personal experience, try to make your MVP as best as it can be, with the skills, resources and time that you have. We are swimming in an ocean of endless products that keep coming up on daily basis. Better your MVP is, higher the chances of your success.

I have built a couple of SaaS products myself and also writing a lot of content around Micro SaaS to 15000 people every week.

Here are my thoughts on this.

• Have something that is functional (Don't worry too much on improving the layout to pixel perfect. The goal should be talk to users and validate your reach)
• Validating and building in parallel lets you talk to users and progressively add features to users.

As a dev, you will be naturally more inclined to build features rather than talking to customers and doing marketing and sales. Come out of this loop and follow the below strategies that have been working for most dev founders to get ‘that traction.’

1. Build In Public - This is the latest trend where most devs keep posting updates typically on social media as they make progress. This could be posting about the landing page they designed, getting the first signup, creating a waitlist, spinning infrastructure, showing the cost of infrastructure, and showing the first paying customer. Note that ‘build in public’ is not always about the positive things. You can also post things like payment bills, hitting churn, losing customers, your product getting hacked, etc. too. Anything and everything that people like to know can come under ‘BuildInPublic’. This strategy is typically used on Twitter. See more here on the latest Tweets around this hashtag: #buildinpublic https://twitter.com/search?q=%23buildinpublic

2. Marketing Week & Development Week: This is another trend where most devs want to block a full week to only market the product without working on dev work. This would be difficult initially as devs are more prone to pick coding. But eventually, this will help you to block specific time (a full week) for marketing activities like cold outreach, writing content, etc. This can be further tweaked to a 3-Day dev work and 3-Day Marketing work, too, based on what works for you. You can also cheat this by building a side-project during the Marketing week, which will help market your main product.

For your MVP, focus on the functionality that delivers on your unique value proposition and brand positioning statement.

The "must have" stuff, and not the "nice to have". Classifying what belongs where is a tough exercise, but if you always try to relate it back to your unique value, you should be able to keep the MVP narrow to begin.

Also, congrats on dedicating to the project - that's the first step! :)

PG always told me to launch while still embarrassed. Usually, the thing that you launch with, your assumptions will be completely incorrect and it's important to find out where you're wrong.

Sometimes when we spend too long working on an MVP, we're polishing the wrong thing. We're working on making a tool look sexy when no one wants this tool in the first place.

If your MVP however is so shitty that nothing can be learned from it, then maybe you launched too early. But short of that, launch quickly

This is how (un)polished the Dropbox MVP looked like:
https://www.youtube.com/watch?v=qxFLfY7_Gqw

Before you proceed any further

I would strongly recommend you check out

1. https://www.youtube.com/watch?v=njZ4H-5WRYA and

2. "The Mom Test" book.

You will save a tonne of time and money, at the MVP stage.

There were recommended to me here by @thmsobrmlr

I certainly wish that I had found these earlier!

Good Luck!

More power to you!

I would add that if your product is intended to be used by designers or people with a good visual state, MVP should be attractive enough, not just workable.

E.g., if you are making a community for designers, it must be modern and slick.

An MVP needs to be as polished (or unpolished) as required before the user experience is below par and stops people using it. This depends entirely on what you are building, and for whom. MVP is better thought of as minimum usable product. MV(U)P's are not demo versions, powerpoint slides etc. Choose a single compelling feature/benefit of your bigger vision and work on making that a useable, convincing experience.

The answer is "a lot less polished than you think".

I have made a fully working version of my SaaS available exactly for these types of discussions. Here's it looked like when it launched: https://v1.keepthescore.co

I'm now at 1,500 USD revenue per month.

I've always heard that you should be embarrassed of your MVP - give everyone a taste of the chocolate shake, but maybe not serve it with a straw. And maybe it is in a red solo cup instead of a nice malt glass - and then sell everyone the whip cream and cherry! (well, sell the vision, don't sell vaporware).

the minimum viable product should be well thought out

If it's a web product, using standard UI lib will get your product looking halfway polished already, such as MUI. It's probably good enough for MVP launch for validation purposes.

An MVP should be polished enough to be presentable to potential users, but doesn't need to be perfect. It's more important to get feedback from users and make sure the MVP is meeting their needs than to spend time on making it perfect.

As Reid Hoffman, founder of LinkedIn said:

If you're not embarrassed by the first version of your product, you've launched too late.

Just launch and get some feedback, don't stress about it looking good. If you are providing value to customers they won't care about a modern website.

Whenever possible try to sell what the output of your MVP is going to be without actually building it. For https://www.fusionmetrics.io (KPI Dashboard for Shopify Partners) I actually sold statics report created with Excel before building a MVP.

seriously its a great question, i build this little project to help people make their ideas shine, even if they are not in tech, but i never know when it will be the right time to call him an Mvp 😅😅 yet some people have started posting on it.

I've found it helpful to focus on the value or problem your product is trying to solve (basically the "viable" part of the equation). Your MVP needs to solve the core problem for your users. Everything outside of that can be rough but the happy path for the core functionality should work smoothly.

It's also important to manage expectations for your users. There is a big difference in what users will put up with if you're charging even a minimal amount to validate the market and positioning your product as a "beta" version.

To summarize, I would focus on making sure the core functionality works well and that you position your product in-line with the level of polish/usability of the product.

What I understood is that early adopters don't need super fancy UI.
Just show your product to a small group of people first, even if it doesn't work properly and don't have all features.
Sometimes it's okay to just show even simple clickable design prototype to understand direction

Imagine your final product is a big, tasty, flavourful pizza.
Your MVP should be a slice of that pizza.

it depends on what kind of pain point product is solving for your customer.