Ship Quickly versus Make a good impression
The advice people give is to build an MVP quickly and launch rather than waiting to make it 'perfect' or fix the bugs.
I 100% agree with this but I think there's a certain threshold you need to cross with respect to product quality.
Sometimes if a person has a terrible experience with your MVP, they'll never use your product again because you made a terrible first impression.
My thoughts to fix this:
Beta testers are a lot more forgiving so you need to have a solid beta period where you iron out a lot of the bugs.
What do you think? Is spending a long time in beta a waste? What would you say would be a stage where you can come out of beta?
I think you can get the best of both worlds by selectively narrowing the scope of the projects you ship. @csallen captured this succinctly here:
I think it may be worth digging into the advice a bit (which I also generally agree with).
Why do we want to do this?
The goal is to validate, and test assumptions before sinking a ton of time into polishing something that no one wants, produces little to no value, or doesn't have the expected market size you want or need.
The next question you may want to ask is..
What is the fastest way to do this?
There are a ton of definitions out there about what an MVP is and is not (with a lot of contradicting advice). So going back to the goal of validating and testing assumptions - can this be done without writing code? Can you do it though conversation? I've seen the term "minimal viable test" or "minimal viable experiment" thrown around to describe this idea.
My take - if you've done the above and removed a bunch of assumptions and have validated the idea enough, then I like to polish the MVP in beta (I'm doing this right now with my new startup). We've got users and revenue and we're still holding out on public launch because we know exactly what needs to be done to increase our odds of a successful launch. We know this because we're in constant contact with our existing beta users and we're talking to 5 to 6 a week with a specific experiments or tests in mind to refine and further validate.
Another perspective - Slack's CEO put out a letter to the team in 2013, two weeks before their "Preview Release"
https://slack.com/blog/news/we-dont-sell-saddles-here
This is another factor to consider. Are you building something that people want really really bad or is it something they need but don't quite understand yet? If it's the former and you have a built MVP and you haven't collected feedback or done validation - I'd probably launch. If it's the later, I'd make sure I've done enough validation prior to committing more time to polish, then launch.
Hey Matt,
That's a really thoughtful response. It only makes sense to polish the MVP in beta if you know that it resonates with people. The last question of whether it's something people want or something they don't understand yet is something I need to think about.
Ashish
Yeah that last question (I think) is pretty crucial when trying to answer your original question. It's what led us to dedicate a lot of time to polishing our own beta before we go to launch.
Best of luck with whatever you decide!
Thank you! Good luck with your launch!
I just happened to write a post related to this earlier this week, called "Your MVP needs to Spark Joy" :). Basically I think it's important that your MVP is really polished in areas where it matters. In my opinion the M in MVP means you can leave certain parts out, but does not mean you don't need any polish at all (I used to example of how the first iPhone - not exactly an MVP but it applies to later product versions as well - didn't even have copy&paste, but it did have rubber band scrolling which looked amazing).
An MVP and beta is important in getting your product off the ground by creating initial fans. Those early adopters will be more forgiving, which is why you can leave a lot of parts out, but you also want them to have such a great experience with your product that they want to tell others. At least the core vision needs to shine. Spending a bit of extra time on making the experience great really pays off in that way. Plus, because you don't want to spend endless time on your beta, it forces you to really focus on what the core parts of your app are and work on those first.
Once the core vision gets you a few people who are really fans of the product, I think you're ready to go out of beta and add the long tail of other features over time.
Hey Wim,
That's a really good analogy. I guess some parts do need to be polished and exceptional. The parts that really sell the user on your product. And the rest can be a bit janky at first.
I'll check out your post! Have you considered writing the posts on Medium?
Ashish
Never thought about it so far, maybe I should!
Just started testing the waters with Medium yesterday.
I find publishing on Medium a lot easier than publishing on a personal blog. Publishing on my own website feels too much like sending my story into the void 😅
If you pay for a Medium subscription they let you have a custom url for your Medium page. For example: blog.introspekt.app instead of medium.com/@ashish.selvaraj which might be cool.
A different perspective would be; if a person has a terrible experience with your MVP and you manage to address those problems fast. They'll probably love the solution and approach. Thinking their opinion matters, their voice heard. Further on whatever they'll need in the future has a higher potential to be implemented quickly. Even tho that's not the reality.
I think beta testing not suppose to be in MVP stage. Better put if it's going through a beta phase it's not an MVP anymore. It's more of a mature product you are releasing into the market.
I'm thinking about the customers who don't bother to report the bug. The majority of people won't bother telling you, they have other stuff to do so they'll just churn out and never look back.
But you have a good point, if it goes through beta testing it's not an MVP anymore.
An e-mail to those who churned asking for the reason and another e-mail when that problem has gone. Sounds logical but I don't know how it works in reality.
I wouldn't write tests for an MVP, but extensive logging probably help me find those bugs early on.
When it's something like an app, I don't think you can send an email to the ones that uninstalled.
But in other cases that's probably the way to go.
Customers will always have a good experience if your solution is solving their problem.
Eg. If a dentist's clinic does not have a good interior but his treatment gives me relief from my tooth ache, it's a good experience for me. Having a good interior is nice to have, IMO.
If the MVP is not giving a good experience to the users, the MVP is still not complete.
The focus is on solving the pain point.
Think about calling it a demo first. It can even be some kind of slideshow without even developing code.
Here's a different way to think about it without compromising quality while still delivering the value needed:
https://basecamp.com/shapeup/3.5-chapter-14#cutting-scope-isnt-lowering-quality