I like GitHub. They make a really great product that is loved by almost every developer I've talked to who has used it. That is a worthy achievement.
Well, I read this post by Zach Holman about how GitHub has scaled their development process. It is well written by a guy who obviously loves his job, which means he's an performing as a real artisan.
Unfortunately, I think it would be highly unfortunate for any startup to take this as advice on how to do things at their company.
People work on what they want to work on. Product development is driven by whoever wants to drive product.
No. No, no, no, no. No.
That is the surest way to stack the dice against your startup. In this case, it may also become a prototypical case study in survivor bias (see my previous article discussing other types of logical fallacies in product development)).
GitHub is lucky that they are building a product that is tailored for developers. It means they get a saving throw. It is only a saving throw, though, because their developers, who are choosing what to work on, are only vaguely similar to their customers.
Think about this: GitHub is lucky their developers are similar to their customer (or at least their customer's influencer). The further these two points are from each other, the worse this advice becomes.
A startup needs somebody who understands how to find a market and drive a product that fits into that market. 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 for a market.
For what it's worth, 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 a huge sum of money, the lights got turned off.
Building more barriers to product development is not the answer.
Neither is building features that confuse your market, cost you money to maintain, and, in general, don't advance your company's objectives.
I take my relationships with my developers very seriously. Developers who are treated as artisans create better products. I always strive to have relationships such that I am providing the why we are building it; the developers are I are going back and forth on the what to build; and the developers own the how to build it. That back and forth is crucial to building great products and is one of the best parts of my job.
But the answer to keeping the development pipeline open is not to just let developers build whatever tickles their fancy. The answer is to make sure you have enough bandwidth in product management to keep your developers stocked with features that are providing value to your customers and advancing your standing in your market.
If you want to do it right and get a +10 to all your die rolls, hire product management first.
OK, now I'm really done with the D&D stuff...
Photo credit: TomGazpacho