Fat startup: Learn the lessons of my failed Lean Startup

There seem to be two schools of thought here, both interesting to me. The author seems to think that his failure has something to do with problems associated with the "lean startup" model and other commenters (lean startup adherents, apparently) seem to hink his failure has something to do with failing to properly follow the tenets of the philosophy.

I suspect actually that the author adhered about as closely to "lean startup" as many self-identified "lean startups" who have succeeded in the past, and made a pretty average number of mistakes in the process. I don't think of 'lean startup' as a way to guarantee success, I think of it as a way to fail gracefully if you don't succeed. The author came pretty close to this, actually - it doesn't sound like they burned through enormous piles of venture capital money, it seems like they learned a lot in the process, it seems like they didn't spectacularly fail to make payroll causing half a dozen family-bound engineers to suddenly lose their livelihoods. The only less-than-graceful element of their failure was that it took two years, which is probably a little (though not a lot) on the long side. Frankly late in the process they came pretty close to scoring what sounds like it would have been a pivotal investor, and that combined with lessons learned could have produced a true MVP, product market fit, and a viable startup...

So, I think the author successfully followed a good chunk of lean software advice, made some mistakes, got unlucky, and failed. This is what most startups do - even most lean startups - and there should be no shame in it. Paul Graham himself has remarked he wishes he were able to bring himself to invest in more likely-to-fail black swans because that's the way you get to own enough vol to have a real winner in your portfolio - we all should be more comfortable with the risk of failure.

What I've learned from my failed startup during 2000/2001 [1]: With enterprise software the MVP is a power point deck with mockup screen shots. You first need to validate the idea, words, concepts before you start developing. This also helps with the deep decision pipelines that enterprises usually have to buy your enterprise software.

Next time I'd start immediately going around with a powerpoint deck of mockup screenshots instead of developing software first (which we did and failed).

[1] http://codemonkeyism.com/6-reasons-why-my-vc-funded-startup-...

Minimum Delightful Product is the variant that I like best.

"Our first customer, a Canadian social services department, was led by a Deputy Minister with a fondness for a wall chart showing the logic models under his charge."

Several years ago, a friend and I started a non-profit that tried to work closely with a Canadian social services department. Consequently, when I read this sentence, I cringed. Turns out that big Canadian government departments have these massive tomes called 'procedure manuals'. These procedure manuals spell out every single activity that the department could possibly perform, seemingly in the name of getting rid of ambiguity, judgement and any sort of innovation. Consequently, trying to innovate alongside a government department is, more often than not, an extremely frustrating experience that results in a pissed off client and a stymied startup.

Long story short, just because someone comes at you with money, it doesn't mean that your demand is validated. Rather, sometimes the wrong kind of customer is worse than having no customer at all!

Organizationally, non-profits are a special beast, requiring very different handling than corporate IT buyers. I don't think the Fat Startuppers grok'd their customers at all.

Honestly, I don't think they learned very much - their "four fundamentals" are just platitudes. There must be more to this story - I wish they could unearth it within themselves.