Startup Mistakes | Hacker News Reader

Startup Mistakes

dopeboy.github.io

51 pointsmherrmann21 comments

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.

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.

"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.

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.

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.

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...

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.

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...

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!

So you are saying that an article written by a person that ran an unsuccessful startup for 1 year contains wisdom so deep the original commenter can't possibly understand?

Don't canonize startup founders. Many of them have no idea what they are talking about, even the successful ones. I'm not saying the OP falls into that bucket, but there is certainly no reason to dismiss that notion outright. Your description of startup life also is just your own experience, it doesn't apply to everybody and you have no reason to believe it does.

Human beings learn much, much better from many bits of concrete experience than from a single idea abstracted from that experience.

Hehe. You'd be surprised. :-) Many of the entrepreneurs I interact with are, sadly, in a situation that is very close to that of OP:

1. Little to no customer development

2. Lots of over-engineering

3. No co-founder when they'd actually need one

Having made many of the same mistakes he made, I suspect you're not in the target audience.

He's speaking to engineers who want to start a business. They frequently start by focusing on the engineering things and not on the things that matter to validating their idea is buildable and scalable in a business sense. It's easy to think "we're going to be in a world of hurt if we don't (have automated testing, pick the right framework, design for scalability, handle complicated edge cases, get the design right, etc)."

Engineers will often focus on these aspects while missing the bigger problems like "will the people telling me this is a good idea write a check right now to get it?" and "what non-technical roadblocks have I completely missed and won't be aware of until I'm iterating with customers?" These don't seem obvious to people who haven't been in the business of selling something before. And launching with half-baked crappy hacked software goes against every instinct of a good engineer who has worked at more mature companies.

Starting a business is about finding out, as quickly as possible, if anyone actually gives a shit and then building a business after you have determined that, yes, they actually might. The actual act of making the product feels like building a business but it is not.

No you're not mean because I thought the same thing.

The biggest mistake this guy made was quitting his job BEFORE validating whether there was demand for his idea or not.

Some of the things are obvious, but others not so much. I upvoted it because I went through a similar situation where (like the OP) I built a product without first figuring out the market and hard to learn everything the hard way. I'm sure plenty of others here on HN can relate. But mostly, I think those who are just starting out and thinking about building a product can learn a thing or two from it.

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).

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...

"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.

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

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/

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.

Reply on news.ycombinator.com