A good read, but the article makes it sound like Seth was some kid who hadn't the slightest idea of anything business, kept trying, and finally hit jackpot with Meebo, when in fact, his CrunchBase profile says he "worked in IBM’s mergers and acquisitions department, while also working on corporate strategy and venture capital initiatives prior to starting Meebo." That's not to invalidate his advice, but that seems like a hell of a lot of advantage to have, on top of a great founding team, when heading into a startup.
Is Meebo really "the jackpot"? Their service which seems, at best, marginally useful, and I despise the name. How on Earth they spent $38 million re-inventing the web-based chat wheel is a mystery to me.
Meebo is not just another web-based chat. Meebo allows access to all the major instant messaging services via the web. In other words: whenever you just have http-access to the internet, you can get access to your instant messaging.
For those people with a lot if communication happening via ICQ and MSN and whatsoever, this is a very strong and helpful thing.
Being the assistant manager at Olive Garden does not mean you can open your own restaurant. I think that experience at IBM might help in some instances, but it probably didn't translate well to the startup mentality.
No, it doesn't mean you can open your own restaurant, but it means you have at least an idea of how a successful restaurant is run, rather than just starting a business because you're a good cook.
Its not my path (Go out, get job, learn how to do things there, start own business), but it definitely brings some advantages with it.
Working in a corporate environment in any capacity I think really takes away from understanding what it takes to start a company.
I've built many trading systems but getting my own thing off the ground has been really really hard. I'm getting there slowly but looking back I think I'd have been more sucessful if I had tried to start a company right from college.
In corporate america, all you do is take care of your own small corner of the business. Namely either sales, business or coding. Building a business means knowing all three.
Working in M&A at a bank would basically mean that he created word documents containing lies of how great an acquistion a certain company is for potential buyers. I have 3 friends who do this for a living. I would bet 0 of them would have a clue how to start their own business.
In his case he (ie working for the aquicuirer) would be reading these documents and trying to decide if they make sense and which company to buy. BS because mostly your say really doesnt matter.
I'd disagree with this, but I do think it's important to understand the limitation of what you can learn in a corporate environment.
My path was the opposite of many people: I worked for 2 startups, founded one, am now working for a big company, and hope there's another startup in my future. Google was the first company I've worked where I didn't have to set up the build system. And naturally, Google's build system is better than anything I've ever set up.
When you work for a big company, you get to draw on the accumulated wisdom of thousands of people that have come before you. A lot of things that seem obvious once you've looked at them - like how to organize your code, or how to design C++ programs with clear object ownership, or how to unit test libraries with lots of dependencies - require lots of laborious trial and error to get right before yourself. Many startups are filled with people that are fairly new to programming (because that's all they can get) and don't have that experience. You can easily go through several jobs thinking that SourceSafe and zip files count as a version control system, it's normal for functions to be 400 lines long, and deployment consists of FTPing a JARfile to the production servers.
The weakness in big companies is that you don't see all the false steps that led to these "best practices" being instituted. So you might leave and found a startup thinking that you absolutely must have 100% unit test coverage for everything, because that's the way things were in your 100+ person division in the old company. Or you might go too far in the other direction, and think that you don't have time to setup a decent build system. It takes experience - in both environments that have them and those that don't - to understand the particular circumstances where "best practices" are really best practices.
IMHO, the ideal career setup for founding a startup is to intern at startups in high school & college, then work for a fast grower or big company for a couple years afterwards. (And start lots of little companies while you're in classes, of course. ;-)) Startups typically demand more from interns than big companies do, because there's more to do, and you also get to see firsthand all the problems caused by inadequate development practices. And then you can see things done right at a big company, with enough time to actually dive into the meat of it. You still probably won't succeed with your first company (almost nobody does), but at least this'll expose you to what both success and failure looks like.
Well in the big-company that I work for some groups still use a unix directory as their SCM system. Some groups still use fortran and some groups still link everything into one executable which is around 975mb for one instance on the file system.
By big company what you really mean is "work for google".
Again the only thing you'll learn is tech. You wont learn sales or business or accounting.
Taking your example of organizing code and designing C++ code, you could develop these skills by just working on open source code will give you that.
Infact I use a lot of the tools/programming idioms/libraries that I've learnt from the open source community at work. It actually gives me an edge over the crap they do at my big-company.
Again, if by "work for big company", you mean work for Google then I totally agree.
"Again, if by "work for big company", you mean work for Google then I totally agree."
Man, I have failed again in my quest to experience every kind of employer.
I think my next job is going to be at McDonalds. I've never worked in food service, and perhaps it won't be quite a distorted perspective as where I've ended up.
In corporate america, all you do is take care of your own small corner of the business
That's true, but you still have the opportunity to learn about other aspects of the business even if you're not responsible for them. I talk to people in other departments, go to their (open) seminars, read about what's happening. Not to mention large corporations have many, many training classes in various areas. I'm a software developer, but I took in-house classes in Finance, Recruiting (improving interviewing skills), Communication, Influence, and more.
Don't just sit in your little corner and you may be amazed at how much you can learn.
He was quite self depreciating about his pre-launch role (button goes over here!) which is in my experience a universally good indicator of someone I would want to work with.
(Plus 'button goes over here' type input is actually really valuable - when working on UI stuff you tend to get tunnel vision and/or implement what works with the underlying design rather than what makes sense to a user who has no idea about the structure of the data.)
"When I point out that they’re all business people, and wonder who’s going to build the product, they almost always fall back on “we’ll get a couple of undergrads to do it,” or, “we’ll outsource it.” If I hear either one of those, I know the startup’s already dead."
God, ain't that the truth. It's an unrecoverable error. Learned that one the hard way.
His entire product is just an HTML front-end to libpurple, which is 99% of his codebase. And that is FAR from "nothing"
And libpurple isn't even mentioned in the article, yet a ton of space is wasted on how he kept thinking about a "next great thing". What an asshole.
At least Pidgin folks openly say "we are GTK+ front-end to libpurple". Will it kill these SV types to admit building HTML front-ends to open source products?
There was something very right about Zed Shaw's rant regarding open source licenses.
its easier to preach than actually do, you ALWAYS start thinking, "man I need more content" or "this one extra feature will REALLY make us take off."
same thing goes for the servers, everyone starts out thinking that they need some server farm, just in case they hit some success. Here is a dirty little secret, don't expect overnight success, you'll have plenty of time to grow into needing that big server, but there is no point in wasting money on something you don't need.
> Here is a dirty little secret, don't expect overnight success, you'll have plenty of time to grow into needing that big server, but there is no point in wasting money on something you don't need.
Definitely true. One remark though: "plenty of time" won't be entirely true. When you first need to scale up you probably don't have any kind of server monitoring set up. There's more important stuff to be done. This means that you will notice far too late that you're out of capacity. It will be hard work and it will be painful for you and your start-up.
The best bet is to just use the cloud, like AWS. Sure it's not as fast as a dedicated server...but honestly is it really that bad? You might get 90% performance, and chances are your users won't even notice.
It scales for you, and you only pay for what you use. So if your site starts out slow, you'll be paying similar costs to a shared server. If your site takes off, you'll be paying similar costs as a dedicated server. But the important thing, is that you won't have to bother guessing which will be the case for your site.
There are many things you don't need to be focused on at the start, but monitoring is something you should set up from the very, very beginning. Knowing when you're open for business and when you're not is absolutely crucial. Plus, it's cheap -- $5/month or less.
At the risk of being downvoted, I disagree. Maybe this is just a good introduction to the series of posts, but for now he simply regurgitated what we already know, ie "Build something, put it out there, then iterate". What it fails to tell you is how to get that initial traction.
For every 50 consumer startups that email Techcrunch/Venturebeat/Gigaom etc... one will be covered. If this does not happen, then getting that first set of beta users will be extremely time consuming (unless you resolve to less-than-ethical methods aka SPAM).
Products like Meebo took off from the start. I am sure most issues they had were around hiring, scaling, and monetizing. Most startups' problem is not what to do with the traffic or how to afford more servers, larger teams. The biggest problem we have is not even building a prototype or convincing someone to partner with us. The issue is how to get users.
Maybe in his next posts he will touch this subject.
I don't get this. Let me say this as succinctly as possible: it's not 2005 any more. TechCrunch, VentureBeat, Mashable, and GigaOm will not help you get users.
We've been in those publications multiple times, and since I run Google Analytics with goals, I know how many new users and transactions they send. It's de minimus. The links might be good for PageRank, but you'd rather be in Lifehacker anyway.
If you think users will come because you get into these pubs, please try harder.
Everyone knows major blogs will send a bunch of visitors to your site and most will bounce back immediately. Webmasters usually follow up with "Techcrunch traffic does not convert...". Well, in all fairness that is not the bloggers' duty to figure your conversion method. At any rate for most consumer startups a bunch of visitors from leading tech blogs is better than no visitors.
I run Google analytics with goals too for my website and at my day job. And let me tell you that in both cases I am pushing products that no one is jumping to write about. The same is true for (arbitrarily) 9 out 10 companies. Hence organic traffic is not easy to create, and paid traffic is as good as throwing money off the windows.
So when giving advises, give advises to this group. Not the one who can built a product and gain traction easily. I have not done this successfully so I cannot tell anyone how to but here are a few examples:
- Don't go to major blogs first, go to smaller ones (TC used to be small when Meebo launched in their living room) and create a relationship there. Find a few competitors or a business that is complementary to yours and do a Yahoo Link Search/Google BlogSearch to figure who is writing about them (call it regression analysis if you want), and drop them 4, 5 lines and ask them "Can you please present us to your audience". Email users with an "Invite your friends" link. SEO is a marathon, not a Sprint. Be steady and set a goal to email at least 5 new blogs/newpapers everyday. Call a couple local radio stations, or TV stations, everyone is looking for a story. If people don't answer after 21 days email again with a polite 2 liner, because sometimes your emails get overlooked. Email the guys at Startupschwag, and ask if they can include your startup in their next mailer. Etc....Be HOTDAMN PERSISTENT, because the "only thing you can control is INPUT".
Could your problem be that you're pushing the wrong product? If people don't find your product useful/exciting/etc, there's no reason to expect any amount of coverage to make an impact on your traffic.
I couldn't agree more, which is exactly why in my spare time I've been making Traction, an interview series on this very subject: http://traction.blip.tv.
However, I still find the OP useful. I can't tell you how many aspiring entrepreneurs I've met who need a reality check. This post provides it succinctly and understandably. Granted, this crowd (HN) is pretty much already on the next step, but a lot of people are stuck on that first one.
Hopefully he'll get there. Anyway, it's a good place to start a series - essentially, how to start.
Maybe it's not a typical symptom in the HN community as much, but in general, I really hear a lot of people working on startups from the outside in: high concept, powerpoints, spreadsheets, raising money, legal nonsense, THEN finding someone to build their idea.
It's good to be reminded occasionally to just build the product when you're getting started.
Getting users: the most important part of any startup that most founders like to ignore because it is one aspect they can't control.
Hyper-focus, have patience and persistence, and constantly keep improving the service. There is no other way. TechCrunch only helps you for a day. But after that day is over, you are back to the same problems again.
The best composition is probably one engineer whose passion lies in the pixels on the screen and another engineer whose passion is making bits fly really fast through servers.
Seriously though, having someone who comes from the aesthetic/UI side is a lot more useful than the generic "MBA" type who has a big vision and just needs someone to build the site. For instance, Flickr and Typepad both had a hacker/designer founding team. One of the recent YC teams had 2 designers and only one hacker and have been doing really well. The best example is probably Apple, SJ had some technical skill, but his real art was designing the UX, but had SW to handle the technical challenges. I'm all for the coder/coder team, but a great designer is not a bad addition!
I think what you want is someone who can do both the interaction design and the front-end coding - they have skills in making things look pretty, but can also write enough JavaScript/Python/C++/whatever needed to interface with the backend. Someone like Eric Costello of Flickr or Glen Murphy of Google Chrome.
My ideal founding team would have three members: a frontend engineer/designer, a backend engineer, and a business/marketing person. I think this is basically what Seth was saying, and I've also heard the RescueTime founders say that this is a great combination (it's what they have).
I wouldn't really want to go without the business person entirely, simply because somebody has to hold the entire product vision in their head, and the engineers usually have plenty to think about anyway. The tension between "C'mon guys, we can make this better" and "Okay, let's dive in and make this better" seems to be necessary for great creative works. That was really Steve Jobs' role in Apple - as I understand it, he did basically none of the coding. It also helps to have someone take care of all the interruption-driven tasks of running a company - following up on leads, talking to the press, drumming up excitement, getting feedback from potential customers, etc.
I would say that in the end, it's all about the user experience, and that unfortunately or not, comes from the design.
The cleverest app, or piece of coding is useless if the user doesn't get what they want from the experience of using it.
Brilliant design doesn't have to be flashy or clever, and of course, the simplest interfaces are always the best. There is a huge amount of skill and intelligence involved in taking what is a potentially complex idea or concept, and expressing to the user, not only how to use it, but also what the app is capable of, in a simple, graphical way.
There's been a of of discussion on HN about the new Sequoia site. I think I'm one of the few who think it's brilliant, because it already assumes a lot about its users, and that if they're on the site, they probably have a pretty good idea already of why they're there. The site is tailored to those people, they don't need to be hand-held with descriptions and explanations. This would be completely out of place in many other instances, but the designers knew their users, and what their needs were, so built accordingly. The web is a graphical interface for information, great design is crucial.
The OP made the point about a team...my point is that this has to a be a balance of skills, each member understanding their value and importance to the project, and understanding and valuing the importance of their colleagues. Teams made up of entirely one skill set will never be as productive as one with a wide range of skills.
Good read. When should founders start to incorporate a company? Can founders just release a Web application without worrying about things like incorporation?
I believe, the incorporation is a USA thing more than other parts of the world. Again with no credentials im under the impression outside of America it is easier to setup a company and just kick off a web app without an "incorporation".
Maybe a budding lawyer can shed some light on the benefits of incorporating before you have anything truely worth incorporating.
