June 25, 2010

Learning When It's Time to Walk Away from a Project

I wanted to take the time to follow up on some of the additional lessons I learned from my May startup project, some of which I already shared in The Myth of the Single-Person Startup.

This week I decided to indefinitely postpone my startup project, the same project I spent a month of unpaid leave working on sixteen hours a day. The decision wasn't at all painful, and I came away from it feeling oddly successful and much wiser for it. The project taught me a lot of hard-earned lessons, the kind you only learn experientially, and all it cost me was a couple of paychecks - not bad considering that I don't have any obligations outside of paying my rent on the first of the month at this stage in my life.

But back to the point of this article: learning when it's time to walk away from a project. I have no idea how hard it is for other people to dump something into which they've invested a lot of emotional energy, time, and even money, but for me all it took was recognizing the following things:

  1. The effort needed to actually implement the project's MVP (minimum viable product) grows explosively even though you're not adding any new features or functionality.

    I suspect that anyone who reads this is going to think "well, why don't you reduce the complexity of your MVP then?" to which I reply "the point of an MVP is that that's as simple as it gets - you can't reduce it." Reducing my initial feature set wasn't an option given the competition in my space as it would forgo requiring my product's differentiation - although I had plans for something much more grandiose down the road, my vision of an MVP was assuredly realistic and modest on paper.

    However, when it came time for implementation I came to appreciate just how complicated some of the mundane details of the project truly were. It wasn't over-engineering, it wasn't poor design, and it wasn't any of the usual suspects - it was that I was unable to realize the full scope of the project's complexity without getting into the guts of it.

  2. The competitive space and surrounding ecosystem is changing more rapidly than you can keep pace with.

    My idea (a social media analytics tool for marketers) is in a domain with lots of fast-moving competitors. Although none of the present competitors have built anything that truly captures the value or essence of my idea, they're rolling out innovations and new products at a pace I cannot maintain, and they're better suited than I am to adapt to rapid changes in the surrounding environment, such as Facebook's rapid changes to its APIs.

    I'm a one-man startup trying to compete with well-funded companies in an explosively innovative space - without quitting my day job, finding funding, and building a team, things I'm not suited to do presently, it's a battle that would have been difficult for me to fight.

  3. The technical depth of the product goes beyond your technical expertise.

    This is also called "getting in over your head." As you can probably tell by looking around this website, my real world experience in software development is wanting not for lack of intellectual effort mind you. It's largely because I've been out of a computer science program for two years working full-time as a marketer.

    Nevertheless, I'm enthusiastic about getting back into it and I was excited to take on a big project like this. Unfortunately, I learned quickly that an MVP for a startup is a terrible place to catch up on programming techniques and technologies.

It's was really the combination of all three of these that drove me to ultimately shelve the project, rather than any single one. I'm sure with enough ingenuity and effort one could find the resources and methods to overcome at least one of these problems, but all three at once was too daunting for a young solo entrepreneur who was still working full time.

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..