People work on what they want to work on. Product development is driven by whoever wants to drive product.
That is the surest way to reduce your startup's odds of survival. In this case, it would become a prototypical case study in survivor bias.
GitHub is lucky that they are building a product that is tailored for developers. It makes their survival rate doing this slightly higher because the developers are (only vaguely) similar to their customers. The further these two points are from each other, the worse this advice becomes.
A startup needs somebody who understands how to drive products into markets. Whether this is the CEO or a product manager hired off the street doesn't matter, but they need somebody doing it who has the real authority to turn those learnings into a product fit for a market.
FWIW, I've lived the flip side of this coin: building a tool for developers driven by what we thought would be cool to build instead of having a product guy hitting the street to understand the real customer. After burning through more than $20M, the lights got turned off.
I'm not entirely sure what you mean by "only vaguely." The fact that passionate developers are building developer tools has a lot to do with why we've been successful.
Chris, the CEO, has spoken at length about this topic. He and I built another site prior to GitHub where there was very little correlation between our interests and the product we were building. Not surprisingly, our hearts weren't in it and we threw in the towel.
All of this said, just because you're working on something you're passionate about doesn't immediately mean you're bound for success; it just helps tremendously.
I say only vaguely because what you want to use may or may not have any correlation with what people want to buy, and it is extremely risky to assume that correlation exists.
just because you're working on something you're passionate about doesn't immediately mean you're bound for success; it just helps tremendously.
It helps immensely (in fact, if you don't have that, you are doing it wrong, IMO :), as long as you don't let your passion get in the way of figuring out what your customer wants.
Like I said, dev tools are a special breed that have more wiggle room for this, but as my experience shows, it is not immune from failure (in fact, developers are notoriously cheap because there are so many good, free dev tools out there, but I bet developers aren't your primary customer, but rather their managers).
My response can be summed up in one sentence: with all startup advice, beware survivor bias!
I think the idea they're pushing is, why force a centralized structure for product development/design decisions, when your programmers are intelligent and independent enough to do it themselves? It's not just a free-for-all where people work on shiny toys; developers should be allowed to think about the customer too! It's quite a different energy when the same guy is recognizing what needs work (i.e, what a 'product manager' would do) and developing it.
Think about the Linux kernel - contributions are distributed and asynchronous, and most of the authority figures arise organically rather than by decree. I don't think you need product managers, they just relieve the developers of having to do that work themselves.
And yeah, it definitely helps that github uses github to write github. But dogfooding really isn't that unusual or difficult.
I wonder how they keep the product focused with a do whatever you want product development schedule. Rather sounds like a good way to end up with an elephant with a long neck and a short nose.
That is the surest way to reduce your startup's odds of survival. In this case, it would become a prototypical case study in survivor bias.
GitHub is lucky that they are building a product that is tailored for developers. It makes their survival rate doing this slightly higher because the developers are (only vaguely) similar to their customers. The further these two points are from each other, the worse this advice becomes.
A startup needs somebody who understands how to drive products into markets. Whether this is the CEO or a product manager hired off the street doesn't matter, but they need somebody doing it who has the real authority to turn those learnings into a product fit for a market.
FWIW, I've lived the flip side of this coin: building a tool for developers driven by what we thought would be cool to build instead of having a product guy hitting the street to understand the real customer. After burning through more than $20M, the lights got turned off.