Joel Liu's List: Product managment

• It helps, as a program manager, to be pretty good at coding yourself. This is unfair. Program managers aren’t supposed to write code. But programmers tend to respect programmers a lot more than non-programmers, no matter how smart they are. It is possible to be an effective program manager without being a coder, but the burden of earning the respect of the programming team will be higher.
• The other way to earn the programming team’s respect is to demonstrate intelligence, open-mindedness, and fairness in any debates that come up. If a program manager says dumb things, the programmer might flip the bozo bit on them. If a program manager becomes personally or emotionally attached to a certain way of doing things, to the point at which they’re being unreasonable, they’re going to lose a lot of credibility… both sides, but especially the program manager, need to be emotionally detached from the debate and willing to consider new evidence and change their opinions when the facts merit it. Finally, if a program manager is seen as playing politics, having private meetings with the boss or trying to divide-and-conquer to win a debate instead of debating on the merits, they’re going to lose a lot of trust of the programmers.
• Mostly, becoming a program manager is about learning: learning about technology, learning about people, and learning how to be effective in a political organization. A good program manager combines an engineer’s approach to designing technology with a politician’s ability to build consensus and bring people together. While you’re working on that, though, there are a few books you should read:

1 more annotation...

• If the developer wants to design, let them!  Just be there to guide them rationally and fill in the gaps when they have to go back to developing.  If you need an artistic outlet, do it at home, or you’ll always be bitter.

•  

  I finally realized this after being a developer and then a designer.  Your job as a designer is to get the computer to act more human and to be more understanding of human communication.

• 4. Force business to iterate in design, not in development

   

  There’s nothing a developer hates more then spending months on something that once the business guys see it they realize they want to do something else.  I won’t hand anything off to the developers until I have thought it through and iterated through it with the business guys as much as humanly possible.  There are many decisions that can be made off of drawings rather than programming it.  And business will quickly realize that getting the designers to change their designs is a thousand times cheaper than paying expensive developers.
• There’s nothing a developer hates more then spending months on something that once the business guys see it they realize they want to do something else.  I won’t hand anything off to the developers until I have thought it through and iterated through it with the business guys as much as humanly possible.  There are many decisions that can be made off of drawings rather than programming it.  And business will quickly realize that getting the designers to change their designs is a thousand times cheaper than paying expensive developers.

2 more annotations...

• This being HN, let's talk about software.

  I have seen people very wrong-headedly trying to apply rules to all employees because of one misbehaving person, under the misguided notion that this is somehow "fair". For example, a long time ago there was a person in the admin group that was basically a slacker - came in late, left early and didn't work very hard. Management got really annoyed by this and made a "Everybody in by 9am OR ELSE, no exceptions" rule. Well you can imagine how that went down will all us geeks who were slaving 14 hours a day till the witching hour to fix problems. They managed to piss off the most productive people in the building, instead of standing up to one person and saying "you will be in by 9am, because that is when your manager needs you, and if you're not, you will be fired".

  So, unless you are managing an organisation that is so large, and you trust your middle management so little, that you can not address problems on a case-by-case basis, then stay away from sweeping rules. I'm with the OP on this one.

• I believe this "more features = better" mindset is at the root of the misjudgment, and is also the reason why so many otherwise smart people are bad at product design (e.g. most open source projects).
• What's the right approach to new products? Pick three key attributes or features, get those things very, very right, and then forget about everything else. Those three attributes define the fundamental essence and value of the product -- the rest is noise. For example, the original iPod was: 1) small enough to fit in your pocket, 2) had enough storage to hold many hours of music and 3) easy to sync with your Mac (most hardware companies can't make software, so I bet the others got this wrong). That's it -- no wireless, no ability to edit playlists on the device, no support for Ogg -- nothing but the essentials, well executed.
• We took a similar approach when launching Gmail. It was fast, stored all of your email (back when 4MB quotas were the norm), and had an innovative interface based on conversations and search. The secondary and tertiary features were minimal or absent.
• By focusing on only a few core features in the first version, you are forced to find the true essence and value of the product. If your product needs "everything" in order to be good, then it's probably not very innovative (though it might be a nice upgrade to an existing product). Put another way, if your product is great, it doesn't need to be good.
• Ultimately, the real value of this device will be in the new things that people do once they have a fast, simple, and sharable internet window sitting around. At home we'll casually browse the web, share photos (in person), and play board games (Bret's idea -- very compelling). At the office, maybe we'll finally have an easy way of chatting with remote people while discussing a presentation or document (e.g. audio iChat with a shared display). Of course these things are theoretically possible with laptops, but it always ends up being so clumsy and complicated that we don't bother (or give up after trying once).
• Making the iPad successful is Apple's problem though, not yours. If you're creating a new product, what are the three (or fewer) key features that will make it so great that you can cut or half-ass everything else? Are you focusing at least 80% of your effort on getting those three things right?

4 more annotations...