What I'd tell myself about startups if I could go back 5 years
talkingquickly.co.uk
talkingquickly.co.uk
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.
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.
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.
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>
If so, then you should pick the platform/stack that lets you iterate the fastest. Consider both your experience and your problem space when making the choice...
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.
More here: http://henrikwarne.com/2014/12/15/programmer-knowledge/
The best developers I've ever met all have one thing in common. They've all written stuff outside of school and the workplace. Not that everyone keeps doing so, but they all have at least when starting out.
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.
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).
..why did you choose Erlang?
Jan Koum: Oh. [Laughs] It's one of those intuition, intuition, things. I knew nothing about Erlang and when we - I actually we still don't; we have a lot of our engineers who do - and we actually have like a really small server team, probably seven or eight people supporting our entire user base on the backend, who are insanely brilliant and who wake up in the middle of the night and fix servers. The thing about Erlang is that I was looking for an open source chat server to drop into this backend that we built that could identify which of your contacts are WhatApp's users. I was thinking, we can probably use XMPP, which was an open protocol for messaging, and I was looking for an open source XMPP server and I couldn't find one. There was one written in C, but it was outdated. There was another written in Perl and I knew that wouldn't be able to scale. And then I came across Erlang -- "What is this Erlang thing" and it was the first time I'd heard of it and so I began to research. It turned out to be the best engineering decisions we ever made, by just -- we were forced to because there was nothing else to use. It allowed us to scale really well. It's like built for what we need to do and it's a functional program -- a language that has message passing. It lets you cluster servers into nodes and the others like devalued database that's really cool. It can like synchronize all the data across the servers. We obviously tweaked it a lot internally. We have a couple guys who specialize in tuning Erling, but part of it was like we have no choice. It was the only one available at the time and it works really well for us.
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).
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.)
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.
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.
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.
> 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.
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.
Ten years is an obvious extreme but the point is that hiring managers who try to get people who already know the programming languages and tools their company is using aren't idiots. It's a defensible posture.
Young people are ready to work lower salaries, will do work on weekends, late nights and in general a lot more agile in a lot of issues.
In fact the 10000 hour/10 year rule itself is subject to a lot of assumptions like access to information being expensive in terms of time and effort, so having someone on the team with that information would help. These days you have stack overflow and a dozen places on the internet who can much of that at a far more lesser price.
Its getting easier over time to build systems and solve problems.
Having a lot of unstructured information in your brain has no value.
If you learn a lot, and then start putting patterns together and build more complex rules out of that - that has value. And by the way, the result of that process is the kind of thing that could be easily transferred to other particular areas.
Unless you're doing the literal bottom-barrel of engineering work where you don't involve algorithmic know-how, there's no escaping having deep engineering.
Perhaps what offends me most is the notion that "you can just google/stackoverflow it". No you can't. If you don't know your tools, every problem will be a nail and your only tool a hammer. You're not being fast, you're being hasty and creating a lot of waste by moving very slow on the aggregate. It's this attitude that introduces massive bugs in the system because an engineer copy/pasted code without knowing it's implications.
Development is knowledge working; you need to invest in your knowledge tools else you're just moving really slow and you don't even know it.
If you think of it as inert info, the accessing of which in the brain is equivalent to reading it on a web site...
But it isn't. Brains, especially in respect to deeply understood domain knowledge, change in response to how they're used.
Experts' minds create shortcuts to information in their area of expertise.
Having more information means having the ability to synthesize it, gain epiphanies that would otherwise be overlooked--and reading someone's blog post about their epiphany isn't the same as having it yourself.
Looking things up won't do you any good if you don't understand what you find, and you're going to waste time flailing around if you're unable to recognize the class of problem you have (which is what algorithms are for -- they're solutions for classes of problems).
Also, people without understanding of CS fundamentals often unwittingly write dog-slow code.
Where I am sitting, you absolutely have 10 years (or more) to give toward a specific cause, and the path of the software developer is one of lifelong improvement.
Stuff like "the rate at which tools are changing" doesn't matter too much, because that stuff is just surface-level knowledge, not deep knowledge.
I am 43, and have much to do yet; if you are telling me I am due for retirement, I suggest you have a very warped view of the world.
if so, cheers to you! keep up the good work. if not, same sentiment regardless.
All of the Web dev I've been involved in is pretty straight forward stuff to manage records in a database or make it easier to interact with the records on a browser.
The only thing remotely complex was 3d rendering. Perhaps I have a narrow view of what is considered web dev now.
I didn't mean to say that. Everybody has individual choices, and I respect yours.
And not all of us would like to code when we are 50+. Personally I would like to retire early to take time off for other things. This is entirely a personal perspective, and might change from person to person.
No, no thanks. I work in the medical device industry, but this applied everywhere. If you don't understood your tools at a deep level please, study. Go off and write some trivial stuff before you infect important systems with your ignorance.
If that's indeed a trend, then this industry is moving towards a pretty bad place.
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.
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.
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.
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.
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.
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.
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.
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?).
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.
You're probably fine if you're buying commodity products like, say, web-hosting. You might get into trouble if you do it with negotiated purchases like contractors. YMMV; again, "not pissing people off" is a pretty good legal defense, and I certainly know folks that have hired artists or app developers before incorporation without anything bad happening.
http://www.irs.gov/Businesses/Small-Businesses-&-Self-Employ...
Here was what I was trying to do: http://www.palere.com/blog
I also tried to crowdsource the interview process...
Someone's always already working on the same idea and that's not a bad thing
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.
Some folks are good at the former, others are good at the latter. The really good ones are comfortable with both.
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...
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.
Lots of people at evening startup events just want to have a drink after work. Get their card and pitch them on office hours.
Agreed. I can even be tempted by the occasional lunch as well!
"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?"
Excellent point about an excellent list in an excellent post.
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."
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.
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.
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.
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.
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?
Coding something for more than half a year without any real users makes selling the idea difficult, and makes any setbacks bigger in terms of lost morale and keeping momentum.
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.
Maybe you run into these people all the time. You just don't know because they don't tell you about it.
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.
Their end product took quite a few iterations because they saw things they thought were better and started over so many times. You don't do that when you are solving problems for people, you can't just throw something away so you get dirty and you solve real problems. Sure, you're not going to win internet points on hacker news for the most pornographic code base, but you're actually helping someone with your code.
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.
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.
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.)
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!
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.
Apologies, tricky wording.
I find this hard to believe and can see why experienced people would keep startup ideas close to their chest.
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.
It's supposed to be humbling advice to directly contradict this argument.
Edit: Apparently in their mission statement they claim to only use proven ideas, but I still wouldn't do business with them regardless.
It's even in their mission statement: > Rocket identifies and builds proven Internet business models and transfers them to new, underserved or untapped markets where it seeks to scale them into market leading online companies.
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...
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.
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.
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.
while it feels counter-intuitive, this is absolutely true. people don't steal your idea because theirs is always better.
Zuckerberg got the inspiration to do Facebook from the project the Winklevoss twins were trying to get off the ground, and further to do an elite social network riding off of Harvard. That was their primary contribution to what became Facebook; which is to say, not much.
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.
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.
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.
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'.
Ideas get better when more people think about it.
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.
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.
> 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.
No matter how you approach it, feigning interest, dismissing them, or talking about your reserverations, they never seem to get it.
The list itself would benefit from the same advice -- cutting it down to half as many items would have upped the overall quality IMO.
- 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
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.
Pitching anything farm tech / data related in the bay area between 1994 - 2012 or so, would have mostly fallen on deaf ears.
Under no circumstances would you have run into a scenario of 1,000 bay area entrepreneurs stumbling over themselves to copy your farm tech startup ten years ago. You can be sure there are blind spots of opportunity today in the same way.
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?
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.
> 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.
http://sfist.com/2014/09/15/sf_gets_its_first_bitcoin_atm_at...
So true. Should probably block HN.
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.
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.
Pure curiosity.
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.
Interestingly I read an article (perhaps it was posted here?) in recent days about westerners struggling in Japan and one key point was the expectation to go out drinking heavily after work every night.
I can see the merit in holding networking events surrounding drinking as alcohol will (perhaps) get people to put their guard down, relax and socialise more than if everyone were stone cold sober.
I will be interested to see what happens with regards to marijuana and networking events. Though the moral argument against marijuana is gone, there is still a stigma associated with the drug. In many professional circles cocaine is currently more likely to be the accepted drug of choice than marijuana (going by personal experience).
Marijuana is also different to alcohol in that one can have a few drinks over a reasonable amount of time and be more relaxed without getting intoxicated, however a few drags on a pipe with reasonable marijuana in it will cause rapid intoxication. How well that bears for networking events is something I'll certainly be interested to see!
This should be one of the HN guidelines.
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.
> 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.
Conversely no growth is a clear call to action that the product sucks, and needs to be abandoned!
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?
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.
I don't think I've missed any quality opportunities with this approach.
I'm always very polite about it and explain my reasons.
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.
You can watch it here: http://developertalks.tumblr.com/post/115528336319/zach-holm...
>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.
And also a nice problem to have. Most 'startups' won't get to this stage, so spending time on a logo _is_ a waste.
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
Ikea
Dyson
Coca-Cola
Pixar
Since we're talking about startups, can't forget Facebook's original name/logo: http://logos.wikia.com/wiki/Facebook
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 .
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.
while !comprehensionCan you elaborate on this please?
I was just about to do this... hmmm... maybe I need to think harder.
I hear this a lot. What's the reasoning?
What is this supposed to mean?
Also that meaningful investments don't necessarily come from traditional, real investors.
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.
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.
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.
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.
Indeed, while your post can be considered harmful, mine cannot.
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...