Good/Dead Product Management (via Khosla Ventures)
I came across this Khosla Ventures entrepreneurial resources page and, honestly, it’s full of a lot smarter ideas than what I had planned to write about this morning, so you should all dig in.
from Khosla’s Good Product Manager doc:
Bad product managers define their role narrowly as a marketing resource: someone who writes data sheets, arranges press releases, gets customer feedback, etc.
It occurs to me that this would be a good interview question: “What, besides the things listed on the job posting, would you expect to be part of this job?”
Good candidate: “Whatever it takes to get the product launched and successful - anything from personally ensuring that all the teams understand the goals to interviewing consumers in the product beta to QA’ing the product to ordering pizza for the engineers so they meet deadlines…”
Bad candidate: “Well, this job posting is similar to the tasks I did at [previous employer], let me tell you about what I did there…”
A good product manager is acutely aware of what they know and why they know it, as well as what they don’t know. A good product manager understands the difference between opinions, hunches, and objective facts. A good product manager knows that their job is to fill in these gaps in knowledge, not to defend or obfuscate them.
Good product managers pay attention to defensiveness. That vaguely-offended, vaguely-nauseous feeling is always a sign that you’re missing something. In the above example, being defensive is a sign that you haven’t set expectations properly. A good product manager is clear from the beginning that they don’t have all the answers but that their job is to find them (and until they do, they will be relying on some assumptions, guesses, and estimates and asking their cross-functional counterparts to help where they can.)
from Khosla’s Good Group PM/Dead Group PM doc:
When Group Product Managers fail to deliver a return on the investment in the relevant time frame, they get fired. There is no difference between incomplete and failure. That does not mean that GPMs should work 100 hours a week; that does mean that Group Product Managers must be absolutely ruthless about prioritizing.
At my old company, we had a group of very vocal beta testing users who would complain repeatedly about the lack of certain features, or our poor implementation of certain features. Of course, there was good reason why those features weren’t already at the top of our roadmap - they were simply not a factor in our product’s success.
Whenever new employees would read the feedback coming from these vocal beta users, they would cringe and immediately try to push those features to the top of our roadmap. When consumers are posting publicly that “you suck”, it’s hard to have a thick skin.
Finally I came up with the way to phrase it to make our priorities clear: “Let me summarize our beta user feedback: ‘Your product sucks, but it sucks less than all the other competitors out there.’ In other words, these consumers may not like us but they are continuing to use us. They’re even continuing to recommend us. When they ask for a feature, we need to ask ourselves: ‘Will the mainstream user use this?’ and ‘Will the absence of this feature cause a significant percentage of users to jump ship?’ Unless the answer to both is ‘yes’, it stays on the nice-to-have, never-build list.
Good GPMs are paranoid… Good GPMs are especially paranoid about areas they don’t understand. Dead GPMs pay more attention to areas they like or are familiar with.
A good GPM will think through an executives concerns and address most of them proactively. A Good GPM knows when to defend his position and when to accept feedback and move on. Dead GPMs don’t think through issues in advance and then find the executives managing the product instead of themselves.
Full of good ideas. Happy reading!
-->
Powered by