I will soon be working as a PM at one of the big tech companies as my first job.
I've gotten the gist of these lessons from a software engineering class, HN articles, and from my internship (at the same company), but I'm still not very confident about becoming a great PM. Can you recommend any books or resources that covers more of this kind of stuff?
I'm going to be joining a startup upon graduation as their first PM and posts like these are invaluable. There is just so much a PM must do and excel at that I've started a notebook to keep everything structured till it becomes second nature to me.
I'd love pointers to other such great resources that shed light on what makes a good, no great, PM.
This is really interesting and I might pick this up! I'm actually on the other side of the equation. I want to learn how to work better with the PM as an engineer. I'm working in a "startup" environment and we're having some issues working as a team and aligning well.
Technical PM in big tech here. Going to chime in with some thoughts as I made that same transition after 5 years in engineering. And been doing it for the last 5 or so years.
Given that PM has two definitions:
Product manager - what & why
Program manager - when, who, how
Some companies simply get these two disciplines mixed up or a single PM handles both(hard job). Some PMs act more like engineering managers & other PMs act more like MBAs.
The number one way to grow as a PM? Read and embed yourself with your users & product.
Learn from other accomplished individuals, find mentors on what works and try new things for yourself. It's amazing to me of how many complements you may get about some strategy or tactic we used as a product team successfully that just came from a book & applied to our space. Lenny's newsletter is great too, but even books about successful / failed products are just as helpful.
> Don’t let gaps form between you and your customers and between you and the builders
This is commonly an Ivory Tower problem in which teams don't do any customer research or get out of the building to talk to people they're building for. It's hard to blame them when they've never done it before to be successful nor have a PM who understands the value of embedding themselves in the product they're managing.
> People matter most
My personal motto for any new product or effort is to "work the people, then the problem". It doesn't matter if there's deadlines if nobody is talking to each other or learning from the very people you're building the product for. Once everyone is rowing in the same direction & agree on a common vision, it's smooth to execute upon it.
> Write your resume in ten years.
My ten year plan when I first started in software was to become a DBA(wrote it in 2010). And that DBA dream was more close to modern data science today. The data science side of PM work is an absolute joy and fun. It's exactly what I wanted when I wrote that 10 years ago. Oh how things have changed. Now that I'm a more senior PM, that 10 year plan has shifted to be a director and/or running my own successful product with all the skills learned over my career.
> The “art” of product management matters more than the “science” over the long term.
The art is the right brain(creativity), the science is the left brain(logic). I personally like to see this as emotions vs. facts. How you feel about something is much different than the reality of it. The art of being a good PM is by invoking emotions. How engineering feels about the backlog priority? How do users feel about an upcoming feature/change? How do leadership feel when you present your next year plans? There's a reason why many popular PM books are called "Inspired" or "Empowered". It's because of the emotion being invoked when your team is firing on all cylinders and your users are happy with your product decisions.
id argue acquiring the skills and experience to be a good pm is on par with doing the same to become a better engineer. good pms have very different skills to software engineers - communication, communication, more communication. obviously software experience lends itself to managing software projects well so youre half way there, but i wouldnt underestimate it. it sounds to me, that if you recognize and have identified your weaknesses as an engjneer, youre also half way there to learning from them and getting better at it. the question is what do you enjoy and what will you be motivated to work at? do that.
That's great to hear. For a second, i was worried that i will fall behind because i don't have any tech experience. Just recently, i was able to get an overview of what a PM role is like within the company i work for. Definitely looking forward to learn more about it so i share my experience here in HN.
This is a great perspective! Thank you for sharing. I guess this applies more to dev roles though and tough to do for product management roles. Thoughts? Are there platforms where you could build credibility like SO for PMs?
You are so right on the QA thing and so wrong on the PM thing. If you have a PM that just came out of uni, your company has no idea what they are doing. Good PM's are really really good at communicating at multiple abstraction levels within multiple levels of the organizational hierarchy. Why? Because they have to build consensus and coalitions to get the things ( money, people, buy-in, details, information ) required to build really good software and build all the ancillary things to sell and support that software. I think what you are calling a PM is what I call a jr. project manager.
I became a PM last year only months after learning what a PM actually is. I did not have a software or product background, but I did have a significant technical background in the product domain for which I was hired.
I have found the entire experience both incredibly rewarding and incredibly humbling. I've never worked in a position that is so broad - from technical expert to support to tech writer to customer success to management.. every day is different. I do think this sums it up well:
> 14. Be on top of your shit. Until I figure out how to better articulate this, I’ll say it ineloquently as “just be on it.” Know your business, your product, your team, be responsive, communicate relentlessly, make good decisions, own your results, get 1% better every day.
If you're not constantly on top of everything, it becomes chaotic and obvious very quickly.
Well, on the bright side, all you aspiring PMs out there, take note: see how low the bar is??
Speaking as a PM/PO that, I hope, doesn't suck, if you simply take the time to:
1. Understand the market.
2. Understand the product.
3. Understand the user.
4. Actively engage with and converse with developers and negotiate requirements rather than acting as a lofty dictator, and listen when the engineers raise concerns.
5. Be engaged in the process so the product can truly evolve as market and technical requirements are uncovered.
6. Own failures.
7. Share successes.
I'm sure I've left lots off the list, but it's pretty basic stuff (which, I suppose, all starts from the same basic place: humility)...
I've been a product manager for about 2 years, coming from a development background, I suggest getting as much technical background as possible and a nice helping of people skills.
It's been said before but the PM is mainly a servant and facilitator, and it helps a lot if you know what you're talking about (we have a PM here that confuses VPNs with DNS, doesn't know how to report bugs, etc.)
IMHO, getting to be a PM is mostly demonstrating that you're dependable in a lower level position and showing that you have enough knowledge/leadership skills to get the job done.
No book. Build a product from scratch. If you've never built a product from A to Z, including having at least 1-2 users you're communicating with, then you won't land a PM job.
This is a good article. As someone who has now done both for a long enough time to know the roles well, nearly all of this rings true to me.
As an engineer, I almost never had time to pay attention to high-level business needs, because I was too deep in the weeds of a specific problem. I hated meetings and bureaucracy.
As a startup founder, I was torn between the need to pay attention to high-level business needs, and suffered when I spent too much time in the code, but there wasn't a choice.
As a PM, I regret not being able to spend time on engineering details, because I spend most of my time working on higher-level issues.
That said, if I could wave a wand and make one change to the current industry, it would be to make 100% of PMs have deep knowledge of engineering. I have no idea how you do the job well without this experience, other than living in a constant state of fear. Too many PMs are bad engineers or worse, non-engineers. This is a recipe for an ineffective PM.
I spent a lot of years as a PM and PgM, and the general gist of this article seems to be that if you have better PMs your project outcomes will be better. I know HN loves to talk about how much the PMs they've reported to suck, but having worked with many clients on dozens of projects, it's rarely that simple. While bad PMs are definitely way too common, so are bad development teams. And remember that PMs are usually getting shit on from two directions at once (development teams and management teams) with often very little authority to actually fix things. It's usually bad management practices and attitudes that sink projects and make life hell for everyone, and the cause of that is usually lack of understanding and empathy for how software development works.
The greatest PM in the world can't help a project if the executive sponsors keep changing scope and requirements or making ridiculous promises to clients to increase sales (and I've seen good PMs quit over this). We don't just need better project management training, we need better management training in general for anyone whose job is dependent on software. Also, companies need to actually be willing to pay for good PMs instead of pulling the cheapest contractor they can find and acting surprised when regurgitating the PMI handbook doesn't actually work.
You shouldn't go trying to be a PM, because you've got neither the experience nor the respect to get there. Sorry to be blunt, but this'll save some time.
Instead, focus on being the best engineer you can be, on building and crafting software as well as you can. That will earn you the respect of the people whose respect is worth something, and will give you the insights needed for leading a team properly.
I've gotten the gist of these lessons from a software engineering class, HN articles, and from my internship (at the same company), but I'm still not very confident about becoming a great PM. Can you recommend any books or resources that covers more of this kind of stuff?
reply