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 :(.
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.