Building Product Ops 0-1: Month 9 of 12
How I build Product Ops in (near) real time - part 9
This is a continuing series of articles documenting, month by month, a full year of building a brand-new Product Operations function at HeliosX, a rapidly scaling, now £750m+ HealthTech. It is designed to show you the journey; it’s not a warts-and-all exposé.
I make no apologies that this focuses on the achievements, the methods and how we overcame challenges in a positive light, showing a practical journey with details to reuse and take away. It is still my job, after all!
This series is not an advertisement for the company, but is published with the blessing of HeliosX.
Read Month 8 here:
---
The summer is here (well, in the UK for about 17 minutes) and eyes are beginning to turn slowly to both the end of the year and 2026. In this edition, I focus specifically on Planning, as well as providing some updates on existing high-profile projects - which allows me some space to dive into the details of a key aspect of Product Ops enablement.
Quarterly planning timeline
Ah, planning... so often the topic of choice for product management commentators. What is too much, too little, how often, why bother planning at all...
Well, 'how we do' product planning is something we have iterated on consistently here at HeliosX, and this month we have taken a bigger leap and mapped out who does what, when and with whom.
For context, the business as a whole largely does its planning/replanning quarterly. I don't believe there is a right or wrong cadence personally, but I strongly believe that whatever that cadence is, it should be shared and aligned to, by all divisions.
And so our typical scenario has been to get to the month prior to the quarter, start thinking of what is next, and spend many hours in groups planning, crafting roadmaps, Initiatives, booking more meetings with stakeholders, etc I am sure this is a familiar story to many readers. In truth, 'thinking of what is next' is more a case of 'vocalising what is next', our PMs are typically on the ball with their longer-term plans - business pivots notwithstanding.
One of the (many) issues with this approach is the lack of thinking time, particularly with stakeholders and dependent teams - others who need to take action for your plans, or theirs, to succeed. Often, other internal teams around the business will be making their own plans and rely on product outputs to progress/deliver on time, or they need you to be lined up for their rollouts.
Another issue already mentioned is that of a time-sensitive, fixed volume of work condensed into a limited window, while also keeping the lights on elsewhere (executing on the previous plans).
So what have I done?
I've stretched it!
The first thing to do was understand just how much time we actually have available - and the answer is a full quarter. (Tick)
I am a very visual person, so I started to map out the time available as a timeline, split the quarter into 3 months, and then plumbed in key fixed dates - in particular a key strategic planing date for the whole business, which is a key decision-making time and one product has a big influence in, and vital we do influence in.
And so leading up to this key event, we need to ensure the key attendees within our own division are aware, aligned and agree with the specific initiatives proposed - that they are able to represent the product plans, making strong arguments and confidently answering questions. So built into the timeline are 2 checkpoints, at the end of each month, to discuss the planned initiatives with specific PMs, query the plans, and help them refine.
The plans are those of the PMs; they have significant autonomy based on overall business objectives - product leaders' role at these checkpoints is to encourage the refinement of the ideas, query any gaps, ensure cross-functional needs are explored, and absorb the plans ready to promote and defend them at the higher levels.
Why 2 checkpoints?
We are stretching the planning time to allow for the right conversations to happen at the right time, providing more capacity for discussion and thinking time in between, and for iterations of discussions too - refinements, new ideas and approaches after the first meetings, particularly with stakeholders around the business. Those stakeholders, often division leaders, will have their own plans to discuss and align to, and compromises happen, and original plans need to change. Those new plans and adjustments will be discussed within their own divisions, challenges and new ideas will come to the fold, and the next iteration of discussions can happen.
All of this previously was either very rushed with no time for this iteration, or compromise was difficult to do without thinking time, discussions with other colleagues - unless you got half the business in a big room together, the process relied on the information to hand at that moment, or worse, dictating plans from one team to another without change.
So our stretched timeline allows for more discussion and iteration - and those iterations and updates need to be known by the product leadership in their absorption of the plans.
Details
Additionally, I spent time understanding exactly what details and level of detail were needed at different stages of the planning process, against the likelihood of change and the risk of wasted effort. Assets such as PRDs (no groans at the back!) and high fidelity designs are higher risk to produce early than later in the process. This is about balancing the amount of detail and resources with the value they hold at different points on the timeline; at different points of the lifecycle of the individual initiative.
To that end, Month -3 (3 months before the quarter, and the first month on the planning timeline)is all about high-level ideas with enough research and analysis to safely say 'Yes, this idea is worth going after and here is why'. At Checkpoint 1 at the end of that month, this is the level of detail shared.
In Month -2 (2 months before the quarter start), more detail, more research, more conversations and more alignment, all in preparation for the business strategic planning sessions. But still no PRDs, no roadmaps (though a sequenced plan is sensible), no sprint plans. Because things can still change significantly. Only as much detail as stakeholders in and out of the product division need to be aligned.
Into Month -1, business decisions have been agreed, product initiatives have been approved, now the teams can proceed with execution plans knowing the business and stakeholders are aligned and plans are 'fixed'... as much as ever will be. The likelihood of assets and documentation being wasted and not used is low. All of this is with plenty of time to produce these assets and roadmaps and gain specific delivery alignment.
Cognitive load
Our timeline across 3 planning months covers key planning and review sessions, makes recommendations for assets and details to produce for each, with allowances given for how long these key tasks and collaborative events will take to achieve. Additionally, and something I have used a few times in building planning and delivery schedules, as well as on the timelines, is an indication of WHO is required for each key event. From PMs to engineers and designers, to product leadership, squad/product stakeholders and senior leaders - who are expected to be involved. This helps both squad leads know who to be reaching out to, as well as setting expectations amongst irregular contributors such as stakeholders and SLT.
But why stretch this out over the 3 months?
Aside from the difficulty of trying to align many key staff to a small window of opportunity (and assuming they are available on our timescales), a big factor here is cognitive load. Our teams are still working to deliver initiatives and products - they do not stop in the final weeks of the quarter and dedicate all their time to planning. All of the above conversations, thinking, negotiating, and asset delivery happen on top. Doing this in smaller chunks over a longer time, on balance, is just better, more collaborative and lessens the intense pressure in a constrained environment and timescale. There is more wiggle room, balanced against instances where plans significantly change between the start of planning and the end/start of delivery. But to be fair, such things happen at any time whether planning has happened or not!
At the time of writing, we have rolled this out to about 60% of the squads and trialling this in our current planning cycle in preparation for Q4. So far, I have had very positive feedback from both ICs and leaders, and we recently completed the first checkpoint review, which was well executed by the product managers and delivered exactly what was expected (kudos all round). Everyone gets the theory, and the reality seems, so far, to be living up to expectations.
Zentrik Pause & AI Tools Rethink
In the previous update, I wrote about the pilot we were kicking off with Zentrik - a product management AI platform that takes on the bulk effort of creating PRDs, feature documents, tasks, epics, etc.
In our first review as a team, we decided the platform - at this time - is not right for us. In part, we felt that at this time, the specific outputs we were so keen on - the ability to write accurate user stories for our teams - were too generic and not specific in comparison to what the teams were creating in parallel. To be fair to Zentrik, this was in part due to a lack of contextual information provided during onboarding (though the onboarding flow was basic and unguided and relied on manual intervention by the team at Zentrik).
I am absolutely sure the timing of the engagement was just not right, and expect the team at Zentrik to fly in the very near future with the right customers.
What this did do for us, however, was focus our minds on exactly what it is we want/need out of any product management AI tool. Rather than identify the specific need and seek out a solution, I think we have fallen into the common trap of 'AI can help us, so let’s find a problem it can solve'. This experience reminded us of this, but also allowed us to identify what problems we want to solve - namely and very specifically, the bulk work associated with creating good, detailed and standardised user stories. We don't need PRDs being written, we don't need roadmaps being created - not at the expense they come with vs time saved.
As I have previously mentioned, my AI aim is 80/20 - saving the teams 80 of the effort or work on a project, leaving 20% for human review and filling in the gaps. A task like user story creation fits this bill, even if it is un-flashy.
Also made clear in this journey - the importance of good context to supply AI tools with, to help them understand our business, our customers and our products, without this, they cannot hope to assist us.
To that end, at the time of writing, we're crafting good, central contexts covering out business, market, customer type/personas, tech stack and competitor landscape. And ironically (via a great suggestion by one of the team) I have my PMs asking their chosen AI tool, which they have individually been using for some months now, to gather what they know about HeliosX based on interactions to date! Surely, this is another 80/20 example!
Mapping the complex formulas for Sprint Reporting in Airtable
In a fairly minor update, but one important for the continuity of the business, and my own sanity, I spent some time mapping out how I have constructed some of the more complex aspects of our Airtable product management database.
Specifically, where various calculated fields have been built upon and built upon - even when I go back to make improvements, I need to rework my way through everything to remind myself how and why I built it in that way. So, how would someone fresh come in after me and understand how this operates?
Graham
My thanks to HeliosX (obviously for employing me!) for blessing this continuing series, to my colleagues, and specifically to Joe Tarragano for his support on this.