image description:
a girl is smiling in front of the camera, not directly looking at it. in front of her is a big cake. the text on her reads, "PM showing off latest features"
just on the left and a little behind is a guy, out of focus, blankly staring at the cake. the text on him reads, "dev getting 0 credit"
Hate this. I work as a PO. Praise my devs every chance I get both internally and towards our clients. Always pass on positive feedback and use negative feedback only translated into priority weights.
I see my job as keeping stakeholders at bay and let them do their job. I bundle requests into feature requests that cover as many current and future needs as possible, but never without internal meetings first.
Just getting sales to stop making deals on feature requirements with clients was a very long uphill battle that we have mostly won. Now it all goes through my team first and we always do estimates with our development teams. Takes a bit of time, takes a bit longer, but never have I seen a client get back to us with the same urgency as they request a quote anyway. If they can not wait a week, they won't be a good fit for what we are doing and how we do things.
I once had a sales-bro tell the client we'd "monitor the internet for X". That has remained one of the most important hammers for me to wield when discussions even start coming up. How the fuck does one "monitor the internet" to a degree that fits the clients interpretation of this phrase. Sales guy is still with us and a good lad, he owns that mistake. But fuck was it ever crazy.
Yes, it's fun when you make an estimate and planning for the lastest sale and it turned out the three weeks sold is three months of work. No, I don't care what you promised, it'll be ready in three months. Ask for an estimate before you make that promise next time.
We've decoupled timelines from estimates almost entirely and to the ire of all our sales and C-Level only give out Quarter based estimates anymore. "End of Q3 or early Q4". When we deliver mid Q3, everyone is happy. The funny bit is that since we've made these changes, we've not noticed any drop in client interest at all. What we do notice is that we actually ship what we promise (sometimes even more). We also don't have clients who think we'll do 10 hours of work for free anymore, because we've anchored the value of every little bit we do properly. We also filter the stingy clients who are completely pointless and are just wasting our time, while engaged with our competitors.
There's a lot, a looooot of FOMO in sales on the side of our own sales people. So they lowball their shit to make sure we close. Then we can't keep what's promised and nobody is happy and contracts that would only be profitable after like 3 years don't get renewed and we lose a client. Great stuff. Then try and get them back after a shitty experience like that.
I'm a PM in a different field (science stuff). If anyone asked me to present on behalf of the science team, I would say no. It's their work. Managing a team and timelines and budget does not mean I do the work. I think this is why when job searching I get a lot of interviews with dev and other tech. They just want competent managers. Some of them, anyway.
In swoops the project team to sign a contract with a software vendor without any architectural or Product input, then expects you to implement changes for whatever the software does and however it works. They do not know.
Eh, I don't want to present features to stakeholders. It's pretty thankless, in my experience. The real worthwhile merit is in presenting architecture designs and reviews to tech leadership.
In my current project, we hold reviews together with our customer, because supposedly they work together with us on this project (they have done nothing of value since project start).
And it's so miserable, because among us colleagues, we really don't know what everyone else actually developed, because you obviously don't want to go into deep technical discussions, nor be too critical, when the customers all sit there.
In every dev job I've ever held it's been me or one of the other devs doing demos (usually me though). Granted I haven't worked on anything truly high profile that a demo would be An Event.
they rejected my request for raise because "you already are amongst the ones with highest percentage raise in the past"(which is in single digit, BTW). meanwhile peers who do nothing all day are more paid.
i'm not jealous. just feel like I'm underpaid and overworked
As a former PM/PO who has moved up the chain, your PM is full of shit and you should look around. Looking out for your top talent is how you succeed as a PM.
Then find another company and negotiate a salary you should be on. Maybe add on a bit more so that can negotiate you down to what you want. Ignore the question of how much you are on as much as possible. Answer with "I am looking for £x".
Been there. I didn't even know that there had been a product launch party until the next day when people were wearing pins with the product logo & talking about the great time they had. Nobody thought to invite literally the only developer.
There are different audiences for demos though. It should be that way at the "working level". When you start moving up the chain with more senior leadership in your org, it starts to make more sense to have the PM do the demos/briefs.
Usually devs don't particularly care or want to and sometimes they aren't really qualified to--its not their skillset. But if it's a good PM, that's where they shine. That's the value they bring to the project. They (should) know the politics, landmines, things that specific leaders would care about (and to highlight for them), and how to frame it to current business needs. They have the context to understand when a seemingly innocuous question is actually pointed. They might not know the intricacies of your code, but they (should) know the intricacies of the organization. That's not something most developers know, and why should they? That's not their job.
Sometimes it even involves groundwork meetings and demos to make sure you have support from other key components in your org-- like getting your CTO excited because one of his performance goals was x and your project is the first real implementation of x. Now, you have the CTO ready to speak on your behalf in front of the CIO. As a PM you know that the CIO has been getting flack from the CFO because there hasn't been a good way to capture costs for Y, but your system starts the org down the path to fix that. Now they are both excited about the project and in your corner. Etc etc