This is the same philosophy of the MVP. It didn't work for me. I made a software for schools. Teachers came back with their feedback: "I can't do this, I can't do that", "I'd like this feature, why don't you have it?" and "This is incomplete". I told them it was not the final version, and it seemed that I was wasting their time.
The "start smaller", "mvp" philosophy is good, but be careful with your users/customers.
I had a similar issue with a project I was working on, but AFTER adding a few of the requested features, I came to the conclusion that it wasn't the lack of features that was the barrier to purchasing, it was an excuse to not purchase. I'm convinced that even if I had built every requested feature, there still wouldn't have been a sale at the end of the day. I was doing more than the current system the had in place, and yet, they always wanted more.
You have to consider not only the product/feature fit but also the market you're selling into.
"MVP" or "Start smaller" is not a magic bullet; like all rules there are places where it works and where it doesn't. Figuring that out is part of your product strategy.
MVP typically has a higher chance of success in nascent markets with low competition which gives users extremely low facility to compare your product with existing products. MVP will fail if you apply it to enter a market with massive competition as users will have plenty to compare your product with, which is what happened in your case.
You have two choices, one is to enter a crowded market and go with all guns blazing - tons of features, cross-platform availability, incredible design with great UI/UX, hidden easter eggs (emotional UX), massive amounts of marketing, extreme levels of support with hands-on training, hype, offers, discounts, sales funnels etc etc etc. The other, is to find a completely new niche inside the education market where you have absolutely zero competition and where users have absolutely nothing to compare to - THIS is where the MVP/"Start Smaller" strategy will work.
So that's not a MVP. You didn't find "the" feature that they needed badly enough.
I can say that because I was there trying features and getting the same "I need this, and that" you're talking about. But honestly, it should be "I'm giving you only this." and they should tell you "Where do I send my money?". I'm exaggerating a little bit.. but not that much.
> "I can't do this, I can't do that", "I'd like this feature, why don't you have it?" and "This is incomplete"
The key about that is to not worry much about it: things are not as bad as they seem, and they are not as good as they seem.
If someone tells you "I'd like this feature, why don't you have it?", probably what you don't realize there is that this person is currently talking to you and is talking about your product. That's a lot. Starting from there you can go further like for example start to charm him/her.
Exactly, one should be careful when dealing with teachers as customers.
Don't mean to generalize but the school teachers are not known to be internet/computer savvy. Especially the older and slightly older ones who didn't use internet in their teens. After dealing with rowdy kids, they are just too pooped to sit in front of a computer to learn something new. And I don't mean to put them down. Being older and not having the energy after a challenging day at work are serious obstacles to overcome to learn something new...
I know. My wife is one.
Btw, a doctor friend told me he knew of an older doctor who simply retired because he didn't want to be forced to learn to use the new electronic charts. So learning internet/computer is a challenge even for well educated people also...
Most of the comments are that the product wasn't viable which might be true insofar as being able to gauge whether the market wants it but I'm not sure why you say the approach didn't work.
You did something really hard which is much easier spoken about than done (showing a product you know isn't perfect) and you successfully obtained direct customer feedback. The missing feature reports could save you a massive amount of effort by directing your energies to the right features.
Personally I'd really enjoy delivering the follow up release including a feature a customer requested. Its a great chance to hook a product evangelist because you have listened and responded to what they said.
Wouldn't that suggest the product wasn't viable, by definition? MVP doesn't mean you can give them something that doesn't cover what they need. Maybe you cut out stuff that was actually needed to be successful. More research might have uncovered that up front, maybe.
I talked with a few teachers before I started coding, but it seemed they didn't know what they wanted or didn't expressed correctly, or maybe I didn't get it.
People who never tried, imagine creating a new product (not to say a "disruptive" product) is a simple A-B-C process:
* talk to potential customers
* do it!
* PROFIT
Whereas unless you are an expert yourself in the domain you're entering, it's almost hopeless.
People/businesses don't know what they want, until it's presented to them on a golden platter and all of their colleagues/competitors are already braying about it.
Totally agree. Programmers should understand the value of intimately knowing the domain. "Customers don't know what they want" is part of the game, and as such is not an acceptable excuse for building poor software.
The "start smaller", "mvp" philosophy is good, but be careful with your users/customers.