What I'd tell myself about startups if I could go back 5 years

http://www.talkingquickly.co.uk/2015/04/what-id-tell-myself-about-startups/

by vinnyglennon • 11 years ago

865 275 11 years ago

talkingquickly.co.uk

peshkira• 11 years ago

Very interesting points. I agree with many of them as they reflect my own experiences.

Assuming you are the author :) Could you elaborate on 3 "Always refuse if someone asks you to sign an NDA before hearing their idea".

This is something I always find frustrating, but I usually end up signing the NDA as it seems irrelevant to me anyway. I'd be interested to know how people react when you tell them that you don't want to hear their idea. Do they change their attitude towards it, or you don't follow up?

talkingquickly3• 11 years ago

Hey, author here. My logic is usually that an NDA is a restriction on me, so I won't usually sign one unless I'm getting something in return. E.g. I'm happy to sign one in the context of a piece of paid work.

Most people are quite receptive when I explain the above and that in practice I don't believe that ideas really get stolen. Well not (web/app)tech startup ideas anyway. I've never had what you'd call a "bad" reaction to it and in about 75% of cases, people have then gone on to explain their idea.

ckluis• 11 years ago

I just say I have a $2,000 NDA fee as it places liability on me.

prawn• 11 years ago

In my experience, if I explain that I won't sign an NDA and they don't return, I've dodged a bullet. Last one was an older guy who wanted to rebuild eBay on a strict budget and just wasn't at all comfortable talking about his idea without an NDA. I'm willing to bet, months later, he's made very little progress.

I don't think I've missed any quality opportunities with this approach.

I'm always very polite about it and explain my reasons.

bkeroack• 11 years ago

To add to the other comments, it also shows the requestor to have incredible hubris and/or naivete. An experienced entrepreneur understands that raw ideas have virtually zero value, it's the team and execution that matter. If an NDA enters the conversation it's possible that you're speaking to one of the perpetual "idea guys" in search of coders, and you should terminate the interaction quickly.

aestetix• 11 years ago

Too bad Clinkle didn't have this.

AndrewKemendo4• 11 years ago

That's a blast from the past. Only 6 mentions of Clinkle on HN over the past 6 months. Seems like that failure got swept under the rug.

ljoshua• 11 years ago

Great list that made me smile. My two favorites from it include:

- Falling in love with a product (rather than the problem) is really dangerous

- It's really hard to build a product if you don't have a big personal investment in the problem it solves

beat3• 11 years ago

On the other hand, there are a lot of problems that are highly valuable because they aren't sexy and you can't fall in love with them.

jkestner3• 11 years ago

In those cases, I fall in love with the projected result. Visualizing a bunch of people happier because some obstacle is removed is motivating. More so when they start emailing you their joy over this pain point being removed.

tdaltonc2• 11 years ago

Do you have an unlovable problem in mind? I guarantee I can recast it as the sexiest most important problem there is.

Edit: On second though, if you can show that there is big money in solving [unlovable problem], I wont have to recast it. 1000 bay entrepreneurs will be stumbling over one another to recast it on their "Join The Team" page.

NeutronBoy• 11 years ago

Pretty much sums up the software/IT problems of enterprise.

AndrewKemendo4• 11 years ago

I'd always rather work with someone who ships over someone who's technically brilliant

Lets define what ships means then. Does that mean that they are just really good at debugging so that the limited features you do have don't break? Does it mean they know how to distill exactly the use cases needed so that you don't develop more than necessary?

I can think of many ways to ship something that is incomplete, but that doesn't mean it's worth anything so I am curious about this statement.

grey-area• 11 years ago

Lets define what ships means then.

It means delivering a product.

Some companies die before they even ship a product to customers, and actually getting your imperfect product out there in front of customers is a really important and difficult step to take, and usually results in you finding out you need to change it in significant ways you hadn't even considered.

Some companies die after they ship because they used up all their money just getting to the shipping stage and run out of time.

AndrewKemendo4• 11 years ago

What you are defining is a single event. Shipping is a constant process. "ABS" always be shipping is pretty much the standard, so your definition makes no sense.

Maybe I am just crazy though because isn't that the whole point of Lean startup, MVP etc...? You ship before things are ready in the "pretotype" phase?

toolz2• 11 years ago

Have you been around people who own a project from start to finish and nothing but their name is on it? The most common holdup is that it's never good enough for them. I've seen start up projects that I could've done solo in a couple of months that took a small team a couple of years. The reason for things like that is usually they don't ship a product and when you don't ship you don't have feedback motivation to work on the important things (or sometimes no motivation to work on anything at all)

AndrewKemendo4• 11 years ago

Have you been around people who own a project from start to finish and nothing but their name is on it?

I actually have never seen this. Everyone I have ever interacted with who was working on a project either had it in a customer's hands (so they said) or had it available on github for people to look at.

I am sure it exists, but I have never run into anyone who refuses to release their work to anyone at all. In fact it's generally the exact opposite, they can't stop telling people about it.

91bananas• 11 years ago

I've seen start up projects that I could've done solo in a couple of months that took a small team a couple of years.

Perhaps speaking to the net result of the product, you maybe could have done that in a couple months... But there is far more to building product and a company than one developer coding in a room. I highly doubt that you as an individual can create a solution that matches a good team with domain knogwledge, in fractions of the time it took them.

This makes me think of 2048 the game, where the Dev took some time to build it, released it, and in hours there were clones in the App Store. Sure anyone can reverse engineer anything. Especially web sites where you are given their code. But thinking through, debating features and functionality, truly solving a hard problem takes time.

bedhead• 11 years ago

I interpret the author's use of "ships" to mean "gets shit done" - which I agree 100% with. It's too easy to get seduced by the dazzling technical mind, and in my experience these folks are great on paper but have an odd way of causing nothing but chaos outside of their specific talent.

ing33k• 11 years ago

getting the product out is one of the hardest things for a early stage startup. people who can ship will increase the possibility of the product being released .

small example :

Business guy : guys we need to send a welcome email after a user registers.

coder1: adds code in the registration controller . ( 10 mins ) done.

coder2 : I think its better to use a event system to create an event for user registration and use a spool to send the email.

coder2's "idea" might be technically better than coder1's implementation but its waste as Coder2 doesn't actually take the initiative to code ..he knows just about everything in CS and for some reason prefers not to code . And still argues that coder1's solution is not correct.

gedrap4• 11 years ago

This is a pretty good example of what does it mean to be good at shipping. Sometimes you have to acknowledge that what you are doing right now is not the best solution architecture/design/whatever wise, but it provides the best quality/cost ratio.

Of course, it shouldn't be used as an excuse for releasing simply crap solutions. Experience comes handy when it comes to deciding whether it should be improved or it is good enough and should be refactored some time later.

greenyoda2• 11 years ago

"coder1: adds code in the registration controller . ( 10 mins ) done."

And once your code accumulates enough of these 10-minute hack jobs, it becomes incomprehensible and unmaintainable, and every little change will break something. At that point, progress grinds to a halt. You'll then need someone like coder2, who has a talent for system architecture, to refactor them back to a sane state again. (I've been both coder1 and coder2, under different circumstances.)

nasalgoat• 11 years ago

Well, coder1 is leveraging technical debt. You have to find a balance because that 10 minute hack will come bite you in the ass later - sometimes only days later!

corysama• 11 years ago

I've known a few great starters, a few great finishers and a lot of neithers.

The starters could rapidly invent brilliant tech and get it to a prototype phase that looks beautiful on the surface, but is unshippable under the hood. When it came time to clean, polish and fill out all the annoying details, the starters got bored and distracted. They either slowed to a crawl or convinced themselves that some new invention is necessary to ship what they are supposed to be finishing.

Good finishers are actually more rare than good starters in my experience. The finishers I've known are terriblely uncomfortable at the start. Everything is too vague and open ended. They weren't terribly imaginative or inventive. But, when it came time to ship they got in gear. Here's the burn-down list. Fill in the details. Check the schedule. Get it wrapped up, put a bow on it and shove it out the door!

