product owner

Product Ownership – A Team Sport?


How many of you have heard a Product Owner being described as a single-wring-able-neck, or read that the Product Owner is solely responsible for the “Return On Investment” of a product or project? Are you aware that the Product Owner is responsible to work with stakeholders to define the product or project, and they are also required to be available to the team to answer questions, give feedback, and accept the deliverables produced by the team? If you are doing Scrum, you’ve likely heard all of this.

As defined by, the role of Product Owner is responsible for the business value of the project. To take this a step further, Roman Pichlar inked a solid blog called Being an Effective Product Owner. In this blog, he better explains the expectations and or responsibilities of an effective Product Owner including close collaboration with team to guide and direct the team, active management of the backlog (ranking, grooming, etc.), proactively manages stakeholders [expectations], has a thorough understanding of customer needs, and has some knowledge as to how good software is developed. These responsibilities closely resemble the four aspects that Robert Galen outlines in his book, Scrum Product Ownership — Balancing Value from the Inside Out. These four aspects include part Product Manager, part Project Manager, part Leader, and part Business Analyst.

As pointed out by many in the Product Management space, the role of Product Owner is fairly broad and, although many folks like Roman and Robert have done a good job helping to better define the Product Owner, the role itself is often viewed as ambiguous. Let’s face it, in order to be a good Product Owner you are asked to know your customer, have an in-depth knowledge of how the product or project should satisfy the needs of the product, you must represent the product to both internal and external stakeholders, price and support the product/project to ensure profitability, define requirements, answer questions to the team, be a part of elaboration and planning discussions, facilitate discussions between customers and developers, work with industry analysts, plan and schedule, define what is the most important thing, … ok this is getting ridiculous. This is a lot to ask of any one person.

In years past, when organizations made the transition to Agile (specifically Scrum), the Product Owner role typically defaulted to the Product Manager or the Director responsible for a specific service area (e.g. Customer Service Director). This often meant that in addition to your current job, we are going to ask you to make yourself more available to the development team that is building your product or project. In some cases, this worked out fine — but in most, you’ll see that either the stakeholders are not happy or the development team is not happy. This is simply because there is not enough time in the day, not to mention the expectations and requirements are so broad.

Today, it is common place to see the Product Manager or Director be paired up with a Product Owner. The Product Owner role is given to a Business Analyst or Project Manager that has strong subject matter expertise. In some cases, you’ll see titles stay the same and in others, team members actually given the title of Product Owner. These two (maybe more) team members pair up to become the Product Ownership Team. The Product Manager works the external stakeholder needs while the tactical Product Owner works the internal stakeholder needs — specifically working closely with the delivery team. Arlen Bankston of Lithespeed talks about the roles of Strategic Product Owner and Tactical Product Owner in this blog.

productownershipteamThe Product Ownership Team approach helps reduce the time burdens and constraints, while still fulfilling the need of having a role focus on business value. The advantages of this approach are:

  • More brainpower up front to help understand customer needs and align to solutions,
  • Time afforded to thoroughly understand the marketplace,
  • Capacity to satisfy the “on-demand” need to work with the team, and
  • The ability to avoid unnecessary waste due to bottlenecks that result from a poorly maintained backlog.

The possible pitfalls to look out for with this approach are:

  • When the tactical Product Owner is not empowered to make decisions — you will likely end up conversations being conducted through heavy documentation and sign-off processes,
  • A proxy-type relationship that can keep the delivery team from making a connection with the end-customer,
  • The lack of clear vision since the tactical Product Owner my be too far down in the weeds and not able to clearly articulate the big picture, and
  • Without the Product Manager (or Strategic Product Owner) interacting frequently with the team members — trust and a positive rapport does not develop between the business and the delivery team. This can lead to poor morale and underperforming teams and products.

What approach does your organization employ? Do you have a single Product Owner? Or, is Product Ownership comprised of a Team? If it is a team, are there multiple players or just two?


When I talk with folks learning about Agile, I often play the game Presto Manifesto where the room talks about what it means to have a successful project and then break up into groups and based on their experiences come up with a list of critical elements that they’ve noticed on successful projects. This exercise is meant to bring people to the concepts of what makes up the Agile Manifesto.
The interesting thing is that in many cases we discover that we’re programmed to believe that failures of projects relate to not knowing everything up front. I almost always hear, “complete, thorough, and approved requirements” as an element of successful projects. This programming aligns well to the formula of success I learned during a short stint at an ERP consultancy firm:


This formula leads us to make sure we set clear expectations so that we can meet and hopefully exceed them; thus, leading to success. However, as we know and learn in Agile (and really any process) – thinking the users/customers know everything about a project (a.k.a. need) six-to-nine months before they get their hands on it is simply a fallacy. Sure we can make the customers agree to the expectations ahead of time, but doesn’t that negate the ability to ensure that value and ROI is actually achieved on the project. What generally happens is that the customer/user defines the requirements and agrees to them, then sometime about a month before the project is delivered — they get their hands on some working capabilities and the say, “this doesn’t work like I expected, can you add a screen that does this and we’ll need a report that gets generated daily; if we don’t get these, we really can’t use this.” The response of the team is first, “but you signed the requirements document” or “those are great ideas, we’ll need to do that in the next phase” or “that will need to go through the change control process, we’ll need to escalate this.”

