Saturday, April 16, 2011

The Project Owner

I recently paired on an Agile Fundamentals training for an organization. Its a two day course in agile philosophy, principles and basic practices offered by ThoughtWorks Studios. Its more of an awareness programme than training that you can put to use in your daily life. This makes sense as any two-day training that promises "take-away"s that can directly be applied to your situation is probably bogus.

Although the training itself is pretty much "canned" in terms of material, the discussions that happen over those two days are very important. In discussing various aspects with people from this organisation, I saw another instance of an engagement setup anti-pattern.

There were multiple stakeholders in the client organization (there always are) and the IT team was dealing with all of them. There were a lot of conflicting priorities, priorities changed while development was going on, people who made decisions went away and new people made opposite decisions due to lack of context, etc. Here's where I think the problems is but first lets talk about the product owner role for a bit and then we can discuss how this ought to work in a services context.

The Product Owner

In my view a product owner role is defined by two simple characteristics:

  1. She has absolute authority over what features go into the product.

  2. She is absolutely responsible if the product doesn't work.

To satisfy these conditions, the product owner will show several behaviors.

  • Has a clear vision of what the product should be

  • Knows exactly what the product is currently capable of doing

  • Knows the target market (user segment) and the trends in that market

  • Takes inputs from the organization, the development team, the marketing guys, the market itself and base

  • Based on such inputs, is able to prioritize between planned features, bugs and new ideas

For a product, this role is absolutely necessary. And companies usually don't go wrong there. But when companies set themselves up for running a project, they usually miss this role. It leads to a lot of heartache for everyone and needs to be taken seriously while setting up the project governance.

The "Project" Owner (for lack of a better name)

Let me try to explain what this role should do in a project context. I will also add some context around each point and why I think its important.

1) The Project Owner should ideally be from the client organization

  • Since the product owner is supposed to be the absolute authority on what features are developed, he should be part of the client organization.

  • If the product is not external facing, it is probably going to be used by employees of the organization. An internal person will be able to understand their needs better

2) The Project Owner should be fully involved in the development process

  • To understand the current capabilities and gaps in the product, the product owner should be fully involved in the development.

  • She should attend all the showcases, test the application and give feedback to the development team

  • She should be involved in story discussions so that she can give inputs about the best way to achieve a piece of functionality based on her knowledge of the user base

3) The Project Owner should have complete authority and responsibility

  • She should be the Business Sponsor herself (possible in small startup like companies) OR be someone who is completely trusted by the business sponsor.

  • She will take inputs from various parties but will decide what to do herself.

  • She will have to have a strong personality to negotiate within various stakeholders in the client organization to make sure the product stay true to its purpose and doesn't go off track because one of the stakeholders shouts louder.   

Common arguments and pitfalls

If I am an IT vendor and I ask my client to create this new (almost full time) role, why would they listen?Well, it can turn out to be a tough conversation with some clients. But the basic idea is the same. The way you ask for time commitment from the client, you should also ask for such a role. Its in everyone's best interest. For some clients, you might need to prove the requirement before you ask for someone to take on the role.

Can it be someone from the IT organization?Well... its better than having no one I guess. But its not ideal because there's a lot of client context required for the role. Maybe a smart BA/PM who is permanently stationed at the client site can do it but its not where you want to go.


  1. I've been always wondering if a BA is a product owner surrogate for the dev. team. I mean the BA has the overall idea and makes suggestions and assumptions that were not even descussed with the real product owner.

  2. If you are talking about the BA taking decisions about a feature implementation, you are right. However, there are decisions about what goes into a product that will have significant impact on how / whether the product will sell. These are not usually made by a BA (especially from a vendor IT firm). Anyone who makes these decisions should be called the Product Owner anyways :)

  3. Such a good post. Keep up the good work Akshay! :-)