hectorperez• 11 years ago

Great points! I added some of them to AgreeList [1].

For example on [2] you can see that Richard Branson also agrees on the advice "trust your gut".

[1] http://www.agreelist.com/talkingquickly

[2] http://www.agreelist.com/s/listen-to-others-but-go-with-your...

S4M• 11 years ago

Linear growth can be worse than no growth

Not sure I get this one right. For me, some growth is better than nothing. If your growth is linear, it means that you have something like n new users every week, which is probably because they found it through ads or something, but they don't recommend it to their friends - otherwise, you would have every week n+knumber_of_users[previous week]* and the growth would be exponential. I suppose that's why OP is saying this, but I think the real metric is not growth, but retention. Better to have a few users who stick with your product.

Is that what the OP means?

talkingquickly3• 11 years ago

Yeah you're totally right, it's a huge over simplification. I was specifically thinking of the scenario where you add roughly the same number of users each period, where that number isn't really enough for it to be a viable business but because there are some users, it becomes really hard to say "this isn't working" and either radically change something or quit. Agree that retention is often a much better metric.

jim-greer• 11 years ago

Yes.

Kongregate always had decent-but-linear growth and very good retention (of registered users, not so good for guests). Worked for us: here's a graph of web sessions per day with the units taken off.

http://i.imgur.com/715wGwX.png

It flattened out as mobile took all the growth out of browser-based games. It took us a while to figure mobile out but now we're doing well as a publisher/marketer/funder of indie free-to-play games.

https://www.appannie.com/apps/ios/publisher/kongregate/

JonFish85• 11 years ago

"It's really easy to become hyper-critical and respond to every idea with "yeah but that won't work because of x". This is lazy, don't do it."

I'd say that while this is true, there's an important "other side" to this, that not everything is a world-changing, ground-shaking idea that's going to revolutionize the way the world works. Sometimes ideas are indeed stupid, and one of the things I don't love about HN is the echo chamber effect. If everyone is telling you how great things are, coupled with 17 ("Constantly exaggerating how well you're doing can be very tiring.") things can disconnect from reality quickly.

windust• 11 years ago

Mandatory xkcd comic https://xkcd.com/1497/

minimaxir• 11 years ago

Sometimes ideas are indeed stupid, and one of the things I don't love about HN is the echo chamber effect.

However, Hacker News is one of the surprisingly few communities that will tell you if your idea is terrible, which is one of the reasons for the recent "gratuitous negativity" controversies.

timbowhite• 11 years ago

These are some great points, yet this one made me scratch my head:

44. No-one has ever used a Bitcoin ATM for practical reasons

I've used one because it was more convenient and anonymous than giving a scan of my ID to an online exchange, or meeting a stranger in-person to do a trade.

rongenre• 11 years ago

There's one in San Francisco at 180 Montgomery. I've never used it.

http://sfist.com/2014/09/15/sf_gets_its_first_bitcoin_atm_at...

winnopeg• 11 years ago

It was moved from Workshop Cafe, it's now at 2415 Mission St. housed within "Nakamoto's", a Bitcoin-only store. They actually have two there now. http://nakamotos.io/

johndevor• 11 years ago

The ATM in Baltimore is used constantly.

mootothemax2• 11 years ago

The people who are really getting somewhere aren't the people who are always out for drinks

Too true.

As a side note, there are an awful lot of people who seem to go to a different startup event every night of the week, and then some hackathon over the weekend.

I generally find it's the other people who are getting stuff done.

mpeg• 11 years ago

I'm always up for a coffee though and I've found that to work well for most people.

Lots of people at evening startup events just want to have a drink after work. Get their card and pitch them on office hours.

mootothemax2• 11 years ago

I'm always up for a coffee though and I've found that to work well for most people.

Agreed. I can even be tempted by the occasional lunch as well!

TravisLS• 11 years ago

Wow, I don't have anything useful to add, but I have to compliment the author. Every single one of these is spot on, and almost perfectly mirrors my experience. Great post.

timdaub• 11 years ago

There is a similar talk on this topic called "If Only I Knew This Shit In College" by Zach Holman.

You can watch it here: http://developertalks.tumblr.com/post/115528336319/zach-holm...

ttty• 11 years ago

64. Read this again. (Until i < 10, so you don't hang in a loop)

MoOmer• 11 years ago

    while !comprehension

afarrell2• 11 years ago

4. Like it or not, most networking in London is focused around drinking. Find a way to deal with that without having a constant hangover.

One of my classes at uni taught me that doing drugs (especially alcohol) is sometimes necessary for getting things done, but I still wish this wasn't the case.

borgia2• 11 years ago

Can you expand on that? What was the class? Was this advice issued or was it something you came to realise yourself?

Pure curiosity.

afarrell2• 11 years ago

This was an engineering leadership class at MIT. The advise specifically was first an anecdote about working in Japan and going out to get piss-drunk on sale after work and then a generalization of that to drinking as a means to networking in general. My generalization to other drugs is my own. Since there is no moral difference between alcohol and marijuana and there soon won't be a legal one.

The reason why alcohol culture frustrates me is that in high school, I had an older friend who started going to AA and brought me along for moral support sometimes. I've since grown up, developed a fondness for craft cider, and realized that I personally don't have much to worry about from addiction. But for the same reason I think startup events should be expected to be wheelchair-accessible, I think folks should be cool with teetotalers.

jgroszko• 11 years ago

I think Europe is more beer-centric than the US, but here you can always ask the bartender to put a lime in your club soda to make it look like a cocktail... Bartenders are usually pretty friendly to people that aren't actually drinking, whether you're the DD, recovering, or just don't want to actually drink.

tashoecraft2• 11 years ago

This is my strategy at any networking event. Usually have one drink then switch to club soda and lime. While many others are pounding back drinks because "free bar", I'm slightly loose and able to hold intelligent conversations still.

vjvj2• 11 years ago

6. Linear growth can be worse than no growth

Can you elaborate on this please?

nhayden2• 11 years ago

No growth could mean you're still at the flat part of exponential. Linear means it's definitely not exponential.

princeb• 11 years ago

wait, this makes no sense... there is no flat part of the exponential... the derivative of the exponential is the exponential!

eli2• 11 years ago

I'm not the author, but I think it's related to the following point about failing fast. It's not a good situation to be pouring yourself into a business that just plods along, never really in danger of going bankrupt but also never in danger of great success. A clear failure would be preferable because it would be a lot easier to walk away, pivot, start over, etc.

mattbee• 11 years ago

Putting 40hrs/week into a stable, increasingly-profitable business is hardly a slow death, though.

mfringel• 11 years ago

Along with what others have posted, it may mean that you've chosen a business model that only scales linearly.

rralian• 11 years ago

Sometimes startups are funded early based on track record and opportunity. If they instead launched and demonstrated lackluster (linear) growth before seeking funding, they could have a much harder time convincing investors of the exponential growth potential. If you're going for VC dollars, you really need to have a compelling story about how you will grow to be huge, and having some history of linear growth is a counter-argument to that.

robotnoises2• 11 years ago

Nice list! Good balance of humor and practicality. I especially enjoyed this one:

"If you end up pitching to someone over coffee, ask to hear their pitch afterwards."

A nice thought, as a lot of people view networking only through the lens of "what can I gain?"

davemel37• 11 years ago

Ironically. The best way to gain from networking is to forget about what you can gain and focus on the other persons interests.

Excellent point about an excellent list in an excellent post.

robotnoises2• 11 years ago

Excellent reply!

willlma• 11 years ago

What does he mean by "their pitch"? Doesn't this assume they're launching a product?

balls187• 11 years ago

A nice thought, as a lot of people view networking only through the lens of "what can I gain?"

One thing that stuck out to me as a founder going through TechStars was the advice: "Ask them [mentor|investor|founder] if there is anything you can do for them."

cletus• 11 years ago

What a great list. My favourite:

Facebook is the Facebook for X

The one point I would elaborate on is listening to customers. This deserves more attention because listening to what customers _say_ can be a disaster. People will tell you all sorts of things about what they think they want and need. A lot of the time they're wrong. This can be worse than just building things you want or think are important.

Listening to customers really means measuring what they respond to. Or, to put it another way, ignore what they say, see what they do.

kifler• 11 years ago

Ditto. Every time I end up at a networking event, someone without fail always ends up pitching that they have either Facebook for X or Groupon for Y.

No matter how you approach it, feigning interest, dismissing them, or talking about your reserverations, they never seem to get it.

CheckHook2• 11 years ago

People don't steal ideas. Tell as many people as possible. Never ask someone to sign an NDA before hearing your idea, you'll instantly lose all credibility

I find this hard to believe and can see why experienced people would keep startup ideas close to their chest.

tashoecraft2• 11 years ago

This is the general motto for a majority of people. If you've done several startups with big exits, then yeah keep your idea behind NDA's because you can.

For everyone else, no one is going to steal your idea. Even in the remote possibility that they somehow would, then you better be more motivated then them and should be well enough ahead that they can't catch up.

krenoten• 11 years ago

Like everything else, it's a tradeoff. Knowledge about certain market topologies actually can constitute a tremendous advantage, although NDA's are employed far more than is actually necessary.

diminoten2• 11 years ago

Can you elaborate at all on why?

CheckHook2• 11 years ago

Somebody with more funds and connections could ship your idea before you rendering yours obsolete. In the case of a hardware based startup they could even patent the idea first.

billmalarky2• 11 years ago

Ideas are mostly worthless. It's the execution that is valuable. I mean I wouldn't share my idea with Rocket Internet, but you get my point.

smcl• 11 years ago

Context: Rocket Internet is the name of the German company operated by the Samwer brothers, who have a reputation of cloning silicon valley's latest and greatest ideas for the German\EU market. Not technically doing anything illegal but certainly not held in the highest regard.

realusername• 11 years ago

Even in Rocket Internet, the value is mostly in the execution, they have the resources and the expertise to copy any kind of project and they can create a whole team from scratch really quickly. And they are not going to spend anything on an unproven idea, before being copied by Rocket Internet you have definitely more important things to worry about.

thejosh• 11 years ago

Ideas are like assholes, everybody has one.

geebee2• 11 years ago

I agree, though I've never really agreed with the concept that idea and execution are separate things. I see an "idea" for a software application they way I see an idea for a novel. The execution and idea are very closely intertwined. Even intertwined is probably the wrong word, because that conjures up an image of two different things that are too tangled up to separate. I'd go even farther. The idea becomes the idea through the execution.

I suppose there is a sort of genesis of an idea, but even that probably already arrives with images of a UI and perhaps code in your head...

VLM• 11 years ago

I believe the source of the confusion is the difference between your secret sauce and your elevator pitch. They're talking about the elevator pitch. If "everyone" doesn't already know your elevator pitch, or at least doesn't hear it soon, you've probably failed. They're not talking about your secret sauce like, I donno, your AWS login credentials or a really interesting development roadmap or your financial or marketing strategy or something like that. If you can't separate your secret sauce and your elevator pitch that's also a serious problem.

The elevator pitch for facebook is we're gonna get prime demographic young people to look at advertisements on our social website.

The secret sauce in the roll out was to try aspirational marketing where only ivy students can join and diffuse out thru cool/rich. The medium term secret sauce was something like the pages don't look as foul and obnoxious as myspace pages by dramatically limiting them and the real name policies. The longer term secret sauce is the content they view is sneakily going to be provided by the viewers for free via social networking effects luring them on.

alain94040• 11 years ago

People copy success, not ideas from random people they meet at parties. It's really that simple. Once your idea turns into a success (that's a lot of work), then people will start wanting to copy you.

