Fumbling To Success: How Founders Do Things the Wrong Way

Success image from Demetri Martin’s “This is a Book”

For some reason, Founders are very open about all of the things they did “wrong”. Whether or not things worked out in the end, everyone has a narrative about how they bucked the trend, ignored advice, or just plain screwed up.

I recently asked 53 founders that I know about how they did things the “wrong way”. A few dozen replied. Due to my poor wording, about half of them interpreted the question as “What did you do that ended up being a mistake?” The other half interpreted it as intended: “What did you do that people told you would be a mistake but you did it anyway?”

The two interpretations actually worked out quite well, which is kind of my conclusion — things that were arguably “mistakes” are often responsible for success. In the responses, the key decision that doomed one founder to failure would be described by another as a non-traditional choice that brought success. As an entrepreneurship professor once told me, knowing all the “right” ways to do things can be detrimental. If everyone did things the “right” way, every company would be mediocre and average.


A big area of “non-traditional decision making” was around funding. As I’ve written about before, Context Optional had an unusual funding path. Other founders described their own funding quirks:

  1. Took VC money with just an idea. Didn’t work out. Wishes he hadn’t taken the money. Less funding “forces you to think through how you might build the solution to a problem you are envisioning in the simplest way possible.”
  2. Took VC money with just an idea. Worked out. Gave them the needed runway to actually find the right product. “There are a million things I’d do differently except for this.”
  3. Turned down VCs to take money from angels. Worked out. Allowed a smaller and more flexible outcome. “Because we had only taken angel funding, they were supportive.”
  4. Turned down VCs to take money from angels. Didn’t work out, because funding opportunities dried up. “You cannot control timing, but you can be far better prepared for adverse changes.”

What can we learn from this? Depending on you look at it, it’s either hopeless (there’s no right answer) or liberating (no matter what you choose, you can succeed). My favorite response about fundraising the “wrong way” comes from someone who shall remain anonymous:

We never, ever, ever, EVER took our eyes off of fundraising: it kept the company alive in spite of doing anything (and often everything) else wrong. When we weren’t fundraising it was because I am lying we [were] always fundraising… I’d rather be in business and incompetent than not in business.


When it comes to product, most of the responses indicated that non-traditional approaches didn’t work out. When they strayed from the modern approach of building the simplest possible product and validating it with users, things went wrong.

  1. Built features before they were necessary. Didn’t work out. “Every day is sacred when you’re building a company and even if something ends up being only a few days of wasted time, it can still sting.”
  2. Built for the wrong market segment. Didn’t work out. “Pretty much every time we’ve messed up it’s because we started with a solution rather than a problem.”
  3. Built slides instead of a product. Didn’t work out. “We would have horrified anyone who likes to lecture founders with the phrase ‘product-market fit’… Eventually we stumbled into a product by accident, not by genius or by iteration.”
  4. Built a solution to an emerging but not yet accepted problem. Didn’t work out. “Turns out the naysayers were right, at least on any reasonable timeframe. I’d absolutely do it again, but I’d try to be smarter about the timing.”


The dizzying array of NoSQL databases, JavaScript frameworks, and new languages make decisions on how to build stressful and complicated. In most cases, the responses came from Founders who were technical, but not /that/ technical. They were mixed on how well their technical decisions worked out:

  1. Non-developer wrote initial code. Didn’t work out. “My original PHP code… was a hole that the developers on my team were digging out of for 4+ years.”
  2. Underinvested in infrastructure and testing. Worked out… eventually. “Did we pay the price later? Yes. But how MUCH later. About $60-70M in revenue later. I will take that exchange.”
  3. Used unproven, but promising technology. Outcome still pending. “That’s a big bet on the future of other startups aligning with ours. We’ll see how this turns out in the long run, but it’s certainly exciting.”


Well, if my small sample size, non-scientific methods, and personal biases are any indicator, you can do quite well by marching to the beat of your own drummer when it comes to funding. You can, and particularly with Engineering resources at a premium should, innovate when it comes to technology. But when it comes to product, do it the “right” way — make sure you’re addressing a real problem with a simple solution that you validate early on.

Note: Due to the self-deprecating nature of the quotes above, I’m not directly attributing them to their sources. You guys know who you are.

Leave a comment

Your email address will not be published. Required fields are marked *