You need both the big and the small picture to deliver value.

You need both the big and the small picture to deliver value.

The concepts of project and product provide two alternatives that might lead readers to believe that one perspective is more important than another. You need both sets of behaviors generated by the project and product perspective. How these behaviors are incorporated into roles on teams is not as straightforward as designating a role representing project concerns and a role representing product concerns and never the twain shall meet. Both roles do not have to be separate people. Agile spreads the project-centric behaviors across the entire team. Even the product owner typically absorbs some of the project-centric activities. However, other than at a philosophical level, the team is not typically charged with performing the product-centric activities. Agile techniques spread project behaviors across the team while product driven behaviours are more concentrated.

Project-centric behaviors are focused on the delivery of the tactical plan, while the product owner has more of a focus on the vision of the long-term future, i.e. the product roadmap. Even though the product owner has a distinct interest in the tactical (what is to be accomplished in a sprint or release), the team has a more focused interest in day-to-day activities. The team must plan, monitor and adjust the day-to-day activities needed to meet their commitments during the sprint (commitments in Agile are by definition tactical). The product owner can contribute, however they typically do not have the technical acumen to deliver functional software. However, without a product view, the day-to-day project considerations will typically trump long-term considerations. In a mature Agile environment, the product view interacts with the project view to generate an equilibrium between long- and short-term perspectives.

Project and product focuses require a different measurement. The project focus on delivery/short-term goals generates a need to understand, pursue and measure delivery efficiency. Efficiency is a measure of transformation; how much of a set of raw materials is needed to create an output. Efficiently producing any output is only valuable, IF what is being produced is what is needed and can be actually delivered. Interestingly most software is a step toward a different product that is bought or used. Because the software being developed or enhanced is a step along a path, the value assigned often does not represent the ultimate impact to the organization (See our Re-Read Saturday series on The Goal for more on this topic). The product owner, as the steward of the product perspective, owns the definition and measurement of value. He or she needs to take the big picture view of what the market needs AND what the market will pay for. What the market will pay for is just as important for an internal product as an external. In order to understand the value a product delivers, the product owner must ask whether the result of a sprint or release positively impacts ROI, profit and cash follow. Efficiency is a mechanism to determine whether a team is making the most out of their “raw material,” but it does not provide feedback on whether what is being produced is the right thing, or whether the functionality delivered yields value to the organization.

In general the product owner will be the champion for the product perspective, however every team member needs to have an understanding of the how the future should unfold and the value they are being asked to deliver. The team will need to temper the product vision based on the constraints that the day-to-day environment provides. Both the project and product perspectives are needed to maximize value. Putting either perspective ahead of the other for any length of time will create an imbalance that will reduce team effectiveness.