back

by KentBeck·17y ago·view on hn ↗
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.

1 comments
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.

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

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.