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