5 ms·

Sounds a lot more like a project or program manager than a product manager.

• ajkjk 3y ago
  Nevertheless it is the role called "product manager" at many companies.
• moandcompany 3y ago
  And ironically it seem like the things you'd positively attribute here to a product manager used to be/are actually part of the scope of what was traditionally a "project manager" or "program manager." For example, look at the scope and definition of a "program manager" from Microsoft or the US DoD in the 1980s, 1990s+, as well as literature describing the role of a program manager and the discipline from that time.
  • lukevp 3y ago
    Why’s that ironic? There didn’t used to be frontend / backend / full stack devs either. As software engineering has matured and grown in scale, more subdivision of responsibilities is a natural outcome of that. We’re not all just directly writing code on mainframes and our customers aren’t just < 1k of users who directly call us on the phone if something goes wrong anymore, it’s millions of people using services 24x7 now. MS wasn’t making real-time collaboration systems and cloud sync in the 80s and 90s. They were making a stand-alone offline machine that barely could install device drivers and didn’t know what the internet was. Completely different products, and much simpler.
    • pseudalopex 3y ago
      What subdivision of responsibilities? Clients and servers were divided for as long as clients and servers existed. Full stack is aggregation of responsibilities. DevOps too. Dedicated QA is rare now. Most companies with product managers have fewer customers and less complex products than 1990s Microsoft.
• sanderjd 3y ago
  Yep, a common pitfall is to not understand how product managers are supposed to do, and thus they just do project management, which often has neutral or negative value.
  • marcosdumay 3y ago
    I've seen competent project managers work very hard to achieve that neutral-value proposition. I haven't yet seen any one succeed. In my experience, as soon as you decide your projects will be formal and managed, you are already doomed to that negative value.
    • midasuni 3y ago
      Sometimes you need a formal project. We’re kitting out a new office over the next couple of years, it’s a major programme of multiple projects, all which interact. At the end of it though we have a building fit for purposes following the plans currently set. I’m sure those plans will adjust a little, but the end date is January 2025, or July, or something - I’m sure the date will slip. You can’t build a £20m facility with a series of sprints.
      • marcosdumay 3y ago
        Well, the Empire State Building was famously built as a series of sprints... You need a formal design. This doesn't mean you need a formal project. Some amount of planning ahead very obviously helps, but how much is debatable, and when you have people whose sole specialization is "planning ahead", you are certainly past the point where it's too much. Anyway, the most valuable people are the ones "planning behind", looking for what was left broken and could be done better from now on. Project management defines those people out of existence.
        • trog 3y ago
          Think of the "formal project" is the API by which executing the design can be understood by all stakeholders. It is a high level abstraction that allows all parties to understand what they need to do and when they need to do it. For large projects it is simply essential - you need your external vendors to plan their availability, months or sometimes years in ahead, so that they can commit to the timeline. If you're lucky enough to work on large software projects where there are no managers or other stakeholders asking "and how long will this take, exactly?" then maybe the design is enough. But pretending planning ahead on large projects that is something that will just happen by osmosis or people "just doing it" simply won't work. Good project managers who do what they're supposed to are worth their weight in gold (just like good product managers).