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!

When your customers complain about bugs or usability issues, you should fix them. When your customers ask you for new features, 90% of the time you shouldn’t put them on your product roadmap.

Why?

(more…)

When everything is a P1, nothing is a P1.

One of the process improvements I’m most proud of introducing is laughably simple - ordinal prioritization. As an organization, we were quite good at separating the critical requirements from the important and nice-to-have requirements. The problem was, when we classed requirements as P1, P2, P3, and below, we were unknowingly withholding the even more useful information from our overseas development teams.

Simply put, if we as an organization could only complete one requirement, what would it be? If we could only complete two requirements, what would they be?

By lumping together all “critical” requirements into one designation, we lost that information. We also lost valuable time in the change request process - if a new feature request came up, we needed extensive discussions to identify what could be “bumped” to make room for it.

Ordinal prioritization forces some lively debates, and generally requires signoff from an executive sponsor. The criteria for what makes a #1 a #1 and not a #4 will vary from organization to organization. For us, it was “Will this feature have definite quantifiable revenue impact in landing deals?”, “Will this feature have definite quantifiable usage impact (which drives more revenue?)”, “Will this feature significantly differentiate our products from that of our competitors?”, “Will this feature fix something which is causing significant user experience issues, support issues, or deployment issues?”