How to determine which decisions you should make

When I was the product owner at Agile Alliance, we built a custom conference registration system because we believed it required a tight connection to our membership system.

It gave us some of the distinctive capabilities we wanted. But as we struggled to support the first conference, we realized it was missing table-stakes features attendees expected. We also figured out we didn’t need to integrate the systems as tightly as we thought.

We ran into difficulties because we treated several decisions as though they were one.

Backlog prioritization is only one horizon of product ownership

Most people think product ownership primarily means prioritizing the backlog. But product owners of business systems also play a role in deciding whether a problem is worth solving and what form the solution should take.

I think of those as decisions in three horizons: strategy, initiative, and delivery.

Deciding whether to solve a problem is a strategy decision.
Determining the form the solution should take is an initiative decision.
Prioritizing a backlog is a delivery decision.

It’s helpful to understand where decisions fit into these three horizons so you can clarify decision rights and make sure the right people handle the right decisions.

By the time a problem reaches the product owner for a business system, someone has often already suggested a solution. The work can quickly become a question of what to build, configure, or prioritize next.

Before you decide what to do with that proposed solution, it helps to ask What decision are we actually trying to make?

Deciding about conference registration

Agile Alliance’s Executive Director changed how we registered people for conferences. He made that decision alongside an effort to redo the organization’s website and membership system.

That connection was intentional. Agile Alliance offered registration discounts to members, so the Executive Director wanted to make it easy for members to receive the discount. He also wanted to prevent people who were not current members from receiving the member’s discount.

That was a strategic decision. Agile Alliance had decided that improving conference registration was worth investing in, and that the registration, website, and membership work needed to support a broader member experience.

The first initiative decision was to build the conference registration system from scratch as part of the website project. The digital agency Agile Alliance selected to build the new website recommended that approach. Their recommendation reflected an interpretation of the requirement: membership and conference registration needed to be integrated in order to apply member discounts and prevent misuse.

I was part of the group that reviewed the agencies’ proposals, but the Executive Director had the ultimate decision. Once the work began, I took responsibility as product owner for the website, membership, and registration efforts. I made many of the day-to-day decisions about the functionality we needed, what to do first, and what we could defer.

As the project proceeded, we fell behind schedule. We were running out of time to support upcoming conferences, so we had to make tradeoffs about what to build from a registration standpoint.

The result was a system with the unique features we had asked for, but without many of the table-stakes features attendees expected from conference registration systems.

As we limped through supporting the first conference, we realized we didn’t need to tightly integrate the membership and registration systems. We could still give members their discounts and prevent fraud without building and maintaining a custom registration system as part of the website.

That changed the initiative decision.

I drove the decision to switch to a purchased conference registration system for the next conference we ran. We hadn’t changed our minds that conference registration was worth improving. We changed our understanding of the problem and, therefore, the form the solution should take.

The three horizons often inform one another, and they are not a one time sequence. New evidence from delivery can force you to revisit an initiative decision. But it shouldn’t automatically force you to reopen the strategy decision.

The strategy horizon: Is this worth solving?

The strategy horizon is where you consider the needs of your customers in relation to your organization’s strategy and determine what initiatives you will, and will not, pursue.

The strategic question you ask is: Is this need worth satisfying?

For Agile Alliance, the strategic decision was not should we replace the registration system? It was whether changing the conference-registration experience was worth the investment, particularly because registration discounts were a membership benefit.

That type of feedback may be a sign that you have significant issues with your conference registration system that require a significant investment rather than a few small changes.

You may not own the final strategic decision. In many organizations, a founder, executive, or sponsor controls the investment. But as the product owner, you often see the signals first, such as recurring workarounds or poor adoption. Your role is to make the underlying need and the tradeoffs visible so the right person can make an informed decision.

To make a useful strategic decision, you need to understand:

The actual need, not just the symptom.
The impact on customers, members, attendees, employees, or other people the system serves.
Whether the benefit of satisfying the need outweighs the cost of doing so.

If those answers are not favorable, stop working on the idea.

That can feel uncomfortable. Teams are often much more comfortable deciding how to address a request than explicitly deciding not to address it. But “not now” is a legitimate strategic decision.

The initiative horizon: What form should the solution take?

Once you decide a need is worth satisfying, decide how you will satisfy it.

The questions in this horizon include:

What outcome are we trying to achieve?
What solution options could help us achieve it?
Should we create something new, change an existing system, purchase a product, or pass for now?
If we buy, are we willing to work within the product’s capabilities rather than customize it into something unrecognizable?
Should we continue, change, or cancel the initiative as we learn more?

This is where you as a product owner need to resist treating the first plausible solution as settled fact.

At Agile Alliance, the initial answer was a custom-built system because we believed membership and registration had to be tightly coupled. Experience with the first conference proved that assumption wrong, which reopened the build-versus-buy decision.

The point is not that buying is always better than building. The point is that the team should choose the solution after understanding the problem, rather than assuming the request already contains the answer.

The delivery horizon: How will we make the solution work?

The delivery horizon is where the familiar product-owner work happens.

You decide which aspects of the selected solution to deliver and in what order. You decide whether the team has enough shared understanding to make a change. You decide whether a set of changes is viable enough to release.

As product owner at Agile Alliance, I made delivery decisions about the functionality to include and defer. Schedule pressure meant the first system delivered specialized capabilities but missed registration features attendees considered basic.

A poor configuration can create a frustrating registration experience. A backlog that does not reflect the desired outcome can consume a lot of effort without delivering much value.

But delivery decisions should follow from the decisions made in the other two horizons.

A three-horizons decision filter

Before you turn a request into work, pause and ask these questions.

At the strategy horizon

What actual need are we trying to satisfy—not just what symptom or requested change are we hearing?
Is the benefit of addressing that need worth the investment compared with the other needs competing for attention?

At the initiative horizon

What outcome would tell us we solved the need?
What solution approaches should we consider before we commit to one?
Do we need to create, change, buy, build, or pass?

At the delivery horizon

Given the selected solution, what is the smallest viable change we should make next?
How will we know the change works for this specific context, customer, or event?

In the conference example, applying these questions earlier might have surfaced the assumption about tight integration before we committed to building a custom system.

Product ownership is more than backlog ownership

A reasonable objection is that product owners do not have the authority to make strategic investment decisions or approve a major initiative.

That’s often true.

You don’t need to own the final investment decision to improve its quality. Your contribution may be to show that several small requests share an underlying problem, clarify the outcome the organization needs, describe the options, and make the tradeoffs visible.

That gives the founder or other decision-maker something better than a request for a feature. It gives them a decision they can actually make: invest, defer, or change direction.

When we learned that membership validation did not require a tightly coupled custom registration system, we did not need to revisit whether conference registration mattered. We needed to revisit what form the solution should take.

So the next time someone brings you a request for a system change, do not start with, “Where does this fit in the backlog?”

Start with: What decision are we actually trying to make?

Reply and tell me about an example where you made decisions in some, but not all, of these horizons.