Ask HN: Product Managers, how did you get there and what's your background?
PM @ a well funded AI startup. Previously PM at Netflix. Management consultant prior.<p>Undergraduate degree in Psychology. Background in marketing&#x2F;business and customer acquisition. I learned enough programming to automate my marketing activities, and found that I liked driving a roadmap more than I liked acquiring customers.<p>-Communication and conflict resolution skills are key. You are in a role where you must drive influence without having any direct reports. This means effective, articulate communication skills are required. Know how your voice needs to change between communication to engineering versus communication to an executive or board member.<p>-At Netflix, I was often told my job was to add clarity. Add clarity to a technical specifications document. Add clarity to the marketing teams understanding of a product feature. The best PMs are able to consolidate their understanding of a 35 page technical document into two sentences.<p>-Market sizing and back of the envelope calculations. Know how large the market is for your product. How much more can you charge for your product if you add X feature? How long is X feature going to take in engineering cycles? Is this the best way to spend your engineering resources? In my daily routine, I probably make 10 calculations like this and have a response ready for either our product director, CEO, board member, or customer.<p>-Financial modeling. I&#x27;ve found that modeling skills are absolutely key - know how to model out customer lifetime value, churn rates, and cash flow. You should be prepared to be a &#x27;mini CFO,&#x27; because at the end of the day, you are asking for more resources from your executive suite, and are best off making those requests in CFO format.<p>-Know your technology. Know what is possible and know how to articulate requirements that speak to your technology. This is why there is often a technical barrier for PMs - you have to know how things work, and what is physically possible versus cost prohibitively impossible. This doesn&#x27;t mean you need to know how to code - but that is helpful. Know source control and developer operations processes. Know how to plan for scale. Know how to recognize elegant solutions for difficult problems, and reward your engineering team for failing spectacularly.<p>-Finally - be humble and be accountable. It is always your fault, because you are accountable for the success of your product. Don&#x27;t throw your engineering team into the middle of a sh*tstorm of management politics - be their umbrella. Don&#x27;t blame customers, politics, or resources. It&#x27;s always your fault. Find a way to fix it.