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.
This is where spending some years in a big organization can be really helpful. You can find mentors who have managed major products. You learn from them, but at least as importantly, you have their contact info and these are people who answer their email when you have an interesting problem or question for them.
Doesn't have to be corporate. The high end of government has some really stratospheric talent executing high cost, high stakes projects.
While I agree that good PMs are busy, I'd argue that the bigger problem is that busy PMs aren't incentivized to share their knowledge.
I've been doing my best to try to share my knowledge as a product manager (disclaimer, I write for Product Manager HQ), but that's been a challenge - it takes anywhere from 8-20 hours for me to pull together a thoughtful article, especially because I'm keenly aware of the fact that there's an overwhelming number of low-quality product management articles. I've been lucky to have time on weekends to write, and I know that's not a luxury that every product manager has.
Many of my peers and colleagues are hesitant to jump into writing, specifically because they aren't incentivized to do so. (I'm incentivized by my personal mission "to make other people's lives happier, easier, and better", but personal missions can only incentivize a single person...)
Hackathons are a great way for engineers to share their abilities with others outside of their day-to-day work. I wonder whether there are similar outlets for PMs - maybe some sort of open-mic for best practices, or a company-sponsored "blog day" where every PM sits down for the day and pulls together learnings?
That's an interesting point. I'd be really interested in some advice on how to prevent it. Currently with our project Hot Tips form PMs for PMs https://www.jamlondon.io/tips/ we do manual curation (people submit text, or I reach out to specific experts) and then it goes through approval/editing process. It'd be cool to be able to automate it though.
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"
Yeah, I don't think PMs can really burn out / grow to hate your job as easily as developers do (unless you just have low performance). Also their skills don't transfer as easily. I see people with the title of "PM" (not product though) I work with making more than me who just click through the data visualizations/backend I made and turn that into reports to management... why would anybody give up that job when 1) they are making a lot of money doing something low-stress 2) those skills don't transfer at all.
It's also just a case where lots more people are qualified for this kind of job so it's not as hard to fill a position when the need arrises.
>>>> It's also just a case where lots more people are qualified for this kind of job so it's not as hard to fill a position when the need arrises.>>>>
Interesting. I think it's the opposite. Because PM culture differs from company to company, I feel like companies interview for PMs with a bias for how they expect their PMs to behave. This would be unlike Developers where companies are looking for folks proficient in specific languages.
I've had friends who interviewed with companies for PM positions and the focus was on their doing great UI mockups. The interviewer was looking for good UIs. Unfortunately, these folks were coming from places where the UI mockup they did was just basic placement of elements to communicate the elements they expected their solutions to use. A seperate design team would later turn their mockups into beautiful UIs
That's fair, I do acknowledge that the PM role varies greatly between companies (and often within companies). For example at my company PMs would never make a UI mockup, they would basically be the bridge between designers, management, customers, and engineers when it comes to UI. But if you aren't requiring your PMs to be technical, I mean the sheer amount of people qualified to do that job (even with stipulations such as "knows design") is a lot greater than the set of people who are qualified engineers.
But I also think it's ignorant to say that companies just want folks proficient in specific languages. That might be true for people without much experience but in most cases beyond that (which pay well) people are looking for deep technical understanding of a specific technology (e.g. deep learning) or a specific problem (e.g. scaling large web services).
>>>> But I also think it's ignorant to say that companies just want folks proficient in specific languages. >>>.
Fair Point. For experienced hires, companies want technical knowledge of a technology/domain
>>>> But if you aren't requiring your PMs to be technical, I mean the sheer amount of people qualified to do that job (even with stipulations such as "knows design")>>>
Well, for experienced hires too, domain specific knowledge is also relevant for PMs.
In full agreement. The expectations of a product manager from one company to the next are wildly different. Far different than any other role that I can think of in fact.
Because I see this sentiment (PMs have easy jobs and don't really do anything) a lot on HN, I want to offer an anecdotal counterpoint: I am a PM in San Francisco and most of the PMs I know personally work extremely hard and add a good deal of value to their companies. I realize that as a PM I am biased towards thinking I provide value/work hard, but I can safely say I have never heard of anyone working in a PM role as easy/useless as the one you describe.
As a small team's CTO doing both product management and engineering, I'd say product management is the more difficult role. Might be because I'm not as experienced, but despite having a natural aptitude for it and even after having gone through training and spent a lot of time doing it, I find the job damn hard. You're the broker for a lot of unstructured information and have to fend off all kinds of disruptive influences to land even close to where you're trying to go. I have immense respect for product leaders at innovative organizations.
I don't think all PMs have easy jobs or are useless, and I even know PMs who I think have kind of easy/unimportant jobs (not that I would ever tell them that about their job) who still take a lot of pride in their work and do work hard anyway. But I do think there are lots of PMs out there who essentially fill the role of "business analyst" who end up doing low-skill things that fall outside of easily-defined role-buckets. That's not the employee's fault so much as the organization's.
(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.
Out of genuine curiosity - which topics or questions would be most valuable to you?
I've written 50+ articles on Product Manager HQ, and the feedback I've heard from my readers thus far is that each one has been uniquely insightful, covering topics that they haven't yet seen discussed by other blogs.
I'm doing my best to close knowledge gaps - would love to hear what's on your mind!
productmanagerhq.com has been a let down for me. Its mostly people sharing articles and tool recommendations. No real or deep discussion. No one points flaws in others thinking/products. I was very disappointed with the community.
That said, the article recommendation in weekly newsletter are good .
I find that's 99% of professional communities. Even the comments here.
Cargo culting gets you way further in most careers than making good decisions. Unless you're high enough up in your company to seriously shape it's future, it's usually +EV to just follow the herd and to be seen doing it, loudly, and often. Hence all the shitty Medium articles about how great every single tool/ideology/framework/technique is.
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.
I can spin a clone up tonight if there is enough interest, cause it's something I think would be valuable. That said, we tried this before specifically for longer form hacker news discussions [1] and it died in less than a year.
Not sure how to guage interest without seeming spammy, people can email me or just upvote this comment I suppose.
What would a potential url be? Suspect it would be useful to keep the ycombinator “brand”.
So maybe a sub-site like “pm.ycombinator.com”? Mentioning it here to see what others think...
Edit: Another thought: what if there was a way to “set” an option which would “filter” ycombinator depending I your background interest? When submitting you “tag” of relevant to an area (such as pm, software dev, testing, etc). If you set your interest levels at the top, it will automatically prioritize items based on interest, but allow general interest items to remain on top. (Also avoids issue of second website to visit)
I wouldn’t do it until we had a way of enforcing the no-fluff rule - even more so than generic up/down voting. I wish there was an ArXiV for this type of knowledge.
The key challenge there is that while scientists are expected to produce papers and to review papers, product managers are not expected to do so.
We're expected to manage our products (which makes lots of sense), but that leaves us little time to curate a neutral and high-quality repository of product management knowledge.
While I've done my best to share my knowledge in my spare time (I've published 50+ articles at Product Manager HQ), I strongly believe there's a systemic challenge at play here.
Many of my colleagues are insanely good at what they do, yet they haven't written any articles on product management because that behavior isn't incentivized.
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.
Wow, how have I never come across this site. What's your current strategy to encourage more meaningful conversations? I see in some threads you yourself add the first answer, I imagine to set the tone which I think is a good strategy.
What's the current main problem? Not enough answers, or lack of "quality" answers? How do you quantify/measure quality interaction?
Sorry for this inquisitive interview, it's just a very interesting topic. I'd like to automate my own processes, and haven't spoken to anyone managing a reddit-style forum before (apart form one guy who is creating one, but that's a dev more than a community person ^_^)
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/
Working with more senior PMs is the only working solution I have found.
Product Management is a very complex role...there is no straight forward learning path today other than doing the job ,building shit and strong mentor ship!
It's also very different from company to company. Some companies will refuse to hire non-technical PMs. In other companies you will find PMs who do not know basic SQL. It's strange.
I couldn't agree more. I had the PM title twice before I worked with some senior PMs at a very successful Fortune 50. What a difference experience makes. I cringe when I think about how incompetent I was in my first two PM roles.
Ditto. My first three stints (albeit with zero help from peers or mentors) were terrible. It seems like you need a couple of epic screwups under your belt before the patterns start to present themselves.
Totally agree. I've taken a number of juniors on over the years where I have spotted raw talent. I would say 50% of them are now killing it versus more experienced (and expensive) external hires. 20% are doing just fine. And 30% just couldn't make it work, at least in our organisation.
It's a tough, complicated and at times lonely role but I wouldn't do anything else... working for someone else at least.
Part of the challenge here is that the product manager role itself isn't well-defined.
My favorite analogy here is the one about cancer - cancer isn't one disease, it's thousands of diseases that all look the same on the surface, but are really different when you dive in. A cure for skin cancer doesn't really help get you closer to a cure for lung cancer, as an example.
Specifically for your partner - what kind of product management is she doing? B2B or B2C? Customer-facing products or internal products? Web or mobile?
The more specificity you have, the more likely you'll be able to find more relevant professional development resources for her particular flavor of product management.
That being said - once a PM hits a particular threshold of experience and self-awareness, they can generally come up with their own professional development track, though it always helps to have a mentor.
there was a spinoff professional networking/mentoring group whose name is escaping me at the moment, but she can find such resources via women in product: https://www.womenpm.org
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.
Related tip: ban the word "just" from your vocabulary. As an engineer, hearing a non-engineer say "can't we just X" is never a positive experience. Just that one word carries so much baggage - it's the shortest way possible to say "I don't value your expertise or expect you to have thought this through".
Sentences with "just" in them always work better if you drop the word.
"Why don't you rip out Mongo?" - now we can have a conversation.
"Why don't you just rip out Mongo?" - you've just started a much more hostile conversation entirely by accident.
To add to your comment, "I don't know" is a critical phrase, and so is following it with "help me understand the technical issues at play here" -- technical people generally love teaching someone who is curious, respectful, and has asked them to help guide a decision that is at least in part technical.
This works especially well when they can see you making a sincere effort to understand, by paraphrasing and repeating back what they've explained to you: "So what you're saying is that this component works like such and such, and one weakness of the approach is xyz? Am I understanding right?"
Also involving them in the business issues at play can help - "I hear you saying this approach will be more robust in the long run, and what you say makes a lot of sense to me. I'm struggling to balance this against business issues of the expected lifetime of this feature and our target ship date. If we are in a situation where we don't expect to use this feature for long and we have ship date pressure, what are your thoughts on the approach that is less robust in the long run?"
Doing the above helps keep people from thinking you're a poser who refuses to understand the issues, and also helps technical people from becoming grumpy about what may look like idiotic decisions that are in fact driven by a business issue that nobody told them about or included them on.
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'm a non-technical product manager, and I've heard the same sentiment with the engineers that I work with. My engineers want business context and user context - they don't need someone to provide technical guidance.
To address your questions directly:
1) The most helpful skill in an engineer is the skill of speaking up. When I reflect on the dozens of engineers I've worked with, I consistently find that the ones who provided the most value were the ones who would question me constructively.
My specs aren't perfect, because I don't have a detailed understanding of the technical constraints. I love it when engineers tell me why my spec won't work, and then provide multiple alternatives for how to get the spirit of my spec to work.
As for how to help you look good - I really appreciate it when engineers honestly keep me informed about their bandwidth. That way, as I keep stakeholders in the loop, I can accurately set their expectations.
It's never helpful when engineers say "I can complete these 15 tasks by next week", and wind up only completing 2. On the flip side, it's equally unhelpful when engineers say "I can complete only 2 tasks by next week", then wind up knocking out the entire backlog.
2) I can't speak clearly to "technical adviser"-type roles, unfortunately, since I'm not technical to start with. That being said, the technical folks who interface with management and executives are typically managers of managers of engineers.
In other words - the engineers who drive the technical vision of the company are also the ones who are directly responsible for their teams' execution on the tactical work.
>>>> What skills are most useful in an engineer, and how do we make you look good/help you make us look good >>>>
1) I don't think it's technical skills per se (your hierarchy would have reviewed that when you were hired). I think it's more of an attitude. I've lost count of the number of times PMs make a case for a feature to behave in a specific manner and Dev doesn't want to invest the time or effort to even investigate if it's possible/how that can be done. From Dev POV - we already do it this way so live with it. PM makes the argument that is not the best from a functional POV but Dev is simply not interested.
Note: I'm not saying all Devs behave this way, just pointing out a technical way of doing something might not provide the best functional experience and being open to explore or understand what PM is trying to achieve is important.
2) Ability to look at the big picture. Sometimes one is so focused on the immediate tasks and its technical design that they miss the fact that the PM has a road map and this feature or set of features is just one bit on the roadmap. This means that whatever is being built now should if possible make it easier to implement the other features down the line.
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.
This is an interesting point. The first several years of my career, I was an engineer working on low level operating system stuff. I later switched to product and my technical chops really helped me earlier in my product career. As I got more senior however, the business, strategy, and product vision components of the PM role became more important and my technical skillset was less "directly" useful. It was more helpful in getting me trust with senior engineers, and therefore transitive trust with executives (because eng directors are often the first people a new exec will turn to to "read" the org in a large company)
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.
I work at a big company and about half the PMs I work with were developers, myself included (for around 15 years). I have found this to be totally normal both when I was coding all day and now that I'm managing all day. There are no lanes.
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.
A counter point - I've worked with Developers who have told me a load of BS. In those instances I knew it was BS because I was quite conversant with that bit of knowledge (this is not to imply that I'm some astounding developer; but anybody with some basic technical knowledge would have realized it was BS).
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?
It's just an extremely nebulous role and completely different from company to company, which means you could be perceived as great in one co and terrible in another. I find it hard to measure my own real value.
You're right - it differs from company to company.
I think you'll enjoy the role if you are in a company where the PM drives the feature - the PM determines what features should be implemented, does the design (UI, logic, behavior, etc and then Dev does the technical design and codes it).
One way to measure your value is also your ability to solve customer's problems. By this I mean - you could have a feature/capabilities and then a customer has a unique situation; being able to figure out how to use your feature in a non-conventional manner or coming up with a work-around (not one that creates a loop hole) to solve the problem can feel rewarding. The challenge though is that it is sometimes difficult to quantify this when you are trying to move companies
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