Man, I would love to work for someone that actually strives to do this. Awesome.
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.
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.