Ultimately, the team is not happy because they don’t get to experience SUCCESS because the RESULTS fall short of EXPECTATIONS. On-top-of-this, the customer is not happy either.

By using an Agile approach, we can improve on our SUCCESS rate through applying these very basic ideas:

  • The customer (a.k.a. the Product Owner) stays engaged with the team delivering throughout the project life-cycle. In fact, they are part of the team. At no point in the process should they disengage; thus, decisions and expectations are set near the time the need is built and subsequently delivered – requirements evolve. And since the customer stays engaged, changes should not be surprises to either the delivery team or the customer.
  • Needs are delivered in small valuable bites. This means that the delivery team and customer work together to understand what is smallest piece of value that should be delivered first and they deliver just that. This approach helps both the customer and delivery team by narrowing focus which results in faster delivery and a focus on getting the high-value need right (with quality). By the way, if the delivery team falls short of expectations for some reason it should not be a surprise to anyone and since we handle just a small bite – we fail small.
  • At regular intervals the delivery team (including the Product Owner) shows off the demonstrable product increment. Preferably what is demonstrated is a complete capability; however, this is not always possible. At a minimum enough is demonstrated so that feedback can be provided and the team can show that they are doing what they said they would. This demonstration provides a checkpoint for measuring success as well as it provides a way that expectations can be continuously molded and refined.
  • Conversations are constant within the delivery team, with the customer, and the stakeholders. Instead of having formal meetings that are dubbed “Status Meetings” — we have ongoing, regular discussions about the EXPECTATIONS. When an engineer has a question, they grab the key team members and product owner and discuss real-time. This results in clear understanding and a lack of hand-off breakdowns (where information is translated as it passes from one person to another).

There are many more things we do with agile delivery methods that ensure our projects are successful (e.g. continuous planning, short release cycles, engineering best-practices, and a ephemeral drive to get better). But if you start with the above ideas, I can assure you that the team and the customers will start getting that feeling of SUCCESS.

What are your thoughts?  How does your team measure success? Another great question, do you define SUCCESS before you start your projects?

Five Ways to Establish Trust


As everyone knows, a key success factor of an agile process implementation, specifically Scrum, is establishing trust between the team delivering and those waiting on the delivery (basically between the product development team and the business).  In order to establish trust, a development team should be meeting their commitments made during the planning meetings; thus, delivering what they said they would.  Sounds like a pretty simple formula and for the most part — it is.

Never trust the teller. Trust the tale.
– DH Lawrence

Outside of simply delivering what you said you would in a sprint, here are five ideas to establish trust:

  1. Always act with integrity. It goes without saying, truth sets you free.  But what is more than simply being honest while communicating with someone, but it is more important to perform your job duties with integrity.  This means, no cutting corners, maintain the utmost quality, and always keeping the team informed when it comes to matters that may impact the core deliveries.
  2. Ask questions and share information. Make sure that if an idea is not understood, be sure to not be afraid to ask a question (sometimes, the first thing that comes out the mouth is “I don’t know”). Be sure not to assume you are all-knowing about an issue, so share what you know — this is an excellent way to facilitate conversation and potentially discover what you don’t know.
  3. Reasonably accurate expectations (estimates to complete). In the agile world, estimation can be challenging.  This is primarily due to the lack of data present at the beginning of tasks.  The easy way to overcome this and become more accurate with your estimation is to be sure to break down stories into common development tasks.  This may include an analysis, design, build out, unit test, etc type task.  I also like the proto-type, stub, or even the sub-functional task where a small piece of functionality is implemented.  Estimates generally get better the smaller the task and they are of course better when more than one person sets the estimate (leveraging the experiences of others will help).  Finally, always accurately update estimates to complete daily.
  4. Deliver within the boundries of the commitment. Simply stated, don’t always try to be a hero and deliver beyond the expectations of the original commitment. This can be viewed by management (be it product or development) as sand bagging estimates, or simply going rogue and “doing as you want to”. Not to say that finding a great way to do something that was much more productive is not a good thing or seeing that you can do a lot more within the context of the product functional area is not appreciated. But the right way to handle this is to disclose that you found a faster way to do something and your estimate-to-complete is much less than orginally anticipated, so you would like to work on another key capability that is similar to the functionality being implemented. Negotiating this within the context of the daily standup (and possibly within a follow up meeting) would be the correct course of action.
  5. Consistency is key.  Having one good sprint is not enough, a team needs to establish a trend of delivering on sprint tasks on a consistent basis.  This applies to the team as well as the individual.  Once a team is able to demonstrate a consistent trend surrounding capacity, story points delivered, hours worked, etc — the product stakeholders can start to reasonably expect that what the team says they will finish will in fact be delivered.

Remember the idea of trust should also exist within the scrum team and between scrum teams where there is a need to share deliverables or even if you all work within the same development organization. The five ideas above should be applicable to ensuring that all scrum teams work well together and within the overall scope of an organization.

What techniques or ideas do you have about how to build trust with the product management or project stakeholders?  What have you’ve done that works?