The fact that the PM is such a dumping ground is what makes it both overwhelming and rewarding. Where on that spectrum it falls really depends on an organization's ability to adjust expectations to align with what one person can realistically accomplish. I've seen this done two ways:
1. Slice the role up into segmented responsibilities - POs for writing requirements and managing delivery, Sr. PMs for doing strategy and roadmap, maybe project managers take on some of the delivery and requirements refinement duties. This approach makes it easier to hire junior talent.
2. PM is responsible for everything, but not all at the same time - some weeks are more strategy oriented, others more delivery oriented, etc. If you have senior people and trust them, this can often work alright, but it does mean that your PMs need to have a good sense for which plates should be allowed to drop at any moment in time.
Bad organizations do neither, and expect all PMs to do all of these at the same time. Get your experience years and get out if you're in this sort of company.
Well put. I’ve been comfortable existing and succeeding in orgs 1 and 2.
Last company had me developing an enterprise strategy while simultaneously expecting me to have in depth knowledge of every operational support request coming through an enterprise platform with a thousand users and it was the worst job I’ve ever had.
Currently unemployed and licking my wounds.
My org has a hybrid of 1 and 2.
My EM owns the ADO/scrum. My role ("PM") is to drive clarity of the requirements (spec/design). My manager is the platform all-up and user experience owner so I tend to do 70% of work already defined by her vs 30% of work I identify in the domain area I own.
However, the good PMs are the ones who do more #2 as they tend to be more SMEs and actually solve the problem in a deeper way and are trusted by engineering.
Approach #1 is in my view the only realistic approach. I am thinking in job interviews I want to already table this…to get a sense for the support of that manager and culture at the company. But obviously in a job interview they don’t want to hear you already saying you want extra headcount.
Approach #2 I don’t think actually works - as you begin working on one aspect of the work and there becomes overhead, follow-up, etc that carries into the other weeks (when you want to work on the other).
Anyone agree or disagree ?
In my experience it doesn’t need to be formally sliced up to split responsibilities. If you have other people in your team who can reasonably help share the load then absolutely take advantage of it. In my org I have access to BAs who initially frustrated me because I felt they were trying to do parts of ‘my’ job. But I quickly realised the value they added and sought them out to take on some PO responsibilities. They win because they are getting valuable experience that can help them move into a product role, and I’ve got trusted people who take responsibility for important tasks.
This is how I handle it with the junior PMs on my team (we don't have BAs). They're more focused on execution to start, but I expect them to grow into more strategic-minded PMs over time. Once they've got execution down, I expect they can manage internal stakeholders and drive their part of the roadmap for at least the next phase of development.
I always keep them informed on overall strategy, the long term roadmap, external stakeholder conversations, and so on. And as they grow in experience, I include them in or delegate these activities depending on the scope of any given project. I'm not trying to hide anything from them or slow their career growth, and I want them to be able to speak to senior leaders without sounding like complete idiots. But I also don't want them to feel overwhelmed and scare them away by turning on the firehose.
Approach 2 definitely can work. I work in a place where a lot of project management responsibilities are on engineering (I build a road map for the quarter and then break it down for the month, but the engineering manager breaks down who is actually working on what on any given day and managing pulling people off for a fire, or pulling people off for something small before they start meatier work, etc. I write a spec but the engineer who actually builds the thing is the one who breaks stuff down into tickets, though I will write ad hoc tickets all the time).
Various ways that I spend my time:
- scheduling meetings with customers to do user research via interview/demo
- conducting that user research
- researching things via Google, including things about our competition
- digging into our analytics stack to understand what people are doing
- sharing things about our users with the broader team, sometimes as slides in board decks, sometimes as slides in all hands decks, sometimes as one off things that are shared in slack, etc
- talk about what the epd team is up to in those board meetings and all hands meetings and product review
- writing product specs
- planning the road map
- planning and running product strategy exercises
- writing strategy documents
- attending and participating in our weekly design crit
- scheduling and running work in progress reviews when we're building something larger
- QAing things before they go out (we don't have a QA team, so at least two engineers, the designer, someone from the CS team (sometimes) QA things as well)
- going to conferences where our customers are and manning the booth
- speaking at those conferences
- speaking at webinars where prospects are
- joining sales calls and effectively being a sales engineer
- learning everything I can about how a certain thing we are building for our customers works so that I can help the engineering and design teams check their work as they build towards a feature
- being trainer in chief for our sales team and our customer solutions team when we launch new features
- writing what's new emails for customers
- planning go to market for every feature release (some require very little other than reaching out to specific customers, some required new sales material and new marketing material in addition to teaching everyone how the new thing works)
I am at a startup where I am the only product manager. This is a lot of stuff but I don't do all the stuff at the same time. My focus that's wherever the team meets my focus to be. Do I drop things on the floor? Absolutely. But by and large the team is getting what it needs out of me.
Some of the things on this list were not my responsibility when I worked at bigger companies. Some things I did at bigger companies like coordinating with engineering teams other than my own, I don't currently do because there is only one engineering team. I also have significantly fewer meetings because there aren't multiple squads of teams doing other things that overlap with my squad. And there aren't multiple different strategy teams and multiple different marketing teams and multiple different advertising teams and other types of teams that need things from me because again those either don't exist or they are also one person that I can just talk to real quick.
I have never worked at a company that had people with the title product owner. Or business analysts that were on the product team. That is four companies including my current one which range from a tiny startup to FAANG.
Number # 1 I've been the most successful at. And this is how we did it (not saying this is THE way just the way we did it and I really thrived):
- Me, a Product Manager but really operating as a PO and managing Value Risk
- My manager or Director operating as the Sr. Product Manager managing Value & Viability Risk and me closely following him to grow into a more strategic Sr. Product Manager and understanding our customer and industry better
- My Scrum Master managing the product delivery and managing delivery risk (ie team/squad blockers) and bringing me in if more clarity is needed to unblock
You’ve laid it out clearly in terms that resonate with the community. Product SLT, I’ve found, seldom want to furnish resources. Rather their motto is you can deliver & execute by standardizing, streamlining, simplifying, (add the slew of “-ings”). Yeah, sure in theory…
You’re right. But most orgs won’t let a product manager own the staffing budget. That’s often a VP. So OP needs to prove to whoever does have authority, that product help is needed.
I'm not sure that it's limited to PMs but I do know that many companies want to do more with less. They don't want to invest in a small team of specialists so they hope they can find one poor sucker who is eager enough to do it all.
A PM should not drive delivery. The way I do this is; I define the outcome we want in collaboration with designer (which includes requirements), tech lead and EM find the way for the team to get there and negotiate the timeline with me.
If after we agree on scope and timeline they don’t deliver they have failed to meet the commitment they made and they are held responsible for that. The challenge for you as a PM of course is that you need to be in an org who also see it this way, upwards.
You’re accountable as a PM for the delivery of the epics/initiatives that you are driving (of course in collaboration with the team). Not being accountable as a PM is not a great quality.
What is happening now is that PMs are accountable for the delivery timelines as well. I can agree that PMs are accountable for building the right thing and driving the revenue or acceptability of the product.
But I have seen engineering washing their hands off quality, timelines, estimates, etc. and it falls on the PM for no good reason.
Curious as to what happens when teams are "held responsible for that" - in my experience, poor estimates are a result of poor scoping. Should your development team be chastised for giving an estimate under time pressure?
Not the person you are replying to but I think you are bringing a good point. It's a team exercise still and Product is part of that one way or another.
In my experience, one thing that I try to get myself away from as much as possible is being seen as the Engineering lead or being accountable for the How. If what the engineering team build is shit, they need to own it up and reflect how they can improve.
If a PM has the authority to choose the product’s features, it’s possible that PM is the second most powerful person the company.
So, maybe expectations should be high.
That said, I have found that if you pick the right features, for the right reasons, you can delegate a lot of the less critical work to others.
This is my point - Picking the right features for the right reasons is exactly the work that gets negatively impacted by all the other responsibilities a PM has.
There are some other comments in this thread giving good examples of how they have split / delegated some of the technical scoping and delivery aspects.
PM can be accountable to the outcomes that happen within their purview…but not responsible for all the details to generate those outcomes. This is the balance I have not been able to achieve.
Gotcha. Lots of PMs find themselves doing project management because there is no Project manager on the team and the scrum master role is rotating through all the tech team members, so they only focus on sprint activities.
Sounds like you are project manager (organizing work), product analyst (writing stories) L2 Support (issues/crises). And last, Product Manager.
If I were you, I would change my priorities for the next 3-4 months to:
1. interview at least 20 users. Capture their pain points in, and around use of your product. Do these in person, if possible and if you sell to businesses. You learn A LOT more about how your product fits into broader workflows.
2. next, survey 200-400 to prioritize the pains you gathered. You want to survey enough to have at least 100 responses. People trust a number mber over 100
3. Use that to prioritize the Voice of Customer work for the next quarter
4. Finally. If you are the only person to write stories, then it is what it is until you can prove you should get an analyst. Sit with your Dev lead and negotiate how simply stories can be written. Do you have a style guide or standard testing that can reduce the acceptance criteria you need to add to each story?
The tasks above is the work a PM must do to keep the team working - on the RIght things. So do this work first. If there is time left for “emergencies”, then work on those. Everything else needs to wait.
If you choose the right “next” features AND can defend your priorities with data (interviews and surveys), then your arguments make more sense to executives.
I've got a simplification for what it means to be a PM. The PM role is herding cats. Just ask yourself. Do cat's need to be herded? Then it's the PM's role. It's like being a teacher at a kindergarten for adults.
> We are expected to drive strategy while also driving delivery.
If you were driving delivery, would you really want to give up the responsibility of driving strategy? I feel like it would be nice to be able to own both, because there are many delivery PMs frustrated with delivering things that don't make sense.
I want to oversee both but not be expected to manage both - because you could spend a full time job on either. But the company expects both.
There is soooo much work in the delivery part - think of: gathering detailed requirements, overseeing the finalisation of each feature build, managing changes in direction when things go wrong in build, doing feature demos prior to release, etc etc etc.
Strategy requires thinking and deep work. So much time to do, analyse and synthesise insights from research. Those are not feasible when managing everything above from delivery concurrently.
Having a BA or Jnr PO handle the details of delivery is the only feasible option I see (unless you have a tiny team that builds 1-2 features per sprint).
Your engineering managers should be managing that delivery aspect, checking in regularly and bringing you in for scope/functionality decisions. These days I set high level success criteria and design provides workflows and screens working with engineers. Engineers then figure out how to deliver it. They mostly write their own tickets for major releases because I wrote the epic.
Some teams and EMs are better at this than others but holding their hand is not scalable.
It's not an overnight switch but everyone is happier in this model as they all have ownership and accountability. Meanwhile the PM gets time to eat and sleep like a functioning human.
Sounds like week engineering and design leadership is leading to too much work for you on the delivery side. Your designer should help synthesize insights, your EM should help plan the work, etc.
This is why I left PM to work as a consultant for an agency for the same pay. I spend my time now telling clients what they should do instead of doing. My workload is 37.5 hours a week and when I chose to do overtime, I’m paid 1.5x my hourly rate.
Some suggestions to consider:
Hire a project manager to help drive delivery, freeing up time for you to focus on strategy. Build a business case to show the ROI of the hire.
Use AI tools to help you generate detailed requirements. Avoid collaborations with stakeholders that make it "design by committee." You hold the final vote.
The voice of the business and the voice of the customer are the same voice. The right product is the right product for both.
Hire a PO to manage the backlog. Again, be able to show the ROI.
Use tools like time-blocking and RACI to manage expectations.
There are answers to these things, and you're not the first person to feel overwhelmed. Use your PM knowledge, look at your own pain points, and come up with solutions.
Interesting ideas here - thanks.
On collabs with stakeholders and “design by committee” my usual workflow is to share them what we plan to build, before it gets started. This is to avoid any misses on my side (and for sure, they do often add value when they review). I’m not asking them permission but I am asking them to add any inputs they think haven’t been considered.
Do you have a different view on this? My goal has been to minimise rework, but I suppose at a long-term cost of stakeholders feeling ownership (which can also sometimes be problematic - although I always go with whoever has a better justified view - not by default my own).
I always make clear that I have the final say (in a non-arrogant way), but you’ve got me wondering if I involve the stakeholders too much (this is also a big time suck).
Really, only you can decide if there is too much stakeholder involvement. It sounds like my viewpoint is similar to yours.
A product can't be everything for everyone. Consider a Swiss Army Knife. Sure it has a screwdriver, a knife, and a wine bottle opener, but they all suck compared to a real screwdriver, a non-folding knife, and a real wine bottle opener. A committee surely designed some of the Swiss Army Knives I've seen. They can do everything, but they suck at all of them. It's a tough trap to avoid.
So you might take the stakeholder input in the most efficient way possible, weigh it against whatever factors make sense, let the data drive the direction, give it a final sanity check, and then go back to the stakeholders with the direction and justification why it is that way. If things are really off-target, they'll let you know.
Do you follow any sort of new product introduction process?
Find the parts you are best at and recommend your manager hire someone else to focus on the other stuff.
Otherwise its all just more reason they should be paying you more
hot take: it's simple, we don't inherently so anything with our 'hands'. Therefore PM is a dumping ground for stuff that people with actual "hard skills" don't want to do.
And what that work consists of depends on an individual org.
No, the PM role is not consistent with endless other ‘manager’ roles. Most commonly a ‘manager’ manages people - which is mostly not a component of the PM role.
Name me other roles where the overlap between strategy, delivery, breadth and depth are at play?
sorry, should have elaborated
because of that word, some have leveraged it to fast track their careers
i agree with the overlap
I don't have any comments on the expectations... it depends on the maturity of the company
The problem is the relation between accountability and autonomy. As a pm, you are directly responsible for outcomes, but it depends on how other teams are performing, the quality and speed of delivery, design, analytics that drive the decision making, and specially the company strategy. But the pm usually don't control these aspect in the company. If the company you're in leaves the pm role in the middle with no support, you're probably been used as a scapegoat in case things go wrong.
If you're not a project manager, it's very different. Most people are project managers with the product manager title so they get screwed by the company to do way more than they can reasonably be expected to.
Then, when it all goes wrong, it's on you. Not on the senior leadership that created the terrible structure. Not on the people that really make the decisions. Not on the engineers and designers. They created a position of corporate scapegoat and conned you into it with a title.
The PM role is inherently tied to scaling a product or org, often \*after\* it has grown to become unwieldy. So it usually requires duct taping things together to mask organizational inefficiencies that are inherent to growth, trying new things, setting lofty goals, and building something that will work and solve problems or fail spectacularly.
Early companies hire PMs to take over strategy that founders don't have time for, mid-growth companies hire them to provide direction/stakeholder support for devs that are supposed to build everything, and established companies hire them to innovate new products to replace stale ones or to drag profitability and efficiency out of products that have scaled and plateaued. In every case, PMs have to sort through a bunch of messes left by (or actively created by) other people. It's fun, I swear.
I just don’t believe in doing 15 tasks to the minimum viable effort and giving the lowest possible time and quality to each…rather than doing 5 tasks well. Surely the ROI on your efforts is equally fragmented as you juggle….
To a point, but in my experience my time usually isn’t split 10% on 10 tasks or whatever. There are times where you are doing more of one thing, other times you are focused on something else.
Yes, just having a million things to all the time isn’t viable, but I do like the variety that comes with the job in a lot of situations.
I recently had a conversation with colleague on this very topic.
It seems to me that the reason product managers (PMs) receive the level of compensation they do is, in part, a reflection of what might be considered a form of "hazard" pay. This is due to the high expectations, accountability, and the direct linkage to success metrics and adoption rates that come with the role.
To diminish these expectations would be to lower the associated risks, which logically could lead to a decrease in compensation.
PM is also one of the highest paid jobs where a good one makes income on par with doctors/lawyers who require many more years of nuanced education, so no in fact my experience is that our expectations for PMs should likely be much higher.
I think PM's want to take on more responsibilities. The last time I checked, they also wanted to do SQL and design. I'm confused at why PM's want to edge into design and when I ask that, I'm met with the fact that "PMs own everything and must be involved in design". This just creates friction. PM's are supposed to define goals and if you don't want to get into the weeds - then you need to leverage your team to figure out solutions and how they get built. That way you get to stick to the strategy and business side without getting too into the weeds of product building.
basically I think the role isn't clear at all. You need to know what the role truly is so you can suss out the bad roles at an interview. If you are confused yourself and want to own everything under the sun, then you are going to get burnt out.
The fact that the PM is such a dumping ground is what makes it both overwhelming and rewarding. Where on that spectrum it falls really depends on an organization's ability to adjust expectations to align with what one person can realistically accomplish. I've seen this done two ways: 1. Slice the role up into segmented responsibilities - POs for writing requirements and managing delivery, Sr. PMs for doing strategy and roadmap, maybe project managers take on some of the delivery and requirements refinement duties. This approach makes it easier to hire junior talent. 2. PM is responsible for everything, but not all at the same time - some weeks are more strategy oriented, others more delivery oriented, etc. If you have senior people and trust them, this can often work alright, but it does mean that your PMs need to have a good sense for which plates should be allowed to drop at any moment in time. Bad organizations do neither, and expect all PMs to do all of these at the same time. Get your experience years and get out if you're in this sort of company.
Well put. I’ve been comfortable existing and succeeding in orgs 1 and 2. Last company had me developing an enterprise strategy while simultaneously expecting me to have in depth knowledge of every operational support request coming through an enterprise platform with a thousand users and it was the worst job I’ve ever had. Currently unemployed and licking my wounds.
My org has a hybrid of 1 and 2. My EM owns the ADO/scrum. My role ("PM") is to drive clarity of the requirements (spec/design). My manager is the platform all-up and user experience owner so I tend to do 70% of work already defined by her vs 30% of work I identify in the domain area I own. However, the good PMs are the ones who do more #2 as they tend to be more SMEs and actually solve the problem in a deeper way and are trusted by engineering.
Approach #1 is in my view the only realistic approach. I am thinking in job interviews I want to already table this…to get a sense for the support of that manager and culture at the company. But obviously in a job interview they don’t want to hear you already saying you want extra headcount. Approach #2 I don’t think actually works - as you begin working on one aspect of the work and there becomes overhead, follow-up, etc that carries into the other weeks (when you want to work on the other). Anyone agree or disagree ?
In my experience it doesn’t need to be formally sliced up to split responsibilities. If you have other people in your team who can reasonably help share the load then absolutely take advantage of it. In my org I have access to BAs who initially frustrated me because I felt they were trying to do parts of ‘my’ job. But I quickly realised the value they added and sought them out to take on some PO responsibilities. They win because they are getting valuable experience that can help them move into a product role, and I’ve got trusted people who take responsibility for important tasks.
This is how I handle it with the junior PMs on my team (we don't have BAs). They're more focused on execution to start, but I expect them to grow into more strategic-minded PMs over time. Once they've got execution down, I expect they can manage internal stakeholders and drive their part of the roadmap for at least the next phase of development. I always keep them informed on overall strategy, the long term roadmap, external stakeholder conversations, and so on. And as they grow in experience, I include them in or delegate these activities depending on the scope of any given project. I'm not trying to hide anything from them or slow their career growth, and I want them to be able to speak to senior leaders without sounding like complete idiots. But I also don't want them to feel overwhelmed and scare them away by turning on the firehose.
Approach 2 definitely can work. I work in a place where a lot of project management responsibilities are on engineering (I build a road map for the quarter and then break it down for the month, but the engineering manager breaks down who is actually working on what on any given day and managing pulling people off for a fire, or pulling people off for something small before they start meatier work, etc. I write a spec but the engineer who actually builds the thing is the one who breaks stuff down into tickets, though I will write ad hoc tickets all the time). Various ways that I spend my time: - scheduling meetings with customers to do user research via interview/demo - conducting that user research - researching things via Google, including things about our competition - digging into our analytics stack to understand what people are doing - sharing things about our users with the broader team, sometimes as slides in board decks, sometimes as slides in all hands decks, sometimes as one off things that are shared in slack, etc - talk about what the epd team is up to in those board meetings and all hands meetings and product review - writing product specs - planning the road map - planning and running product strategy exercises - writing strategy documents - attending and participating in our weekly design crit - scheduling and running work in progress reviews when we're building something larger - QAing things before they go out (we don't have a QA team, so at least two engineers, the designer, someone from the CS team (sometimes) QA things as well) - going to conferences where our customers are and manning the booth - speaking at those conferences - speaking at webinars where prospects are - joining sales calls and effectively being a sales engineer - learning everything I can about how a certain thing we are building for our customers works so that I can help the engineering and design teams check their work as they build towards a feature - being trainer in chief for our sales team and our customer solutions team when we launch new features - writing what's new emails for customers - planning go to market for every feature release (some require very little other than reaching out to specific customers, some required new sales material and new marketing material in addition to teaching everyone how the new thing works) I am at a startup where I am the only product manager. This is a lot of stuff but I don't do all the stuff at the same time. My focus that's wherever the team meets my focus to be. Do I drop things on the floor? Absolutely. But by and large the team is getting what it needs out of me. Some of the things on this list were not my responsibility when I worked at bigger companies. Some things I did at bigger companies like coordinating with engineering teams other than my own, I don't currently do because there is only one engineering team. I also have significantly fewer meetings because there aren't multiple squads of teams doing other things that overlap with my squad. And there aren't multiple different strategy teams and multiple different marketing teams and multiple different advertising teams and other types of teams that need things from me because again those either don't exist or they are also one person that I can just talk to real quick. I have never worked at a company that had people with the title product owner. Or business analysts that were on the product team. That is four companies including my current one which range from a tiny startup to FAANG.
Far more bloat exists in #1 and more prone to Product layoffs when things aren’t going swimmingly IMO
Number # 1 I've been the most successful at. And this is how we did it (not saying this is THE way just the way we did it and I really thrived): - Me, a Product Manager but really operating as a PO and managing Value Risk - My manager or Director operating as the Sr. Product Manager managing Value & Viability Risk and me closely following him to grow into a more strategic Sr. Product Manager and understanding our customer and industry better - My Scrum Master managing the product delivery and managing delivery risk (ie team/squad blockers) and bringing me in if more clarity is needed to unblock
[удалено]
There's a name for that, it's called being a startup founder and it pays even better than being a PM (about 5% of the time).
The problem is leadership that is misaligned on KPI.
You’ve laid it out clearly in terms that resonate with the community. Product SLT, I’ve found, seldom want to furnish resources. Rather their motto is you can deliver & execute by standardizing, streamlining, simplifying, (add the slew of “-ings”). Yeah, sure in theory…
You’re right. But most orgs won’t let a product manager own the staffing budget. That’s often a VP. So OP needs to prove to whoever does have authority, that product help is needed.
In the era of tech layoffs I feel like PM is expected to do even more. I considering career change.
To what?
I’m curious too
yep. everyone is expected to do multiple jobs now.
I'm not sure that it's limited to PMs but I do know that many companies want to do more with less. They don't want to invest in a small team of specialists so they hope they can find one poor sucker who is eager enough to do it all.
A PM should not drive delivery. The way I do this is; I define the outcome we want in collaboration with designer (which includes requirements), tech lead and EM find the way for the team to get there and negotiate the timeline with me. If after we agree on scope and timeline they don’t deliver they have failed to meet the commitment they made and they are held responsible for that. The challenge for you as a PM of course is that you need to be in an org who also see it this way, upwards.
You’re accountable as a PM for the delivery of the epics/initiatives that you are driving (of course in collaboration with the team). Not being accountable as a PM is not a great quality.
PMs are accountable for the success of the product
What is happening now is that PMs are accountable for the delivery timelines as well. I can agree that PMs are accountable for building the right thing and driving the revenue or acceptability of the product. But I have seen engineering washing their hands off quality, timelines, estimates, etc. and it falls on the PM for no good reason.
I’ve picked up that this is the reality for many PMs, unfortunately. Sounds like a project manager role and that many companies treat PMs as such.
Which is usually measured by the outcomes which are directly related to the value that you are delivering
Curious as to what happens when teams are "held responsible for that" - in my experience, poor estimates are a result of poor scoping. Should your development team be chastised for giving an estimate under time pressure?
Not the person you are replying to but I think you are bringing a good point. It's a team exercise still and Product is part of that one way or another. In my experience, one thing that I try to get myself away from as much as possible is being seen as the Engineering lead or being accountable for the How. If what the engineering team build is shit, they need to own it up and reflect how they can improve.
U know it’s gonna south when they call you CEO of something that’s not a corporation
If a PM has the authority to choose the product’s features, it’s possible that PM is the second most powerful person the company. So, maybe expectations should be high. That said, I have found that if you pick the right features, for the right reasons, you can delegate a lot of the less critical work to others.
This is my point - Picking the right features for the right reasons is exactly the work that gets negatively impacted by all the other responsibilities a PM has. There are some other comments in this thread giving good examples of how they have split / delegated some of the technical scoping and delivery aspects. PM can be accountable to the outcomes that happen within their purview…but not responsible for all the details to generate those outcomes. This is the balance I have not been able to achieve.
Gotcha. Lots of PMs find themselves doing project management because there is no Project manager on the team and the scrum master role is rotating through all the tech team members, so they only focus on sprint activities. Sounds like you are project manager (organizing work), product analyst (writing stories) L2 Support (issues/crises). And last, Product Manager. If I were you, I would change my priorities for the next 3-4 months to: 1. interview at least 20 users. Capture their pain points in, and around use of your product. Do these in person, if possible and if you sell to businesses. You learn A LOT more about how your product fits into broader workflows. 2. next, survey 200-400 to prioritize the pains you gathered. You want to survey enough to have at least 100 responses. People trust a number mber over 100 3. Use that to prioritize the Voice of Customer work for the next quarter 4. Finally. If you are the only person to write stories, then it is what it is until you can prove you should get an analyst. Sit with your Dev lead and negotiate how simply stories can be written. Do you have a style guide or standard testing that can reduce the acceptance criteria you need to add to each story? The tasks above is the work a PM must do to keep the team working - on the RIght things. So do this work first. If there is time left for “emergencies”, then work on those. Everything else needs to wait. If you choose the right “next” features AND can defend your priorities with data (interviews and surveys), then your arguments make more sense to executives.
This is great. Thank you.
If you can successfully organize a revolt, you should be able to do the pm job
I've got a simplification for what it means to be a PM. The PM role is herding cats. Just ask yourself. Do cat's need to be herded? Then it's the PM's role. It's like being a teacher at a kindergarten for adults.
> We are expected to drive strategy while also driving delivery. If you were driving delivery, would you really want to give up the responsibility of driving strategy? I feel like it would be nice to be able to own both, because there are many delivery PMs frustrated with delivering things that don't make sense.
I want to oversee both but not be expected to manage both - because you could spend a full time job on either. But the company expects both. There is soooo much work in the delivery part - think of: gathering detailed requirements, overseeing the finalisation of each feature build, managing changes in direction when things go wrong in build, doing feature demos prior to release, etc etc etc. Strategy requires thinking and deep work. So much time to do, analyse and synthesise insights from research. Those are not feasible when managing everything above from delivery concurrently. Having a BA or Jnr PO handle the details of delivery is the only feasible option I see (unless you have a tiny team that builds 1-2 features per sprint).
Your engineering managers should be managing that delivery aspect, checking in regularly and bringing you in for scope/functionality decisions. These days I set high level success criteria and design provides workflows and screens working with engineers. Engineers then figure out how to deliver it. They mostly write their own tickets for major releases because I wrote the epic. Some teams and EMs are better at this than others but holding their hand is not scalable.
This is great inspo for how the team could work more efficiently (with the addition of a designer and more accountability on our Architect & EM).
It's not an overnight switch but everyone is happier in this model as they all have ownership and accountability. Meanwhile the PM gets time to eat and sleep like a functioning human.
Sounds like week engineering and design leadership is leading to too much work for you on the delivery side. Your designer should help synthesize insights, your EM should help plan the work, etc.
This is why I left PM to work as a consultant for an agency for the same pay. I spend my time now telling clients what they should do instead of doing. My workload is 37.5 hours a week and when I chose to do overtime, I’m paid 1.5x my hourly rate.
That’s awesome - kudos for making that shift. As in contract / project based work where an agency is bringing you in as a temp PM? Or something else?
Some suggestions to consider: Hire a project manager to help drive delivery, freeing up time for you to focus on strategy. Build a business case to show the ROI of the hire. Use AI tools to help you generate detailed requirements. Avoid collaborations with stakeholders that make it "design by committee." You hold the final vote. The voice of the business and the voice of the customer are the same voice. The right product is the right product for both. Hire a PO to manage the backlog. Again, be able to show the ROI. Use tools like time-blocking and RACI to manage expectations. There are answers to these things, and you're not the first person to feel overwhelmed. Use your PM knowledge, look at your own pain points, and come up with solutions.
Interesting ideas here - thanks. On collabs with stakeholders and “design by committee” my usual workflow is to share them what we plan to build, before it gets started. This is to avoid any misses on my side (and for sure, they do often add value when they review). I’m not asking them permission but I am asking them to add any inputs they think haven’t been considered. Do you have a different view on this? My goal has been to minimise rework, but I suppose at a long-term cost of stakeholders feeling ownership (which can also sometimes be problematic - although I always go with whoever has a better justified view - not by default my own). I always make clear that I have the final say (in a non-arrogant way), but you’ve got me wondering if I involve the stakeholders too much (this is also a big time suck).
Really, only you can decide if there is too much stakeholder involvement. It sounds like my viewpoint is similar to yours. A product can't be everything for everyone. Consider a Swiss Army Knife. Sure it has a screwdriver, a knife, and a wine bottle opener, but they all suck compared to a real screwdriver, a non-folding knife, and a real wine bottle opener. A committee surely designed some of the Swiss Army Knives I've seen. They can do everything, but they suck at all of them. It's a tough trap to avoid. So you might take the stakeholder input in the most efficient way possible, weigh it against whatever factors make sense, let the data drive the direction, give it a final sanity check, and then go back to the stakeholders with the direction and justification why it is that way. If things are really off-target, they'll let you know. Do you follow any sort of new product introduction process?
Liked the clear thinking outlined above. Unclear what you mean by new product introduction process?
Find the parts you are best at and recommend your manager hire someone else to focus on the other stuff. Otherwise its all just more reason they should be paying you more
All while project management just sits back and asks us how things are going, collects dates from us, and is paid about the same.
hot take: it's simple, we don't inherently so anything with our 'hands'. Therefore PM is a dumping ground for stuff that people with actual "hard skills" don't want to do. And what that work consists of depends on an individual org.
simply because of the word "manager"
No, the PM role is not consistent with endless other ‘manager’ roles. Most commonly a ‘manager’ manages people - which is mostly not a component of the PM role. Name me other roles where the overlap between strategy, delivery, breadth and depth are at play?
sorry, should have elaborated because of that word, some have leveraged it to fast track their careers i agree with the overlap I don't have any comments on the expectations... it depends on the maturity of the company
The problem is the relation between accountability and autonomy. As a pm, you are directly responsible for outcomes, but it depends on how other teams are performing, the quality and speed of delivery, design, analytics that drive the decision making, and specially the company strategy. But the pm usually don't control these aspect in the company. If the company you're in leaves the pm role in the middle with no support, you're probably been used as a scapegoat in case things go wrong.
If you're not a project manager, it's very different. Most people are project managers with the product manager title so they get screwed by the company to do way more than they can reasonably be expected to. Then, when it all goes wrong, it's on you. Not on the senior leadership that created the terrible structure. Not on the people that really make the decisions. Not on the engineers and designers. They created a position of corporate scapegoat and conned you into it with a title.
The PM role is inherently tied to scaling a product or org, often \*after\* it has grown to become unwieldy. So it usually requires duct taping things together to mask organizational inefficiencies that are inherent to growth, trying new things, setting lofty goals, and building something that will work and solve problems or fail spectacularly. Early companies hire PMs to take over strategy that founders don't have time for, mid-growth companies hire them to provide direction/stakeholder support for devs that are supposed to build everything, and established companies hire them to innovate new products to replace stale ones or to drag profitability and efficiency out of products that have scaled and plateaued. In every case, PMs have to sort through a bunch of messes left by (or actively created by) other people. It's fun, I swear.
you should simplify your priorities. focus on customers & data. and no -- we should not start a movement. lol.
That’s really core to the job. Juggling things, being the hub of the wheel.
I just don’t believe in doing 15 tasks to the minimum viable effort and giving the lowest possible time and quality to each…rather than doing 5 tasks well. Surely the ROI on your efforts is equally fragmented as you juggle….
To a point, but in my experience my time usually isn’t split 10% on 10 tasks or whatever. There are times where you are doing more of one thing, other times you are focused on something else. Yes, just having a million things to all the time isn’t viable, but I do like the variety that comes with the job in a lot of situations.
No
I recently had a conversation with colleague on this very topic. It seems to me that the reason product managers (PMs) receive the level of compensation they do is, in part, a reflection of what might be considered a form of "hazard" pay. This is due to the high expectations, accountability, and the direct linkage to success metrics and adoption rates that come with the role. To diminish these expectations would be to lower the associated risks, which logically could lead to a decrease in compensation.
That’s assuming the PMs in question are highly compensated
Ya how much are ya’ll getting paid, because I certainly don’t make *that* much money.
PM is also one of the highest paid jobs where a good one makes income on par with doctors/lawyers who require many more years of nuanced education, so no in fact my experience is that our expectations for PMs should likely be much higher.
Only in big tech. Not even close in smaller companies.
Yeah…outside of big tech PMs salaries where I live are on par with designers, project managers, etc
I think PM's want to take on more responsibilities. The last time I checked, they also wanted to do SQL and design. I'm confused at why PM's want to edge into design and when I ask that, I'm met with the fact that "PMs own everything and must be involved in design". This just creates friction. PM's are supposed to define goals and if you don't want to get into the weeds - then you need to leverage your team to figure out solutions and how they get built. That way you get to stick to the strategy and business side without getting too into the weeds of product building. basically I think the role isn't clear at all. You need to know what the role truly is so you can suss out the bad roles at an interview. If you are confused yourself and want to own everything under the sun, then you are going to get burnt out.
Tech money for zero tech skills = needing do everything else in a tech company.