There is clearly a lack of boards/forums/websites dedicated to product managers. But what I miss the more is a website, when we can get valuable insights about best practices.
On HN you can get super useful information about any stack/language/framework by reading the comments, but when you are a PM you have nowhere to get that kind of information
The challenge in building such a community is that PM is a highly sought after job in the tech sector, so any forum or website built around PM discussion is inevitably going to turn into something like Medium, which today is a list of poorly written thought pieces by (mostly) amateurs.
Has anyone noticed how few "Who's Hiring?" posts are looking for PMs. In an avg month with nearly 1000 comments, I see maybe 10-15 instances of the word "Product Manager"
(Disclaimer - I'm a writer at Product Manager HQ, so my perspective is biased!)
I've seen that boards/forums and websites/blogs are distinct categories of resources.
I haven't found a board/forum that really helped me to grow as a product manager yet. My hypothesis is that because there are so many different kinds of product managers, it's difficult to hit any kind of critical mass of invested users who can all answer each other's questions. Even a forum with thousands of PM's may not succeed, because there are so many kinds of product managers (B2B vs B2C, web vs mobile, API vs UI, internal vs external, etc.)
That said, there are Slack communities that are a bit more lively than boards/forums, but even then the user ratios are usually heavily skewed towards newer PMs rather than more tenured PMs.
I strongly believe there are great websites/blogs, however. Two of my favorites (again, bias warning):
1) Product Manager HQ (https://www.productmanagerhq.com/) - generally relevant content for aspiring PMs, new PMs, and experienced PMs. Not as much content for Heads of Product, unfortunately.
2) Black Box of Product Management (https://blackboxofpm.com/) - solid resource for directors of product and higher.
Too true brother. Lots of fluffy thinkpieces that are really marketing or recruiting but very little substantive discussion about how to indentify and prioritize what’s important.
Sounds like a good reason to release an HN clone for PMs - or use the r/ProductManagement or r/prodmgmt forums on Reddit in a more consistent manner. I'm all for sharing best practices too - but they're locked in my Google Keep without real sharing capability. SMH.
It's already been mentioned by a few others, but just calling out Roadmap.com again. I actually help manage the community. So, if you have any feedback or things you'd like to see improved, send it my way. I'm always trying to make the site more functional and encourage meaningful conversations.
Also, as a side note, we put up a monthly jobs thread on the 1st of each month (and it's pinned as the first question on the homepage). I just put up the February one this morning.
I was researching this recently (why, I'll say in a sec), found a couple of interesting clack channels of sites people mentioned here: producthq, women in product, product coalition, product school, etc..
A lot of discussions are unstructured or hard to keep track of. I mean, it's slack, not a forum.
What I'm helping create with the wonderful team at JAM London is a curated collection of 'Hot Tips' with short practical and no-nonsense answers form PMs for PMs. It's picking up interest, looks like your question hit the nail on the head! :D https://www.jamlondon.io/tips/
Are you looking for domain or technology specific project management (PM) information, or referencing best practices for PMs in general? E.g., is https://pm.stackexchange.com/ what you are looking for or more developer and technology-centric planning techniques?
General question I've been wondering tangentially related:
Engineers:
is working [edit: replacing 'under' with 'with' due to replies! good clarification, didn't mean under] with a non-technical product manager a dealbreaker for you? (Do you look to filter out places you'd work at while job searching?)
Conversely, have you ever worked under a non-technical product manager you loved? Would you mind sharing details about your situation?
I was a non-engineering background PM (I dropped out of high school). I can tell you about what I didn't know early in my career that was painful for me then (and something I've internalized hard now): It's ok to say "I don't know". Conversely, saying "I have the answer" when you don't is lying.
The worst thing you can do as a PM is to make a technical assertion that you don't understand to a technical audience. You will instantly lose the audience's respect and trust (and those things are very hard to get back). To my mind, being technical is about actually understanding how things work such that you can make arguments grounded in facts and experience about systems. If you make arguments like "why don't you just rip out Mongo?" without understanding how painful that would be, it's really hard for people to believe in you.
Being non-technical doesn't mean opting out of technical discussions, it just means saying "I don't know" when you don't know. This is something I see PMs screw up all the time.
In reality, nobody knows everything, but pretending you know something when you don't is a verifiable road to hell.
Lastly, product is about two things: intuitive narrative and fact-based decision making. If you can't reason about your product hypotheses from first principles and/or bring established respected metrics to the discussion, you deserve to not be taken seriously.
By "working under" do you mean having an engineer report directly to a product manager, where the PM is responsible for the engineer's career growth, compensation, reviews, etc?
As a former engineer turned product manager, I would not advocate such a reporting structure. A PM wouldn't be the best person to help manage an engineer's career growth and everything else. I think it's perfectly fine to be on the same cross-functional team though.
> Conversely, have you ever worked under a non-technical product manager you loved? Would you mind sharing details about your situation?
I've had several.
The key feature is that they bring something to the table: I don't actually need technical guidance on how to build the product -- I (or another engineer) knows enough to solve the technical aspects, that's why the corporation is paying me (or them). But what I do need is help coordinating with other teams, help interacting with executives, help prioritizing tasks, help with the kinds of brainstorming exercises that nucleate the project plan, help with understanding and interpreting customer feedback, etc. Colloquially, the "people side" of the job -- it's just not what my skill set is.
So, I actually prefer non-technical PMs: I want people who complement me, not people who are probably less informed about technical issues trying to micromanage my choices there. A non-technical PM is bring a skill set that diversifies a team of engineers, and helps the team more successfully do its job of interacting with both the corporation and customers.
If the PMs here will indulge a couple questions from me:
1. What skills are most useful in an engineer, and how do we make you look good/help you make us look good?
2. What advice would you give to an engineer looking to move into a role like technical adviser, which more directly interfaces with management and executives?
I think it's OK to start out as non-technical product manager but over time they should pick up some technical knowledge. Some product managers refuse to learn anything technical which doesn't work well in the long run in my view.
Same for developers. They shouldn't just wait for requirements but also understand their users to some degree.
In the end engineering and product management should develop some competence in the other's area. Otherwise communication is very tedious and error prone.
Depends what you mean by non-technical. I've worked with product managers who didn't have an engineering background, and thst worked fine as long as they were able to understand the trade offs that we presented to them. I've also worked with product managers who just couldn't grasp any sort of technical nuance. That did not work out well.
I notice you phrase it as "work under", and I wonder if that is part of the issue you've had. Where I've worked, while it was true that the PM was guiding the direction of our work, they weren't our boss- they were simply a part of a team with a different role (in the same way that QA often takes direction from engineers, but they don't work for them). If the relationship you had with your PM was "one way" in this sense, then I can see why you wouldn't like it...
20-years in the industry and counting, and I've never even MET a "technical product manager".
I have met a handful of people who somewhat thought of themselves as technical. Because they did a touch of Visual Basic or something in their first job out of school, before immediately washing out and pursuing a non-technical career. Some of those guys liked to talk loudly about how much they're "one of you", and "get it", etc.
Without exception, that subset of PM's/PO's were absolutely dreadful to work with as a developer. I would ONLY want to work with a non-technical PM/PO, who stays in their lane and is comfortable with their role.
CS degree and am an engineer now, but I was a PM for ~6 years and hired/managed PM's.
I split technical background into two things: domain expertise and engineering experience. I value domain expertise most, engineering experience second.
Whether it's a dealbreaker really depends. In adtech, I wouldn't consider either matter a dealbreaker even for senior PM's. In cybersecurity, lack of technical background would absolutely be a dealbreaker, and except for junior hires, I would consider lack of domain expertise a dealbreaker too.
One problem domain is much trickier than the other and much more prone to paying the cost later for shortcuts taken earlier. I want to know my PM can navigate that with nuance.
By non-technical do you mean someone who has neither previously been a developer nor have a CS/Eng degree? I've worked with both and have found the lack of an engineering background is not determinant in my opinion of the PM. For the non-technical PMs with whom I've worked, the more important factors are willingness to listen when I explain the impracticality of a proposed change/feature and their own willingness to dive deep into understanding the problem domain and customer pain points.
Depends on the product and the actual functional relationship between PM and engineers. Is the product manager mostly working with designers and customers to see what is needed for the underlying project, and then communicating that equitably with engineers? That's ideal. Is the product manager making high-level technical commitments to management (e.g. "we are going to move our VMs from AWS to Azure by EOW!") because it's what they want to hear and then acting extremely bossy and assholishly to engineers trying and likely failing to meet that deadline? Do they not even do anything other than acting as a second manager who is way less qualified? Then they are actively making the work environment worse. Both situations are possible and honestly technical skills don't even matter that much here.
Now, if you are working on a very software-y product like SAAS or some other thing where other developers are the consumers, then you should not be non-technical (or if you are non-technical you should have a ton of experience being the PM for technical products) simply because you have little hope of understanding the needs of the consumers of the product. But this is a minority of products
The positions I've worked with non-technical PMs has been one with a kind of dual structure - there was a lead developer who was the technical expert as well as largely the PM's equal. The PM was more of an ancillary addition to the team, and any decisions were filtered between the two.
From my experience, a PM being technical can not do harm, but as a PM you work with multiple people: both front end backend engineers, data analysts, designers and maybe sales/ops/etc.
You can't have a background in every talent you work with, so for me as an engineer, if you don't have a technical background, no big deal.
What's important in your behaviour is, as some other comments as stated:
- Don't fake it. If you don't know, say you don't know, it's ok.
- Be (honestly) curious, and do everything you can to understand how things work. You don't need to understand how a specific database scales, but if a specific product connects to 3 different databases, understanding why, and what that implies technically is very important.
- Being honest and curious will build trust with your team. You also need to trust 100% your team. If someone tells you that something you thought would be easy is in fast hard, don't question. Ask questions to understand why and get more context on how your product works. Don't ask to make sure the person is not BS'ing you, ask to know, out of honest curiosity.
- Be on top of 100% of your product. Nobody else should know your product better than you. If you own a complicated onboarding flow, you should know exactly, by heart, all the different steps, situations, how someone gets to what steps, what happens when someone signups with a wrong email, etc etc.
All those previous point are true for engineers, design, data and every other role on your team. You are the CEO of the team. That doesn't mean you have authority, but that means you work with VPs that bring expertise, from it, you make strategic decisions on where to bring the team. So you don't have to have a technical/design/data background, but you need to be broad and curious enough to understand what everyone explains you and what to do of those.
The worst PMs I worked with were the kind of PM who would not make such efforts, ask repetitively the same questions or make the same wrong assumptions because they don't know their products and don't understand / learn / remember when you explains who/why something is hard/not worth it/not possible.
The ones that come and say "but why don't you just drop mongo" (see sibling comment).
non-technical PMs are the best. They don't try to do things they can't, they take our word wrt complexity of implementing things and tradeoffs. And they are mostly women, which brings an extra layer of much-needed balance.
Good to know there other PMs out there. I have found HN invaluable over last few years for news discovery and insights. Not sure we need a new board just more PM posts in this one.
Does anyone want to discuss website find.xyz?
I have a hard time finding information on the internet. As they state on their website, if you google something it's SEO game and very often how much the article matches your keywords and not specifically highest quality articles first.
However, I find it hard to find information on find.xyz that interests me. When you click on tech you see a lot of Benedict's tech news (Maybe he is investor?). Maybe the problem is the site seems to be new.
How do you find information online? I tend to find best articles here on hackernews and on twitter, but it is very random. I wish there was a way to find high quality articles on stuff that interests me without googling for hours.
This is glorious! And actually saves me quite a bit of time. This subject extends much deeper than the rote teaching of "soft skills" to engineers. And is more akin to realizing one's own humanity ;)
I can also recommend a text called Product Design and Development used in the grad-level MIT class
It's the same with DevOps. There are very few books and thousands of articles. I'm slowly trying to filter and categorize them so they can be reviewed and summarized, because only a few people will ever read these things and the information won't get to regular people.
I'm curious to learn more! I've generally been trying to write articles based on personal experience rather than abstract frameworks or untested advice.
In your mind, what would a "rubber meets the road" kind of resource look like? What sorts of questions would it address?
[+] [-] polote|7 years ago|reply
On HN you can get super useful information about any stack/language/framework by reading the comments, but when you are a PM you have nowhere to get that kind of information
[+] [-] rchaud|7 years ago|reply
[+] [-] dawhizkid|7 years ago|reply
[+] [-] clementkao|7 years ago|reply
I've seen that boards/forums and websites/blogs are distinct categories of resources.
I haven't found a board/forum that really helped me to grow as a product manager yet. My hypothesis is that because there are so many different kinds of product managers, it's difficult to hit any kind of critical mass of invested users who can all answer each other's questions. Even a forum with thousands of PM's may not succeed, because there are so many kinds of product managers (B2B vs B2C, web vs mobile, API vs UI, internal vs external, etc.)
That said, there are Slack communities that are a bit more lively than boards/forums, but even then the user ratios are usually heavily skewed towards newer PMs rather than more tenured PMs.
I strongly believe there are great websites/blogs, however. Two of my favorites (again, bias warning):
1) Product Manager HQ (https://www.productmanagerhq.com/) - generally relevant content for aspiring PMs, new PMs, and experienced PMs. Not as much content for Heads of Product, unfortunately.
2) Black Box of Product Management (https://blackboxofpm.com/) - solid resource for directors of product and higher.
[+] [-] tschwimmer|7 years ago|reply
[+] [-] carchase|7 years ago|reply
- productmanagerhq.com - productschool.com - mindtheproduct.com - roadmap.com - departmentofproduct.com
[+] [-] dopeboy|7 years ago|reply
https://bestpracticer.com/topic/product-management-151996004...
[+] [-] mud_dauber|7 years ago|reply
[+] [-] myguysi|7 years ago|reply
Though I think you’re possibly looking for discussions rather than lectures?
[+] [-] bryanmccarty|7 years ago|reply
Also, as a side note, we put up a monthly jobs thread on the 1st of each month (and it's pinned as the first question on the homepage). I just put up the February one this morning.
[+] [-] m_krzem|7 years ago|reply
A lot of discussions are unstructured or hard to keep track of. I mean, it's slack, not a forum.
What I'm helping create with the wonderful team at JAM London is a curated collection of 'Hot Tips' with short practical and no-nonsense answers form PMs for PMs. It's picking up interest, looks like your question hit the nail on the head! :D https://www.jamlondon.io/tips/
[+] [-] timlloyd|7 years ago|reply
[+] [-] pitzahoy|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] adpirz|7 years ago|reply
[+] [-] SysINT|7 years ago|reply
[+] [-] s17n|7 years ago|reply
[+] [-] no6inbash|7 years ago|reply
[+] [-] captain_crabs|7 years ago|reply
Engineers:
is working [edit: replacing 'under' with 'with' due to replies! good clarification, didn't mean under] with a non-technical product manager a dealbreaker for you? (Do you look to filter out places you'd work at while job searching?)
Conversely, have you ever worked under a non-technical product manager you loved? Would you mind sharing details about your situation?
[+] [-] josh2600|7 years ago|reply
The worst thing you can do as a PM is to make a technical assertion that you don't understand to a technical audience. You will instantly lose the audience's respect and trust (and those things are very hard to get back). To my mind, being technical is about actually understanding how things work such that you can make arguments grounded in facts and experience about systems. If you make arguments like "why don't you just rip out Mongo?" without understanding how painful that would be, it's really hard for people to believe in you.
Being non-technical doesn't mean opting out of technical discussions, it just means saying "I don't know" when you don't know. This is something I see PMs screw up all the time.
In reality, nobody knows everything, but pretending you know something when you don't is a verifiable road to hell.
Lastly, product is about two things: intuitive narrative and fact-based decision making. If you can't reason about your product hypotheses from first principles and/or bring established respected metrics to the discussion, you deserve to not be taken seriously.
[+] [-] mikeleeorg|7 years ago|reply
As a former engineer turned product manager, I would not advocate such a reporting structure. A PM wouldn't be the best person to help manage an engineer's career growth and everything else. I think it's perfectly fine to be on the same cross-functional team though.
[+] [-] NotAnEconomist|7 years ago|reply
I've had several.
The key feature is that they bring something to the table: I don't actually need technical guidance on how to build the product -- I (or another engineer) knows enough to solve the technical aspects, that's why the corporation is paying me (or them). But what I do need is help coordinating with other teams, help interacting with executives, help prioritizing tasks, help with the kinds of brainstorming exercises that nucleate the project plan, help with understanding and interpreting customer feedback, etc. Colloquially, the "people side" of the job -- it's just not what my skill set is.
So, I actually prefer non-technical PMs: I want people who complement me, not people who are probably less informed about technical issues trying to micromanage my choices there. A non-technical PM is bring a skill set that diversifies a team of engineers, and helps the team more successfully do its job of interacting with both the corporation and customers.
If the PMs here will indulge a couple questions from me:
1. What skills are most useful in an engineer, and how do we make you look good/help you make us look good?
2. What advice would you give to an engineer looking to move into a role like technical adviser, which more directly interfaces with management and executives?
[+] [-] maxxxxx|7 years ago|reply
Same for developers. They shouldn't just wait for requirements but also understand their users to some degree.
In the end engineering and product management should develop some competence in the other's area. Otherwise communication is very tedious and error prone.
[+] [-] nicoburns|7 years ago|reply
I notice you phrase it as "work under", and I wonder if that is part of the issue you've had. Where I've worked, while it was true that the PM was guiding the direction of our work, they weren't our boss- they were simply a part of a team with a different role (in the same way that QA often takes direction from engineers, but they don't work for them). If the relationship you had with your PM was "one way" in this sense, then I can see why you wouldn't like it...
[+] [-] kevinventullo|7 years ago|reply
[+] [-] StevePerkins|7 years ago|reply
I have met a handful of people who somewhat thought of themselves as technical. Because they did a touch of Visual Basic or something in their first job out of school, before immediately washing out and pursuing a non-technical career. Some of those guys liked to talk loudly about how much they're "one of you", and "get it", etc.
Without exception, that subset of PM's/PO's were absolutely dreadful to work with as a developer. I would ONLY want to work with a non-technical PM/PO, who stays in their lane and is comfortable with their role.
[+] [-] munchbunny|7 years ago|reply
I split technical background into two things: domain expertise and engineering experience. I value domain expertise most, engineering experience second.
Whether it's a dealbreaker really depends. In adtech, I wouldn't consider either matter a dealbreaker even for senior PM's. In cybersecurity, lack of technical background would absolutely be a dealbreaker, and except for junior hires, I would consider lack of domain expertise a dealbreaker too.
One problem domain is much trickier than the other and much more prone to paying the cost later for shortcuts taken earlier. I want to know my PM can navigate that with nuance.
[+] [-] BillSaysThis|7 years ago|reply
[+] [-] opportune|7 years ago|reply
Now, if you are working on a very software-y product like SAAS or some other thing where other developers are the consumers, then you should not be non-technical (or if you are non-technical you should have a ton of experience being the PM for technical products) simply because you have little hope of understanding the needs of the consumers of the product. But this is a minority of products
[+] [-] SketchySeaBeast|7 years ago|reply
[+] [-] jypepin|7 years ago|reply
You can't have a background in every talent you work with, so for me as an engineer, if you don't have a technical background, no big deal.
What's important in your behaviour is, as some other comments as stated:
- Don't fake it. If you don't know, say you don't know, it's ok.
- Be (honestly) curious, and do everything you can to understand how things work. You don't need to understand how a specific database scales, but if a specific product connects to 3 different databases, understanding why, and what that implies technically is very important.
- Being honest and curious will build trust with your team. You also need to trust 100% your team. If someone tells you that something you thought would be easy is in fast hard, don't question. Ask questions to understand why and get more context on how your product works. Don't ask to make sure the person is not BS'ing you, ask to know, out of honest curiosity.
- Be on top of 100% of your product. Nobody else should know your product better than you. If you own a complicated onboarding flow, you should know exactly, by heart, all the different steps, situations, how someone gets to what steps, what happens when someone signups with a wrong email, etc etc.
All those previous point are true for engineers, design, data and every other role on your team. You are the CEO of the team. That doesn't mean you have authority, but that means you work with VPs that bring expertise, from it, you make strategic decisions on where to bring the team. So you don't have to have a technical/design/data background, but you need to be broad and curious enough to understand what everyone explains you and what to do of those.
The worst PMs I worked with were the kind of PM who would not make such efforts, ask repetitively the same questions or make the same wrong assumptions because they don't know their products and don't understand / learn / remember when you explains who/why something is hard/not worth it/not possible. The ones that come and say "but why don't you just drop mongo" (see sibling comment).
[+] [-] megy|7 years ago|reply
[+] [-] avip|7 years ago|reply
[+] [-] monkeydust|7 years ago|reply
[+] [-] cpeterso|7 years ago|reply
Google's re:Work blog: https://rework.withgoogle.com/
Harvard Business Review (HBR) blog: https://hbr.org/the-latest
Practicing IT Project Manager blog shares curated links to project and product management articles: http://blog.practicingitpm.com/
[+] [-] qnsi|7 years ago|reply
However, I find it hard to find information on find.xyz that interests me. When you click on tech you see a lot of Benedict's tech news (Maybe he is investor?). Maybe the problem is the site seems to be new.
How do you find information online? I tend to find best articles here on hackernews and on twitter, but it is very random. I wish there was a way to find high quality articles on stuff that interests me without googling for hours.
[+] [-] marenamm|7 years ago|reply
[+] [-] ArtWomb|7 years ago|reply
I can also recommend a text called Product Design and Development used in the grad-level MIT class
http://www.ulrich-eppinger.net/
[+] [-] yingw787|7 years ago|reply
- Product Management HQ: https://www.productmanagerhq.com/
- Roadmap.com: https://www.roadmap.com/
I haven't used them enough to rate how good they are, though.
[+] [-] peterwwillis|7 years ago|reply
[+] [-] 3into10power5|7 years ago|reply
There are very few "rubber meets the road" kind of resources.
[+] [-] clementkao|7 years ago|reply
In your mind, what would a "rubber meets the road" kind of resource look like? What sorts of questions would it address?
[+] [-] dawhizkid|7 years ago|reply
[+] [-] rahimnathwani|7 years ago|reply
[+] [-] baxtr|7 years ago|reply
[+] [-] xuesj|7 years ago|reply
[+] [-] rblion|7 years ago|reply
[+] [-] adwivedi9994|7 years ago|reply
[+] [-] ct520|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]