
Start Smaller - jasonshen
http://www.jasonshen.com/2014/start-smaller/
======
jamesjyu
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
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
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
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
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
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
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.

------
Ygg2
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)

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

~~~
jasonshen
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
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.

