Learning the Right Lessons From Failure

John Finneran’s postmortem: “Fat startup: Learn the lessons of my failed Lean Startup” shows he did not learn the right lessons from failure.

Learning the Right Lessons From Failure

John Finneran recently wrote a postmortem on a startup that aspired to be “the 37 Signals of non-profit software entitled “Fat startup: Learn the lessons of my failed Lean Startup.” My concern is that he did not learn the right lessons from failure.

It’s a candid narrative the ends with four “lessons learned”

First, pursue achingly high standards in every aspect of your startup. Mediocre execution will slowly murder your startup.

Second, narrow the scope of your product until you can develop an extraordinary product. The purpose of your first release (and every other release)  is to give your customer immediate value. You are not launching a series of science experiments for you to learn what you should already know.

Third, find enough funds for a substantial marketing budget.

Finally, beware of Lean Startup principles, or any other shrink-wrapped utopia offered by the entrepreneurial dream industry. A weekend trip in a “Lean Startup Machine” may feel useful and fun, but treat their practical value with extreme skepticism.

SKMurphy Lessons Learned Were Quite Different

I had a different set of lessons from this article than the conclusions that the author draws:

• Your customer is the firm that will pay you. They picked a problem–writing a grant application that relies on a “logic model”–that may not be a real need. They interviewed 1,000 people seeking grants and found “writing a logic model is confusing, complicated, and impractical.” They don’t appear to have interviewed the organizations requiring the logic model to determine how it would be used beyond the grant application. If it’s only needed for a presentation then a PowerPoint version may be all that’s ever needed. I think there may be a deeper need to uncover in understanding why a logic model is required and how it’s updated over it’s lifetime. Conclusion: if you are going to create an on-line artifact to replace a powerpoint slide make sure it will be used more than once (e.g. needs to be updated quarterly to maintain grant, etc..). An alternative customer might have been to find grant writing consultants who wanted to become more productive.
• Pick a problem or pain point that is real and preferably recurring. One way to tell that it’s real is that a prospect will find value even in a partial solution or offering that only addresses a portion of the full problem. This is the core of a minimum viable product: it provides enough value for a target customer’s real problem/need that they will make a minimum purchase. Instead “our original idea put on weight quickly” they expanded their initial concept to become the 37signals of non-profit software.
• Most assumptions you make when you start out will prove to be imperfect and in need of refinement: plan for this. This is not a fault of any particular business model approach, it’s a function of your knowledge of the customer’s needs and buying process. One example from this situation: “We assumed customers would sign up online with a credit card.’ Most B2B software, at least for initial sales, will have to be sold with many conversations much hand holding. Lacking any testimonials or case studies, you will have to have a number of serious conversations with a prospect to ensure that you understand their needs and that they agree that you do.
• Rehearse the demo an internal champion (“earlyvangelist”) is going to run using their exact configuration; do this with enough lead time that you can identify and fix any issues it uncovers. If your internal champion does not want to rehearse then they are not really an earlyvangelist.
• Always consider starting out by selling the result that a customer wants as a service.  This is a startup that would have benefited from using the concierge model or partnering with a consulting firm already doing logic models. Their target customer wanted to pay for a logic model, they should have started by selling that result. It’s not clear if the customer would have used the application after submitting the grant so selling the result would have been a better place to start.

Update Wed-Jul-1-2015: the original website has been taken down but I came across more commentary on it at https://blog.smartdraw.com/lean-startup-right-strategy-fools-gold/ buried in the comments was this one by “Mike”

Mike July 8, 2014 at 9:15 am #
What I find utterly bizarre is that Eric Reis was a founder of IMVU in 2004. A company he continually cites as the lab in which he grew his Lean concept. Let’s take a look at that for a second. In 2004 a European start-up called Weeworld.com already had 10 million users creating avatars, buying virtual goods and occupying a series of virtual worlds. Weeworld already had institutional investment in place to the tune of $20M with global partners at MSN, Motorola, AOL, etc etc. IMVU effectively used this exact business template to approach the exact same Tween market with the exact same product. Call me cynical, but I’m a little confused as to when all this Iterative LEAN Product development took place, Eric? It was a classic case of “MeeToo.com”. How do I know?… I was that founder.

The Wikipedia article for WeeWorld

The avatars were created in 2000 by the then CEO and Founder of Saw-You.com, Mike Kinsella in Glasgow, Scotland. In 2003 Microsoft began offering the avatars[8] for use to their Hotmail customers via the MSN chat service.[9] The new service attracted 150,000 users during the first day of the avatars being launched, with the WeeMee website attracting 1.5 million hits daily.

The LinkedIn profile for this Mike Kinsella lists him as Founder/CEO of WeeWorld.

Related Blog Posts

• Pixar’s Ed Catmull Highlights Value of Post Mortems
• Hiten Shah: Four Lessons I Learned Squandering My Opportunity at KISSMetrics
• Record to Remember, Pause to Reflect
• Impatience For Success Works Against Learning
• Howard Tullman on Distinguishing Mistakes From Failure
• Rob Fitzpatrick on Five Mistakes Bootstrappers Should Avoid
• Failure to Thrive