A big part of how I see my role as a Product Owner in an Agile environment is to bridge the gap between the business and the developers. On one side of the bridge is the Product Manager, whose primary goal is to hear and relay the voice of the market. Her job is to make sure that what we develop meets real and common market needs in a way that clients will pay for. On the other end of the bridge are UI/UX designers, coders, and testers who make sure that what we build works well. There are no firm barriers keeping us separated (I’ll write another time about why I like the way Agile brings the two ‘sides’ of the bridge closer than more traditional methods tend to) and hopefully there is good and frequent communication among all those on the product team. When this kind of communication doesn’t happen you end up with something like this: http://funnysalescartoons.com/photo/funny-sales-marketing-cartoon?xg_source=activity.
But someone has to hold responsibility for making sure that the voice of the market is getting translated to the language of the developers, and someone has to make sure that the questions of the coders get answered based on the real needs and wants of the market rather than just one person’s opinions.
Hopefully that’s what I do. I stand on the bridge and facilitate this conversation, making sure that the right questions get the right answers at the right time. I keep a foot in the market (especially relying on the Product Manager but also talking directly to some clients and prospects) and a foot in the world of coding and design (relying on lead developers, architects, and testers to make sure I grasp enough of the technical issues). Hopefully I listen at least as much as I talk. When I do my job well the bridge is strong and everyone can do a better job. When I do my job poorly the communication breaks down and the other folks on the product team spin their wheels. It can be a fun and fulfilling role to play with a committed and creative team in a company with the resources and vision to develop the disciplines of great product development.
Of course, in truth it’s not that simple.
InTruthItsNotThatSimple 
Reblogged this on InTruthItsNotThatSimple and commented:
I started this blog in July 5 years ago. A lot has changed since then – in my life, my role at work, and the wider world. But the basic motivations that pushed me to start writing here remain the same: I enjoy sharing things I am learning about software development and leadership; I want to participate in a wider discussion of these topics (which I do both here and on Twitter as well as in many face-to-face settings); and I think at least sometimes I have something insightful and humorous to add. In acknowledging the 5 year anniversary of this blog I want to go back and share some of earliest posts; these were ideas I drafted before beginning the blog because I wanted to make sure I had something to say before i started blogging. In rereading these now I find the ideas still do a good job of capturing how I think about software development and the Agile methodology. There are ways in which my thinking has evolved of course and I may note some of those. But hopefully you will enjoy these thoughts – either as blasts from your past or as fresh ideas – as much as I enjoyed reviewing them myself. And if you have thoughts of your own please share them in comments here or reach out to me in other ways. I know I don’t have everything figured out because in truth it’s not that simple.