In most traditional organizations, there seems to be a gaping void between the team building the product and the customers using or requesting it. This gap is being exacerbated by organizations seeking to create and enforce multi-layer interfaces between the customer and the team members, while also creating committees and multi-step processes for making decisions about the direction of the product. The lack of a decisive voice representing the needs of the customer and the economics of the business with the authority to set and change the direction of the product is dramatically reducing these organizations’ ability to innovate, adapt, and deliver great products. The Product Owner role seeks to eliminate this problem.
The Product Owner is a singular voice that is granted the authority and responsibility for making decisions and setting direction to ensure the team builds the right thing. The Product Owner represents the customer or user base and other key internal and external stakeholders. The Product Owner fulfills their role through empathy and economics with transparency.
Building empathy for the customer within the team and employing an economic framework to drive scoping decisions is at the core of the Product Owner’s duties. Everything the Product Owner does stems from these core responsibilities.
Why Empathy?
The ability to see the world through another’s eyes is a powerful thing. In the world of product development, empathy is critical. When delivery team members can empathize with the needs of the customer, they can be leveraged to enhance the products being built to meet those needs. In this model, team members become more than order takers. They become innovators. Who, through open dialog and working product, help the customers see and understand what is possible, so that together they can build what neither party could foresee alone.
How does the Product Owner enable Empathy?
Create and communicate a compelling vision
Building empathy within the teams should start with a compelling vision. There are seemingly endless numbers of ways to capture and communicate a vision. However, the intention of the vision is static. The intention is to paint a picture of the future and provide high-level direction for the product or project. A well-constructed vision can act as the foundational decision criteria for the team and allow for prioritization questions such as, “does this change support or enable the realization of our vision?” or “is our approach to the work aligned with our vision?” A compelling vision will act as a North Star for teams, allowing them to, at consistent cadence, assess their position in context of the star and make course corrections.
Know stakeholder pool and understand/communicate their needs
Understanding your key stakeholders and building empathy for their needs within the team is at the core of the Product Owner’s responsibilities. Your key stakeholders include all parties invested in the product you are building. This group includes everyone from your end users to your first level support team to your executive team. Basically, if they are impacted by your work, then he or she is a stakeholder. That being said, not all stakeholders are created equal in the context of the vision. The work of identifying, categorizing and prioritizing, and understanding the needs of these stakeholders is the job of the Product Owner. Given this unique vantage point, the Product Owner is responsible for negotiating and communicating with the stakeholders to make scoping and timing decisions (More on this later). To build products that meet or exceed customer expectations, you must connect with your stakeholders and their needs at a personal level.
Bring the customer closer to the team
The people using your product and those paying for you to build that product need to be brought closer to the team. The interfaces, layers, and structures built to separate the doers from the requesters have caused a huge communication gap. This is an obvious issue that most of us saw the repercussions of as children while playing the telephone game. In the telephone game, kids line up and the first child in the line is read a sentence. Then, they whisper the sentence to the next person in line. Then, that child whispers what they heard to the next person in line. This continues until the last person in line receives the message. When the last person in line tells the group what they heard, it is always something completely different from the original message. This is not a problem that can be overcome by documentation, as a document is simply another communication medium and creates another node in the chain from customer to doer. This is why we seek to close this gap and allow team members to communicate directly with customers. The Product Owner is not intended to be the gateway to the customers, just an empathetic representative with decision power. The more distance you put between the team and the customer, the higher the probability of building the wrong thing.
Tactical Communication
The Product Owner is responsible to the team for ensuring they have the information necessary to deliver. This means that the Product Owner must make themselves available for day-to-day discussions with team members to clarify feature requests and answer detailed implementation questions to keep the team moving forward. These daily discussions allow the team to avoid making assumptions or shifting tasks due to unanswered questions. Customers usually can’t commit to daily interaction; A Product Owner must.
Why Economics with Transparency?
Economic frameworks with transparency of decisions provide the foundation for the decentralized authority of the Product Owner to make scope and steering decisions about the product without the blessing of a committee or an approval process. This allows you to reduce the cost of making decisions and in turn, increase the value delivered to the customer and the company. This also enables the Product Owner to make objective decisions and protect them from emotional bias. Leveraging economics with transparency to gain the ability to decentralize authority to the Product Owner is a powerful competitive advantage.
How does the Product Owner employ Economics with Transparency?
Manage the Product Backlog
The Product Owner is responsible for managing the Product Backlog. The Product Backlog is a stack-ranked list of features and functionality yet to be built. There are four key ways the Product Owner manages the Product Backlog. One, he is responsible for maintaining the stack-rank of the items through prioritization based on economics and negotiation with stakeholders and the team. Two, he is responsible for ensuring the items have the correct level of detail based on their position (top, middle, or bottom). Three, he is responsible for ensuring the items are estimated. Four, he is responsible for ensuring the Product Backlog is visible to the team and key stakeholders. Managing the Product Backlog through these four key responsibilities, the Product Owner enables economic decision-making, a steady flow of work to the team, and transparency into what the team plans to work on next.
Create and communicate Product Roadmap
The Product Roadmap is owned by the Product Owner and is intended to provide the team and key stakeholders visibility into the forecasted future. The Roadmap should show the planning or release cadence through time-bound intervals, the features that are planned for each interval, and the business objectives the feature set is meant to achieve. This visual is built through collaboration with the team and key stakeholders. This artifact should be at a high-level, containing just enough information to clearly communicate the currently projected deliveries. Given that the Product Roadmap is a point-in-time representation of the forecasted future, it must be maintained as a living document, continuously being updated based on the latest information from the market, the team, and the organization. A Product Roadmap that is well crafted at the right level of detail and easily understood at a glance is a powerful tool for communicating the projected path of a team and/or a product.
Identify Minimum Marketable Features
One important way that a Product Owner can manage the economics of a product is to identify Minimum Marketable Features and Feature Sets. A Minimum Marketable
Feature (MMF) represents the minimum amount of functionality required to release a product. This is an extremely important construct, due to the speed at which markets change and evolve. By employing MMFs, we can speed our time-to-market and gain valuable feedback directly from our customers based on real, working product. Ideally, the Product Roadmap is built based on MMFs, with each interval delivering an MMF to market. The earlier we can deliver an MMF, the more time and flexibility we have to adjust our plans to match the true customer needs.
Provide team with decision rules
Another adjustment in how agile teams approach the work is a focus on decentralized decision-making. We already know that decisions for the direction of the product are decentralized to the Product Owner, but there is an opportunity to further decentralize the very small decisions to the team. This is only viable if the Product Owner creates and clearly communicates a decision model for team members to follow. This allows the small tweaks that were once forbidden to now become economically viable. By this I mean that if we can make small adjustments without the overhead of a formal change control process, we can increase the value of the adjustment by reducing the cost of the decision to do it. With this model, small value-add tweaks made by the team can have a sizable economic return.
Communicate to the larger whole
The Product Owner is responsible for making decisions visible outside of the team and for communicating the product direction and the status of forecasted deliveries. Through transparency of progress against forecasts and product scoping decisions, the Product Owner manages stakeholder expectations and the risks inherent in decentralizing decision-making authority. There are a countless number of ways to achieve this high level of transparency, all of which follow the pattern communicate, communicate, communicate, and communicate again. Product Owners that have been highly successful in creating transparency have used many different mediums for communicating. They use easily understood visuals and graphs, clear and concise emails and status reports, and frequent face-to-face communication. However transparency is implemented, the goal remains the same; full disclosure.
There are many changes in the way teams approach the work in an agile environment and the Product Owner plays a key role in shaping that approach. To enable the transition to an agile approach, you must invest in Product Owner Competency that focuses on building empathy for the customer and managing product economics. Great code does not equal great products. Great code enables us to solve complex problems. However, without empathy for our users and economics to drive decisions, our great code may be wasted solving the wrong problem.
Agile Sean 
Posted on August 9, 2012
0