We started Parse with only an iOS SDK (no Android or even REST API!) It had very limited functionality: basically the ability to save an object and retrieve them using a query.
We could have waited to include lots of other useful things, like object counts, user login, push notifications, analytics, etc. It's easy and addictive to create a list of features that would go into an ideal product.
But, that's the danger. The more you think of these lists, the more you think must have them to make your product useful. Suddenly, it's months later and you realize you've barely gotten any real customer feedback.
The key discipline for your V1 is to understand the smallest set of features that will bring enough value to customers for them to try it out. Just keep iterating from there.
As somewhat specifically indicated in your list by "user login", you also launched without any kind of permissions model, and most of the applications built on your stack for a very long time thereby were, without even realizing it (as your marketing materials I will argue weren't really honest about the issue) storing customer data in insecure ways. I imagine many of those applications are still out there, unknowingly exposing information that they don't realize just anyone can go download (or even manipulate) via your API.
(Even the Instagram-clone demo application you guys had to show how awesome your solution was had these issues: anyone could fake comments or pictures as any other account. You managed to just barely fix that one in time with a new major feature you launched the night before my talk at 360|iDev 2012, where I was doing demos of all of these security flaws in solutions like yours ;P. I sadly hadn't bothered to come up with third-party applications using Parse that had issues, so I wasn't able to then do any cool live demos against your offering, but obviously those would have still been vulnerable: you hadn't even yet updated the tutorial showing how to build the application how to use the new security features :/.)
(For the people reading this who aren't aware of these kinds of problems: people use these services relying on client-side verification. I had an example of a company--unnamed in the presentation--using StackMob that was a singles meet-up application. Using the StackMob API you could download their entire user database, including all of the Facebook full-access offline tokens they had for each user and every private message the users had sent to each other. Storing data in a scalable and secure manner is not an easy problem, but the business model of these kinds of companies kind of rely on making it seem like an easy problem, leading people into horrible implementations without guidance or often even the tooling required for security.)
Now, clearly: that didn't keep you from being successful, so nothing I'm saying should detract from the "lesson" here being learned, even by your specific example; but, this is a bug in the way people interact with product marketing that depresses me to no end daily: that people who wait to include critical functionality--not something optional like "object counts" but something absolutely core to the value proposition of "manage your application's data without running your own server" such as "user login" and server-enforced permissions--in the end can often get screwed by being "beaten to the customer mindset" by someone who decides "engh, unimportant" and decided they could "iterate" on security or safety features once already deployed :(.
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.
This works in all markets. I'm not saying you can beat a market leader with an underpowered product, but if you have a hypothesis that a faster search engine is what people want/need, just build the speed thing as your V1 and don't worry about optimizing result quality or scraping every data source. If speed truly is a differentiator, you will find out when you push out this barebones but fast search engine.
You may very well need a big product to win, but that doesn't mean you can't start getting feedback sooner with a small one.
I am a veteran of the market leader in a section of our industry that sees a lot of start-up competition. Perhaps the most start-up competition.
I had a number of roles over the course of my stay. One of them was to watch for threats on the horizon, estimate how far they will go, and figure out how to stay ahead of them if they were to become any real threat. I reported directly to senior management. I have an unusual (and hopefully elucidating) perspective on this topic.
In my experience, MVP products go one of two ways: Either they never grow, and eventually disappear; or they grow too quickly, drop in quality, and disappear. Either way, they disappear.
In my section of the market, you get very little attention unless you're swinging for the fences. Not that swinging for the fences is a recipe for success, but it's certainly an ingredient.
I mainly watch for three things (this list is hugely oversimplified):
- Do they understand our audience?
If my interaction with their product is fatiguing, they don't understand our audience. If their copy or humor or interface isn't equally accessible to a 46 year old mother of two in Nebraska and a 28 year old lawyer in New York City, they don't understand our audience. If they haven't convinced me that they have all of the information they need to serve me informed results, they don't understand our audience. If, after one session, I feel I've seen everything there is to see; they don't understand our audience.
- Do they have the technological ability to produce magic?
If they can do more in a timely fashion (under 130ms per page load) with limited hardware than we can with our huge budget, they are capable of magic. If their results are good I can't figure out how they do what they do, they are capable of producing magic. If I am seeing something I haven't seen before (and it's good), they are capable of producing magic.
- Are they passionate enough to stick around?
Production quality shows me passion. A tight and intuitive flow shows me passion. Well written help/tutorials shows me passion.
What I saw most was MVP products, and none of them survived long enough to warrant planning a fight.
My section of the market might be different than yours. The lessons learned during the MVP V1 may have been enough to show our new friends that they don't want to be a part of our game. I don't know. Some companies make it, and they get acquired. We acquired a number of them.
The MVP approach can allow you to build fewer features that are actually useful for your user base.
There are tons of product out there that are gaining market share against older/bigger companies, think about the CRM market for example.
The big players can't remove all the "wrong" features they built in the past because a portion of their user bases is attached to them, smaller players can iterate at a much higher pace.
We started Parse with only an iOS SDK (no Android or even REST API!) It had very limited functionality: basically the ability to save an object and retrieve them using a query.
We could have waited to include lots of other useful things, like object counts, user login, push notifications, analytics, etc. It's easy and addictive to create a list of features that would go into an ideal product.
But, that's the danger. The more you think of these lists, the more you think must have them to make your product useful. Suddenly, it's months later and you realize you've barely gotten any real customer feedback.
The key discipline for your V1 is to understand the smallest set of features that will bring enough value to customers for them to try it out. Just keep iterating from there.