I’m working at a very high growth B2B SaaS and I’m currently the only PM with 12 devs, but a new PM will join us in a few weeks, and 5 more devs
We always had trouble updating other departments on those things:
- Why do I say no to some of their feature requests (how product mgmt works)
- Where we want to be and how are we getting there (vision, strategy, OKRs)
- What changes were made to the product recently and how they work (educating)
- Syncing the marketing efforts with product changes (growth)
Where should the PM’s responsibility stop?
Frankly, I don’t have the time right now to do 3 and 4
Are they the product marketing manager’s responsibility?
Is 1 something I should do? Explaining why “but it takes only one day to do” is not an argument, why do we don’t add every feature request to the product, etc…
As for 2, I’ve made a live document written by me and the founders so that they can better understand the prism of thinking we use for every product decision taken.
Your insights and feedbacks could help me decide better.
Thanks in advance.
Fine, the advice is to take care of 3 and 2 in sprint reviews. People can attend them and be updated or not then it’s on them to be fed in.
Second using 2 you can deflect 1 because it doesn’t meet the strategy is an easy deflection.
And for point 4 you can just arrange a meeting with the marketing department to discuss the changes but I wouldn’t say you were leading on it.
@Karan, Thanks, makes a lot of sense
We choose to don’t do sprints, but I guess a meeting every 2/3 weeks will do the trick in my case
In my opinion you should be involved in all 4 The first three actively but can be done through communicating the roadmap and the reasoning behind it clearly to all key stakeholders and 3 being done automatically with good documentation and some TLDRs contained in that.
4 depends on your goals and targets If you think marketing should be involved because of a key launch approach them actively otherwise they could always involve you and you play a more passive role but you should definitely have an overview and align with them
Communication and collaboration with stakeholders is an essential part of the PM function. It would be best if you established the processes and ground rules for how you will align and work together. This is where that “influence without authority” part of the PM job description comes into play. This isn’t easy, and it’s not something you’ll fix overnight.
Have you read Cagan Inspired? It’s more aspirational than prescriptive but may offer clues.
@Nathan, Never read it, I heard it was more aspirational than actionable (like you’ve said)
I think I’ll try some things and iterate based on their efficiency/effort
I’d caution spending too much time on #1 trying to satisfy people with a reason because they don’t want a reason, they want you to say yes, they want to hear your objection so they can get around it. Ideally, if you do #2 well enough it actually covers a lot of #1 and stops it sucking up your time because if you can say “we’re building x because it goes towards OKR y and overall strategy z” that also explains why you’re NOT building all those other things. I never had the strength of vision from the leadership as mentioned in someone else’s comment to really put that into action and it pains me to this day, so that might throttle your attempts too, just have to do the best you can.
I’d be wary of leaving the education piece up to a product marketer - their focus is often on “how do I describe this in a way that helps us show people how valuable the product is and what they can achieve with it” and they don’t always also have the particular skill of explaining how to use the thing click by click in order to achieve that - BUT as the person in the room when you were deciding why this thing would be so cool to bring into being it’s on you to share that with the people who can fill in the details in the way they are required for their job, be it marketing or support/documentation. I don’t think you get to just throw new functionality over the wall to them and let them figure it out for themselves by clicking around. And ultimately, the better relationship/communication you have with them the more successful your product will be and the better you’ll look
@Naomi, Very insightful comment, thank you so much!
I think people define delegation as finding out who’s responsibility is what. I look at it as “who does what best.”
Instead of asking where do my responsibilities end, maybe ask “who’s skilled at communicating XYZ.”
I’ve asked devs to explain why we can’t do things to stakeholders. Albeit we had a lot of trust in our relationship. But they were better at communicating technical limitations than I was. I approached it as “hey I’m having trouble doing XYZ, can you help me define the limitations of our work?” Bring them on board.
Same with 4, if you’re not good at it, who is? If no one else, then it’s on you.
You can also say somethings not worth your time. “No” with no clarifier can be an answer. Your team will have to just accept it.
@RisaButler, Cagan does lay out a model for responsibilities and authority in a perfect world. I just left a software company that tried to run under that model. Even then everything goes to sh*t under dysfunctional leadership.
Just be savvy. Own the situation or it will own you.
A partial solution that we did for #3 was to have internal “Release Notes” for every new app updates (I was on mobile). There was a group email including all the relevant people, from CS to the CEO.
I had to do it for users anyway, so making an adjusted for internal use was no biggie.