Reframing Failed Projects

The word failure comes with a negative connotation, but should it? I’ve been grappling with this question the last few weeks. If an attempt isn’t successful, is it therefore a failure? Is there no middle ground? Does failure imply a boolean?

Originally published on Medium

A few years ago, I built an app that I never followed through on. Needless to say, it never became an overnight success, or really anything close to a success. It’s a given you have to tell people about a thing before they’ll even know a thing exists. But yet somehow, some bots found it and I had to add captcha. If a tree falls in the forest…

Irrespective of my lack of marketing, I took it off auto pilot and shut it down recently. I couldn’t help but feel like it was a failure. But was it? I learned a lot. I built the app. I designed all of the functionality, including some complex calendar parts. I installed the security certs and established the deployment pipeline. I implemented some new email APIs I hadn’t interfaced with in past apps. I hooked it up to Stripe for payments. It certainly wasn’t a waste of time because I learned a number of things. But I still felt like it was a failure when I shut it all down and eliminated the hosting bill.

It’s easy to say why it didn’t go anywhere. That part is dead simple. I didn’t follow through. I didn’t promote it. I didn’t build the mobile client and find the App Store traffic. That part is black and white. I don’t feel bad about that part. Other things in life were prioritized over doing those things and with good reason. This was a side project after all.

This lead me to start thinking about whether failure is always a bad thing. Maybe I could reframe the label and call the app a prototype or learning experience, but that is an injustice. I set out from the beginning to build an app and make it publicly available and by all means it was. If you stumbled upon the URL, you could start a trial. You could even pay for it if you wanted to. You could have invited your friends and family and had your own little private social network. In the functionality sense, it wasn’t a failure. I just didn’t make it a screaming success and attract all of the VC dollars that people may have been willing to throw at it. In the business sense, it failed. No one signed up. No one paid to use it. Failure as defined in business 101.

I called it quits and shut it down. And that felt good honestly. One less distraction. One less app to maintain. One less monthly hosting bill. Remove that project from the list. But the little piece of nagging was still there in the corner of my attention. I spent hours building something and now it was no more. It’s a feeling that I am sure will go away, but I wanted to understand how others felt about projects that they ran and eventually shut down.

Adam Grant*, author of Originals, covered this topic. To quote: “The greatest originals are the ones who fail the most, because they’re the ones who try the most,” Grant says. “You need a lot of bad ideas in order to get a few good ones.”

It is a stretch to say that this app, that I failed to make succeed, will eventually lead to a good idea down the road, but maybe. However, my ego likes the idea of reframing the failure as “I tried”. There is some truth in that. I did try. I spent the hours and accomplished something. I was able to build something that not everyone can do. It took time and effort and knowledge. So I did try, and as I mentioned above, I learned a number of things.

On a sidenote, it’s common to hear “well, I tried” which often carries a disappointment implication. Maybe we’re doing that wrong. Maybe we need to drop the “well”, and celebrate “I tried”.

Steve Jobs has many quotes on failure. In a YouTube video with nearly 3 million views, he explains you have to try and be willing to “crash and burn”. I didn’t set out to handle crashing and burning. I set out to make something that would hopefully gain some traction and by some definition achieve success. I didn’t achieve success. I know why. So now, I have to become ok with crashing and burning. That’s easier to wrap my brain around with the connection to trying.

Many of us build apps and processes and projects that either never see the light of day or maybe run for six months before we call them failed experiments. More of them should probably be considered prototypes truly, but that is a whole different topic.

Another sidenote: I don’t think the industry uses prototypes or recognizes prototypes as much as they should. 

With these projects, maybe we could go into them with a mindset of “let’s try” a little more. Be more curious and remove the fear of failing. Obviously, there is money to consider and people’s time, but most software only lasts a few years at most anyway. Regardless of intentions and mindset, the software we write today more than likely will be erased or removed or replaced in the next few years. The lines of code matter less than the idea and the trying. We have to give the ideas a try. Maybe if I had the mindset of “I’m going to try building this app” with the sole intention of seeing what it takes to build the idea, maybe the nagging feeling would never have surfaced. I was successful in that case. I did see what it took to build the app. The failure side depends on the perspective.

My app was small and I was the only one impacted. That is not the case inside organizations where there is a team behind the effort. More people may be left with the nagging feeling when something is shut down or considered a “failure”. Is there a way of framing projects as being a “try” or ephemeral from the start to prevent the nagging feeling if the project doesn’t become wildly successful? Morale is important. Setting proper expectations from the start has dramatic impacts no matter what the topic is. As someone leading an engineering team, the definition of success is important to define up front. Maybe that definition includes things like “learnings”.

I’m treading into Eric Ries’ territory here. In The Lean Startup, he advocates that startups should place a lot of value on “validated learnings”.

“

In the Lean Startup model, we are rehabilitating learning with a concept I call validated learning. Validated learning is not after-the-fact rationalization or a good story designed to hide failure. It is a rigorous method for demonstrating progress when one is embedded in the soil of extreme uncertainty in which startups grow. Validated learning is the process of demonstrating empirically that a team has discovered valuable truths about a startup’s present and future business prospects. It is more concrete, more accurate, and faster than market forecasting or classical business planning. It is the principal antidote to the lethal problem of achieving failure: successfully executing a plan that leads nowhere. - Eric Ries

”

That may cut to the heart of it and explain my nagging feeling. I wasn’t mindful in the beginning about what I was wanting to learn or prove as a valuable truth. I am using learning as a good story designed to hide failure. However, it remains to be seen if what I learned have discovered valuable truths about a future business prospect.

That may be the key takeaway for me. In future projects, either solo or as a team, I should define what learnings are to be validated. The team or I will define what valuable truths can be discovered along the way and how to measure them. Teams and organizations should be able to do this within a short period of time, iterating as they go. I could have done the same and I didn’t. It’s not exactly mindful to think I’m going to go build this app and turn it into a business. That’s not putting a lot of thought into it. It doesn’t properly plan. It doesn’t set the metrics or the timeframes needed to measure and validate. It sets you up for failure! Yes, I tried, but I set myself up for failure by not establishing the validations along the way.

My nagging feeling will certainly go away, and probably as soon as I hit post on this piece. I did try which feels good. I could have properly defined my goals better before getting started. I’ll be sure to do that in the future on both solo projects and with teams. I look at failure a little differently now. Failure is actually a log of tries. More tries are a good thing. It gives us data to work with. Shutting things down and carrying the knowledge into future projects is also a good thing. Being mindful of the why, before you try, will have a dramatic impact on the “success” of a project. Hopefully this will help your mindset before you try your next project as well.

[^1]

[^1]: Watch Adam Grant’s Ted talk at: https://www.ted.com/talks/adam_grant_the_surprising_habits_of_original_thinkers