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.
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?
3. what's the downside of a bad first-look?
The expectations of MVPs from just about everyone have gone through he roof.
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.
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.
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.
But also: how many people found really, really crappy MVPs to actually work and make sense. e.g.: not scare users.
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.
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.
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).
If possible Google forms plus shlepping.
As long as you're solving their problem, the vast majority people don't care how you're doing it.
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.
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.
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.
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:
- Lean Startup
- Sprint (Jake Knapp)
- Product Hunt Began as an Email List: http://ryanhoover.me/post/69599262875/product-hunt-began-as-...
- Building Your SaaS Startup’s Launch List: https://medium.com/@cliffordoravec/the-no-bs-approach-to-bui...
- Successful SaaS MVPs: https://belitsoft.com/custom-application-development-service...
- Wizard of Oz test: http://blog.ycombinator.com/ask-yc-upfront-technical-investm...
- Shameless plug--I wrote more about MVPs here: http://jameskoshigoe.com/how-to-build-an-mvp/
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.
