Costly Mistakes Made by Startups

This analogy isn't making a lot of sense:

"It’s like they put a sign on a door that said “Free Lemonade” and a bunch of people came inside… only not that many people are drinking the lemonade… What’s wrong?? How do we fix it? They ask.

"If anyone had bothered to mingle about the room and strike up some conversations, they might have realized that the majority of people in the room were diabetics… So they couldn’t drink the lemonade.

"They came in the room hoping there would be other drinks… like water… but left after they couldn’t find any. Had someone learned this information and grabbed a case of water, the room probably would have stayed full and more people would have showed up… even without changing the lemonade sign (word of mouth travels fast)."

So the diabetics came because of the lemonade sign even though they can't drink it? And while they're in the room, word of mouth about free water is spreading outside the room? I'm having a hard time picturing this scene.

I'm not trying to pick on you, just suggesting that this section might be improved by replacing this confusing story with something more related to the real world :)

Only one Mistake. Reading too much about startups and not actually doing anything of value.

The other one is being busy "startupping" and not, you know, actually building your business.

Every single point he made is crucial for a startup to succeed. I know - I spent 14 years bootstrapping my software company (exited last year). I think this article is excellent.

While ALL his points are valid, I want to differentiate between two specific points he made.

1. "If you’re not talking to your users, then you’re simply guessing at what they need and want from your business. This is slow suicide."

2. The section called "8 — Building Too Much Stuff"

When you talk to your users, you WILL get that feature list one-mile long. If build that list, you'll end up with a product that doesn't have an opinion. Your product won't be targeted at anyone specific. Why should a customer pick you over competitor X?

So, to know what to build, you must talk to your customers and know them. But you must know yourself as a company - why do you exist? What kind of customers do you want (size - small/med/enterprise, industry, location if applicable).

For example, define your company as "Performance review software for medium sized US cities, counties and law enforcement" versus simply saying "We make performance review software". This helps you determine a focus and know which customers to target and which features help them.

Further to the "building too much" section, you only need so much to close a sale. After a while, the new features are great for reducing support or customer retention (both of which you should be measuring), but build too many and you risk having a complex product with training costs that are too high and even more importantly, investing in features that don't help you sell the next customer. At some point, move on to the next product.

Also a tip, we stopped building lesser-used admin features that required a UI. UI is hard to maintain and train people (and hard to kill that feature). Sometimes it's possible to simply have a script you can run that will make changes to the data model that customers would like to have. When customer call asking for something, you can offer that solution and have your dev team run the script.

On visual design, if you don't have a visual designer you are simply asking someone who is not a designer to do it instead. You're fooling yourself if you think you are somehow not doing it.

Having a designer on board from day one in no way means that you can't experiment. In fact, a good designer would have told you about many of your other recommendations such as "user research is important."

I'd replace 9 with "Not taking design seriously."

The fire soon fire often ideology is stupid advice for anything but a small startup. The reason it's stupid advice is that you already have a bunch of people that over time will develop their own politics in the organization, and they will then exercise power in the organization using that politics. For instance the developers will figure out ways of working less by overestimating everything or forcing project managers to do additional work to delay things, and any new developer that does not get the games that they are playing will be denied enough information by the lead developer to do his job properly and will be promptly fired for that. Any new comer that does not adhere to their politics will be fired. All that this sort of advice does is it maintains cultures, whether they are positive or negative. Good team players can get kicked out to maintain the rotten apples or vice verse and often upper management is clueless to what's actually going on.