Connecting product and technology work to business priorities.

In a previous product and technology leadership role, I introduced a quarterly operating rhythm to help an around 60-person B2B fintech/regtech company focus its product and technology effort around clearer business goals.

Before this, the organisation had too many competing priorities.

Sales might push for a feature to help land a new customer. Customer success might push for a fix to retain an existing customer. Product and technology might be trying to improve reliability, reduce technical debt, or make progress on a longer-term product direction.

Each of those things could be valid in isolation. The problem was that there was no clear mechanism for deciding which mattered most at that point in time.

The result was constant switching, bloated roadmaps, slow flow, and reduced confidence in product and technology. Teams were busy, but the organisation was not always aligned around the same outcomes.

What was getting in the way

Product and technology were often treated as delivery functions.

Work would be escalated, reprioritised, added to the roadmap, removed from the roadmap, or pushed directly to teams because something had become urgent somewhere in the business.

That created a few problems.

First, it slowed everything down. Starting and stopping work meant less actually got shipped.

Second, it made trust harder. When priorities kept changing, product and technology looked unreliable, even when the real issue was the operating model around them.

Third, it made technical and product trade-offs hard to explain. Work on reliability, quality, infrastructure cost, technical health, or product foundations could be important, but it was difficult to show its value compared with a visible customer request or revenue opportunity.

The organisation needed a better way to agree what mattered, show the trade-offs clearly, and keep the whole business aligned long enough to make meaningful progress.

What I changed

I designed and introduced a quarterly planning rhythm called the Quarterly Climb.

It was both a planning mechanism and a change to the operating model. The aim was to align the organisation around the most important goals for the quarter and connect product and technology work to those goals more clearly.

The centre of it was a single document.

That document started with a short story for the quarter: a simple explanation of what the organisation was trying to achieve and why. It needed to make sense to the board, the executive team, product, technology, sales, customer success, and operations.

Underneath that, we made the relevant KPIs explicit. Where were they now? Where did we want them to be by the end of the quarter? Why did those movements matter?

The document then broke the quarter down into the goals that supported the story. Some were product and customer experience goals. Others were capability goals, such as improving the operating model, investing in innovation, introducing AI, or making technical improvements that enabled future progress.

The point was not to create another bloated KPI dashboard. The point was to create a simple alignment tool that made the quarter easier to understand, discuss, and manage.

Product managers created the first draft for the following quarter. They gathered input from sales, customer success, finance, operations, product, and technology, then refined the plan with the leadership team before the quarter began.

This also changed the role of product managers. They moved closer to the centre of business decision-making. Instead of mainly taking requirements and turning them into delivery plans, they became responsible for shaping product direction, explaining trade-offs, and connecting product work to measurable business progress.

What changed

The leadership conversations became healthier.

Before, the conversation was often some version of "why is this taking so long?" or "why can't we do more?"

After introducing the Quarterly Climb, the conversation became more grounded. The business could see the competing priorities in one place, discuss which outcomes mattered most, and understand the trade-offs involved.

For example, if the organisation wanted to spend 10% of its effort on innovation so it could adopt AI properly, that choice became visible. It was no longer an abstract request for time. It was a deliberate trade-off against other work, with a clear reason attached to it.

That visibility made it possible to protect innovation work that would otherwise have been squeezed out by short-term demands.

It also helped different functions find shared value. Sales and customer success might start with different requests, but the planning process created space to ask whether one piece of product or technology work could support both goals.

The organisation moved away from prioritising whoever had the most urgent escalation and toward prioritising the work with the clearest business value.

What improved

Product and technology started to rebuild trust by making their commitments clearer and their progress easier to see.

When teams delivered what they had committed to in the Quarterly Climb, confidence improved. When they did not, there was now a single place to understand why.

That transparency mattered. In some early quarters, work still got interrupted by top-down reprioritisation. The difference was that the impact was now visible. If one piece of work was stopped halfway through and replaced by another, and neither shipped, the organisation could see the cost of that decision.

That became a useful teaching tool. It helped explain why focus mattered and why changing priorities midstream had a real cost.

The rhythm also reduced competing priorities for teams. More of the work was shaped through cross-functional discussion before it reached product and technology. That meant teams were less likely to be pulled between disconnected requests, and more likely to work on things that supported multiple business goals at once.

Over time, the conversation shifted from activity to outcomes. Product and technology were not just reporting what they were working on. They were showing how the work connected to customer engagement, customer satisfaction, revenue, velocity, reliability, innovation, or other relevant measures.

Why it mattered

The useful change was not the document itself.

The value was in creating a better operating rhythm for the business.

The Quarterly Climb gave the organisation a shared way to decide what mattered, communicate trade-offs, protect focus, and understand progress. It helped product and technology become less of a reactive delivery function and more of a strategic part of how the business moved forward.

It was not a perfect OKR system, and it was not a one-shot fix. Some metrics were imperfect. In places, we used proxies while improving how the data was captured. Different parts of the organisation still had different levels of maturity.

But that was the point of the approach. It did not depend on pretending everything was perfect before changing how the organisation worked.

It created enough clarity to build momentum, and enough momentum to keep improving.

For me, this is a common problem in growing product and technology organisations. The teams are usually working hard. The harder problem is whether the business system around them helps that effort turn into meaningful progress.

Start with a clearer view of what is getting in the way.

If your product, technology, or AI work feels harder than it should, HRVN can help you talk through the situation, make sense of the problem, and decide what kind of support would be most useful.

Talk through what's getting in the way [email protected]