Eh, that line is fuzzier than it looks from a distance.
Product managers are responsible for dealing with roadmaps and timelines. Managing expectations is necessarily part of that job.
Add in agile practices where the PM may also be a PO directly managing a backlog and the line gets fuzzier still.
It's part of what makes that job so challenging, as you have to wear so many hats. It also makes the job very difficult to define, and I think, makes the question itself a little tough, since a PM in one org might be a very different role from a PM in another.
all fortune 500 companies I worked on that had only PM doing both jobs it went like:
PM promises some project worked out with a designer that only knows the how to wireframe generic screens, both lack understanding of the product and tech. usually because the PM just moved from another place 3 months ago.
PM show up every day at standup and fail to understand the current priorities, push the new project, the enginners see how pointless but easier than real priorities it is. Then remember it is a fortune 500 company so the easier the better. Everyone works on the useless project, try to explain the product to the PM but he will have none of that, after all the wireframes are done! Agile is actually used as an excuse "don't worry, we will iterate later". The PM will now disappear until close to the deadline when you will get constant meeting invites to assess progress, which will never be the standup. Project goes live shoved into actual product and it is a complete failure but everyone mentions it on their accomplishments so management starts to see it as a success. Everyone involved gets a promotion. PM moves over to help troubled team. Some engineers stay and are tasked with maintenance. A year later execs see the numbers and blame the current team, labels them as a troubled team so they get a new PM (remember they had none because the other one left to help another team labeled troubled).
Well, on the bright side, all you aspiring PMs out there, take note: see how low the bar is??
Speaking as a PM/PO that, I hope, doesn't suck, if you simply take the time to:
1. Understand the market.
2. Understand the product.
3. Understand the user.
4. Actively engage with and converse with developers and negotiate requirements rather than acting as a lofty dictator, and listen when the engineers raise concerns.
5. Be engaged in the process so the product can truly evolve as market and technical requirements are uncovered.
6. Own failures.
7. Share successes.
I'm sure I've left lots off the list, but it's pretty basic stuff (which, I suppose, all starts from the same basic place: humility)...
Product managers are responsible for dealing with roadmaps and timelines. Managing expectations is necessarily part of that job.
Add in agile practices where the PM may also be a PO directly managing a backlog and the line gets fuzzier still.
It's part of what makes that job so challenging, as you have to wear so many hats. It also makes the job very difficult to define, and I think, makes the question itself a little tough, since a PM in one org might be a very different role from a PM in another.