Nice Tom, now our backs are against the wall to justify our existence to the Bob's! 
It's funny, but every PM position I've had has included a slightly different set of responsibilities. This should be a lively discussion!
In my current position as a "strategic product manager" for a startup, I'm the big aggregator and translator. I collect a lot of information from all of the internal stakeholders: sales, marketing, services, engineering, and executive staff. This is usually a combination of “we need to…” or “competitor/partner X is doing…” or “it would be really cool if…” or “we’ve committed to deliver…” or “it’ll take X person-months to develop…” or “we’re getting killed without feature X…”. I parse these out to a base set of product constraints and priorities. I augment this with my own research, with partners, and with customers.
I run this through an analysis based on a scorecard model that includes things like financial metrics, customer satisfaction, strategic goals, etc. This gives me relative priorities for fixed-resource projects (projects where we’ll use existing resources and not add any capacity). For mission-critical projects we run more numbers to propose whether additional resources should be added to accelerate the projects.
This all gets compiled into 12-18 month roadmaps and product plans. The roadmap is consistently updated as things change. The product plan is updated periodically as major things happen. These get presented for feedback from our product board and adjustments are made.
Once engineering is ready to begin the estimating, I write the series of release documents and requirements. After unending reviews, we get detailed project plans from engineering that we come to agreement on (varying scope and date as necessary).
At this point, I hand the project off to my counterpart (our “technical product manager”), who handles the “delivery”. He works with engineering on spec reviews, fulfillment reviews, and defects. If anything comes up that significantly changes date or scope, he comes back to me to negotiate the change. Otherwise, he keeps the wheels on the tracks from the product management perspective.
He’s also in charge of delivery to the field. He writes a series of internal training documents for marketing, sales, and services. These are used for the development of collateral, demos, and other training.
The two of us do this for seven products in three product suites supported by an engineering staff of roughly 30. Of course, every step is done collaboratively with other teams depending on the phase and need.
That's the standard stuff - it doesn't include firefighting, answering questions, giving webinars, writing white papers, customer calls/visits, and "being the calm center of the tornado."
...and I've got people skills!
Tad |