Approaching a Minimum Viable Product for a Startup
threeriversinstitute.org
threeriversinstitute.org
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.
A lot of people have this inclination. Maybe this frame of reference will help you, because it helped me: don't worry about not making a splash your first day, because nobody will see you, anyway. 99.99999% of the people who eventually visit you will not be there on your first day. For someone who arrives on day 2, day 20, or day 2,000, you just launched.
The day I launched, I had 124 visitors to my site. Most of them were, in all probability, not wowed. I got better. It is now 3 years later. Today, I launched to 800 people (plus some folks who have visited before -- welcome back, returning customers, I am eternally grateful for your support).
I've got a notebook sheet worth of tweaks to do today, to get ready for the launch tomorrow.
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.
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.
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.
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.
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... (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.
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.
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.