6 ms·

Start Smaller

80 points by jasonshen 13y ago

jamesjyu 13y ago
I couldn't agree more. 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.
- saurik 13y ago
  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 :(.
pmtarantino 13y ago
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.
- boyter 13y ago
  I would have to ask though, if you didn't have your MVP would you have known to add the functionality that the teachers requested? Its possible you would have spent months building things only to discover later you built the wrong things.
  - pmtarantino 13y ago
    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.
    - LambdaAlmighty 13y ago
      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.
      - mattfenwick 13y ago
        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.
      - 13y ago
computerslol 13y ago
This makes sense if you're not working in an established market.
- jasonshen 13y ago
  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.
  - computerslol 13y ago
    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.
Ygg2 13y ago
I can definitely relate, trying to write a YAML parser - REALLY hard (151 ebnf rules). Writing a XML spec compliant parser - hard. This goes double for validating parser (81 ebnf rules + VC and WFC rules). Writing a XML spec that disregards DTD - managable. Modifying it to parse DTD - still managable (unless doing in-situ parsers). Writing OGDL parser - fun :D (~18 ebnf rules)

80 points by jasonshen 13y ago

I couldn't agree more. 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.

saurik 13y ago
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 :(.

pmtarantino 13y ago

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.

boyter 13y ago
I would have to ask though, if you didn't have your MVP would you have known to add the functionality that the teachers requested? Its possible you would have spent months building things only to discover later you built the wrong things.
- pmtarantino 13y ago
  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.
  - LambdaAlmighty 13y ago
    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.
    - mattfenwick 13y ago
      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.
    - 13y ago

computerslol 13y ago

This makes sense if you're not working in an established market.

jasonshen 13y ago
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.
- computerslol 13y ago
  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.

Ygg2 13y ago

I can definitely relate, trying to write a YAML parser - REALLY hard (151 ebnf rules). Writing a XML spec compliant parser - hard. This goes double for validating parser (81 ebnf rules + VC and WFC rules). Writing a XML spec that disregards DTD - managable. Modifying it to parse DTD - still managable (unless doing in-situ parsers). Writing OGDL parser - fun :D (~18 ebnf rules)