Skip to main content

The Product Owner

According to the Scrum alliance the Product Owner is "a single person must have final authority representing the customer's interest ...". They are often described as a product visionary, and also as someone that has a lot of influence within an organization. That is to say that they are the final arbiter for the product. In short this individual has a tremendous responsibility and in many ways are responsible for the success (or failure) of the product.

Unfortunately, in my experience, this is not how the the role is implemented. I believe a lot of this has to do with how software projects were run in the past. I've seen several common variations of how they they are often fulfilled. The first being the PO believes that they need to perform more as a Project Manager. They focus more on control, and trying to manage the team. This often comes from people with experience from pre-agile days that either don't fully understanding how the role is meant to implemented, or they are simply sticking to old habits. The other variation that I have seen is that often someone higher up in the organization has the vision for the product, but simply doesn't want to be involved in the details of working on the product, so they instead delegate this role to someone else. By doing this they put their faith into someone else; often someone without the vision and frankly without the passion for delivering a great product.

Don't get me wrong; they are some great Product Owners out there. However, in my experience they are far and few between. There simply are not enough of these visionary types out there to match the number of software projects that exist. Occasionally you'll come across one, but putting the success of the product on a single person's shoulders can be limiting.

One of the key principles of the agile manifesto is having the developers working together withe the business. Additionally in agile, engineering responsibilities are shared across the team, instead of an single individual.  In a similar light, perhaps instead of putting all of the product responsibility on a single person, the Product Owner, this responsibility should be shared by the entire team. That is to say that developers shouldn't just be concerned with good engineering; their ultimate concern should be making a great product. This includes thinking of what is best for the customer. There's no reason that this concern should be exclusively a single person's responsibility. Of course this isn't limited to developers; it includes UX, quality assurance, business analysts, etc. Ultimately the goal of the team, to make a great product, should a collaborative effort and not an edict from a single authority.

If an organization has a true production visionary; someone with a true passion, great ideas, and strong convictions, and is willing to work with the team that's great and you should considered your organization lucky. If not, consider making this a shared responsibility that you encourage your entire team to share. The truth of the matter this is the in the spirit of of the agile. Even if you have the perfect Product Owner, it's in everyone's best interest if the entire team is always thinking of what's best for the customer. It's ok to have a single person with the final say, but everyone should encouraged to bring their own opinions and ideas. This includes ideas that may contrast what the Product Owner originally envisioned.

In summary, trust your team to help make the right decisions and allow them to have a bigger role. The end result is that you'll likely have a better software product for your customers. In the end, that's what really matters.

Comments

Popular posts from this blog

Value and Quality over Schedules

According to a study by CEB Research, 70% of software projects are delivered on time, but only on 38% meet stakeholder's expectations. In most cases the people that use your software will not even be aware of internal project deadlines. Case in point, think of all of the software the you use everyday. You are rarely aware of what the due date was. However, what you do notice is how well the software does it's job. It's it's of low quality, you'll very likely notice right away. Even if it appears to be of high quality, if it doesn't provide any major value to you, chances are you still stop using it. With that in mind, then why do many software projects today have a set scope and a hard due date? When building software for a customer, it's only natural for them to what to know what exactly they are going to get and what is will cost them. That is a very reasonable thing to want to know. Even when developing software internally, there are often similar expe

Let's Get Moving With Software Development!

Recently I was reading a discussion on Twitter about software projects, and it reminded me of something. Many years ago I had a conversation with my dad about moving. After just having moved, he wasn't too pleased with the moving experience. He mentioned that there was essentially two models that movers operated under. The first was you paid a fixed price for the move. I don't remember the exact details, but the movers quoted a price most likely along the lines the square footage of the house, or some similar metric. The other model, was simply to pay the movers for their time. If it took them 20 hours to complete the move, you paid for those 20 hours. Now the catch was, as he described it, if you paid for a fixed price the movers didn't really put a lot of care into the move. They simply wanted to get the job done as quickly as possible. I seem to recall that if they broke something, they would reimburse you. However, that wasn't a pain free process. More importantl

The Cost of Meetings

Meetings ... love them or hate them they are a part of everyday business life. I've had multiple bosses that detested meetings, saw them as a waste of time, and would dissuade us from having them. On the other end of the spectrum I've worked for organizations that had countless meeting, many that were of little relevance to me, and left little time in the day to accomplish my other duties. In this posting I aim to examine the cost and benefits of meetings, and also touch upon what it takes to have effective meetings. As someone that has worked as a software developer, team leader, and manager of developers over the years, I'd like to think that I've seen the good and bad side of meetings. Let's start first with the cost. Everyone would agree that a 1 hour meeting requires at least an hours worth of time for everyone that attends. Add to that the need to break ones focus from what they were doing, and regaining that focus after the meeting, you may even raise that