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

25. June 2010

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.

If you enjoyed this post, remember to subscribe to my RSS feed!

Startup

Comments

6/26/2010 11:25:54 AM #
Funny reading this post, and how much it resembles my situation, except for one thing: I'm still working on my software thingy.

It's close to a year now that I've been working on (yet another, it seems) social media analysis tool for marketeers or anyone interested for analytics, for that matter.

I regularly have doubts on whether my project will be generating any ROI, but I want to see if I can at least make something useful. And meanwhile I'm learning new stuff all the time, which is also payment in a sort of way - I can reuse what I learn.

Since I have a full-time day job, I can only program in the evenings (and being a bit more along in life, after the kids have been put to bed).

I hope to have something to show for my efforts in a month or two.
6/26/2010 3:11:47 PM #
Alex,

One of my Twitter (http://twitter.com/Cama) followers sent me this in response to this post:

thesquigglyline.com/.../

I think to some extent this is what you're speaking to - taking a big project slowly and do it well. Instead of going slowly on one big project I thought it would be best for me to shift to smaller projects that just take less time to complete.

I figure that way I'll have more opportunities to make mistakes with projects and more clean slates to make new mistakes, until eventually they aren't so many of them :p

Either way, stick with your project if you're happy doing it and satisfied how it's helping you as a developer / product designer.
8/5/2010 10:00:41 AM #
About number 3 getting in over your head. I find focusing on the process of the project instead of the outcome can help to be more effective and productive. There is a article by Dr. Kevin J Roby titled "Process goals vs outcome goals" that has a great example on why focusing on the process instead of the outcome works so well.

Add comment


(Will show your Gravatar icon)

  Country flag

biuquote
  • Comment
  • Preview
Loading