Tag Archives: product management

Agile Examples – Product Owners

This is an excerpt from the textbook that I am writing with a co-author on Agile.  Here are examples of a strong and weak Product Owner.  (Names are made-up so don’t think you know them  🙂

Would love to hear your thoughts and comments.

Product Owner

There are many examples of good and bad Product Owners in the workplace.  These are challenging jobs with a number of conflicting inputs with regards to prioritization so it takes a strong personality with a collaborative work behavior to be successful.

Let’s look at Keith.  He was assigned as the Product Owner to an application that had several high profile and demanding clients.  Keith researched all of the necessary competitive and market information so he could ascertain the best prioritization for the development work that needed to be done.  One Account Manager who handles one of the high profile clients didn’t like Keith’s prioritization because something that their client wanted was not at the top of the list. Keith was very deliberate in his analysis and he felt that the requested feature would not be adopted by others in the marketplace – it would really just apply to this one client almost as if it was custom code.  Therefore, Keith put other features that he felt would drive more business value before the requested client feature.  But that didn’t satisfy the Account Manager as she felt like her client’s request was vitally important. So she pleaded with Keith again and again.  She called him and sent him e-mails and held meetings and just pestered Keith relentlessly to try and get him to change the prioritization.  Finally, in a moment of frustration, Keith said “Fine. You go talk to the IT manager of the Development team.  If she thinks they can get it done, then so be it.”

Is that an example of a good product owner or a bad one?productowner

Keith was having a bad day and in that moment, was a very bad product owner.  The Product Owner sets the priority for the work of the IT team based on their knowledge and research of the marketplace and what will drive the highest business value.  Further, the Product Owner must collaborate with all of the constituents to “sell” the prioritization.  The product owner must be collaborative and must hear input from a number of sources, including account management.  So it was Keith’s decision as to whether or not the client request would be prioritized high on the list.  His decision and his alone. By deferring to the IT Manager, he was shirking his responsibilities.  He should have either convinced the account manager that his backlog was prioritized correctly by articulating the business value of the high priority items and clearly explaining to the account manager why their desired task did not have the same business value – or, if he couldn’t do that – then he should have reprioritized the backlog to move up the client’s task, based on the information learned from the account manager.  Being a Product Owner is a difficult balancing act but the role is critical and must be performed well for Scrum to be effective.

By contrast, Sam is a great product owner.  He actually moved his desk to sit with the Scrum team so he could be immediately available to answer questions of the team.  Sam spent a portion of his time with the account managers, salespeople and actual customers so he could stay on top of how customers were using the product and what problems they were having.  He also learned from the salespeople what objections they were hearing from prospective clients.  He was able to distill all of that feedback into the user stories that he created and he understood which features would drive the most business value so he could effectively prioritize. Sam also listened to his Scrum team and understood enough about the technology to contribute to the discussion around various choices that could be made to solve a particular problem.  The best product owners have enough technical expertise to be able to follow a technical conversation and contribute salient points to the discussion.  Product Owners do not have to be developers by any means but they should demonstrate a technical aptitude.

Want to read more?  We have examples for Scrum Masters and Teams too.

 

52 Blogs – Determined or Nuts?

Like everyone, I have some personality quirks that drive my behavior and response to situations. One of those – my determination to adhere to self-assigned goals – has been top of mind lately. You see, I set a goal of writing 52 blogs in 2013, one per week. No one asked me to do this and I am not sure that many people even read them. But I established this goal and I had a 4 week lapse in my delivery. Others might consider a job change and all of the associated networking, traveling and interviewing as a good excuse for a hiatus, but not me. I said 52, darnit, so I have some catching up to do.

52-weeks-to-awesome-500This personality quirk makes me smile. The need to honor my commitments to myself, even if it is inconvenient, is just part of who I am. Hopefully my tenacity will suffice and I will be able to write the full 52, even if that means I am blogging on New Year’s Eve!

But this gets me thinking – why am I this way and how can I turn this ‘quirk’ into an asset? Here’s is what I have come up with:

  1. Set meaningful goals –  Blogging for the sake of blogging might not be the best use of my time so I need to ensure that blogging is also contributing to a higher purpose, like furthering the brand of my company, or my personal brand. Or conveying information about subjects like Agile and Product Management that others might benefit from.
  2. Manage time effectively – make sure that the goals are achievable. Saying that I am going to work-out every day or write three thank you notes each morning or read for one hour each evening – those aren’t really achievable. I need to give myself the time to do what I committed to do and the flexibility to know that life will inevitably get in the way.
  3. Avoid tortuous activities – I need to only commit to the things that I enjoy and that serve a noble or entertaining purpose. For me to commit to gardening or (heaven forbid) cooking would be disastrous. I don’t enjoy those things, I am not good at them and I really have no passion develop an aptitude for them. I need to stick with what I enjoy – while certainly stretching and going outside my comfort zone – but not undertaking something that I would dread.

I hope this resonates with you and can help you set new goals and see them through. It is a great sense of accomplishment when you reach the finish line and you can say “Oh yeah, I did that!”

CDS Global in the rear-view mirror

It has been a month since my last blog and I actually have a good excuse for my lack of prose, which will also explain my new website. I am in the midst of a job change. I had three wonderful years at CDS Global and now I am looking forward to the next great adventure.

rearview mirror

Image Source: http://lifechallengesemi.org/the-rear-view-mirror-2/

Before I focus solely on the windshield though, I always think it is beneficial to spend a moment looking in the rear-view mirror to savor and appreciate what was accomplished and learned. Here are the three things I am most proud of during my tenure at CDS Global.

1. Technology Roadmap

When I arrived in April of 2010, there was a keen awareness that we needed a technology story to get us to our next stage of evolution. Working with super-smart technologists, we started putting together plans. We had at least two false starts, but in September 2010, we unveiled a vision that has shaped our technology decisions ever since. The reason I am so proud of the Technology Roadmap is that we thought it through and then we stuck to it. Delivering on a tech vision is extra-challenging because the business and the technology changes as you are in the midst of implementing. Our vision was both solid and flexible, allowing us to adapt to new information while providing a strong foundation that advanced our capabilities. To be able to look at a document, nearly three years later, and realize that what were once boxes in a powerpoint diagram are now live, working elements in a layered architecture is pretty darn cool.