Why PM?

New
Xh2Mb

New

Xh2Mb
Apr 24, 2020 802 Comments

I am seeing alot of post here on people wanting to to be PM
What is so great about being a PM besides not writting code?
I really would like to get an understanding

EDIT: I am overwhelmed with the amount of response this received.

Update 11/29/20
Any one hiring for a entry level pm please dm or if you want to mentor an aspiring product person. Thank you!

Update 01/26/2021
DO NOT BECOME A PM

Update 10/20/2021
I am exhausted I miss working 3 hours tops a day and bs during daily stand up. Upside the engineers love me because I relate to them a-lot more than previous PMs
I am making 5x what I was making as an engineer.

Update 12/02/2021

This will probably be the last update.

My tc as a SWE was 52k and now as a PM I’m making 195 base 10-20% annual bonuses 15k share of the company I’m with.

I work fully remote.

I live with my girlfriend and her parents my current expenses is 500$ student loan.

PM is not easy if you find a PM that says it’s easy they’re lazy is that simple.
Best of luck out there anyone making the switch.

I still code but for my own fun.

Also buy Fluffy Coin!

comments

Want to comment? LOG IN or SIGN UP
TOP 802 Comments
  • New
    msquirrel

    New

    msquirrel
    In a large org, engineers don't know the half of politics that happen before the product can make one step in the right direction. Even in companies that are product-driven, there are trade-offs to make between what's best for users and what's best for business.

    Let's say a company decides that it wants to enhance its video conferencing app with a grid layout. Why is this a good idea? Do we want to do this to get on parity with competitors? Which segment of users will benefit from this? How will this increase our revenue? Is the revenue worth the engineering costs? Somebody actually needs to think of all these questions, and then come up with the actual data to prove that it's a good idea to do this. And then you have to figure out how you're going to measure that your feature is successful, because if you don't know your metrics before building it, you're setting your product up to fail before it's built.

    Then once you're convinced you should do it, you have to bring all the other teams onboard. If you're a B2B company, you have to convince the Sales org that this feature will increase their sales numbers, or they won't help you sell it, so you won't make your metrics and your product will die. If you're building something completely new in a new market, you have to convince Marketing that it will play into the long-term customer acquisition strategy and they should help you get it off the ground, otherwise nobody on the internet will find your product after you've built it.

    This is just 2 examples, but imagine you have like 10 different teams that optimize for different success metrics, and you're trying to create something new that they all have to agree with. That's the part that engineering doesn't even hear about.

    When Eng gets involved is when the path is cleared up for them to build, and then the PM looks like they're just basically sitting there watching. That's the result of a clear product vision, communicated and broken down for Eng to go and build. There's nothing for the PM to do, cause they've thought of all these questions beforehand, and laid them out in the requirements. They will often sit in and answer questions and provide context about the user and the why of features. So while it looks like they didn't do much, it's cause they've done their homework ahead of time, and know what's a big deal to sweat over, and what isn't.

    And when there are roadmap changes, because now we need to add some extra feature to meet X goal, because a VP threw a fit over it, the PM is the one worrying about what feature to drop to make that happen, and which users to disappoint, and how the new feature will affect the existing features, and the success numbers.

    Leave an engineer alone to make those trade-offs and deal with the politics and they'll rip their hair out. They'll just complain nothing ever gets done in this company and things change all the time, or that they can't get the resources (btw "resources" allocated to a project don't just happen, the PM fights for your team to be dedicated to 1 product so their attention isn't scattered), or that their projects always get killed. Because it's damn hard to figure out what to build from scratch, build a vision for success, back it up with numbers, and convince 10 other teams to do it with you.

    You all know this. How many of us have apps that we are building on the side that just sit there, unused? It's not because they're bad ideas or we're to busy to build them. It's because we don't know where they're supposed to go, and don't have feedback from the real world indicate success or failure, and point to areas of improvement, or figure out how other ppl would use them. Lack of roadmap and PM means engineering teams will spin their wheels and build things that can't meet user needs, or can't be served up to the users that need them in the way that makes sense to them, or build things they believe in and look promising, but have no idea how to prove that they can grow and that it's a good idea to invest more time/money to build them further.

    PM make it so that engineers have clear things to build, uncluttered by everything that's happening in the real world. So that "the user" is understood but the engineering team as a unified, logical concept, while in reality "the users" are a billion people with unique needs. So that "the business" wants X is a coherent story, as opposed to "Alice is really pushing for this feature, but Bob who's more important doesn't agree with it, so it could go either way, but data from our current users supports building it, so we need to build a stronger case so Bob agrees and gives us the extra budget to build feature XYZ earlier because it's a huge dependency".

    And to the engineers reading this - we usually don't tell you what we do, because "it depends", and because on some level, our own heads spin thinking of everything we need to handle so you can be left alone and out of neverending meetings about thing that may or may not change the product direction. We handle literally everything else, and get shit on by every team because there's no way to make every single stakeholder happy, and take the blame and deal with fallouts of decisions and oversights. And it's all so that you can stay focused and motivated, and feel like the heroes. So yeah, you're welcome.
    Apr 28, 2020 25
    • I like this post. As an engineer it gives me insight into what a PM role should be and why it exists, and what all my PM do behind the scenes. I do think the role is valuable especially in large organizations.

      The reality is a bit different though. I disagree though with the part where you mentioned that PM have “all these questions beforehand, and laid them out in the requirements” and have “done their homework ahead of time”, also “When Eng gets involved is when the path is cleared up for them to build”. I think this is where most of the frustrations engineers have comes from. Most of the times the specs I have seen from PM’s are not well thought out, they haven’t thought of all the scenarios, they have this vision of what the product should be, there are tons of holes in this vision, it’s not grounded in reality. Many times I’ve literally had to redefine specs after finding out issues in proposed approach by PM. They do minimal/shallow work in defining the requirements. As an engineer this is the one and only thing I expect a PM to deliver to me, after that it’s my job to actually ship and deliver the feature, so it’s super frustrating to see that one thing screwed up like 70-80% of the time.

      But I can see how all the other functions a PM does that you mentioned get in the way of them not doing a good job at this; attending tons of meetings, politics, interacting with many different functions like sales and marketing, and also often being PM to multiple features. So they are spread thin and hence drop the ball on defining requirements well quite often. And engineers as focussed as they on actually shipping the feature always pick that up. I will try to give my PM’s more slack after reading your post.
      Aug 26, 2021
    • KPMG
      monicabing

      Go to company page KPMG

      monicabing
      It's been 2 years since u posted this but this gave me so much insight than any PM article I've read.

      Hands down best comment in Blind.
      Mar 28
  • Amazon
    sordid

    Go to company page Amazon

    sordid
    Solve bigger problems. You can never do the amount of work by yourself as you can do with a good team.
    Apr 25, 2020 11
    • Toyota: PMs and Eng are just people with knowledge and talents. Both of them are capable of having a multiplying effect on a team. A great PM can move mountains, helping multiple eng teams solve the *right* problems. Engineers aren’t renowned for discovering and solving difficult business problems. This is a PMs job, and it’s hard - especially since, unlike Eng, it’s tough to know if you’ve done it well.

      Funny enough, some of the best PMs I know have a technical background but have business training or interest. Or, at the very least, they talk about technical stuff with proficiency. A big part of their job is to keep the wheels of progress rolling — knowing how to work with engineers and systems should be a required skill at a tech company for PMs.

      Anyway, I’ve seen PMs manage cross functional projects and have a 20x factor. But just like engineers, a bad PM or bad PM work creates debt that inverts this multiplier.

      They’re neither better nor worse. PMs are just filling another necessary role on a team that would otherwise be filled by some charismatic eng basically doing a PM job.
      Apr 27, 2020
    • Apple
      glasceilin

      Go to company page Apple

      glasceilin
      If I wasn't around to PM my project nothing would get built but all the money would be spent. How do I know this? Because when the project had no PM for awhile it fell apart. People were designing the wrong things because they assumed they were talking to the correct business partner or stakeholder. They weren't. I don't assume to know more than IS&T or anyone else at Apple but I do know how to make sure it gets done and everyone is satisfied. That's my job. I don't give a shyt how it's coded if it meets the requirements.
      Sep 15, 2020
  • Dropbox / Eng
    yurlll

    Go to company page Dropbox Eng

    yurlll
    Besides not writing code? Isn’t a downside?
    Apr 24, 2020 15
  • Amazon
    Covid_19

    Go to company page Amazon

    Covid_19
    I mean it does allow you to write emails, take notes and be a secretary to everyone in the program
    Apr 25, 2020 28
    • Apple
      Uodd54

      Go to company page Apple

      Uodd54
      I’m a designer with < 1yr experience and I make 220TC which is more than the new grad eng interns in my cohort
      Nov 11, 2020
    • Apple - that's the most anecdotal example you could come up with :)

      And do you know how much the top <1 yoe new grad engineers make?

      You are probably someone very talented, but as a whole, engineers make (significantly) more than designers at the same level.

      It doesnt make them superior and it doesn't means everyone should wish to be an engineer, but it does probably mean that an equally talented engineer will usually make more than the designer
      Nov 12, 2020
  • Square / Eng
    ctrl-d

    Go to company page Square Eng

    ctrl-d
    PMs are the worst. They're absolutely useless until it's time to take credit.
    Apr 25, 2020 21