I can assure you no one wanted to copy Pinterest when it was just an idea. Most people think your idea is bad, they are just too polite to tell you.

onion2k• 11 years ago

Experienced people don't keep their ideas to themselves. They don't tweet about them or write blog posts about them, but they definitely do discuss them with their peers, networks and mentors. That's the critical point. You should tell people whose opinions you trust and value because without their input your idea is worth much less, and the chance of them stealing the idea and executing it better is absolutely tiny. If you genuinely trust someone there's no need for an NDA.

Plus, the number of times anyone has been burned by not having an NDA in place is probably a million times fewer than a person has been helped by someone they shared their idea with. Sharing is helpful far more than it hurts anyone.

m3mnoch2• 11 years ago

People don't steal ideas.

while it feels counter-intuitive, this is absolutely true. people don't steal your idea because theirs is always better.

gmarx3• 11 years ago

Everyone thinks this until they start pitching ideas. No one wants to steal your idea; in fact, the most common reaction is to explain why your idea is stupid.

trustfundbaby2• 11 years ago

Be careful about this one. Don't freely tell your idea to people who have the wherewithal to then go and build it, because they just might. What Mark Zuckerberg did to the Winklevoss twins should be enough of a cautionary tale for any entrepreneur.

gscott• 11 years ago

The Winklevoss twins were destined to take their good idea and turn it into crap that Zuckerberg wouldn't want to be involved with and they did eventually turn out a turd.

geebee2• 11 years ago

I'd tell as many people as possible about what I have built, but I might stay a little quiet about what I am building until it is ready to show.

If I have what I consider to be a good idea, and I am actively pursing it (i.e., writing code to implement it), I would probably keep it close to my chest until I have something to show.

robbyking2• 11 years ago

I agree with you 100%. I used to live in a small town and worked for a company whose CEO was infamous for stealing ideas. According to him, he wasn't actually stealing ideas, he was just implementing other people's ideas without them.

The typical scenario -- according to him -- was someone would pitch an idea to him, then he would counter that they should go half on the seed money. If the person wasn't able (or willing) to come up with the money, he'd implement the idea without them.

gaadd33• 11 years ago

How many of those ideas were given the full attention of the CEO and turned into large businesses? It seems like it's easy to take an idea and start to implement it, the hard part is if it doesn't "go viral" or take off massively you now need to really invest more than just money in it.

metaphorm2• 11 years ago

I don't find it hard to believe at all. The simple fact is ideas are cheap and everyone is full of them. Execution matters. The idea does not.

An NDA is appropriate for something that is a bit closer to fully baked than just an idea. If you've got a proprietary algorithm or business database that you don't want to leak, then an NDA is appropriate. If you're demanding an NDA just to talk about an idea that you haven't even started working on yet then you're just wasting time and oxygen.

gedrap4• 11 years ago

An idea alone is very hard to copy unless you have deep expertise in that area and can quickly understand the problems it solves.

For example, you describe me an idea for some SaaS startup targeted at constructions companies. I have no clue about this industry, so no matter how well you describe it to me I simply can't judge it and definitely can't implement it.

Even if you are an expert on the target audience and their problems, the small details that make the difference, you can call it vision, are normally not part of the 'idea'.

chippy2• 11 years ago

I think people are missing a key point a little bit. It's not about telling people your idea, giving them your idea, it's about getting feedback from them, its about learning from others.

Ideas get better when more people think about it.

jarfil• 11 years ago

The idea stealing myth originates from people (cubicle drones) who have so few ideas of their own, that when they finally have one, since it seems so scarce to them, it obviously must be valuable and thus worth "stealing". Unfortunately, this kind of people also lack the ideas necessary to realize the few "precious" ones they have.

Who does have a chance of realizing them, are people with lots of ideas, also about how to actually implement ideas. However, when you reach and surpass the "idea a day" treshold, while being able to implement maybe 1 or 10 each month, you get to discard hundreds of your own ideas each year, making them pretty much worthless.

So you should never be afraid of sharing your ideas; whoever you're telling them to, will either not care, or fail miserably trying to "steal" them. In each case you're safe. As for the monthly surplus ideas, if you're not implementing them, you risk nothing by sharing them either... except maybe feeling dumb in the off chance of seeing someone else successfully implementing an idea you thought was worthless.

PS: in the even rarer case of sharing an idea you're implementing, and someone else beating you to it... you suck, do something at what you suck less.

alvarosm2• 11 years ago

