Wondering how much work you've put into MVP to validate your idea, and how did you do it: mockup, video, prototype, doing stuff by hand with a primitive system.
mine came from a hackathon. (for reference it was an online tournament platform) So it was two people and 48hrs building mocks, getting basic stuff rendered and implementing live reloading in browser (one of the main points for our idea). We ended up winning the hackathon (over 100 teams) so we considered that "validated" and decided we could try building the rest of it.
Spent another weekend building out basic functionality (login/register for tournament/report scores/"staff" ability to resolve disputes) Then we reached out to a gaming league who held tournaments three times a week. They used it had some issues, we fixed them. Opened it up to two more leagues and they all loved it and wanted to start putting money into it. This was the point when we felt "validated" again and considered this our MVP.
At that point it was about 6 days of coding and about a month of testing with these three "clients". We then ran with that MVP for another month, opening up to more people, and collected feedback before doing another round of coding.
Unfortunately there's no good general answer to this. One could say an email blast with a description of what you're trying to do with a credit card form would be the least possible work you could do. You're unlikely to get any real response from that method, though.
Others will say a fully functional prototype of what you're set out to do is what's necessary in order to fully allow prospects to understand what you're trying to do. Sadly this requires a lot of work which probably will be wasted, unless your goal was to simply to do it, and not to build a successful business as soon as possible.
in short, i'd say there are three criteria:
1. how long would it take you to make a functional prototype?
2. what's the potential upside of a good first-look?
I agree with this to an extent, but I also think there's always room to cut features. When I launched my MVP (after the usual no-product-yet-but-sign-up-for-this-mailing-list stage), the feature set was pretty barebones, there was no admin dashboard (it's an API product) and because it was so limited I quickly discovered pain-points that were causing users to drop off, namely not having an admin dashboard. I would of never known that if I just plowed ahead and built everything.
So sure, you can't really get away with an ugly "MVP" that's missing your core feature-set (and I'd argue you couldn't really get away with that in the first place) but you can cut features until you have something barebones that you can start getting in front of users.
Yep. True MVPs only work if you are solving a problem with no other effective competitor.
So it's either your MVP (to solve their problem) or nothing.
That's extremely rare.
If you are making "a better ___". Some basic ugly MVP is not going to get you far.
People will just be like "Ok we'll use one of these 10 other competitors until your product catches up to them".
And yes, I know you will differentiate in some aspects, but a lot of solutions are nearly useless until they cover a large critical set of features. If you implement 5 differentiating features but you lack a polished UI/UX and 100 other "basic" features that other established competitors have, you can't win anyone over because of the differentiation alone.
I think some of the challenges to keeping MVPs really MVPs is that the users being presented with an MVP often can't see past its bare bones nature.
If it's not pretty or the UX isn't as good as other apps they have used then that's all they get hung up on. On the other hand, you can't really expect an end user to find something useful unless they can actually use it with some level of comfort. I think that's where the more and move polished MVPs surface.
Very much so - I'm stuck on the periphery (operating the environments the system touches for data) an endless MVP...1.5 years when the initial sprint was 6 months. Management keeps adding more features before wanting to release it to a test group yet keep calling it an MVP. New teams are being brought in and have to be retained. New management is brought in each time with more ideas of what is "minimal". Yet they keep throwing money at it...
I don't think landing page with an email subscription is an MVP. Many people have done it and it definitely helps in gathering an audience and get your initial users, but it won't help you in understanding your product. Product is more than just users saying ok to try a product. It's about the will to pay or engagement. I think a working product with minimal core features can be called an MVP. The feedback from users after I launched my product* is what defined it.
*https://pipecourse.com/
Seems that MVP is pretty much whatever the situation dictates. So I'll avoid getting to philosophical.
In my last case (funded, growing B2B SaaS company) we built prototypes on "paper" (actually mockups designed for an easy display on iPad). We then went out and pitched potential customers on the back of the prototype. Criteria was getting them to emphatically commit to the product if we were to build it. We were pretty strict on what commitment meant. Probably 1-2 months work.
When we hit the threshold, we built the minimum required, went back to those parties, closed the deals and worked out from there.
1-2 months of work building the prototypes or 1-2 months of work building, iterating and getting commitments, or 1-2 months of work building a launchable product based on them?
Paper prototyping is HUGE. I don't get why more folks won't or can't embrace it. Not only can you do the testing that you have suggested but your engineers and designers will THANK you.
There is a huge upside to paper, UI issues can be spotted early and cheaply.
I have spent usually between 1-3 months to build MVPs..but you can't generalise as it really depends whats viable. Talk to your prospects to define what is viable. For enterprise softwares its usually longer due to various reasons.
My first product was into travel and we spent months just to build MVP that we thought was viable. Stupidest thing we could do. The product didn't go anywhere.
Second product was into logistics. I spent most of my initial month travelling in field with my cofounders and doing stuff manually. This helped me understand what was viable and build product in a month's time.
My third product was education platform. This was a funded startup so they had sales people. I used them to gather information. Like what profs think about the problem space, what students think then what type of devices are they using, do they have good internet access. This greatly helped us figure out whats minimum that we need in product. Like we discovered that students in our country rarely have a laptop or desktop. They use desktops in school's lab.
My current product is about team productivity. I am on call with most of my ex colleagues, friends to figure out what would be minimum. My problem statement is kind of validated as most have felt a need for solution.
So spend more time with prospects to figure out MVP or MRP (Minimum Remarkable Product).
I think that's the way to go. From the outside it looks like the real thing but internally it's the bare minimum. But you have to be ready to scale up quickly if needed.
When I built my project for behavioral and cognitive changes (http://willyoudidyou.com) MVP for me was something that i could use, would want to use, and that would actually do something useful for me. Specifically, I needed to see a change in my behavior. I needed to brush my teeth before bed, do laundry with regularity, and eat healthier. I just needed someone (or something) to help put those things on my radar when they needed to be.
I reached MVP when there was nothing else that I needed to add, feature wise. Sure, there are things I WANT to add, but building out the core was important for me.
Before I slung most of the code... I had done some prototyping. Html/CSS files that I chopped together and tinkered with. It went on to influence the actual buildout, but was more of help with my own brainstorming.
It depends on what you want to test. Atm, testing an idea is easier than ever before, but shipping an MVP gets harder every day. To test the underlying idea we asked contractors to fill in prices in Google sheets. After that we have spent 2 years building our MVP. People expect you to be as useful, adaptive and intuitive as unicorns from the very start. (Looking back, we could have ship it faster, but as always you know which edges should have been cut post factum) Imho.
I really try to do as little as possible. You learn over time that it is better to launch early, get feedback, and iterate.
There was a great write up recently on indiehackers.com with Jeff Atwood about Discourse. He shared some of the older landing pages he first put up in the comments.
It is really a testament to launch early. If you look at Discourse now, its night and day from when it first started.
I think it depends on your definition of MVP. Some are prove to an investor you have a good idea. The kind I like are good enough for your first 10 or 100 customers... time to complete really depends on the product. IMO the MVP should be the basis for all future work e.g. After this first step you are incrementally adding improvements
There is a good book called Lean Product Process that I recommend. $15 and a few hours will help you find how much MVP you need to test hypotheses with customers.
While this may be simply put this really is the best answer. The least amount of effort it takes to push something out the door is the ideal MVP, market validation is many times more important than early stage tech/code in a business, code quality at such stage does not correlate strongly with the success of a business idea.
Whatever it takes to get feedback from someone is the amount of work that is needed. Which means you can throw out 90% of the features and anything that even some what resembles an optimization of code, coding processes or business processes.
That really depends on what kind of MVP it is and what you're bringing to the table. Some startup ideas can be hacked together quite simply by reusing a few existing services, tools and a bit of programming. Others may require some prototyping and fund raising (e.g. hard tech). Whatever it may be, the MVP is a hack and experiment to prove product-market fit. It's the tiniest, minimal effort you can expend to build a test to prove that there are real people who desperately need something you could provide them.
An MVP is more marketing and sales than it is developing. Building your MVP should consume a fraction of your time and resources compared to the effort you'll spend trying to get people to see your hack and validate it. It's more market research than product development. You just want enough proof there's a business opportunity to continue spending time, money and energy on it.
For software startups, there's a few patterns you can employ to build an MVP. One of them is the Wizard of Oz test, where you provide a facade of a real product but do all the hard work behind the scenes manually (until you can automate the rest of it). Another is piggybacking on other existing services and solutions, modifying them to your specific business domain (e.g. form builders, communication services, integration services, open source, BaaS, etc). Then there's the launch page strategy, that attempts to lure sign ups or "beta subscriptions" to show demand without building anything more than a few prototype designs and a landing page.
It seems more compelling to just build it from scratch, but researching options and planning a more clever solution may save lots of development and money down the road. Treat it like a science experiment with incremental solutions and gather as much feedback as possible.
There's quite a bit written about building MVPs. Here's some resources and inspiration:
"launch page strategy, that attempts to lure sign ups or "beta subscriptions" to show demand without building anything more than a few prototype designs and a landing page"
I think this is totally overused these days. It was OK the first few times but now I feel sort of used when I see this.
I agree it's a bit cliché and can be annoyingly deceptive, but there's less shitty ways of doing it, which is discussed in that SaaS Launch List article. Regardless, if it works, I wouldn't discount it. It's basically just a ghetto Kickstarter campaign page. I'd rather employ that trick than spend a few months building an MVP just to find out nobody cares. I've done the latter enough times to know how much it sucks when you're wrong about your assumptions.
Spent another weekend building out basic functionality (login/register for tournament/report scores/"staff" ability to resolve disputes) Then we reached out to a gaming league who held tournaments three times a week. They used it had some issues, we fixed them. Opened it up to two more leagues and they all loved it and wanted to start putting money into it. This was the point when we felt "validated" again and considered this our MVP.
At that point it was about 6 days of coding and about a month of testing with these three "clients". We then ran with that MVP for another month, opening up to more people, and collected feedback before doing another round of coding.