The quarter that lasted a week

Last quarter, we had just finished the quarterly planning cycle. The QBR was done. The business review of priorities was signed off. The roadmap had been socialised, the dependencies were mapped and every squad knew what it was picking up and in what order.

That is about as settled as product work gets.

For roughly a week, the plan was the plan.

Then an industry-wide cyber issue triggered an urgent remediation across financial services. The exact technical detail is not the point of this story. What mattered was the speed at which the operating context changed.

Codebases had to be reviewed. Internet-facing exposure had to be understood. Teams that had spent weeks debating the sequence of roadmap items were suddenly tracing dependencies, checking controls and closing gaps.

Squads paused. Engineers moved onto the remediation. Delivery plans that had been defended line by line only a few weeks earlier stopped mattering in an afternoon.

My first instinct was to protect the plan

Product owners are trained to protect focus. We hold the line against the request that appears from nowhere, the stakeholder who wants their item at the top and the piece of work that is urgent mainly because somebody senior has called it urgent.

Protecting the squad is not stubbornness. It is what makes sustained delivery possible.

So when the cyber work landed, I reached for the familiar questions.

What is the actual scope? What can be deferred? What can we keep moving? How much of the quarter can we save?

It took me about a day to realise that I was asking the wrong questions.

The prioritisation we had just completed was designed for a reasonably stable environment. QBR and the business review of priorities, or BRP, are useful when we can see the options, understand the dependencies, estimate the effort and compare value with some confidence.

They are much less useful when we do not yet know the shape of the problem.

I was trying to use a ranking method in a situation that did not yet support ranking.

An old framework came back at the right time

On the second day, I remembered Cynefin.

I had studied the framework during my MBA, filed it under interesting and then barely thought about it for years. In the middle of the remediation, it became the most useful idea I had in my head.

Cynefin is a decision-support framework developed by Dave Snowden. Its central idea is simple. Different situations call for different ways of making sense and acting. The mistake is not using a bad method. It is using a method that worked in one context after the context has changed.

In the clear domain, cause and effect are evident. We can sense what is happening, categorise it and respond using established practice. This is where routine work and standard controls belong.

In the complicated domain, cause and effect can be understood, but expertise and analysis are needed. This is where much of planned product delivery sits. We can estimate, sequence and make trade-offs because the problem is knowable.

In the complex domain, we cannot reliably work out the answer in advance. We need to probe, observe what happens and adapt. Practice emerges as we learn.

In the chaotic domain, the priority is to create enough stability to make sense of the situation. We act first, then assess the response and adjust.

The framework helped me see that the question was no longer, “How do I protect the roadmap?”

The question was, “What kind of situation are we in now, and what response belongs here?”

The route we actually took

1. Get out of chaos

In the early phase, there was little value in debating roadmap priorities. We did not yet know the full exposure. The sensible response was to act, see what the action revealed and act again.

Contain. Audit. Patch. Verify. Repeat.

My job was not to save as much roadmap work as possible. It was to remove unnecessary decisions, give engineers a clean surface to work on and keep stakeholders clear about why the operating mode had changed.

Ranking is a luxury of order. You do not get it until you have created some.

2. Move from chaos into complexity

Once the immediate exposure was contained, we could see more of the problem, but not all of it. This was where prioritisation quietly returned, although not as a ranked backlog.

It returned as a series of probes.

We took on a small number of urgent risk items alongside the remediation because they helped us learn more about the system while we were already inside it. Each piece of work gave us more information about the estate, the dependencies and the remaining exposure.

We were not yet planning and executing. We were acting, learning and adjusting.

3. Move from complexity into complicated work

Eventually, the problem became clearer. We could analyse instead of guess. We could size the remaining remediation, identify dependencies and understand what capacity was genuinely available.

That was the point at which strategic roadmap work could restart, and not a day earlier.

We ran planned work in parallel with the cyber activity at reduced capacity. The split was stated openly rather than hidden inside optimistic delivery dates.

The ordinary machinery of product delivery began working again because the situation had become one in which analysis, expertise and sequencing were useful.

4. Move from complicated into clear

The final step is the one organisations often rush.

The work is not finished when the immediate fixes ship. It is finished when the learning becomes part of normal operations.

The scan becomes routine. The check becomes a pipeline step. The exception becomes a standard. Ownership is clear. The control is measured.

Without that step, the organisation has left the incident but not necessarily reduced the chance of returning to it.

What this changed about quarterly planning

A prioritisation ceremony produces a ranked list. It does not, by itself, produce the ability to prioritise.

Those are different things, and organisations that run planning ceremonies well can easily confuse them.

Our QBR and BRP told us what mattered under an assumed set of conditions. When those conditions changed, the order of work changed with them. The artefact had a short shelf life, but the shared understanding behind it remained useful.

We knew what each item was trying to achieve. We understood the cost of delay. We knew which dependencies mattered and which stakeholders needed to be involved. That understanding helped us make new decisions quickly, even when the old sequence no longer applied.

This is why I now see quarterly planning less as an exercise in producing the answer and more as an exercise in building a shared understanding of the choices.

The answer may last a quarter.

The understanding should survive the quarter.

The squads that adapt fastest are not always the ones with the most detailed plans. They are the ones that can recognise when the nature of the problem has changed and are willing to change their method with it.

Four questions I now ask when the plan is overtaken

My job that week was not to protect the squad from disruption. That was never on offer.

It was to help people see that we were no longer playing the same game and that the methods which had served us well a week earlier were not the methods we needed now.

The real job of a product owner is to make the cost of decisions visible. That week reminded me that the job also includes recognising when the cost cannot yet be calculated with confidence and having the nerve to say so.

Sometimes the most useful thing you can tell stakeholders is this.