What Makes a Great Product Manager(informedpm.com)
informedpm.com
What Makes a Great Product Manager
https://informedpm.com/posts/great-product-manager
51 comments
100% agreed. As I read this I thought "great for whom?" The PM on my team is not truly on my team ... he's on our stakeholders team, and says yes to anything they want. This is a basic PM skill not mentioned here.
Another one I don't see is communication skills. The PM is the face of the team in so many ways, and if your PM has shoddy communication skills, that ends up feeling like your whole team has shoddy communication skills.
Another one I don't see is communication skills. The PM is the face of the team in so many ways, and if your PM has shoddy communication skills, that ends up feeling like your whole team has shoddy communication skills.
Couldn't agree more. I'm a programmer and I'm not delusional enough to think I'd make a great product manager BUT to me it would seem as the no 1 skill for a product manager is learning how to say "no" to stakeholders. I don't mean in a non-productive way, I mean more like actually challenge poorly thought out requirements, deadlines etc etc etc.
PMs only add value when they serve as an interface between the business, challenging and parsing requirements into actionable tasks with a clear definition of done, aligning with other teams to eliminate blockages etc etc.
Unfortunately, many (most?) PMs do none of this, but instead see themselves as some kind of overbearing slavedriver who cracks the whip on behalf of stakeholders and their every whim without question, demands 100% insight into what everyone on the team is doing at all times, creating stress and throwing people under the bus when the shitty requirements and deadlines aren't met. It a ubiquitous and fundamental misunderstanding of the role that make them not just useless but positively harmful.
PMs only add value when they serve as an interface between the business, challenging and parsing requirements into actionable tasks with a clear definition of done, aligning with other teams to eliminate blockages etc etc.
Unfortunately, many (most?) PMs do none of this, but instead see themselves as some kind of overbearing slavedriver who cracks the whip on behalf of stakeholders and their every whim without question, demands 100% insight into what everyone on the team is doing at all times, creating stress and throwing people under the bus when the shitty requirements and deadlines aren't met. It a ubiquitous and fundamental misunderstanding of the role that make them not just useless but positively harmful.
Very important point.
Having been on the wrong end of a low empathy pm (who on the outside seemed to look like they had empathy), I can say that there is probably nothing more important than this wrt developer productivity.
I don't actually even think that the lack of empathy was intentional, I think that it had more to do with a basic lack of understanding in many areas, that lead to unrealistic expectations.
Having been on the wrong end of a low empathy pm (who on the outside seemed to look like they had empathy), I can say that there is probably nothing more important than this wrt developer productivity.
I don't actually even think that the lack of empathy was intentional, I think that it had more to do with a basic lack of understanding in many areas, that lead to unrealistic expectations.
Not just PMs. As a Dev Manager who's been relatively successful the killer tool in my toolbox is genuinely giving a sh!t about the people on my teams. It's pretty crazy (and a little sad) how far this gets you; the bar is incredibly low IME.
[deleted]
> caring deeply about their team, what motivates them and what they love doing. If you can't apply the same empathy you have towards customers to your own people, you burn them out.
Strongly agree that empathy for the team is important, but I will also say that I'm increasingly seeing junior managers (product or otherwise) become so focused on pleasing their team that they lose track of shipping product that customers will pay for. The problem is compounded in over-funded startups or cash-rich companies where the financial pressure to ship and sell product has become so abstracted away that people forget what the real goal is (sell product, generate revenue).
It's a balance. Managers obviously need to work with, not against, their team. However, managers also need to be able to make the tough decisions and understand how to motivate their teams to do the work that needs to be done, even if it's not exactly the work that people most want to do.
For example, I've had to talk multiple people out of writing complex React-based SPAs for simple features that could be shipped more quickly as basic static sites. I've also worked at companies that suffered greatly because they chose to rewrite otherwise functional core software in new, fun languages because it's what the developers loved doing. A large part of being a manager is focusing people on developing the right things, even if it's not the most fun and intrinsically motivating thing that the engineers want to do.
Strongly agree that empathy for the team is important, but I will also say that I'm increasingly seeing junior managers (product or otherwise) become so focused on pleasing their team that they lose track of shipping product that customers will pay for. The problem is compounded in over-funded startups or cash-rich companies where the financial pressure to ship and sell product has become so abstracted away that people forget what the real goal is (sell product, generate revenue).
It's a balance. Managers obviously need to work with, not against, their team. However, managers also need to be able to make the tough decisions and understand how to motivate their teams to do the work that needs to be done, even if it's not exactly the work that people most want to do.
For example, I've had to talk multiple people out of writing complex React-based SPAs for simple features that could be shipped more quickly as basic static sites. I've also worked at companies that suffered greatly because they chose to rewrite otherwise functional core software in new, fun languages because it's what the developers loved doing. A large part of being a manager is focusing people on developing the right things, even if it's not the most fun and intrinsically motivating thing that the engineers want to do.
I worked for an overfunded startup but it was over funded and used the funds to hire people to give the impression of exponential growth to engineer the company for a successful ipo or sale. The people hired were sales people and they just increased the faucet of requests to the product managers who treated everyone like slaves anyways.
Despite having the funds to slow down just a tad and do things the right way, you'll find the overfunded startups use their funds to put into hiring salespeople marketing and people on the business side who have been successful selling companies or preparing then for an IPO, and the number of engineers hired during this time is logarithmic in proportion to the exponential growth elsewhere. A recipe for disaster when the PMs are slave drivers all the same but everyone is asking for more all of the time.
I've personally never worked under a PM who cared about the team, and I'm my opinion who cared about the product. I think they cared about their ego and seeming important and the idea of taking input from someone they perceived should be providing then requested output perhaps subconsciously threatened their idea of how everyone else might perceive them as being critical to the team. They were critical to the team. They just screwed it up by being so caught up in their egos about maintaining being in control and being right they lost sight of very objectively how their behavior could be putting the technical development and business development of the product at risk.
For whatever reason people with massive egos who can control people is often valued more than the value of whatever output is produced by that. It must be deeply psychological, and for me of course as a woman, I could never be successful as a PM because if I acted the way the men I've worked for did I would be called a raging bitch, because that's exactly what they were in my opinion. For whatever reason in makes this behavior is rewarded. Very bizarre indeed.
Despite having the funds to slow down just a tad and do things the right way, you'll find the overfunded startups use their funds to put into hiring salespeople marketing and people on the business side who have been successful selling companies or preparing then for an IPO, and the number of engineers hired during this time is logarithmic in proportion to the exponential growth elsewhere. A recipe for disaster when the PMs are slave drivers all the same but everyone is asking for more all of the time.
I've personally never worked under a PM who cared about the team, and I'm my opinion who cared about the product. I think they cared about their ego and seeming important and the idea of taking input from someone they perceived should be providing then requested output perhaps subconsciously threatened their idea of how everyone else might perceive them as being critical to the team. They were critical to the team. They just screwed it up by being so caught up in their egos about maintaining being in control and being right they lost sight of very objectively how their behavior could be putting the technical development and business development of the product at risk.
For whatever reason people with massive egos who can control people is often valued more than the value of whatever output is produced by that. It must be deeply psychological, and for me of course as a woman, I could never be successful as a PM because if I acted the way the men I've worked for did I would be called a raging bitch, because that's exactly what they were in my opinion. For whatever reason in makes this behavior is rewarded. Very bizarre indeed.
You read Will Larson’s book, didn’t you? Over here talking about logarithmic functions of headcounts and what not :P
For those that haven’t, or if my respondent hasn’t: https://www.amazon.com/Elegant-Puzzle-Systems-Engineering-Ma...
It’s no holy grail of engineering management, but what it _is_ is a well sourced book of “starting points”. Nuggets of thought. None of them really complete, a good deal wide, not very deep, but ultimately very relevant.
His systems approach to hiring and staffing engineering teams as a pseudo-mathematical problem I found intoxicatingly interesting because it spoke to a challenge my org faces intimately, and much of what you said reminded me of some of the themes in the linked book.
For those that haven’t, or if my respondent hasn’t: https://www.amazon.com/Elegant-Puzzle-Systems-Engineering-Ma...
It’s no holy grail of engineering management, but what it _is_ is a well sourced book of “starting points”. Nuggets of thought. None of them really complete, a good deal wide, not very deep, but ultimately very relevant.
His systems approach to hiring and staffing engineering teams as a pseudo-mathematical problem I found intoxicatingly interesting because it spoke to a challenge my org faces intimately, and much of what you said reminded me of some of the themes in the linked book.
Yup. Or actually acknowledging the software engineers or engineers implementing your product might be able to make you aware of some design challenges, engineering tradeoffs that will impact product or offer a more innovative solution if the PM is willing to listen. This usually requires believing the engineers have any level of intelligence besides being a code monkey and can really level with you on system design at is related to the overall outcome of a product or feature.
Multiple PMs I have worked under have simply demanded an outstanding feature of product without:
a) asking if it's ever been done before anywhere including say a team of 1000 google engineers much less your 11 person startup.
B) input or a guesstimate of an engineers timeline on how long this would take before respectfully working towards a compromise to meet a company goal
For both points having any level of reality internalized about if what they are asking is realistic.
In these cases the engineers not only get burnt out but produce the feature request knowing without additional consideration whether it be addressing tech debt supporting the feature which may finally catastrophically fail under that new load or what have you, and then getting stuck putting out fires to maintain the system only to have the PM come in and finally say ok how are we going to solve this problem but under an even more agressive timeline because it's failing in production because they insisted on pushing it even though they are the only ones who were convinced it was ready.
The only thing worse than pulling all nighters for a PM who thinks engineers just need to be told what to do and given a deadline and don't have any valuable seat at the table when it comes to implementing the design and a desire to help the PM be successful by highlighting challenges that could put the goal at risk to find a cool way to overcome those, is being told to shove out a crappy solution you're not proud of in a fraction of the time and then be yelled at and asked to pull more all nighters fixing it slowly and painfully the right way, with the pressure of failing customers in real time or humiliating the company by rolling back a feature, all the while knowing the root cause of the problem: The PM, is not being solved.
I have crazy one liners I've been given from PMs including but not limited to: "don't talk during meetings. You don't know what you're talking about and this meeting will move along alot faster if I'm the only one speaking."
In 2018 I had a PM chastise engineers on a company public slack channel that on Christmas Eve that he was dissapointed to see people actually using their vacation instead of a chance to get ahead.
I've seen that same guy ask a 55yr old woman going through cancer chemotherapy to pull an all nighter on a plane during the weekend for a company trip to meet no critical deadline whatsoever externally or internally except to meet his own he had set that day and not think twice about it.
I now work for a much more successful company and have been promoted beyond a senior engineer level and don't have to deal with PMs directly as such anymore but wow, it's amazing how abusive people can be in this position.
On the contrary, a really good PM can take a company to orders of magnitudes of success beyond what was previously imagined.
Tldr: mutual respect on a personal and technical and product level between PM and Engineers.
Multiple PMs I have worked under have simply demanded an outstanding feature of product without:
a) asking if it's ever been done before anywhere including say a team of 1000 google engineers much less your 11 person startup.
B) input or a guesstimate of an engineers timeline on how long this would take before respectfully working towards a compromise to meet a company goal
For both points having any level of reality internalized about if what they are asking is realistic.
In these cases the engineers not only get burnt out but produce the feature request knowing without additional consideration whether it be addressing tech debt supporting the feature which may finally catastrophically fail under that new load or what have you, and then getting stuck putting out fires to maintain the system only to have the PM come in and finally say ok how are we going to solve this problem but under an even more agressive timeline because it's failing in production because they insisted on pushing it even though they are the only ones who were convinced it was ready.
The only thing worse than pulling all nighters for a PM who thinks engineers just need to be told what to do and given a deadline and don't have any valuable seat at the table when it comes to implementing the design and a desire to help the PM be successful by highlighting challenges that could put the goal at risk to find a cool way to overcome those, is being told to shove out a crappy solution you're not proud of in a fraction of the time and then be yelled at and asked to pull more all nighters fixing it slowly and painfully the right way, with the pressure of failing customers in real time or humiliating the company by rolling back a feature, all the while knowing the root cause of the problem: The PM, is not being solved.
I have crazy one liners I've been given from PMs including but not limited to: "don't talk during meetings. You don't know what you're talking about and this meeting will move along alot faster if I'm the only one speaking."
In 2018 I had a PM chastise engineers on a company public slack channel that on Christmas Eve that he was dissapointed to see people actually using their vacation instead of a chance to get ahead.
I've seen that same guy ask a 55yr old woman going through cancer chemotherapy to pull an all nighter on a plane during the weekend for a company trip to meet no critical deadline whatsoever externally or internally except to meet his own he had set that day and not think twice about it.
I now work for a much more successful company and have been promoted beyond a senior engineer level and don't have to deal with PMs directly as such anymore but wow, it's amazing how abusive people can be in this position.
On the contrary, a really good PM can take a company to orders of magnitudes of success beyond what was previously imagined.
Tldr: mutual respect on a personal and technical and product level between PM and Engineers.
>>>Multiple PMs I have worked under have simply demanded an outstanding feature of product without:
...B) input or a guesstimate of an engineers timeline on how long this would take before respectfully working towards a compromise to meet a company goal
How would this happen? All my experience with PMs has been where they are equals, not superiors to the Dev Manager. So they can prioritize, cajole, inspire, but they cannot force teams into unrealistic deadlines (unless they somehow whisper in the boss' ear.) How would a PM "force" a timeline without honoring the dev team's estimates?
How would this happen? All my experience with PMs has been where they are equals, not superiors to the Dev Manager. So they can prioritize, cajole, inspire, but they cannot force teams into unrealistic deadlines (unless they somehow whisper in the boss' ear.) How would a PM "force" a timeline without honoring the dev team's estimates?
One very easy way is to promise it to an external customer without first clearing it internally. This can most easily take the form of signing off on Sales putting it into a contract.
Of course, in any sane organization this would result in the PM's immediate removal. But not all organizations are sane.
Of course, in any sane organization this would result in the PM's immediate removal. But not all organizations are sane.
It's actually very hard to generalize these statements.
I wholeheartedly agree that a great PM is a great advocate for the team, bringing team issues forward and freeing the way to get stuff done.
On the other hand it's often a tight rope to walk. I've seen situations often enough where a dev team would like to change frameworks/backends/dev environments/codebases, whatever it might be. And this has to be weighed between short- and long-term success. This is where a more technical product manager shines. On the other end of the scale I've seen dev teams walk all over their (non-technical) PM because they knew they could do so. It's a give- and take between team happiness and advocacy as well as end-user satisfaction and what the company needs at any given point in time. Being a great PM is actually much harder than it seems at first.
I wholeheartedly agree that a great PM is a great advocate for the team, bringing team issues forward and freeing the way to get stuff done.
On the other hand it's often a tight rope to walk. I've seen situations often enough where a dev team would like to change frameworks/backends/dev environments/codebases, whatever it might be. And this has to be weighed between short- and long-term success. This is where a more technical product manager shines. On the other end of the scale I've seen dev teams walk all over their (non-technical) PM because they knew they could do so. It's a give- and take between team happiness and advocacy as well as end-user satisfaction and what the company needs at any given point in time. Being a great PM is actually much harder than it seems at first.
In customer focused companies and at most places I've worked, many team members are indispensable product thinkers (from the CEO to the most junior developer). Simply put, you don't need to be a product manager to be a great product asset or excel at any one of these traits listed in the article. On high functioning teams, product is democratized and many contribute to the roadmap. When product is described as a role, such as product manager, the individual is responsible for bringing teams together through a collaborative process and rallying the team to go all in on a initiative/roadmap to achieve a goal for the business or company. There's other traits involved such as collaboration, practical management of deliverables and timelines, people management, and relentless focus on quality. Last but not least, the article's focus on intuition as a trait didn't seem like the right fit, since many ppl think of intuition as inherent and not learned. Intuition is a combination of experience and continued learning. Anyone who talks with customer, studies an industry, or listens deeply to their coworkers is building intuition around the problem. In practice, I think by saying Data and Intuition, the author intended something more akin to pattern recognition - which again is something available to all of us!
Having done 'Product' for a long time now I think the term is ripe for a reboot.
I personally don't look for Product Managers but Business Managers.
Difference?
All the traits discussed here plus an understanding that your responsible for delivering products that need to generate $. It may sound obvious but I have seen many PMs who are obsessed about crafting beautiful applications when sometimes a cheaper and dirty approach is what is called for to win the business. This requires deep commercial awareness and an understanding of client incentives along with ability to properly cost up your business to form an opinion on the profitability of each client.
I personally don't look for Product Managers but Business Managers.
Difference?
All the traits discussed here plus an understanding that your responsible for delivering products that need to generate $. It may sound obvious but I have seen many PMs who are obsessed about crafting beautiful applications when sometimes a cheaper and dirty approach is what is called for to win the business. This requires deep commercial awareness and an understanding of client incentives along with ability to properly cost up your business to form an opinion on the profitability of each client.
BINGO. Came here to write something like this — frankly surprised (and pleased) to find your comment. Thank you!
A PM’s job numero uno is to MAKE THE BUSINESS SUCCESSFUL, ideally by maximizing the intersection between customer/user needs (solving a problem), business goals, and their team’s/company’s capabilities. Sometimes, though, these three facets are at odds and one needs to prioritize one over the others.
The best PMs bring experience, empathy, and data to bear to figure out which one to optimize for, when.
A PM’s job numero uno is to MAKE THE BUSINESS SUCCESSFUL, ideally by maximizing the intersection between customer/user needs (solving a problem), business goals, and their team’s/company’s capabilities. Sometimes, though, these three facets are at odds and one needs to prioritize one over the others.
The best PMs bring experience, empathy, and data to bear to figure out which one to optimize for, when.
completely agree with this. I hear "data-driven" a lot but most people don't seem to mention impact on P&L data..
Depending on the size of the company in question, introducing actual P&L responsibility makes your description sound more like a VP of Product, or, in role terms, a "product owner", whatever the specific title. But certainly team members should be able to understand the connection between their activities and the creation of value.
"product owner" tends to be either the lowest rung on the product ladder, or the next to the lowest just above "product analyst" anywhere that I've been.
I've never heard of anyone with that title having P&L.
I've never heard of anyone with that title having P&L.
For sure it's hard to compare titles across companies. But P&L would be a pretty hard line at most places, above which are people whose primary responsibility is to financial results, the C-suite, the board, etc. In places you've been, are people in these positions seen as, generally, "product team leaders" or as "people upstairs"?
A great PM has a solid read on what the market will pay for. I think PM "job one" is translating a credible and concrete vision of what a product needs to do to the design and dev teams. A Product Manager primarily interprets the market - customers, buyers, competition - both tactically and strategically on behalf of informing direction of a product's development. Analyze, integrate, interpret, explain, communicate, prioritize - all big PM verbs. It is an advantage to deeply understand key customer "jobs to be done". It is a requirement to communicate well cross functionally with everyone. PM is an influencing function -- visionwise you can be a little ahead of the rest of your team, so being smart, credible, empathetic and service-to-the-mission oriented all help in that way.
The article used a lot of words to not really say anything.
The biggest thing is knowing your customer and your market. Product-market fit. Get it thru analytics, experience or customer interaction... but that’s job #1. The best product managers know their market terribly well by experience but also trust the analytics to know when to veto their gut.
The biggest thing is knowing your customer and your market. Product-market fit. Get it thru analytics, experience or customer interaction... but that’s job #1. The best product managers know their market terribly well by experience but also trust the analytics to know when to veto their gut.
I felt that this was a good article. One thing that may not be evident from reading it is that PM as a discipline has a wide range. Some PMs spend an enormous amount of time in the weeds with engineers doing technical design work, even if there's little coding as their output. Some have practically zero interaction with engineers. But both ends of that spectrum are important.
As a PM working on technical products and collaborating mostly with engineers, I'll offer up an opinion on "good" vs. "not so good" PMs that an peer in engineering told me one. In his opinion, a good PM is someone who an engineer may not be able to easily point at specific things and say the PM accomplished them (e.g., some technical breakthrough), but there is an overwhelming feeling that without that PM involved at every step of the way, the team would just not be as successful. Since then I've made it my goal to be viewed in a similar light by engineering partners (though perhaps with more "I can tell you what they accomplished").
Another one that feels missing but it critical when working in large organizations: great PMs can turn a "it's silly we're not doing this, but it's complicated" situation into "I'm so glad we're finally doing this". Big organizations have enormous political barriers to getting things done and the best PMs in those orgs can steadily cut through that bullshit to make something happen.
As a PM working on technical products and collaborating mostly with engineers, I'll offer up an opinion on "good" vs. "not so good" PMs that an peer in engineering told me one. In his opinion, a good PM is someone who an engineer may not be able to easily point at specific things and say the PM accomplished them (e.g., some technical breakthrough), but there is an overwhelming feeling that without that PM involved at every step of the way, the team would just not be as successful. Since then I've made it my goal to be viewed in a similar light by engineering partners (though perhaps with more "I can tell you what they accomplished").
Another one that feels missing but it critical when working in large organizations: great PMs can turn a "it's silly we're not doing this, but it's complicated" situation into "I'm so glad we're finally doing this". Big organizations have enormous political barriers to getting things done and the best PMs in those orgs can steadily cut through that bullshit to make something happen.
I clicked on this expecting it to be yet another reductive view point over-indexed on one particular aspect of a narrowly defined role, however I was pleasantly surprised that it does a pretty good job highlighting the nuance and context that plays into making good product decisions.
A lot of people (maybe most people?) want a playbook and roadmap for how to do their job. For a PM it might be: identify a problem based on data or customer feedback, conduct user research, ideate with design, get input from external stakeholders, build with engineering, run an A/B test and rollout successful variant. All of these things may be necessary activities in different contexts, but it's also very easy to lose the forest for the trees. The bigger and more complex a company gets, the easier it is to get lost in the process and over-index on the wrong details. I can't count the number of times I've heard lip-service played to "being data-driven" as an excuse to avoid tackling the bigger but less quantifiable problems of how a product is failing to meets its customers' high-level needs.
A lot of people (maybe most people?) want a playbook and roadmap for how to do their job. For a PM it might be: identify a problem based on data or customer feedback, conduct user research, ideate with design, get input from external stakeholders, build with engineering, run an A/B test and rollout successful variant. All of these things may be necessary activities in different contexts, but it's also very easy to lose the forest for the trees. The bigger and more complex a company gets, the easier it is to get lost in the process and over-index on the wrong details. I can't count the number of times I've heard lip-service played to "being data-driven" as an excuse to avoid tackling the bigger but less quantifiable problems of how a product is failing to meets its customers' high-level needs.
My product manager does not talk to customers, just planning to launch a new product to get promoted and kill existing product who is the money maker. The history of a well known company in Bay Area
The modern interpretation of a PM, essentially a glorified order taker, is not one I’d recommend.
Ive seen this model of the PM implemented in small 5 person startups and large 5,000 person public companies.
Ive seen this model of the PM implemented in small 5 person startups and large 5,000 person public companies.
is it weird for other old-timers to see this happen? The number of PMs has exploded, and their scope has gotten much smaller. It seems like every form in an app has its own PM now and every one of them is fresh out of school.
PMs used to be different. They were excellent performers from engineering/marketing/business that caught a bigger view of what was being built and had a gut feel of what needed to be built. It seems like those folks don't have a place to go any more and we continue to beat the cross-functionalness out of folks while saying we aren't.
PMs used to be different. They were excellent performers from engineering/marketing/business that caught a bigger view of what was being built and had a gut feel of what needed to be built. It seems like those folks don't have a place to go any more and we continue to beat the cross-functionalness out of folks while saying we aren't.
Are you familiar with how Apple did product development in the Jobs era? I’ve read a bit about it, but didn’t work there at the time so can’t confirm. From what I’ve read, it essentially had no PMs. They drilled the culture into every aspect of the business and then demanded excellence. Projects were lead by either designers or engineers.
This to me is the ideal state. One person, most likely the lead engineer, essentially acts as what a traditional PM/PO would. They understand the deep technical and business requirements of a product.
I think this might be the only setup in which you can achieve real innovation.
A business only needs a modern PM once they’ve crested the hill. The data roles in. The PMs absorb the data, distill it into tasks, and engineers build it. It’s more of an assembly line than building a product.
This to me is the ideal state. One person, most likely the lead engineer, essentially acts as what a traditional PM/PO would. They understand the deep technical and business requirements of a product.
I think this might be the only setup in which you can achieve real innovation.
A business only needs a modern PM once they’ve crested the hill. The data roles in. The PMs absorb the data, distill it into tasks, and engineers build it. It’s more of an assembly line than building a product.
Those people exist - they are called successful founders or senior executives.
A good product manager converts code written by developers to products used by customers
A bad product manager handles jira tickets
https://www.joelonsoftware.com/2006/04/11/the-development-ab...
A bad product manager handles jira tickets
https://www.joelonsoftware.com/2006/04/11/the-development-ab...
Given that readers on this thread might be interested, and having posted a few replies on what helps us build product and how we do it, here's a collection[0].
We try as much as possible to lay out information and address "meta" questions so people make decisions on their own, know what we're doing and why we're doing it.
For example, the "If I disappear, what will happen" link was a reply to an Ask HN: "What makes a great CTO".
Latest reply[1] to a thread about making product management decisions.
I like to think of it as putting myself out of a job.
- [0]: https://news.ycombinator.com/item?id=25025253
- [1]: https://news.ycombinator.com/item?id=25176818
We try as much as possible to lay out information and address "meta" questions so people make decisions on their own, know what we're doing and why we're doing it.
For example, the "If I disappear, what will happen" link was a reply to an Ask HN: "What makes a great CTO".
Latest reply[1] to a thread about making product management decisions.
I like to think of it as putting myself out of a job.
- [0]: https://news.ycombinator.com/item?id=25025253
- [1]: https://news.ycombinator.com/item?id=25176818
Thank you. Look forwarding to reading!
Good start, but I’d like to add technical empathy and literacy to the list.
I’m a PM and too many of my peers don’t know a lick about how the products in their portfolio even work at a fundamental level. This lack of basic technical literacy leads to the inability to communicate and empathize with their development team. That makes requirements writing a Herculean effort of wading through abstractions, which obviously isn’t going to translate to quick delivery.
Perhaps worse is these types of PMs instinctually don’t include their developers in the ideation process, because they struggle to understand what they could even add to the discussion.
A PM must be curious, and that includes curiosity about the underlying tech. They must be in the business of demystifying and democratizing the building blocks of their products. This shouldn’t be at the expense of the business functions of the job, but it should be part of the multi-pronged nature of the job. PMs shouldn’t just be lobbing requirements over the wall with no idea what they’re asking for. And this doesn’t mean we always need to hire PMs with a technical background. One of the best things about the nebulous “product manager” profession is that it’s really just a catch all for people from all related disciplines who have a talent for working at the intersection of the user and the business. All I’m saying is at least watch a damn YouTube video about React Native, GraphQL, Drupal, or whatever the heck you use and I guarantee it will pay dividends in your requirements writing and your communication with your developers.
I’m a PM and too many of my peers don’t know a lick about how the products in their portfolio even work at a fundamental level. This lack of basic technical literacy leads to the inability to communicate and empathize with their development team. That makes requirements writing a Herculean effort of wading through abstractions, which obviously isn’t going to translate to quick delivery.
Perhaps worse is these types of PMs instinctually don’t include their developers in the ideation process, because they struggle to understand what they could even add to the discussion.
A PM must be curious, and that includes curiosity about the underlying tech. They must be in the business of demystifying and democratizing the building blocks of their products. This shouldn’t be at the expense of the business functions of the job, but it should be part of the multi-pronged nature of the job. PMs shouldn’t just be lobbing requirements over the wall with no idea what they’re asking for. And this doesn’t mean we always need to hire PMs with a technical background. One of the best things about the nebulous “product manager” profession is that it’s really just a catch all for people from all related disciplines who have a talent for working at the intersection of the user and the business. All I’m saying is at least watch a damn YouTube video about React Native, GraphQL, Drupal, or whatever the heck you use and I guarantee it will pay dividends in your requirements writing and your communication with your developers.
Only entry-level or highly specialized positions are described by their titles well. This thread is a good example: the sets of valuable qualities named in the comments often do not even overlap.
Good job descriptions and resumes include a comprehensive (though not necessarily long) list of skills and activities that the person is/must be good at. I wish more articles were talking about these concrete things, instead of using words that don't mean much at best and actively cause confusion at worst.
Good job descriptions and resumes include a comprehensive (though not necessarily long) list of skills and activities that the person is/must be good at. I wish more articles were talking about these concrete things, instead of using words that don't mean much at best and actively cause confusion at worst.
I think this article is a pretty good description of good pm. I’ve both been pm myself and managed teams og pms, and anyone fitting this description would be a great hire.
"You have to really love making things, but you have to be okay with not being the person actually making the thing."
How do people get over this?
How do people get over this?
So basically it's like being a 'human compiler'? They don't execute the project but they are involved in its design and development.
Personally? I have a few jobs that gave me a ton of cross functional experience but were really shitty jobs that made me completely burned out and not want to do any work anymore. However, the discussion and design phase still really interested me so I took up PM. I get to do the part I still enjoy and skip the past I no longer want to do.
I like the article. It has good nuggets for building awesome products. I think decision framework also helps.
A questions for PMs and this community - Would you use a service that delivers similar product insights and research to your inbox or to cloud? I am looking to get in touch with people building products right now for 15 min interview.
A questions for PMs and this community - Would you use a service that delivers similar product insights and research to your inbox or to cloud? I am looking to get in touch with people building products right now for 15 min interview.
DM me on Twitter @grantgumina
If interviews are any indication it’s 2-3 years as a product manager for a junior role and 7 years for an associate level role that makes a great product manager.
Product is different at every org. There is no one side fits all
I agree. I thought the article gave good overall approach to the core skills a product manager needs to have.
great_pm(ordered_bad_pm, count):
return opposites(ordered__bad_pm, count)
for real though, how does one develop the Intuition?
(apart from personal experience of course)
Are there tells?
forgot to add the "conjoined triangles of success" graph
is it just me or this website's scrollbar is missing lol
I've been a PM for 15 years. I've watched the rise and fall of the "ceo of your product" mentality. Mentored dozens of PMs, interviewed hundreds. The one common thread I've noticed across a wide range of successful PMs (and absent from unsuccessful ones) is caring deeply about their team, what motivates them and what they love doing. If you can't apply the same empathy you have towards customers to your own people, you burn them out.