Answer: "Because it wouldn't have mattered."
Before I made the plunge and decided to form a startup, I read everything I possibly could about the process... what to do, what not to do, etc. I knew all the mistakes first-time founders make, and I was pretty sure I'd be able to recognize the issues and avoid making any of the really big ones. I didn't expect to get it all right on the first try, but I was certain that I wouldn't get it all wrong.
Guess what? I still made pretty much every mistake in the book. Almost every single thing that I'd read about basically went out the window as soon as I began.
Why? Because once you and you alone own something and put it out to the world to be used, judged, loved, hated, it becomes a very emotional and very personal experience. And once emotion enters the picture, it's very hard to step outside of yourself and assess the situation logically and pragmatically.
When you work for a large company, it's very easy to distance yourself from the product you're building, because most of the time you are not the only one involved in building it. You shipped a buggy piece of crap? Yeah, it sucks, but it's management's fault because they set an unreasonable schedule. And that contractor that worked on that one part didn't know what the hell he was doing. My stuff worked great.
But now this product is your baby. And when someone tells you it's ugly, you're almost certainly not going to be able to take a good hard look, and say, "You know what? I can see where you're coming from."
This presentation is great. Every single point is true. But speaking from experience, having someone tell you about lessons learned isn't the same as actually learning those lessons yourself.
However, this is untrue. Smart people learn from their own mistakes, and stupid people never learn.
This. Kinda like marriage and relationships. No matter what your married friends/family tell you, you cannot plan it. You have to go through your own set of experiences, mistakes, ups and downs etc. etc. It is nice for someone to get advice BUT I would rather advice "You will go through your own shit. Remember there is no magic mantra and just be ready for the journey. Commitment is the key"
I knew working with customers was important but it wasn't until going through the experience myself that I realized just HOW important it really is. Reading these articles after the fact, help to solidify what I've learned and how I should approach my next startup/business.
The only point I might take issue with would be the talk-to-customers-before-you-write-code scenario. It depends on the circumstance, but it's been my experience that sometimes you need write some code in order to talk to customers. In our particular market, we won't get in the door without having something to put in front of a customer, simply as a talking point to start a conversation.
If there is one point that's understated, it's the notion of a marathon and not pivoting too fast. It's obviously a fine line, but it's a fine line between beating your head against a wall and working to find a breakthrough or secret sauce or whatever the model is that suits your product. Use the knowledge you find, but the less sexy approach of slogging it out is great advice.
Would wireframes not work? In my experience, telling a story about how your product solves a potential customer's problem with wireframes will get you a lot of conversations, IF the problem you're proposing to solve is important enough.
But yes, I can think of plenty of scenarios where wireframes would do the job.
Also, you don't always have to take investments at all (which the author may or may not have been alluding to). We bootstrapped Pathwright out of an existing consulting agency.
I think more people need to realise it's an option and a choice, not a required stepping stone.
I'm not sure what you mean? Why wouldn't battle-tested well-worn advice work with the techie crowd? And who is the techie crowd? Programmers? Tech lovers?
I'm just confused by your comment.
"Stop writing code"
"Don't worry about engineering"
"It's a marathon"
Won't sit well with technical people (mainly programmers, CTO co-founder, etc)
"Stop writing code/did you talk to your customers yet?" - he's so right. I've had to trash a lot of iterations of our code because we didn't heed (or grok) this advice.
I still think code is very important. But coding the best thing ever and it not being used is a nearly 100% waste of effort.
I can imagine that developers who haven't gone through such an experience might feel different, though.
Either way, nice read. Thanks for sharing your lessons learned :)
A good metric on this is the number of investments they've made. More than 4 and you're probably not getting any time.
The point has validity, but I've seen more (and larger) problems caused by likable but not-quite-qualified employees than I have by unlikable but qualified employees. A good board of advisors and broad feedback can help spot this problem and offer appropriate prescriptions.
Likeable B/C-players are tougher because if you lack domain expertise (and aren't getting good advice) you might not realize they're a B or C player until it's too late.