Yeah, exactly. If you have just a couple ideas and you think they're great what are the chances they're actually great? you should have dozens and be pretty sceptical and critical to filter out the really good ones.

brc2• 11 years ago

All true, and I would add that the sharing of ideas helps you to refine them, in the same way that describing a programming problem to someone else often helps you resolve it, because you have to structure the problem in language that makes sense to the other person. Sometimes simply structuring a concept in a way suitable for speech presents obvious answers that weren't possible when it was a ton of internal dialogue.

alvarosm2• 11 years ago

It is often inexperienced people or "business" guys without any technical background who think they have the billion dollar idea when in fact there are a thousand people who had the idea before who couldn't or wouldn't execute.

So, that advice goes for them: forget NDAs and get good feedback. On the other hand, if you really know what you're doing, you'll know if the idea has a lot of intrinsic value and/or potential for being easily stolen (infrequent and often unpredictable in those rare cases), and who you can to talk to about it.

More often than not, "ideas" are pretty simple and valueless and even the best execution can't do much to keep the business afloat. Many successful ideas come from something as simple as merging several different fields (only an expert in both fields is likely to come up with it), or simply from some enabling technologies maturing enough to have everyone and their dog execute the ideas they had but couldn't build successfully before (tablets come to mind, many mobile apps and so on).

Experienced people would know what to do with their ideas. Who to talk to to get advice, what to keep close to their chest or not. Others would benefit greatly from any advice at all they could get and for that they need to run the very small risk of telling their idea to others.

fixxer• 11 years ago

Really great list. #61 can not be overemphasized and includes blogging. I got one of my blog posts in a phd thesis last year (tried so hard to hire that kid!).

dnevogt12• 11 years ago

Awesome writing style, and great examples of what it's like to build a startup in the trenches.

carlesfe• 11 years ago

Yes, I thought the same. I enjoy pg's essays and, while not comparing both styles, it's refreshing to see a bullet-point blogpost with well thought content, unlike the usual "You won't believe these 10 tricks all successful startups have in common"

makeitsuckless• 11 years ago

A good developer can pick up any language or platform in a few weeks

Yes and no. There's a major difference between "picking up" and actually being good at something. If you have nobody on the team that is either already intimately familiar with the language/platform, or has experience with various languages/platforms, you're going to be spending a lot of time figuring out how to do stuff properly instead of just building stuff. And if you are a startup with a limited runway, that difference is crucial.

ddoolin• 11 years ago

I'm glad you made this distinction. With enough time, yeah, sure, we can be "good" at any of them, but I've seen companies bring people on without a developed skill set in a particular technology only to find out the ramp-up time to be as efficient as someone familiar with it to be much longer than they bargained for.

m3mnoch2• 11 years ago

agreed. it's really about lifecycle.

near the beginning of your startup, you need multi-hat-wearing-swiss-army-knives for developers. once you get traction and growth, you need to bring in vertical expertise.

offwhite• 11 years ago

I think the point is that a good developer is happy to start using a language/framework because it is the best tool for the job (regardless of their experience using it), rather than just sticking to what they know.

I think that's probably more useful in a start up. But I go more for the 'get shit working and see what happens' approach to developing. I mean, making it look pretty is what iterations are for.

maybe. or whatever.

jkestner3• 11 years ago

"Best tool for the job" is not a knowable truth. Best for what time frame? For what shifting array of tasks?

Often we pick the tool that will be perfect for high performance or a known task, but if you're still figuring out the product, why not make an MVP using what you know? I rarely see anyone fail because they chose, say, PHP. <cough>Facebook</cough>

nahushrk2• 11 years ago

this may be a great way to go about in hackathons where one has very less to loose and success is greatly rewarding. if nothing, at least you learn something new. contrarily, in a startup a lot of things are on bet - money, opportunity, time - or may even mean difference between success and failure. it all boils down to reward-risk tradeoff.

ohashi2• 11 years ago

Seems like an odd caveat. Why would you pick something nobody on the team is good at? Who made that silly decision to begin with. I'd expect at least one person is good/familiar with the language chosen.

pyre4• 11 years ago

Why would you pick something nobody on the team is good at?

This is more likely than you may think...

"I want to learn Ember.js, so even though I'm proficient at using Angular.js let's write everything in Ember.js instead. Then we can spend months chasing our tail learning all of the 'Gotchas' of Ember.js. Also, just to make things interesting, let's use a bleeding-edge version of Ember.js. Also let's do this at a time when articles on Ember.js that are just 4 months old are already out-dated and no longer apply to the current codebase."

Though I doubt that a warning on HN will deter such people.

emodendroket9• 11 years ago

Resume-building, probably. Or else nobody on the team is familiar with any of the tools to accomplish the desired goal (e.g., you want to make a SPA and none of you have ever done it before).

daenz2• 11 years ago

I agree. I've seen an experienced new hire "pick up" a new language, and the result was them writing non-idiomatic, difficult-to-understand code. They know they want to do Z, but they don't know the language's way of doing it, so they do X and Y to get to Z, making it difficult to understand their actual intentions.

greenyoda2• 11 years ago

This can be solved with code reviews, in which a developer who is experienced in the language can teach the new developer the right way of doing things. Of course, you shouldn't wait until the new developer has written thousands of lines of incomprehensible code before doing a review.

ChuckMcM• 11 years ago

Interesting, I read this as being open to hiring good developers even if they don't know your current platform/language. You can train that, and if you have existing expertise then you can pair them with someone who is experienced to teach them the nuances.

simonw• 11 years ago

+1.

joshred• 11 years ago

Your ability to train an employee is going to be hampered by the size of your company. You need someone with both the experience and the time to already be on payroll.

jksmith• 11 years ago

If one of the intended features of a language is that it can be picked up quickly, that certainly helps. I'd suggest that this is a feature of golang and historically modula-2.

talkingquickly3• 11 years ago

This is definitely what I was getting at. My admittedly fairly small sample makes me think I'd rather hire someone who appears to be an excellent developer in general and train them on a new language/ framework than someone who appears mediocre but already has experience.

cdnsteve• 11 years ago

I think this point should be: - A good developer is open to any new language or platform and willing to learn.

moron4hire2• 11 years ago

There's also a difference between a really good programmer just starting in a new language and a really bad programmer having 10 years of experience in the language. I'll take the former, please.

But really, it's a false dichotomy. No good developer would choose to start a new project in earnest in a new language they don't understand well. They might enter a team that is using a language they don't know yet, and that is what "any good developer can learn a new language quickly" is about.

That's all any of this boils down to: are you working with intelligent, thoughtful people who know how to get work done, or are you working with losers? Every. Single. God damn. Tired. Argument. Good people or losers? That X vs. Y technologies "worked" is not data that X is better than Y, it's data that your team is not comprised nearly completely of losers.

nostrademons3• 11 years ago

"No good developer would choose to start a new project in earnest in a new language they don't understand well."

There are plenty of developers who chose to do just that, eg:

PlentyOfFish (started as a weekend project Markus Frind wrote to teach himself .NET).

