

Approaching a Minimum Viable Product for  a Startup - plinkplonk
http://www.threeriversinstitute.org/blog/?p=333

======
gsaines
I agree that this is hard and necessary. Whoa. When we were developing the
first version of the product, we were always torn between releasing it and
letting people see our steaming pile of half-finished code and tearing it
apart and waiting until it was "perfect" and "wowing" everyone that came to
our site. The reality was exactly what Kent is talking about. We released a
terrible looking and difficult-to-use alpha version that people actually used,
and it took months to disavow ourselves of features that we thought were
awesome that users simply didn't want.

I also agree strongly with bmelton, geez, it's so tough to fight the desire to
release something "perfect" when it's way more valuable to answer the burning
questions and leave perfect for the birds.

~~~
10ren
I worry over introducing incompatible changes (which is more of an issue in
middleware and libraries). OTOH, it's common to see "deprecated features", and
ActionScript (in flash) has been utterly redesigned a few times. They're still
ahead.

Another issue applies to patentable inventions. You need to get this right,
because you need to file a prov before you can launch. What if you find out
your invention doesn't work in some cases, and you need to change it? What if
you have improvements? These encourage a perfectionistic approach - but the
truth is, you can just file another prov (depending on jurisdiction, they cost
$80, so filing several is no real problem). The only danger is that time
started ticking on the first one (you have a year), so you're using up your
time until you have to expend real money and effort to patent it for real - or
let it go.

~~~
robfitz
From what I understand, you can retroactively file an [American] patent
application from within a year of your first public/open demo. Then you have
another year to file a real claim.

------
10ren
related: <http://discoverydrivengrowth.com/site/results/>

There's a story of a guy who wanted to sell cars over the internet, but he
wasn't sure it would work. So he setup the minimal website, where _he_ was the
backend. It looked like it was automated, but under the hood, he just got
emails from forms on the website, and fulfilled them manually. Extremely
inefficient, and therefore defeated the purpose of putting it online... except
it was an experiment to validate the concept. Which apparently it did (though
I've not heard of the actual business, so it may be one of those business
parables/lies).

However, this approach prevents you from succeeding in businesses that can
only become viable once you've solved problems with them that you are _yet to
come across_. You need to go quite a few steps into it before you come across
the crucial problem that makes it a viable business. These types of businesses
can only be successful if run by visionaries (i.e. people who _see_ with their
_eyes closed_ ). That is, they require "faith", "confidence", "trust" _that is
not justified by the available facts_. My business is one of these, and I
think the secret of it is to be motivated by something other than "success",
"fame" or "money", but something intrinsic to the project, that is its own
reward.

I've not done a survey, but I expect that all revolutionary businesses have
some of this in them.

~~~
KentBeck
10ren,

I don't understand the exception you are proposing. If the "crucial problem"
is several steps in, then your first several MVPs succeed easily (indeed, that
is the case for Tattlebird). Any successful startup overcomes several PFAs
(potentially fatal assumptions). You absolutely need faith to proceed on this
path, but you need facts to stay on the path and not waste your time.

I would need to know a lot more about your product before I agreed it was an
exception. Your product's success relies on a long list of assumptions.
Validating those assumptions as quickly and cheaply as possible increases your
chances of success.

~~~
10ren
Thanks for requesting clarification. Maybe it's a narrow exception, so I'll
just give some examples:

