As the product owner, you are responsible for the product’s vision, and ultimately, the value of your product. You “own” the backlog. If your responsibilities include upstream product management—what I refer to as strategic product ownership—then you also shepherd your product through its entire lifecycle.
Bottom line, your prime responsibility is deciding what to build and when to build it. Your decisions guide not just the health and well being of your product, but also all the people engaged in product discovery and delivery.
Yet a common product ownership struggle I see in agile teams—regardless of industry and product type—is determining how to make decisions. As an agile coach, I use a pattern I call “Decide How to Decide.” It’s a simple technique to help people make transparent, participatory, and trusted decisions.
Start with Your Decision Rule.
A decision rule is a mechanism to reach closure. It communicates to everyone how—and when—a decision has been made. Here are several common decision rules.
Notice the two rules categorized as “participatory,” Decision Leader Decides after Discussion and Consensus. These are ideal for agile teams. They engage stakeholders and typically result in decisions that are more sustainable. You need that type of buy-in for the high stakes decisions you make all the time as part of agile product planning and analysis. My work with agile teams shows, again and again: using a transparent, participatory decision-making process helps everyone—not just you, the product owner.
But be careful! Many agile teams have a misconception about consensus. Consensus is a form of agreement in which everyone is of “one mind”. Sure, some decisions are best made by consensus, for example, a decision on the time and location for your team’s daily standup.
However, product decisions rest firmly with you, the product owner. Decisions about backlog refining, planning and validation—what goes in, what comes out, what the optimal sequence is, which items will be pulled for the next delivery cycle, what metrics you’ll use to validate your delivery choices, and so on—these decisions need to be made by you, the product owner—after discussion with your product partners.
Making Decisions
The first step is clearly defining what needs to be decided and sharing it with the appropriate participants. These participants are typically a mix of product partners from the business, technology and customer communities. Since your product partners have deep and broad product knowledge, and often care passionately about the product, you need to find out where they stand on the decision before you finalize it.
A tool I use is the gradient of agreement (see below). It goes beyond a simple yea or nay, using a scale of four levels of agreement. This continuum helps people express their degree of accord with the proposed decision quickly and efficiently.
For the proposed decision, ask the participants where they stand along the gradient of agreement. You ideally want people to be in “the zone of agreement” (“1’s and “2’s). When there are any “3’s” or “4’s”, pause. Ask for background on why those not in the zone of agreement can’t support the decision as-is, or are vetoing it. Their perspectives may provide new insights about the proposal and lead to possible adjustments. If you do adjust the proposed decision, repeat the polling. In my experience, most teams reach agreement in one or two iterations of proposal generation, narrowing, and checking for agreement.
Consider Not Owning Every Product Decision
There are situations where it may be wise to assign decision-making authority to someone else. (You do, however, need to decide how to decide and be explicit about who is the decision leader). Take, for example, a decision about technical architecture. Unless you have deep technical expertise, it’s wise to have a lead architect be the decision leader.
Just because you might choose not to own that final decision, doesn’t mean you aren’t engaged in decision-making. “Decision Leader Decides after Discussion” is a participatory decision rule. This means the right people need to be consulted—including of course, you! Your knowledge about product strategy, customer problems, market risks, competitive intelligence, and more, are crucial to making a solid technical architecture decision.
Case in point: I recently worked a delivery team that on their own made a decision about the product’s technical architecture. They were unaware of regulatory changes on the horizon that would have significantly influenced their choice. In retrospect, discussing the choice with the product owner, prior to making a decision, could have prevented an unfortunate and costly mistake.
The Value of Transparent Decision-Making
The act of explicitly deciding how to decide has a powerful effect on agile teams. It promotes accountability and empowerment. It proactively incorporates seeking input and expertise to deliver the best product possible. The bonus—it concurrently builds trust and transparency.