Posterior Probabilities and Hiring Decisions

  • While hiring a choir singer, you ask the person to sing a carol
  • While hiring a chauffeur, you ask that he drives you a couple of miles around town
  • While hiring a programer, you ask that the person writes code in the language in question to solve a given problem

The job of a hirer is to essentially make good to excellent guesses of posterior probabilities, almost in the same style as Bayesians. Like in Bayesians, the quality of the P(A/B) (read as “probability of event A given event B) is very dependent on how the two events are correlated in the cause-effect paradigm. In all the examples above, the relationship is very strong a-priori and that is why the tests are a damn good measure of how the incumbent will shape up in the role that is being tested for (little chance of a programer turning out to be Joel Spolsky when he can’t write a recursive string reversal algorithm in C++).

For jobs where the a-priori estimation is inadequate (or non-existent) the challenge of establishing a posterior probability becomes onerous.

So what does one look for when hiring a good Product Manager? In all honesty, I do not know the answer even after spending close to a decade in the profession and hiring several superstars (and the occasional disaster) and rejecting many after long interviews (some of who must have gone on to become superstars elsewhere). However, here is a rough checklist that I tend to carry mentally

  1. Throw a qualitative problem, deliberately kept vague and observe how the person proceeds towards deriving clarity out of it. Watch out if he makes conclusive assumptions early up (that’s not good. Probability often equal to that of coin-flip). Product definition in the early stage is most definitely very vague and a good product manager has to navigate through this and elicit (sometimes create) clarity
  2. Find a problem that has elements of cross team communication (doesn’t have to be a workplace problem) and see how the incumbent proposes to proceed with it (like, ask the person to chalk out a plan to communicate the Wall Street bail out plan to Congressmen, to the auto-union at Detroit and to the West Virginia Coal Association to arrive at consensus)
  3. Get a sense of his bias-for-action. I have often encountered the arm-chair product manager – plenty of theory, powerpoints, boxes-and-arrows and flailing arms – nothing at the end of the budget cycle. It is easy to spot them – they’ll have less verbs like “delivered”, “achieved”, “built” etc on their resume.
  4. Ask them about a product (preferably software) amongst the ones they use yet find the most disappointing and then engage them to discuss ways of improving the product. Look out for practicality of the ideas, the incremental steps taken to build out the final stage and if the person has an idea of the final stage to start with
  5. Once the above is done (or while on it) ask the aspirant to create marketing plans for each stage or the final product. The smart product manager always has an eye on the final market value-proposition and should mentally calibrate the product roadmap (the increments) to fit a commercial differentiation proposition

Good luck with the hiring and caveat-emptor just in case you land up a disaster after all this. People still manage to game the interview process.