E.g. 1: My product was a good idea for a tool, but a kind of obvious one, and
one that any library-developer could implement. Although useful, there was no
barrier to entry to protect it (in fact, dozens of people had had the same
idea, and implemented it - which I didn't know). That's fatal. There was also
a technical problem that I didn't worry about much at first because it was
secondary, but it turned out to be a show-stopper: it made the tool just too
awkward to use in practice. That's another fatal. I was positive that it was
impossible to solve; but, with online suggestions (involving an odd route, and
new features in the language), I did solve it. This solution addressed both
fatal problems; but at the start, it seemed unimportant, and then impossible
to solve.

E.g. 2: The idea of the telephone was an obvious one: talking at a distance.
Many people (including Edison) thought it would be really cool, but couldn't
see any commercial use for on for it (they had the telegraph already). It
would just be a "scientific curiosity". Edison had a go at it before Bell, but
it was hard, and he gave up because it seemed a bit pointless to a practical
guy like him. In one of the blog links, a way to test demand is suggested:
create some google adwords, and see if anyone clicks. If this was done with
the telephone, no demand would have been found. For revolutionary ideas,
people often don't know they need them until they exist.

Eg 3. There's a story in the _Innovator's Dilemma_ , where a big HDD
manufacturer makes a tiny diskdrive (2.5 inch I think) at great expense - but
could not find a customer for it anywhere. It turns out that there were uses
for it, but unexpected and tiny markets (I think one was a medical app). This
was well before the iPod used them, and before notebooks and netbooks used
them (I think they're a standard now).

As I said, maybe this is a narrow exception, only applicable to those rare
inventions that are revolutionary (and perhaps only some of them), and the PFA
approach works great for 99% of business ideas.

I am pro-fact, but unfortunately there is more to the truth than is dreamed of
in a philosophy based only on known facts.

~~~
10ren
There's also Xerox, a classic example of this. Alan Kay tells the story of how
the inventor of xerography tried to sell it to IBM, who commissioned
consultants to assess its viability. They found that it was much more
expensive than conventional copying, and there just wasn't that much demand
for it.

This was all true, yet Xerox become a multi-billion dollar enterprise from the
technology.

<http://www.ecotopia.com/webpress/futures.htm> (he's quoting from John
Dessauer's "My Years at Xerox, the Billions Nobody Wanted", but he also worked
at Xerox PARC himself.)

MVP: I like the Minimal Viable Product idea, but mainly in terms of building
the product. It's a great discipline to work out what's important and what is
not _as_ important ("core" vs. "non-core"), and also to get feedback from the
market. I like esr's formulation of it: (1) something that _runs_ (2) has the
promise to become something really cool. Of course, the MVP depends on the
target audience (his target is open source developers).

[http://catb.org/~esr/writings/cathedral-bazaar/cathedral-
baz...](http://catb.org/~esr/writings/cathedral-bazaar/cathedral-
bazaar/ar01s10.html) (paragraph 3 )

PFA: But I don't like PFA. It sounds very sensible, but I'd rather be focussed
on why something might succeed, rather than why it might not. My experience is
that insurmountable problems often turn out to be surmountable, once you
understand them, and had some time for your unconscious to work on them. It
might require a very different perspective, or stepping back to look at the
bigger picture to understand the situation you're in, what's important and
what's not and so on. As a coder, I'm easily trapped in the details, and not
actually be able to see what's important in the bigger picture.

However, I totally agree with your conclusion about shipping sooner, iterating
faster ("release early, release often", esr again), and also the
perfectionistic wish to not release til it's "perfect".

I deliberately fought against perfection for my first product. It was driven
utterly pragmatically, and I didn't care whether it was pretty or not. I made
enough money to live on the interest (barely live on it: _ramen independently
wealthy_ ), and today, 9 years later, it's still useful to people, and still
making money.

~~~
KentBeck
10ren,

It's good to hear cottage industries still exist on the Internet, as that's
what I hope to build. I agree that PFA is too negative. I tried to find a
positive formulation but couldn't find one that was as inspiring to me.

------
prpon
"By far the dominant reason for not releasing sooner was a reluctance to trade
the dream of success for the reality of feedback." The above statement holds
true for me. It's only after investing way too much energy on stuff that does
not help me in being closer to a MVP do I realize it.

------
bmelton
I've heard it before, and I'm sure I'll hear it again, but this, to me, is
absolutely the sort of thing I need drilled in my head over and over and over
again.

The current project I'm working on is simple. The idea is simple in general,
the layout is simple, and while some of the technical glitches and
implementation details may not be (they never are anyway) -- I keep
overcomplicating things in my head.

I've gotten about 3 weeks worth of spare time thrown at it, which isn't much,
but in that time, I've already wasted a ton of effort. I redesigned the layout
yesterday. True, I made it simpler, and I think easier to use, and ultimately,
it's a MUCH better layout for the product, but it was completely wasted effort
to determine whether or not my product is even worth building, because I
honestly don't know the answer.

I guess the main difference for me is that after a number of false starts
(that later ended up as actual products, and profitable ones at that,) I have
committed myself to finishing this thing, if only to say that I can build a
project to completion without external motivators. That almost gives me an
excuse to waste time because if it's rejected early, I'll assume it's due to a
poor layout, or lack of features, etc.

So yeah, I needed to read that, and get back to square 1, and friggin stay
there for a bit.

------
known
<http://en.wikipedia.org/wiki/Progressive_enhancement>

------
nico
Because of my ADD, I usually only barely manage to create an MVP and nothing
else! hehe.

