The question of whether a Product Owner (PO) should adapt priorities to the skillset of their team provokes a sharp divide.

On one side, there's a clear and principled stance: business value comes first.

On the other hand, a more nuanced view acknowledges the reality of constraints, particularly when a team simply can't deliver what's being asked—at least, not yet.

The Case Against Changing Priorities

The most emphatic answer to this question is simple: no.

Changing business priorities to suit the team’s skills is seen as a case of “the tail wagging the dog”.

The PO's responsibility is unambiguous: focus on what brings the most value to the customer.

The PO’s role is to maximise value, not simply hand out tasks that feel comfortable for the development team.

In this view, business needs don’t fluctuate based on internal capability.

If a team can’t deliver on a priority, change the team—not the priority.

The Case for Adaptability

But reality rarely conforms to ideals.

If two backlog items offer similar business value, choosing the one that aligns with the current team’s skills might make sense.

Even when one item holds more value, if the lesser item can be delivered significantly faster, that too may be worth prioritising.

This isn’t about downgrading strategic vision—it’s a tactical adjustment.

A skills gap can shape how the PO sequences work, without redefining what the long-term goals are.

And sometimes, the absolute priority becomes clear: the team must acquire the necessary skills.

When this is possible, skill acquisition itself becomes the first-order priority.

Constraints as Signals

In practice, feasibility matters.

If the team can't realistically deliver on what's top of the backlog, priorities might need to shift.

But rather than just reacting, this becomes a moment of strategic awareness.

The need to change priorities is not failure—it's valuable data.

The correct response isn’t only to reshuffle; it’s to ask: “What would the team need to deliver the most valuable work?”

The Role of Empiricism and Continuous Improvement

Scrum’s foundation in empiricism provides a path forward.

Inspect, adapt, and be honest about current capability.

A skilled Scrum Master can guide this reflection.

During retrospectives, a team might recognise they lack what’s needed to evolve the product.

At that point, the team has a responsibility to act.

Addressing Skill Gaps: Strategic Options

What can a team do when skills fall short?

A few options surfaced repeatedly:

Expand the team with new hires to cover gaps (though this risks inefficiency if done recklessly).
Invest in training to develop required skills (a longer-term play).
Reconfigure the team, which might involve letting people go and bringing in new expertise.
Or adopt a hybrid approach combining all of the above.

But there’s a deeper question too: is the team even empowered to make these changes?

This ties back to their working agreement and the broader organisational structure.

What This Really Tells Us

There’s a powerful principle at play: business priorities should lead.

But in practice, team capability defines the edges of what’s possible.

The correct answer isn’t rigid adherence to strategy or blind adaptability — it’s the ability to recognise when a skills gap is an obstacle, and when it’s a signal.

When used well, these moments become inflexion points.

They prompt better questions:
Are we building the right thing?
Do we have the people who can build it?
Are we investing in growth, or reacting to limitations?

A Product Owner’s job isn’t to bend to team comfort.
Nor is it to bulldoze forward regardless of feasibility.

It’s to navigate the tension between value and capability — with clarity, empathy, and a relentless focus on what moves the product forward.

Should a Product Owner Change Priorities to Match Team Skills?