WhatsApp (Jan Koum's previous experience was in C++, but he wrote it in Erlang because the best open-source XMPP server was ejabberd, written in Erlang).

Google (You can find Larry Page's questions on how to do URLConnections in Java on UseNet, then it was rewritten in Python by Scott Hassan, then in C++ when it became a real company).

joshmarlow• 11 years ago

Agreed.

I'd say "You can pick up 90% of any language or planform in a few weeks." That last 10% though is some edge-case/deep understanding that you won't even know about until you really need it (and it's probably shown up in production).

digikata• 11 years ago

I think that different languages have their own level of how much edge-case there is in total, as well as how much may be exposed edge there is visible now vs later. It's akin to having icebergs of different volume, but unlike icebergs, also different proportions of 'ice' below and above the water.

cbhl2• 11 years ago

I think the the context of this statement refers to hiring, as opposed to choosing what language/platforms your team should build with.

All other things equal, for a startup, I'd rather hire a smart freshman over a middling candidate who had five years' experience with the language/framework I wrote my app in.

Plus, there are a number of startups where the speed at which you can "build stuff" is not the limiting reagent towards success. Even if you were the fastest builder in the world, if you don't build the right product, no one will pay you money, and you'll run out of runway. (Dozens of student "startups" out of the University of Waterloo run into this exact problem during every four month term.)

mooreds• 11 years ago

As someone who just 'picked up' a rails 3 app to add an online order form, I agree that, while you may be able to 'get stuff done', you'll be slower than someone who has experience, no matter how senior you are. At least for a few months. I banged my head against tasks that a RoR developer would have finished far quicker.

However, by being willing to train senior folks (and I'm talking my book here, as I am a senior developer), you gain two things: access to a larger pool of applicants, and the value of cross pollination. (I've seen a lot of ORMs in my time, and concepts translate between them.)

How to choose whether to train or not? It depends on the length of your runway (longer means you'll have more time, obviously), how many other current folks have knowledge of the solution (and can offer code review or other guidance), how committed the applicant is (tough to judge, but desiring employment vs wanting a contract is a proxy), how far you are pushing what you are building (if it is a normal use case--crud app for rails--a book and a few days may be enough training time. If it is not--high traffic erlang application--you may have a harder time training someone up without extensive partnering), and how hard it is to find someone who has experience with your current technology (there is an opportunity cost to training someone, but there is an opportunity cost to having an empty seat as well).

Certainly any senior developer worthy of the name is going to be able to pick up a language and be productive with it in a few weeks. However, they'll make mistakes, just like anyone will, that may require rewriting later.

Junior folks are a whole different ballgame.

tracker12• 11 years ago

I have to agree with you... we all go through it. I always considered myself pretty good with JS (very senior), when Node/npm started getting bigger (3-4 years ago), a lot of things really made me feel out of my depth. You get used to it, you observe, learn and adapt.

Most of the concepts of application development will always apply, and context is everything.

On the flip side, I've met plenty of developers who have absolutely no desire to look at different languages, tools or ideas. To me, that's what is really scary. I can't imagine having that mindset and where I will be in a decade if I did. I just turned 40 a few months back, and feel like I am learning about as much as I did in my 20's. The difference being the objectivity on what to dive deeper into with regards to learning more.

gaius3• 11 years ago

As the old joke goes, a good developer can write FORTRAN in any language.

Pxtl• 11 years ago

Depends on the platform. To me, that's a big measure of how well-designed a platform is that I can pick it up quickly and stop being bitten by its idiosyncrasies.

For example, I've been supporting old ASP.Net Web Forms projects for about a decade and I'm still getting stunned by that damned monstrosity.

emodendroket9• 11 years ago

The famous Norvig piece "Teach Yourself Programming In Ten Years" touches on this:

In 24 hours you might be able to learn some of the syntax of C++ (if you already know another language), but you couldn't learn much about how to use the language. In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using C++ syntax, but you couldn't learn what C++ is actually good (and bad) for. So what's the point? Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing". One possible point is that you have to learn a tiny bit of C++ (or more likely, something like JavaScript or Processing) because you need to interface with an existing tool to accomplish a specific task. But then you're not learning how to program; you're learning to accomplish that task.

kamaal3• 11 years ago

>you're learning to accomplish that task.

If you are learning anything other than that, you should be in academia not building real world applications. Out there in the industry you don't have 10 years to give towards a specific cause. Given the overall pace of our industry, the rate at which tools are changing, and age related discrimination.

In two ten year sprints you will be due for retirement.

westoque• 11 years ago

In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using C++ syntax, but you couldn't learn what C++ is actually good (and bad) for.

A couple of things:

- A good programmer won't just write C++ in the style of Basic.

- A good programmer wouldn't just use C++ to accomplish a task, there must be a legitimate reason, performance, etc.

I myself have done exactly this, I just wrote a Ruby C-extension to make my program faster and I definitely didn't write it in the style of Ruby.

tux• 11 years ago

Thanks for the "Teach Yourself Programming In Ten Years" article, just read it. Yeah I've seen first hand how people code after "Teach Yourself Programming In X Hours/Days" absolutely horrible. There is no quick way to learn GOOD programming. Between, good article OP.

jkoudys• 11 years ago

I've always liked that quote, because it really goes both ways. We see languages change over time, when we learn what one language is good for and start to incorporate some of that thinking into another. e.g. we're seeing `class` syntax in es6, but that's been present in many other languages for a while. PHP has been adding improved support for `list()`, which is basically its way for managing tuples, something very popular in the Python world. The right way to make this progress isn't by just blindly dumping syntax from one language into another, but by learning many and having it change the way you think.

lordnacho3• 11 years ago

I thought it meant "as long as s/he has done something similar with a similar tool".

Ruby/Python/PHP web CRUD, that kind of thing.

I think it's believable, as long as you have at least a few weeks to play around first. As long as designs are similar, it shouldn't be too hard to port.

Also, any number of "from X language to Y language" pages exist, and they should give you the most obvious caveats.

whalesalad• 11 years ago

A good developer + a patient, knowledgable and humble mentor is a winning combo.

guelo• 11 years ago

In a startup context it doesn't matter, the technical founders should be able to whip something up in whatever tech stack as you're ramping up. Once you have some funding, employee #1 or 2 should be an expert and be able to bring in all the cargo-cult best practices for that tech stack and teach the rest of the team.

nahushrk2• 11 years ago

true. this can be compared with learning math(or any foreign language for that matter). you can have a one page cheat-sheet of all the rules and formulas, but that can only help you solve textbook problems. there are tricks and caveats that are learnt only by practice. googling 'how-to' is a very slow process, even with stackoverflow.

reilly3000• 11 years ago

I love Rich Hickey's analogy of the language as an instrument. I am a pretty good musician and can make decent sound from most instruments within a few hours. That doesn't mean I can make music with it. For example, the tambourine has over 90 unique sounds it can generate in the hands of a master. Concertos have been written for the instrument. I can do about 3 of them rather poorly.

Better to hire experts than polyglots if you want to make a concerto. Actually, it is better to design great software with the advice of great players then let them rock out while you stay out of their way.

mbell• 11 years ago

I don't think there will be meaningful slowdown from taking a 'good developer' with a lot of experience in Rails and throwing them into Django development. It takes very little time to figure out the proper way to do something when you're already heavily versed in the core concepts and ideas behind what your doing, in this case MVC web development in an OO imperative language.

Where this doesn't work as well is when you take a 'good developer' who's worked mostly in C++ writing game engines and throw them into web development using Clojure. It's hard to figure out the proper way to do something when your not even sure what your trying to do, or what terminology to use to efficiently google the question.

I think the author is primarily referencing the former situation, not the later.

narrator• 11 years ago

Picking up a language for me involves reading the O'Reily book cover to cover -- every single word. That way I get familiar enough with the language that I don't spend weeks doing things "the wrong way" just because I'm used to doing things a different way in another language. This, and the initial ramp-up time usually takes a few weeks. For really big languages like modern C++ it would probably take longer than for node or something like that.

drcode• 11 years ago

Think hard about a pivot which makes good business sense but leads to a product you no longer care about

I was just about to do this... hmmm... maybe I need to think harder.

rywalker• 11 years ago

Great post Ben, curious if you collected that list over time or just got on an inspired roll :)

dj-wonk• 11 years ago

There are some gems in here, mixed with some highly-specific and perhaps contingent observations. I wish everything on the web, especially this, could be split apart and commented on it a sane way.

kodr• 11 years ago

A few years ago, I used Diigo [1], it's an extension that let you share a website and comment on it, anywhere. It's been a long time since I used it, I don't really if it's still active.

[1] https://www.diigo.com/

soci• 11 years ago

Great piece of advice.

5. The people who are really getting somewhere aren't the people who are always out for drinks

I would add that networking is ok (specially with your customers). But being always networking with the entrepreneurs in your area won't drive you anywhere near success.

Someone once told me this advice that I try to remember myself every once and then:

"Less networking and more working"

Also, although the list of advices nails it at mirroring my own experience, I know that I would not follow most of them. For an unexperienced entrepreneur it's difficult to discern good from bad advice.

euphemize• 11 years ago

A bit uneven as a post. Some really, really great advice, some more questionable I find.

The logo doesn't matter at the start, find a simple text based logo you can re-use for different projects

Not convinced. Your logo will follow you around for a long time, regardless of what you tell yourself. People will see it and associate you and your startup with it. Doing a large rebrand is difficult, costly and time-consuming.

andycroll• 11 years ago

Doing a large rebrand is difficult, costly and time-consuming

And also a nice problem to have. Most 'startups' won't get to this stage, so spending time on a logo _is_ a waste.

at-fates-hands• 11 years ago

While on the flip side of that, investing a lot of time and money to get a logo done when there's a 50/50 chance the company might not make it another six months seems a waste of both.

This is the problem with startups, you just never know. Should I work on growing my brand and banking sales, or stop and spend a bunch of time deciding on a logo? The branding will come if the product and the business model are there. Also, some of the most famous brands have the simplest logos:

The Red Cross

Apple

Subway

Ralph Lauren

Zippo

Adidas

Nike

Google

Ikea

Dyson

Coca-Cola

Pixar

jkestner3• 11 years ago

Agreed, but simple doesn't mean they didn't spend a lot of time/money on it. (NeXT paying Paul Rand $100K comes to mind.) Many logos are an evolution over years. http://logos.wikia.com/wiki/Subway http://logos.wikia.com/wiki/Adidas http://logos.wikia.com/wiki/Nintendo

Since we're talking about startups, can't forget Facebook's original name/logo: http://logos.wikia.com/wiki/Facebook

striking• 11 years ago

Also: the Nike Swoosh was made for $35. http://en.wikipedia.org/wiki/Swoosh

uuilly• 11 years ago

Brilliant post. Most of these points hit home for me. One of the things I've been honing in on recently - which you do as well - is effectiveness. Brilliant developers who don't ship aren't effective. People who don't distill a product down to just what's necessary aren't effective. You hit on this concept - and many others - in a number of spots. Thanks for sharing.

jdiomede• 11 years ago

True, and this is one of the harder lessons to act on. Brilliance in = brilliance out, right? At the most basic level shipping product can be the difference between fail-pivot-success and fail.

obastani• 11 years ago

I didn't really understand this one -- what does it mean to be a brilliant developer who doesn't ship?

chudi• 11 years ago

someone who can code complex algorithms in an environment like a topcoder contest, acm, etc. and can't finish something in the real world.

r00fus• 11 years ago

Perhaps someone who is brilliant but perfectionist and not interested or capable of doing the work to glue/shim a canonical example into a working product.

Some folks are good at the former, others are good at the latter. The really good ones are comfortable with both.

fudged71• 11 years ago

This is closely related to the "Raw Technology Persona"[1]

A developer who can talk you through an entire stack and why specific tradeoffs were made on specific pieces of the architecture... yet hoards code on their box without committing, works on stuff without telling other people, and claims that things are progressed much further than they actually are. It's an ego and accountability problem.

Someone like this might prefer to refactor your entire stack multiple times, partly due to shiny-new-framework, and partly due to the lack of understanding that from a business perspective you often have to work with what you've got. I think it's less about perfectionism and more about inexperience with balancing business tradeoffs with technology.

There's a great series in Forbes specific to CTOs undergoing this "meltdown" [2]. In it, they mention a few warning signs including: never saying no, missing deadlines, low morale, and poor estimation of timelines.

[1] http://www.citoresearch.com/it-management/why-cios-and-ctos-...

[2] http://www.forbes.com/sites/danwoods/2013/08/26/avoiding-a-c...

jroseattle• 11 years ago

I've always referred to this as "realized output". The brilliant engineer might have capacity for greater realized output, but there is little value in the potential. After a certain point, the output must be realized.

plongeur• 11 years ago

16. I still don't know any real investors

What is this supposed to mean?

oe2• 11 years ago

I read it as "don't spend your time trying to find / meet (real) investors", along the lines of #47 "You're probably either building or fund raising."

Also that meaningful investments don't necessarily come from traditional, real investors.

mkagenius• 11 years ago

His younger self doesn't know any real investors. He needs to get more connections. (My interpretation)

kendallpark• 11 years ago

Tech news (and news is general) has a very low return on time invested. Prefer books and conversations

So true. Should probably block HN.

gedrap4• 11 years ago

Personally, I found that my ROI for time on HN is a decaying function.

During my first year here, it was extremely valuable. I've read about many things that I didn't it exists, read comments written by far more experienced people. However, a few years later, there is a lot of repetition and normally I stick to HN newsletters and filters by points.

tdaltonc2• 11 years ago

It's really easy to become hyper-critical and respond to every idea with "yeah but that won't work because of x". This is lazy, don't do it.

This should be one of the HN guidelines.

gopher2• 11 years ago

Good idea, I think that it already might be. They just had that highly commented post about avoiding "gratuitous negativity"

gmarx3• 11 years ago

I disagree with the generally accepted one- build something you want. This is a fine thing to do but the overwhelming majority of good software business ideas aren't for consumers or developers. The overwhelming majority of workers who have problems that could be fixed by software are not developers. Lots of opportunities out there...

gedrap4• 11 years ago

You have a point :)

Building something you want usually means that you have a deeper understanding of the problem. Also, chances are, that you are familiar with the market, alternative tools, etc. Which is a must for creating a good product. Actually wanting to use it adds a little bit of passion which definitely counts in the early stage.

gmarx3• 11 years ago

clearly there are advantages if such an opportunity presents itself. Of course if you are a programming by trade, chances are it will present to a lot of your peers as well

rottyguy3• 11 years ago

Going through this now after a few false starts. I initially picked a problem that everyone's been complaining about forever --HR/Recruiting/Resumes. Seems riped for solving but...

1) Getting engagement is tough in any idea. Extra tough here b/c writing/submitting resumes is not an everyday thing and really a pain point!

2) I knew very few people in the Recruiting industry (see #1) which made getting spun up that much harder.

3) While I agree HR/Recruiting has lots of problems, I really wasn't passionate about the space. What this means is that during the down times, and you'll have plenty of those when you think to yourself if all this work is really worth it, you really need to draw deep. And if you can't convince yourself to keep moving forward, it eventually spirals from there.

