PM @ a well funded AI startup. Previously PM at Netflix. Management consultant prior.
Undergraduate degree in Psychology. Background in marketing/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.
-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.
-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.
-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.
-Financial modeling. I'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 'mini CFO,' 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.
-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'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.
-Finally - be humble and be accountable. It is always your fault, because you are accountable for the success of your product. Don't throw your engineering team into the middle of a sh*tstorm of management politics - be their umbrella. Don't blame customers, politics, or resources. It's always your fault. Find a way to fix it.
>-Finally - be humble and be accountable. It is always your fault, because you are accountable for the success of your product. Don't throw your engineering team into the middle of a sh*tstorm of management politics - be their umbrella. Don't blame customers, politics, or resources. It's always your fault. Find a way to fix it.
Man, I would love to work for someone that actually strives to do this. Awesome.
Were you at any organisations where they did 360° feedback? What kind of feedback did you receive from developers or designers from your team? What I'm trying to understand is how are organisations ensuring that PMs and team are not in disconnect from how things really are. I know that's a different realm but just trying to understand how did you find what to improve or learn to be a better PM?
Netflix and my current organization religiously practice 360 degree feedback. For my own projects, I practice 360 degree feedback as well. I don't think a team or organization can succeed if employees cannot speak to each other candidly about performance.
My typical feedback from engineering:
1) I state resolutions of a problem without clearly defining the problem.
This was/is my biggest failure as a product manager and is something I work on daily. I enjoy the 'fun' of solving problems but respect that my job is not to solve the problem. My job is to understand the market, define customer and their needs, and create requirements that need to be met to resolve those customer needs.
2) I over-engineer. I like to solve problems with complex, scalable, 'sexy' solutions. At Netflix, my team built a real time marketing analytics platform that used kafka/spark/elasticsearch and an enormous cluster to aggregate marketing data from 5+ marketing platforms. The client was built in angular/d3 and returned aggregations on 1B+ rows of data in < 100ms.
We were so invested in scale and performance that minor changes to the underlying schema (which happened often, as marketing priorities shifted) required a lot of work. This was a huge over engineering mistake on my behalf.
3) I can come off as patronizing. In an effort to describe a problem space or market, my tone has been perceived as patronizing.
4) I do not practice enough active listening. I end up driving conversations and do not make people feel heard.
Being humble and asking for feedback is the best way to learn to be a better PM. Of the PMs I've seen rise(and fall) through the ranks of management, I have generally found that humility, integrity/accountability, and communication skills are the most correlated with success.
What a wonderful and candid reply. Those 4 things are common feedbacks as a PM. It's a role where it can be easy to fool yourself that you think you already know everything. I believe a lot of PMs (myself included) often/always need to continuously improve on. But few would be as open and receptive to speaking of them, or ready to actively work on being more humble, more accountable.
This is so awesome, wasn't expecting such detailed response! I think we all have some of these flaws but having channels to have this feedback and to have open discussions without any ego or taking it personally makes the best teams. Currently I'm not in such a team but I was in past and wish to find one soon!
Thanks for sharing. How are you guys organized at Netflix? Is there a distinction between platform product managers and solution product managers? From outside it looks like the world is divided as Content led by Ted Sarandos and Platform led by Neil Hunt.
when I asked this question I first expected a lot of answers in the lines of your "Financial Modeling" part. Funnily, you are the only one that's named it so far. Anyhow all the answers have been so incredibly enriching...
Undergraduate degree in Psychology. Background in marketing/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.
-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.
-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.
-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.
-Financial modeling. I'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 'mini CFO,' 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.
-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'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.
-Finally - be humble and be accountable. It is always your fault, because you are accountable for the success of your product. Don't throw your engineering team into the middle of a sh*tstorm of management politics - be their umbrella. Don't blame customers, politics, or resources. It's always your fault. Find a way to fix it.