I'll chip in two-cents - and I'd like you to value my advice at exactly that.  Warning: I can't seem to answer questions with crisp advice - grab a cup of coffee before you start to read this.

I'll refine that to say that product management should specify a desired outcome.  By outcome I mean what happens after the software ships.  How does the company benefit?  What customers and users are relevant to that business benefit?  What sort of solution does the product manager believe will achieve that outcome? 

I've recently been trying on for size the language used by a speaker from Frog who gave a keynote at IxDA 09 (I forget his name...).  He introduced the language output-outcome-impact

output: is what we build

outcome: is what happens in the world after we release our product

impact: is what happens later - often much later.

We don't want software (the output), rather we want the outcome - the profit, the increased customer satisfaction and retention, the expansion into new markets - all that stuff.  We're ideally driving towards some longer range impact aligned with our organization's vision - to become dominant in the marketplace, or (isn't it google that says) "do no harm."  If we released software that made a profit, but damaged our reputation in the industry, that would be a good short term outcome, but questionable long term impact.  I know a company that had made a choice to include more advertising on their site. It's had a good short term outcome (more revenue).  But, they're concerned that this move may damage their brand having questionable long term impact (their customers grumble about the ads).

Outcome and impact is where the business value lives.  If you don't know what your desired outcome and impact are, you don't know what your business value is.  Don't build software till you do - unless of course you're having fun at it... but then "fun" is your desired outcome.  ;-) 

The product owner and team prioritize work relative to that.

That'll work so long as the product owner understands the desired outcome, gathers the information necessary write stories that could result in software to get that outcome, and engages in some form of evaluation of the software - ideally with users and others - that can help determine if we're likely to get that outcome.

In english now: work with a collaborative team of smart people.  Study the users.  Show prototypes and working software to users.  Watch them use it.  Continuously ask if we're likely to get that outcome when the software is released.  Release as soon as you can - because you never really know.  All software is a speculative until released - like a boat that's never been placed in the water - you'll know it floats when you actually launch it.  Sadly, I've  seen a lot of "concrete boats" being built.

They need to understand the desired outcome as well - as well as have a pretty good "big picture" of the desired product in their head.  This let's them innovate - really think.  When they're allowed to think, they'll begin to move into this sweet spot of quickest to build and helps to secure desired outcomes.  They'll begin to be alert to stuff that wastes time - stuff that although they could build it, isn't in the best interest of organizations.

If you don't communicate the desired outcome and how you envision the product, the developers will still think - still invent - still come up with good ideas.  They just many not always be aligned with what you're trying to achieve.  If you're the product owner, and developers are coming up with what seem like irrelevant ideas, or pushing back against yours, don't argue with them - back up and make sure they understand the desired outcome, the users and customers, the product you're envisioning.  For teams I've worked with, it they still don't understand, I put them in a car (or in a plane) and go to the customer site to watch them work - to see the context.  They'll either understand, or be a little more cautious about being argumentative next time.

I don't have any particular concerns one way or the other about the separation of product manager and product owner.  Luke Hohman describes the scrum product owner role as a "product engineer" - a more tactical and technical role than the product manager normally fills.  I get nervous when the boundaries between any role are two stiff.  I picture my team and company as a bit of a soup.  (stay with me here.)  I can cut up a bunch of vegetables and toss them in a bowl - and the boundaries between the carrots and the potatoes are still pretty clear.  But, when I add water and heat - the soup begins to boil and the boundaries get a bit fuzzy.  The edges of the carrots get a bit blurry - and the soup tastes a lot better than the bowl of uncooked vegetables.  If your roles have stiff boundaries, you're doing it wrong (in my opinion.)

If you mean by that that the team creates them: no.  I've seen some serious problems with the product owner and product manager not really understanding their own backlog.  Consequently they can't "steer" the project.  

The simple steps you describe will likely work fine - but the devil is in the subtlety of how you do it.  I imagine Tiger Woods explaining how to play golf:

1. place ball on tee

2. select golf club

3. hit ball into hole

It's simple see?   Anyone can do it.

Thanks for posting,

-Jeff