I'm now playing in the local space and much happier (even though getting engagement is still a btch!) :-)

I do have a question to the community

1) When is it time to "start the company"? (eg through IRS)

2) If you have an existing company entity (from another failed startup attempt) that didn't have a lot of entanglements, is it better to change the name of that company to your new startup (after passing #1 test) or better to shutdown and restart? Just trying to understand if there are any (longterm) downside to a simple rename.

gearhart• 11 years ago

WRT when you start the company - I only have experience from the UK market, but here you're doing a tradeoff; on the one hand there are a lot of programs and benefits for startups (like SEIS tax relief), so it's beneficial to be 'young' for as long as possible, but on the other hand, some big companies have purchasing requirements that, to protect them from immature, risky startups, only permit them to purchase from a company that has been around for a certain period of time, often years.

As a caveat to that, however, most people tend not to use incorporation date to decide whether you're a startup - start of trading, or fundraising rounds are the most common alternatives, so if you've not done either of those things your previous startup would be, for most purposes, a clean start.

I personally would set up a new one just for cleanliness, but then that's a very cheap, easy process in the UK, I don't know if that's also the case in the US.

cbhl2• 11 years ago

My local incubator's advice was "incorporate as soon as you can afford it, maybe slightly sooner than that".

Incorporating limits your liability. If your businesses screws up before you're incorporated, then you are a sole proprietor, then you can lose everything (say, your house, if you own one).

Granted, it was a college incubator, so they gave that advice knowing that a bunch of students were at an exploratory stage that doesn't warrant the overhead (fees, taxes) of a company.

dkrich2• 11 years ago

There are a couple of distinctions to make here, both practical and probable.

