Product-building articles by PMs at major tech companies
find.xyz
find.xyz
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
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 a tough, complicated and at times lonely role but I wouldn't do anything else... working for someone else at least.
yc’s ffc ( https://blog.ycombinator.com/?s=ffc ) is also useful for the more entrepreurially minded.
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.
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!
Though I think you’re possibly looking for discussions rather than lectures?
- productmanagerhq.com - productschool.com - mindtheproduct.com - roadmap.com - departmentofproduct.com
That said, the article recommendation in weekly newsletter are good .
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.
Not sure how to guage interest without seeming spammy, people can email me or just upvote this comment I suppose.
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)
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.
https://bestpracticer.com/topic/product-management-151996004...
I also think the attrition rate for PMs are much much lower than that of Developers.
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
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).
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.
Doesn't have to be corporate. The high end of government has some really stratospheric talent executing high cost, high stakes projects.
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?
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.
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 ^_^)
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/
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.
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?
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.
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...
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.
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.
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.
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.
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'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?
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'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.
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.
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
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).
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/
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.
I can also recommend a text called Product Design and Development used in the grad-level MIT class
- 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.
There are very few "rubber meets the road" kind of resources.
In your mind, what would a "rubber meets the road" kind of resource look like? What sorts of questions would it address?
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