How would you approach:- definition, prioritisation and communication of a product backlog?

Might the ordering of work which emerges from empirical feedback underpin the approach a Product Owner takes?

In agreement with Ian, absolutely, the ordering of work which emerges from empirical feedback will underpin the approach a Product Owner takes, however breaking this down further, you can start by clarifying the overall vision of the product.

The PBL is defined by identifying the features that the product should have, and this can be done by working with stakeholders to understand the product vision, goals and user needs which will be communicated to the entire Scrum Team. 

Once the PBL is clearly defined, there is a need to identify the most critical features or "requirements of the user" and you can also use various analysis such as MoSCow, Kano Model, Value vs Efforts or Cost Benefit Analysis etc. to prioritise the PBL depending on whatever the user needs, or the PO deem fit. The most important thing is what can deliver value to users timely (MVP) and this I can link to Agile Principle 1&3. 

Communication to the dev involves sharing the PBL that is clear and includes all the necessary details such as user stories, acceptance criteria etc. Communication is key to ensure the dev doing the work understands what needs to be done and are aligned with the product goals/vison. Sprint Review provides empirical feedback from stakeholders/users that can impact the PBL, there is a two-way communication here. 

Thank you guys for your contributions and opinions. 

 

and so sorry for mix up the 2nd skill is PROJECT MANAGEMENT and not Product management 

@Joseph, I'd like to clarify something you stated.  You said "The PBL is defined by identifying the features that the product should have,...".  That is not entirely accurate.  The Product Backlog is defined by identify any work that needs to be done in order to improve the product.  That would include technical debt among other things.  

You also state user stories are a necessary detail. In fact, they are not.  There is no guidance in the Scrum Guide for how the Product Backlog Items are captured.  I have worked with teams that were more successful if they didn't try to use the user story format to capture the needs in a Product Backlog Item.  

@John, the rest of @Joseph's post has some good advice.  But I caution you to remember that it is his advice.  There is no "correct" answer to the question you posed.  Every Product Backlog is unique.  Each Scrum Team is unique.  @Ian's answer is great because it gives you a direction to explore. 

My advice is that the answer to your question is to use empiricism.  In other words, try something, inspect the results of that, adapt if necessary, repeat.  You will never find the "correct" answer because everything changes over time.  You have to continuously look for it but in the meantime you still need to be able to have work done for your Product.  

@ Ian, thank you for your input, that is really useful. @Joseph, thank you for the contribution some good points to take into consideration. @Daniel, you are very correct at ordering of product backlog. and thank you for reminding me that everything changes over time this is important to note. Your contributions open my mind to different perspectives, and broader views.

Thanks guys.