First, forming an LLC does not protect you from liability in and of itself. The idea of creating an LLC is to create a legal entity that is separate from yourself. However you still must act as if you are separate from the business by creating a separate bank account and using it for all business purchases, for example. If you form an LLC but then buy all your supplies and hosting with your personal credit card, in the eyes of the law you are a sole proprietorship.

Ideally this would be done early on, as there isn't much downside. However there is some. First, there are filing fees and a lot of times you must pay a representative for your business (especially if you are filing in a different state). Then if you want to dissolve your LLC, this can cost hundreds of dollars.

Practically speaking you won't get sued unless you're already successful. The reason is quite simple. If you don't have anything worth going after (assets, an insurance policy, etc.), no lawyer is going to take the case without charging sizable fees. For most people, paying an attorney out of principle isn't going to be a realistic option. Therefore, I would say it really depends on your business and the potential liability. If you are starting a company that catalogs baby pictures, your potential liability is probably pretty low. I wouldn't worry about filing for an LLC before I had a decent set of customers. If you are starting a company storing sensitive financial data, I'd definitely file for an LLC and probably take out a large insurance policy to boot (see how those are correlated?).

nostrademons3• 11 years ago

I've talked to a couple lawyers about this and their advice, somewhat surprisingly, was that you don't need to incorporate until you're past the "project" stage. Specifically:

1.) You're handling money. As soon as money's involved your liability goes up significantly - plus, the corporation needs its own bank account.

2.) You have investors. They need an entity to be able to invest.

3.) You need the business to continue if one of the people involved backs out. If you're a few guys in a garage, your startup is probably screwed if any of you back out, and so having a formal shareholder agreement and property owned by the corporation doesn't really gain you anything. If you're an operating unincorporated business with something of value and your tech cofounder backs out, he holds the business hostage, because he owns the IP.

4.) You're doing anything that's risky and may piss people off, eg. spammy marketing campaigns, crashing peoples' conventions, abusing another company's API, scraping data where the ownership is unclear. You can get a lot of protection from lawsuits simply by not pissing people off; people who aren't mad at you and don't think you've wronged them don't sue you. But if you're doing something that's a grey area, you really really don't want your personal assets at risk.

