Embarrassment Driven Development

This site isn't complete and I'm pretty embarrassed, but that actually helps me.

There is commonly referenced startup advice from investor Reid Hoffman, "If you’re not embarrassed by the first version of your product, you’ve launched too late.

I'm in the process of building a product I've wanted to build for years and I'm trying to launch as quickly as possible with a minimal but realized concept.

This site along with that product are things I've wanted to work on for a while. People often say that about their blogs or portfolios and keep shoving it aside for later I've noticed.

I did have a portfolio site up for a while, "Here is my work, let me explain." It wasn't too hard. But now, I'm going to try actually writing but I have something to say after 34 years. It's not original or clever but I'll be earnest and candid.

To that end, I'm going to be candid.

I've been working way too long on this site and it still looks like shit. The general layout is fine, it's making progress but it's not where I want it to be.

But since very few people if anyone will ever read this, I decided to launch it today.

Also, it's a blog. Write words, publish. The goal of MVP has been accomplished.

After launching a "polished" product and now this blog. There are always problems that arise. Bugs or issues, for whatever reason I did not or do not see during development.

I finally deploy and I look at my work at its actual URL and there is usually something that is either a true bug, a typo, or something that just feels like crap to have out in the world for my own ego or users.

This clarity I have post-launch is incredible. I'm calling it Embarrassment Driven Development.

Introducing EDD

Everything I have on my to-do list prior to launch suddenly sorts itself very quickly in order of priority.

At that moment, I clearly see the next thing to do. I can either do it then if I'm very motivated or it's my first to do the following day.

This is extremely helpful in prioritization but also in clarifying the work to be done.

In Embarrassment Driven Development, the goal is to remove embarrassment as quickly as possible and this had led me to some pretty clever or downright simple solutions.

It doesn't mean you leave it be once you've deployed a fix. It just means you had the first crack at it so it's not so gut-wrenching to have out in the wild.

Then you have another two great realizations after you deploy something. You can either:

A) Start working on the better fix that you wanted to do but it would have taken longer to finish.

B) Start working on the next thing that might be even more embarrassing.

Option A is great because it means you might have a shortlist of embarrassing stuff.

Option B is cool too because you stopped the bleeding on one embarrassment and are able to quickly move on to the next item. You're kicking ass.

And furthermore, Option A, even if you want to eventually come back to it, might not be the most pressing thing later like you thought.

Embarrassment for the Masses

Not sure how I feel about this concept but it keeps working for me so I'm going to keep thinking about it.

I think embarrassing features or at least the embarrassment you feel is kind of like the weakest player on a team.

Your project probably has a star of the team that probably gets a lot of attention. But the star is handicapped by a poor performing team around them.

There are loads of incredible tools online that do incredible things. However, if their login is broke, a roleplayer if you will, it doesn't matter what their star is doing on the other side of authentication.