
Startup Mistakes - mherrmann
http://dopeboy.github.io/Lessons/
======
ffn
I absolutely agree with the writer's point about over-engineering. In start-up
/ small business land, optimizations are worthless because the main problem
isn't that "oh, I have a poorly performing inefficient system", and is instead
"I don't have a system and need to build one." So to a start up founder,
timing correctly when to do something is far more important than doing that
thing amazingly well (passable is enough).

In other words, technical debt is not a bad thing (just humbly apologize for
it later).

And regarding building a startup by yourself, I'd like to expand that to never
build a network-related startup by yourself. That is, if...

value = k2 * users ^ 2 + k1 * users + k0

never build a product where k0 = 0 or close to it by yourself. This means, for
example, if you're by yourself, build an indie game where you jump on
platforms, but never attempt "facebook for dogs". This is because you can't
get customers to pay $ for no value, so building social networks without an
extremely strong initial user base in your pocket (which, unless you're a
celebrity, you don't have) is the tech equivalent of buying the lottery. In a
lot of ways, social network features on an app is like legal - if you need to
worry about it, you've already gotten to the point when you can delegate an
employee to do it.

------
softdev12
This is awesome. When I read the previous post by OP that hit the number one
spot (called Consulting), I immediately wished that there was a post-mortem on
the failed startup.

This is important for many reasons, but the least of which is that there's too
little written on what goes wrong with a startup. Everyone (especially the
media) seems to think that every startup becomes one of the billion dollar
darlings that saturate the news.

My take on the overall concept was that it was going to be really hard to pull
off, because you were building a two sided marketplace. And that's exactly
what airbnb is (which is why it's appropriate you called the startup an airbnb
for cameras). Even if you had you perfect execution and built a product that
was 2x better than anything that existed, getting a two-sided marketplace to
work requires an extraordinary amount of luck, marketing, and timing.

The flipside is that once a two-sided marketplace exists, it's really tough to
displace (for exactly the reasons that it's so hard to start). So I would have
loved to hear your rationale for thinking you could overcome the odds of
building a two-sided marketplace. It's twice as difficult as a normal startup
because you need both the sellers and the buyers. And one is not valuable
unless the other is there at the same time.

------
jakejake
"We should have built the absolute minimum and then manually maintained
transactions through the backend if need be. To hell with formality. We were
in the business of proving a hypothesis yet we acted as if it had already been
proven"

We do this at my company when we add a new feature that we are not sure will
take off. You can get something running quickly that looks good enough to the
customer, but behind the scenes is all smoke and mirrors. Then if the amount
of traffic starts to grow you start putting in your automation.

It's really hard to resist the urge to build out all of your automation,
scaling, etc up front. But, most of the time the new feature goes unused and
it winds up being a waste of time.

~~~
untog
This is where client-side A/B testing frameworks can be really useful, but
people get all huffy about it. Inject some custom HTML onto your page! Yes, it
looks a little ugly when you look at it closely, but 95% of your customers
won't. It'll prove a hypothesis very, very quickly.

------
birken
I agree with lessons 1-3, but I'm not convinced about the rest of them.

By definition, any engineering on a failed project is "over" engineering. But
there are certainly some projects where investing in a little more development
at the beginning will have a greater payback later.

Lack of risk subsidizing never stopped craiglist or airbnb (in its early
years). If people want something badly enough they will figure out their own
way to deal with the risk.

Having a good cofounder is probably better than not having one, but there are
tons of successful products and companies started by individual people.

If the market is busy kicking your ass, a little positive encouragement can be
helpful. All startups are really tough at the beginning, and this one never
made it out of that stage. But if it had, this rule would probably be the
opposite. Also if you want some critical opinions, just try to raise money.

Certainly after an failed startup it makes sense to look back and try to
figure out what went wrong, but you also shouldn't overfit. I realize the
medium of blog posts does reward overfitting and making rules, but the real
world is much more nuanced.

------
confiscate
Sorry, don't mean to be mean, but why is this upvoted so much?

Seems like a lot of obvious things no? I agree it's a lot harder to spot when
you're in the middle of it all, but in terms of material for a blogpost, these
"learned lessons" are pretty common/generic, right?

How would this be different from, say, "don't forget to file your taxes or
you'll waste a lot of time if you get audited". Do you really have to go
through an entire failed startup to learn these "lessons"?

Some of the other better postmortems out there have rare insights like "don't
talk to corp dev they have an incentive to pretend to want to acquire you to
waste your time and distract you", or "don't be tempted to expand to too many
geo locations too early or you'll be stretched too thin". Lessons that would
be hard to learn without actually going through a startup yourself. Compared
to those, the lessons here seems...generic

Sorry maybe I misunderstood. Can someone whack me in the head and bring me
back to reality? Maybe it's just me...

~~~
RKoutnik
Apologies for the harshness but your comment makes it clear that you've never
run a startup before. Regular office life is like juggling three balls -
difficult, but manageable with practice (and they're given to you - so you
never need to make a judgement call about what is important). Startup life is
like having hundreds of items all thrown at you from different directions.
Only `n` are valuable - _and you have to decide which ones those are_. Some
can't be juggled, others look promising but are worthless, etc, etc.

It's incredibly easy to get lost in the barrage of objects. Articles like this
one help founders refocus and figure out what's important and what's not. Many
things seem obvious in hindsight that are completely lost in the present.

~~~
confiscate
Ah interesting

Yes I absolutely agree with that. Maybe the 7 "lessons" in the article are not
the real lessons--the real lesson is, as you said, focusing on the
right/important items.

Also, I think point (3) in the article qualifies as something that would have
been difficult for the writer to learn without going through a startup.

I would say, though, advice like "not choosing a confusing name for your
startup", seems, well, obvious, no? I definitely respect the guy for starting
his own company, but not sure how I should feel about someone who can't even
choose a non-confusing name for it...

~~~
iolothebard
Lmao, find a "non confusing name" that has available .com, .net and .org
(because you don't want to buy them after you've started).

Good luck!

------
clairity
repeating such lessons of missing product-market fit is worthwhile if only to
remind us to keep watching out for these pitfalls. otherwise entrepreneurs may
think they no longer matter and make the same mistakes.

it's easy to let yourself think you know the market instead of asking it
(mistake #1), because marketing research is a hard, ambiguous process, while
coding is at least logical and the path (may seem) more obvious (mistake #4).
and while you're in this bubble, you need encouragement (mistake #7) to keep
you going, especially as a single founder (#6, arguably a mistake). these are
all mistakes i've made too.

the statement i disagree with is "I'd like to think I got a very cheap MBA
along the way." it's unlikely the author got much of that, since in most cases
mba's learn much more about running an existing business (accounting,
financial projections, etc.) than starting a new business. to be fair, there
is, at the core of an mba program, a theme of making decisions under ambiguity
and trying to bring as much concrete information into the decision as
possible, and the author may be referring more to that aspect. in any case,
building your intuition for good decision making requires learning from your
mistakes (like other talents).

------
baby
Another post that shows how important it is to launch MVPs (minimum viable
product). I often see friends spending a huge amount of time coding something
that when finally released doesn't build any traction.

This article kind of resonate with me. I have a great product that is being
used by hundreds of people everyday and I get constant requests for
iOs/android apps. If I had more time I would learn how to make a phone app and
I would monetize it...

------
meesterdude
"we should have built the absolute minimum"

This is an easy trap to fall into. While not bad advice, because its easy to
overbuild - sometimes polish is what gets you to success. If slack built just
the bare minimum and didn't flesh things out thoroughly, they would not have
been nearly as successful.

~~~
shaftoe
You don't build the minimum and stop there. You build the minimum to prove an
idea is even worth going further on.

------
namenotrequired
For those interested, I work for a startup that does something similar to what
Qhojo did [1], but for all kinds of stuff.

Thanks for sharing your experience.

[1] [https://www.peerby.com/](https://www.peerby.com/)

~~~
free2rhyme214
That could be useful instead of buying new things but only if you can get
enough users on the service to lend stuff. Then obviously you'd stick ads on
there like FB or Twttr.

