Paul Graham has a great article in “Startups in 13 Sentences:”
Having gotten it down to 13 sentences, I asked myself which I’d choose if I could only keep one.
Understand your users. That’s the key. The essential task in a startup is to create wealth; the dimension of wealth you have most control over is how much you improve users’ lives; and the hardest part of that is knowing what to make for them. Once you know what to make, it’s mere effort to make it, and most decent hackers are capable of that.
Then in “Geeks and Anti-Geeks,” Adam Barr writes:
You notice this if you listen to the chatter before a meeting. Half the time people are talking about World of Warcraft; those are the geeks. The other half they are talking about pinot noir; those are the anti-geeks. In either case, the group then proceeds to discuss a pattern-based approach to refactoring your C# class design in order to increase cohesion and leverage mock objects to achieve high code coverage while minimizing your unit test execution time.
The reason this matters is because Microsoft has recently been pushing engineers to realize that they are not the customer, the customers are not geeks, and therefore engineers can’t design properly for our customers. What I think happens, however, is that the anti-geeks hear this and think, “They’re not talking about me; I know that those beer-swilling geeks don’t understand the customer, but I’m a cultured sort, not a geek–I’m just like our customers!” And so they go out and design software for themselves…and of course they mess it up…because our customers may not spend their spare time playing Dungeons & Dragons, but neither do they spend it tramping across the Burgess Shale.
So I don’t disagree with Mr. Barr, but I do want to expand a little. The fundamental job of the program manager is to understand the market, come up with a solution that will delight the customer, sell that vision to the team, create and drive the product to shipping to those customers. The market only matters in understanding if a product is worth building, and in helping to shape our understanding of the customer by understanding their economic context.
I don’t think I’m anything like most of my customers. Those customers are first and foremost, 35,000 or so software engineers inside of Microsoft, second, security experts helping them or reviewing their work, and third, software engineers at other vendors who build on our platform. I’m most like the second set, but they’re a distant second, and (as several of them will tell you) I have a tendency to reject their first attempt at getting a feature out of hand, because our previous tools were so expert-centric.
More importantly, I don’t need to be like our customers to delight them. I am nothing like a professional chef, but I am frequently delighted by them. What I need to do is actively listen to those customers, and fairly and effectively advocate for their attitudes and words to my team.
As I was working on this Joel Spolsky posted “How to be a program manager,” which covers some similar ideas.