I have been involved in many startups. The same problems come up time and again. But it seems that teams often just want to go out and learn lessons the hard way, just because they believe that’s the only way to learn.

Here are a couple of recent postmortems that are worth reading, with a summary of key learnings. As I find more, I’m going to add them…

Flud — social newsreader (just for the record, what a depressing name! Flud sounds like Dud. But that’s apparently not why they failed. Or so they say. However, the name does offer opportunities for cheap cracks in headlines… Flud’s a Dud comes to mind. But I digress.)

Here’s what the co-founder Bobby Ghoshal says he learned in this Techcrunch article:

• Don’t chase the press; let them come to you.
  In Flud’s case, press caused numbers of users that Ghoshal the product wasn’t ready for.My take: this is true for a consumer product that needs huge numbers; less true for a B2B product which may look for smaller, higher quality numbers. A better way to grow numbers in a less spiky manner — word of mouth.The important thing to remember here is timing: do not, under any circumstances, start seeking press approval until you are ready to take it. PR is not for the faint-hearted. It can go spectacularly wrong.  Timing is everything.
• Don’t worry about competitors if you truly believe your vision is superior, stay calm.
  Ghosal warns that competitors get inside your head and freak you out.My take: but don’t let that allow you not to look and learn; figure out what you can learn from competitors and then add your own spin. Take their best ideas, and leapfrog them.
• Test, test, and test again.My take: what can I say? I can’t count the number of times I ask “what’s the test plan here, guys?” and I’m met with the answer “the programmer has tested it.”

  Don’t forget this: programmer/developers/engineers should never, ever be on the front lines to test their own code. They are the worst people do be asked to do that. Don’t miss the step of quality testing! Bugs stick to me like burs on a dog. Probably because I do things that the engineers never think of.

• Stress test. Load test.My take: again, never miss this step. A stress/load test is a special form of testing, so get an expert. If you don’t know how to do it, find someone who does and get them to help — even if it’s an afternoon’s chalk talk. You’ll regret it if you don’t.
• Know your customers and what they want.My take: but careful not to let your customers design your product. Guy Kawasaki wisely advised me once, years and years ago, “if you let customers design your product, we’d never have got Macintosh from DOS.” I know you’ll probably not old enough to remember what that means, but it’s true.

  Your customers can guide you, inspire you, help your vision … but you need to know where you’re going next. Your customers tell you your next two or three features; they aren’t there to give you even your 6-month vision, let alone your 1-year or 2-year vision.

• Growth or engagement? Growth wins.My take: this is true; you need to to focus on bringing in the users.

  However, if every user visits once and never comes back, that’s a lousy user. Your product has to be basically useful and sticky, and has to have hooks of some sort that encourage users to come back again.