So now that you have your idea, you can go one of two directions:
1. Build a prototype yourself.
If you’re an engineer and the project is something that you can build and launch in your free time or you can cover your own expenses for some period, that may be a good approach.
2. Build a small team.
If you’re not a great engineer, you must go down path two. Another benefit of this path is that good ideas become great ideas through debate and iteration. But it’s often harder to coordinate the work of more than one person in your free time. So this path, for all but the independently wealthy, will likely require that you find a source of funds sooner than path one.
Let’s assume that you go down path two, because sooner or later you will likely need to recruit a team anyway. So who do you need?
For a web-based business, my take on the perfect team includes:
+ 1 designer (interaction design, visual design, and CSS).
I’m a big fan of starting with very detailed interaction flows AND visual design before you write one line of code. This is not the standard design approach for the vast majority of products, which is one reason so many products suck. I’ve made this mistake too many times myself. Spend the time upfront to get the user experience right. It’s worth it.
You don’t hire a designer to do your logo, although she can do that. You don’t hire her to do the visual design, although she should be able to do that too. And you don’t hire her because she is a black-belt in CSS, although that’s a big plus. You make a designer one of the first recruits because a great designer will help you get your interactions right. And it’s much better to do that from the get-go, rather than to try to retrofit design after the fact.
+ 2/3 engineers.
It depends on what you’re building, but it’s always nice to have more than one engineer to discuss ideas. If what you are doing requires a good bit of Javascript or Flash, you likely want to make one of your engineers a front-end engineer. If not, good core engineers can get the basic Javascript / Flash stuff done.
Don’t hire the perfect VP of engineering. Get doers. It’s easier for doers to learn how to manage than it is for managers to learn how to do. Find extremely smart people who can help you think about and build the product. Engineering is not manufacturing. Engineering is about problem solving. Your idea articulates the problem and a high-level solution hypothesis. The entire team needs to work together to solve the problem.
In the early days, all engineers should be general purpose — everyone writes code, does their own QA, and someone on the team takes the lead on operations (most web businesses should outsource their servers in the early days).
That’s it. I believe that a 3-5 person team can build v1.0 of just about anything on the web. If you’re not the designer or one of the three engineers, you’re overhead. Which means that you either shouldn’t be on the team or that you are the CEO and that you should be doing everything else, including getting space, ordering equipment, raising capital, negotiating deals (content acquisition and/or distribution), and doing the dishes.
16 Comments
June 19, 2008 at 3:40 am
Mike, please. I think you are quite hypocritical here. Do you need me to get into chapter and verse in public?
June 19, 2008 at 4:12 am
Joyce,
What’s with the ad hominem arguments?
Do you disagree with the CONTENT of the post? Do you think hiring a designer first is a bad idea? Should folks start with a management team of marketers and BD professionals first instead of engineers? Is 3 too many or too few?
-Mike
June 19, 2008 at 6:25 am
Tell it like it is Mike
June 19, 2008 at 1:54 pm
>all engineers should be general purpose — everyone writes code, does their own QA,
Disagree with you here. All engineers should do someone else’s QA. This is more likely to expose flaws and unstated assumptions, and has the added benefit of improving communication.
June 19, 2008 at 2:58 pm
@Yummyfajitas,
I agree with you.
The point I was trying to make was that you shouldn’t hire a QA team, operations team, front-end engineering, back-end engineering, visual design, interactive design, web dev all as separate people / teams, but rather all-in-one people as much as possible. But I appreciate and agree with your point about having people test each other’s stuff.
June 19, 2008 at 3:03 pm
@Yummyfajitas,
I don’t think Mike was espousing some specific practice of testing, I think he was just trying to make the point of software engineers also acting as QA engineers rather than having a separate teams for both disciplines. In practice though, is there really anything wrong with testing your own code. I mean I never seem to find any bugs when I do it?
June 19, 2008 at 8:35 pm
I’d agree that with a web product the most important ingredient is the interaction design. Most people don’t even know what that is so if you do you’re a few steps ahead. Good interaction designers tend to have very reusable skills.
June 19, 2008 at 9:09 pm
Ooops, don’t drink and comment kids! Sorry Mike.
June 19, 2008 at 9:41 pm
[...] 19, 2008 You have the IDEA and you have the core TEAM, which hopefully includes a great designer (at least as a contractor, but preferably a co-founder or first hire). So now [...]
June 20, 2008 at 12:04 am
Haha, I can’t stop laughing at troutgirl, forget the drinking, maybe it’s something she smoked
@Mike, I agree with your general approach. For my own startup, http://www.jiggyme.com, I considered hiring an offshore guy to do the work but decided to do it myself instead. It took me 5 months to go alpha and 8 months to go public beta.
I am working on my next startup now using the same approach.
June 20, 2008 at 5:10 am
[...] volně založen na základě článku Mika Speisera a vlastních současných zkušeností. Foto wilbertbaan Zhodnoť to:: [...]
June 20, 2008 at 8:09 am
Hm, in your proposed team, who defines the product?
I see how an interaction designer could make a product very usable, but I believe that skill set is different from knowing what product to build. The same is true of engineers.
I know several CEOs who take the role of PM, but it’s tricky to do that while managing everything else. Do you think a PM too much overhead to have in a pre-v1.0 team?
Mark
June 20, 2008 at 5:18 pm
@Mark, I do think that a PM is too much overhead in a pre-V1.0 team, in Mike’s team suggestion, it is a skill that can be shared between the designer and engineers IMHO.
@Mike,
It occurred to me that while your team suggestion makes sense, it is not always realistic for most startups because of lack of funding. While I would like to hire such a team, it is extremely tough to get the right people on board without money. This is a major reason why I ended up doing all the work myself for my startup. Perhaps you can also share your thoughts on how unfunded startups can achieve the same goals (if possible).
June 20, 2008 at 5:20 pm
@Mark, I do think that a PM is too much overhead in a pre-V1.0 team, in Mike’s team suggestion, it is a skill that can be shared between the designer and engineers IMHO.
@Mike,
It occurred to me that while your team suggestion makes sense, it is not always realistic for most startups because of lack of funding. While I would like to hire such a team, it is extremely tough to get the right people on board without money. This is a major reason why I ended up doing all the work myself for my startup. Perhaps you can also share your thoughts on how unfunded startups can achieve the same goals (if possible).
June 20, 2008 at 5:27 pm
@Mark and Bob — I don’t think you should recruit PM in the first 5 hires, if someone else can fill the role. Hopefully someone else can. YouTube (founded by a designer and engineer); Google (founded by two engineers); Yahoo (founded by two engineers); Oracle (founded by an engineer); Microsoft (founded by two engineers); Amazon (founded by a hedge fund manager); Ebay (founded by an engineer). This is off the top of my head and I’m sure some of these folks had PM early. But the product management role clearly can be done by engineers and/or designers.
@Bob — Agreed. That’s why I called it my “perfect team.” Unfortunately, it’s difficult to build a team like this without money. But if you start off by yourself, this is still the path I would pursue once you have capital (from operations, self-funded, or venture) to build a team.
October 12, 2008 at 11:14 pm
[...] neboli na vaší hlavu bude padat všechno ostatní. Text volně založen na základě článku Mika Speisera a vlastních současných zkušeností. Foto [...]
Leave a Reply