Ankur Sharma

This post has been long due. Around a month back, I did a talk on "How to Play & Win the Product Management Career Game" which was my way of saying "How to crack that elusive Product Manager Interview". Now most of us end up reading, Cracking the PM Interview , because everyone else has read that and it is a lovely book. But the challenge with it in the Indian context is, that well, it doesn't really fit in. To crack Indian company interviews, every good PM ends up making his own "Cracking the PM Interview". The attached presentation is mine. I am kind of open sourcing it so that more people can benefit off it. Please do let me know your feedback and share it with others who you believe are preparing for PM interviews. Anyone who needs further help can reach out directly. Will be happy to help in person. How to play & win the product management career game from Ankur Sharma

cc: Ben Ward While at a event  yesterday, discussing what an aspiring product manager should read, I mentioned the list of blogs I usually read. It ignited a lot of discussion. So here I am sharing the list of all what I usually read. Please take your pick. VC Blogs: Fred Wilson Blog : AVC   Benedict Evans:  http://ben-evans.com/benedictevans Mark Suster:  https://bothsidesofthetable.com Hunter Walk:  https://hunterwalk.com Sam Altman:  http://blog.samaltman.com Paul Graham:  http://www.paulgraham.com Chris Dixon:  https://medium.com/@cdixon/ Brad Feld:  http://www.feld.com Product Management Blog: Silicon Valley Product Group (SVPG):  http://www.svpg.com/articles Stratechery:  https://stratechery.com Accidental Product Manager:  http://theaccidentalpm.com Good PM, Bad PM: Ben Horowitz Seminal paper on Product Management Technology News: Global (Primary):  http://www.techmeme.com Global (Secondary):  https://www.techinasia.com TechCircle:  http://t

Henry Ford, after "invented" the car and the process around it was asked if he asked around for what his customers want - in other words did a market research? He said, "If I would have asked them, they would have asked for faster horse, not car!" A lot of organizations with their razor sharp focus on their stakeholders requirements get into what I call a "faster horse" trap, where they just end up building a better version of what their stakeholders have used/already been using. What's more. at times, it backfires and "faster horse" ends up being "pooped horse". Then there is other side of the spectrum where data rules and whatever stakeholder wants in as a requirement, she has to substantiate with data. Sounds great and works great (most of the time). It becomes an Achilles heel when there is no data to substantiate a requirement, an ambitious requirement  which needs people to be intuitive and only people who have gone thro