Ask HN: Product Managers, how did you get there and what's your background?

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 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.

The PMs that take all the credit are bad PMs. The best PMs I've worked with do a ton of behind-the-scenes work and give all the credit to the team. Having a PM that takes care of...

> analytics, user feedback, market trends, business concerns, etc.

..will boost productivity for any engineer or designer.

Great thread! Your responses have taught me quite a bit about our industry!

My background: * I earned a B.S. from Texas A&M University in Computer Engineering and Mathematics (2001).

* After an internship, I joined IBM's Linux Technology Center in Austin, Texas -- a key part of IBM's billion dollar bet on Linux, working mostly on security technologies (including eCryptfs, still co-maintaining), and eventually becoming an IBM Master Inventor creating 75 patents, which I mostly disavow, except for QWERsive (aka Swype) which I still love :-)

* I spent one of those years for IBM, staffed on site at Red Hat in Boston (2005), building bridges between IBM's strategic initiatives and Red Hat's Linux distribution. This was 100% travel, somewhat lonely work, "in the field", but extremely formative in understanding the integral relationship between "kickass open source engineering", and "meeting business objectives". I learned, "never turn down a combat mission". Field experience is super rewarding.

* After 7+ years at IBM, I joined Canonical in (February 2008), at the formation of the engineering team which created The Ubuntu Server. Canonical was less than 100 people at the time, and we didn't have health care insurance or a 401(k) plan. Everyone worked from home; it was a scary, fun, exciting, thrilling time, no doubt! Besides helping bring Ubuntu into the public and private cloud, I also got to create some really cool technology, like Ubuntu's Encrypted Home Directories, Byobu, and a handful of other open source utilities. The lesson here was how important it is to get useful code into the hands of as many people as possible and then iterate quickly!

* I resisted moving into an engineering management role for way too long, but eventually did, and loved it! I came to learn that managing software engineers is fundamentally an extension of hacking code all by yourself, except your colleagues are your functions and libraries and compiliers and monitors and IDEs and test suites and so on. It's amazing how much more a well run team can accomplish, than a single lone engineer.

* I left Canonical after 4 years in (November 2011) to become the CTO of a venture funded startup called Gazzang. Gazzang's key technology (encryption of big data for health care companies) was largely based on the eCryptfs encrypted filesystem and utilities that I had co-authored and co-maintained for several years. Let me tell you, that it's amazing when a hobby, or an open source project that you enjoy hacking on, presents job opportunities. The wonder of open source. Your github/launchpad/stackexchange is your resume. I designed and implemented a key manager for Gazzang, which was eventually acquired by Cloudera.

* And finally, that brings me to product management... In July of 2013, I re-joined Canonical, reporting directly to the head of product management, Canonical's own founder/owner/billioniare/afronaut-space-tourist, Mark Shuttleworth, who invited me back to Canonical to lead product and strategy around Ubuntu itself, and design how Ubuntu fits into the world of containers (Kubernetes, Docker, LXD), cloud (AWS, Google, Azure, OpenStack, baremetal) all the way to the world of connected devices and IoT.

Product Management, for me, sits in the cross-section of engineering, sales, and marketing. I'll describe, in my opinion, a Product Manager's must-have skills in this way:

* 8am, from your hotel room, join a conference call with a journalist, explaining the intracasies of a press release announcing a new product offering

* 9am, lead a video conference with your engineering developers, diving into a shared screen session command line environment, looking at code and design, sharing insight from your experience in the field

* 10am, mic up and take the stage to deliver a conference presentation (keynote, if you're lucky) where you live demo some crazy risky beta features that probably won't quite work perfectly, in which case you recover gracefully and confidently move on

* 11am, spend some time with really sharp people, after your talk, where you answer the really tough questions some people were polite enough not to assail you with on the keynote stage

* Noon, lunch with the bizdev director of a collaborator/competitor in your market, and negiotate a partnership that works for both of you, send your 3-key asks by email from your phone before the end of the meeting

* 1pm, help your sales VP in the big meeting she scheduled for you, with the CTO of a Fortune 500 company who literally wrote the book on Internet Security, and sell them your encryption product (true story)

* 2pm, interview a potential new-hire, this particularly critical in a startup -- A players hire A players, while B players hire C players

* 3pm, write a thoughtful blog post, with unique insight on a real problem, demonstrating both the "how" and "why" around a solution, in well-written English, with a catchy title and clean graphics (demos, examples, etc)

* 4pm, create a slide deck that your sales engineering team uses to sell the new product you briefed the journalist on earlier today (should have been done weeks ago, but hey....)

* 5pm, competitively analyze the competitor's product in your space, actually using their product (or browsing their code) and document your findings and share with your team

* Flight home, hack on some code from your ~/ideas/* directory, that you've noodling over all week. Critically, get it into some minimally working state, by the end of the flight, or else you'll never come back to it

Hope that helps.

Cheers!

@dustinkirkland

It's horrendously inefficient for an organization to take away Product Managers. If you want to bring every designer and every developer and ever sales person... and basically your whole company to a meeting to make a decision... maybe you'll get away with cutting the Product Manager role... But there's so much inherent compromise and horse trading as part of every product launch / sprint.

Without someone to organize all that, you're going to waste a lot of time and force a lot of highly skilled people to do things that aren't in their wheelhouse. And then... at the end of the day... who is on the hook for strategy? "Oh, hey we built the wrong MVP so I guess we'll sack some of our Visual Designers!" That makes no sense.

Any complex system or organization will need a management layer... think of them as lubrication if you want... to help all the different parts move efficiently. The team is responsible for the success of the endeavor, anyone worth keeping in an organization knows how to give praise where it's due... if you have individuals trying to take credit for teamwork... that's an issue you should take up with HR.

As a company scales, there is a tendency to embrace specializations through a division of labor. Of course, different companies adopt different models for various reasons. e.g. Do you need dedicated QA or does that fall upon the developers? With these decisions come trade-offs because you can't optimize for everything. Your proposed model can work, but is far less common in large tech companies because of the overhead of coordinating/communicating across lots of people which tends to fall upon PMs.