The main downside of incorporating is that then you have to deal with all the administrative details of being a corporation. You have to pay yourself minimum wage, or else you're in violation of minimum wage laws. You're taxed on the income you receive as wages (even though it's just a transfer from yourself to yourself), so the IRS is taking 15% or so of your runway off the top. You have to file both corporate and individual taxes, which is a big distraction when you want to be working on your product. You need to have at least nominal board meetings (in the beginning, this can be just you and your cofounder sitting down at the table), where minutes are kept. It also costs a few hundred in fees, which is money you don't get back if the startup never finds any customers (as most don't).

Basically - you can and should be "just a person working on a project" when you're building. When you release it to the world and let people who you don't personally know use it, it's probably time to incorporate.

stevenmays• 11 years ago

http://hired.com already does this, and they seem to be doing it pretty well. I don't want to dissuade you, as they have not upended the industry yet, but check them out.

rottyguy3• 11 years ago

Oh that's the other thing. There are lots of players in this space! But, that's not a bad thing... Someone just pointed me to nsphire (tinder for recruiting?) which seemed interesting too.

Here was what I was trying to do: http://www.palere.com/blog

I also tried to crowdsource the interview process...

jdmichal• 11 years ago

Point (2) in the article:

Someone's always already working on the same idea and that's not a bad thing

lordnacho3• 11 years ago

How does this work? I guess a lot of people are rejected for not being easy to place?

lordnacho3• 11 years ago

Your products and your business do not need to have the same name. Ever seen a shop called Yum Brands? You can just trademark your new brand and continue.

simonjgreen• 11 years ago

If it didn't completely fail then you have the benefits of trading history for getting credit terms with suppliers. That's the only reason we kept the company entity when totally changing direction and it was worth it.

paulhauggis• 11 years ago

This is a great article.

Here is my experience with startups:

-1 co-founder was a designer and after I finished the product (I'm a developer), took 6 months to make changes that could have taken a week or two. Without a boss telling him what to do, he had no motivation to finish anything in a timely fashion. This failed before it got off the ground, but I built lots of nice libraries that I still use today.

-1 co-founder (a developer) gave up after he had to work on the boring parts. A few years later I gave him another chance. We were going to start a consulting business together and I figured, because he already had clients, that things would be different from our previous experience. Well, he took me to his lawyer and wanted me to sign these completely 1-sided contracts where everything I built in my off-time was owned by both of us (he knows I had other companies). He also wouldn't take any risk and give me ownership in his current contracts, but I had to give up mine. Before I even had a chance to tell him no, he changed his mind once again and wanted to "wait a month". 3 months later, I politely told him I wasn't interested and he now works a 9-5.

-The last time in my poor decision making was partnering up with someone that had no tech (besides checking email, etc) or business experience. I was to do all of the development and I figured he could learn the business and marketing skills along the way. His job in the beginning was to do all of the content-creation (which is not easy).

Well, after alpha 1 I built the entire site and he created 5 articles (which was enough to get some people testing it). He was unwilling to learn anything about marketing (because I was better at it as he said) and wanted to farm out all of the content creation to other people (which is a good idea, but not at this stage in the business..especially when we are strapped for cash).

So now we are in a situation where he has nothing to do and my job is to: get customers, design the website, fix bugs, and make business decisions. I'm basically running the entire business myself and he, as an equal partner, is sitting around waiting for things to happen.

So what does he decide to do? Comes up with un-realistic ideas for future business plans that of course only involve things that I will be working on and not him (since he has no tech experience). I also had to fight against his ideas and continue to convince him that we shouldn't be working on the next "Facebook for X" and on the task at hand that had a real chance at making money. This involved hours and hours of phone calls and meetings that took me away from the site that was in alpha. That was another issue: nothing could be explained by email to him, only by phone or in-person.

Everything eventually fell apart and it was a very frustrating experience. He was also a good friend, which made it even more difficult.

I feel like some people like the idea of running a business, but have these un-realistic expectations when it actually comes down to doing the work. I've learned some hard lessons, but I think it will help me in the future when it comes time to find another co-founder.

rgbrgb• 11 years ago

Maybe try going it alone. I know it's counterintuitive but sometimes building something by yourself is the best way to find a co-founder who's actually any good. I never would have joined the current project I'm on (which is going really well) had the designer not come to me with these amazingly beautiful mocks. Before working on programming projects I had similar experience with music projects -- I'd be trying to put a band together to write songs. I learned that it's a lot easier to get people to work on your projects if you've already started them. Incidentally, it seems to be the same with investors, employees, whatever -- they have the pick of the litter and they'd rather not be first money in. Everyone wants to feel like they're getting a deal and everyone responds to FOMO.

benologist• 11 years ago

Take your time and find the right partners while you build your businesses - the same people who advocate having cofounders also take the position that the wrong cofounder is worse than none at all.

DenisM• 11 years ago

Any first-person accounts to support "Linear growth can be worse than no growth"? Seems like something important, but not quite clear; a couple of real world examples would really help.

simonswords82• 11 years ago

I guess the underlying message here is that a product can limp on with linear growth, sucking the team's time and energy that they could be investing elsewhere.

Conversely no growth is a clear call to action that the product sucks, and needs to be abandoned!

dmritard96• 11 years ago

Advice is a good one on here. I would phrase as: "The vector sum of startup advice is 0 - choose carefully and quickly"

gaius3• 11 years ago

Nothing in there about not giving up half a market salary for "options" on 0.001% of the company. Rule #1 in my book.

robbyking2• 11 years ago

Linear growth can be worse than no growth.

This one is huge. I had a manger once who confused linear growth with vertical growth, and as a result our entire engineering staff was spread thin trying to make progress on a large variety of mediocre products.

zerooneinfinity• 11 years ago

Can you explain this in more detail? Why is linear growth worse than no growth?

kstenerud• 11 years ago

Because it has a tendency to lull you into wasting time on a product that's not going to make any real money.

jacobn• 11 years ago

You get fooled into thinking you're on to something, when in reality it's a zombie. Which can be a great lifestyle business, but your (potential) VC backer may be less enthusiastic.

jkaljundi• 11 years ago

Still don't get it. Let's say a linear YoY revenue growth of 1, 2, 3, 4, 5 million. Or the same for net profits. Why is that worse than no growth?

Nicholas_C2• 11 years ago

I think the key phrase is "can be worse than no growth". Linear growth of 5% a year on small base sucks and can be worse than no growth because it provides an illusion of progress. A team could be working on something with a much greater return instead. If a team saw no growth they may have abandoned the project entirely instead of pushing onwards through mediocre or lackluster growth (relatively speaking) for a longer period of time.

Saturnaut• 11 years ago

Sounds like the company I currently work for, sadly. We have .NET, Python, PHP, Java, Node, and front end developers. Most of them are entry and mid level. Owners are constantly trying to get anything and everything through the door. It makes for a frustrating work environment and usually unhappy clients. Sure, we are growing ... just not in the right direction.

gdubs• 11 years ago

A lot of great items here, but number one resonates the most. One of the most common problems I've seen on any project I've ever worked on (my own side-projects included) is a difficulty in saying 'No' to things.

The list itself would benefit from the same advice -- cutting it down to half as many items would have upped the overall quality IMO.

mindfulgeek• 11 years ago

Thanks for sharing! I learned too many of these the hard way... I think I could say that about most things I've learned though :)

Kiro• 11 years ago

Regarding 46 I can't help to think "why don't you just learn to program and build it yourself?". Most ideas are simple CRUD apps anyway.

josu• 11 years ago

Because comparative advantage. Do what you are good at, and pay for what you are not good at. Spending time on learning has an opportunity cost. If your opportunity cost is low i.e.: your current income is low, then maybe learning to program is a good idea. But if you make 200$/hour, you are better off finding a technical cofounder or outsourcing it. besides, having a technical cofounder lets you focus on other areas of the business. At least this is how I see it. The Woz/Jobs tandem would be a paradigmatic example of this.

yzh• 11 years ago

This is a great list, the only missing part here is: WHY? It would be nice to have a short description of the reason attached to each item.

nicholasdrake• 11 years ago

i think there's way too much group think in the Valley. it's carlota perez's overadaptation, overlearning the lessons of the recent past..

shinamee• 11 years ago

#18 ... hmm

chatmasta• 11 years ago

It's really easy to automatically dismiss everyone who starts a conversation with "I'm looking for a technical co-founder". Doing this means you miss talking to some interesting people. But be upfront that you're not that co-founder so no-one feels like their time is wasted.

This is a good point. I suspect many people here have grown tired of hearing "dude I have this idea for an app..." I just graduated from college and many of my nontechnical friends who went into finance are realizing they hate it and want to get into tech startups. During college I was always busy so I shrugged off these conversations. Now I have time to listen, and it turns out, many of them actually do have good ideas and business models. They just don't know how to code them. But these are smart, well connected people who can raise money. Dismissing their ideas is foolish and could certainly be a waste.

I realized I can monetize all my friends asking me to help with apps. I have a team of programmers I've worked with overseas, and I know how to manage them to complete projects. I've started offering a service to my friends where I take them from idea to MVP (usually a basic CRUD web app). I translate ideas to technical requirements, write a spec, divide it into milestones, negotiate payment schedule, and manage the project to completion. I structure the price per milestone so that my team is rewarded for hitting deadlines, e.g. Milestone X (some subset of feature requirements) pays $1000 by 4/31, or $1500 by 4/24. This has worked well for me in the past and is a good way to keep projects on schedule.

I just started doing this, and I've gotten a new lead or two each week so far. None have been serious enough about the idea yet to immediately execute, but I suspect with some pressure applied they will be ready.

I spoke to an alumnus from my school who graduated 3 years ago and did this in an official capacity. He started a "product development consultancy" wih a hybrid employee/outsource model, and tapped his alumni network for projects. His company completed 39 projects in its first year, all sourced from networking.

If you are an engineer also blessed with a strong network and interpersonal skills, I suggest you look into this as well. You don't need to code every app that someone wants help with. Often you can help give direction, or even charge for your services of managing an overseas team. People who leave finance are a good match because they can raise funds to the point that you can offer cheap, quality service from a friend, but also pay your developers way more than median salary in their country. I think of it like arbitraging my networks and skillsets.

Regardless of whether you do that, I definitely recommend putting an end to the habit of ignoring the app ideas of your friends.

tieTYT• 11 years ago

Always refuse if someone asks you to sign an NDA before hearing their idea

I hear this a lot. What's the reasoning?

Retra• 11 years ago

1. They are probably extremely selfish. 2. If they think they need an NDA in a conversation, then they probably don't know how to think well enough to have an idea worth hearing.

vonnik• 11 years ago

1) NDAs are pretty much unenforceable. If someone asks you to sign one, that means they are very new to the business, and probably have a lot of other mistakes to make. 2) It shows they don't trust you. My rule of thumb is: distrust is a disease that NDAs won't cure, and indicates much deeper problems. If you don't trust someone, just don't share with them.

zxcvvcxz• 11 years ago

A lot of these 'problems' and 'lessons' seem to come as a byproduct of being a part of a 'scene' to do with startups, particularly uninspiring web and mobile startups. 'Uninspiring', to me, means people doing a startup for the sake of doing a startup, not because they're passionate about the problem, have found a good opportunity/market to exploit, etc.

One of the best pieces of advice I got was to not associated with losers. It's harsh, I know, but if you see people around you not being productive and successful, chances are you're in the wrong peer group. Better to have a smaller and higher quality social circle than to let your time be wasted by 'the scene'.

There's a good heuristic - anytime someone calls something a 'scene', it's time to leave. It means the people are interested more in the idea of what they're doing than the real thing.

brc2• 11 years ago

It's also one of the hardest things to avoid - associating with losers. That is because the losers tend to look for company and make it easy to join their groups, while the achievers and doers jealously guard their time and acquaintances - which is why they are achievers and doers.

A neat way around this can be to start doing recreational activities that achievers do. Taking time to develop skills in whatever that is will help to make friendships and relationships that matter. This doesn't have to be as obvious as joining an expensive golf club - in fact, that club might be populated by losers in the 'golf scene' - golf is horrendously time-soaking. It could be an early morning cycling group, could be anything. It's most likely not a pub-visiting binge drinking group.

_RPM• 11 years ago

The people who are really getting somewhere aren't the people who are always out for drinks

I've found that true in a lot of contexts.

Everyone has a hidden stash of domains they've never used

Very true for me. I have about 7 domains not being used.

chaosfactor2• 11 years ago

P(you create a successful company|you read this guys post) ~= 0

chrisshroba• 11 years ago

Please avoid gratuitous negativity.

http://blog.ycombinator.com/new-hacker-news-guideline

chaosfactor2• 11 years ago

It's not gratiutously negative - or even negative at all. It's a matter of fact. The advice in that column will not lead you to create a successful company, so take it with a healthy dose of humility and with a grain of salt.

Indeed, while your post can be considered harmful, mine cannot.

giis• 11 years ago

Its a very good list. Completely agree with 53 and 54. Thanks for sharing it. Sometime ago I listed out my experience here giis.co.in/do.html

henryaj• 11 years ago

It's really easy to become hyper-critical and respond to every idea with "yeah but that won't work because of x". This is lazy, don't do it.

I've a close friend who does this -- I wouldn't even call it being 'hyper-critical'; I call it snark. It's a really negative personality trait and one I take pains to avoid.

As Sam Altman said in his How To Start A Startup lectures: usually the best ideas are a little bit weird.

fragglesmock• 11 years ago

A few years ago I took a run at this whole " startup " thing and I would not exactly call the endeavor a ragging success .

I sunk into this hole of building that it is time to come out of and your message from the future makes me feel a lot less crazy .

Thank you for the time you took to write it .

What I'd tell myself about startups if I could go back 5 years

Related Stories