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.
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"
They can help give a slight leaning but I agree that experience definitely helps.
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.
A friend of mine manages a TechStars outpost, and many of these slides reflect a common point driven into the TechStars community: focus on users. It's a great point as well.
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.
> 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.
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.
That's a practical answer and good suggestion. For us, wireframes don't quite work -- we need a little interactivity (customer base, plus existing market entrants, require something...mostly for appearance of progress.)
But yes, I can think of plenty of scenarios where wireframes would do the job.
Echoing what I have learned myself. If you are an entrepreneur and you haven't read "Nail It then Scale It", do so now. No, really. There are few books I solidly recommend, particularly for business, but this book is the one I have found most valuable time and time again. When you finish reading it, go back to these slides and see how many were addressed. Absolutely zero affiliation with the book or authors, just a big fan.
I can't agree with the "investment != success" slide. It's easy to get caught up with all the things you read in the media about Y company raising X amount. Soon, you start to use that a success metric. This can lead to a lot of tension, frustration, aggravation, and self-doubt if you never raise that round.
He's not really making any controversial claim here, he's just saying taking money isn't a guarantee of "making it".
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.
Whilst not controversial, I think a point that needs to be made. A lot of people have their sole focus/goal on raising money. They then raise money and their next sole focus/goal is raising more money.
I think more people need to realise it's an option and a choice, not a required stepping stone.
But raising the round doesn't mean success whether you want to think it does or not. It may relieve internal pressures on a team/founder but that's because they foolishly value it as a "success metric". For me, the slide is one of the more important ones to remember.
"Subsequently many of the points won't sit well with the techie crowd."
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?
As a tech co-founder, I thought this deck was spot on. Maybe it's because I've been through that experience that I don't feel threatened at all byt hat slide.
"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.
Maybe I'm naive but I have to wonder how you can raise a decent clip of angel money and none of the angels told you any of this. Seems like you should add "get angles that are interested in the business and can provide more than just money"
Either way, nice read. Thanks for sharing your lessons learned :)
Have you done it before? Just curious what you're experience was. I've always found that the angel who's willing to put in a lot of time (not just at the inflection points a la every angel group) is really hard to find.
A good metric on this is the number of investments they've made. More than 4 and you're probably not getting any time.
This is a good deck. Thanks for sharing. I'd be really surprised though if really no one had told you at least some of these tips before you had to discover them for yourself.
The only thing I'd consider changing on this deck is point 6 about hiring and firing.
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.
My unproven theory is that assholes are less of a problem, because it's relatively easy to identify assholes and avoid hiring them in the first place.
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.
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.