Building Product Ops 0-1: Month 12 of 12 - Looking Back and Forward
How I build Product Ops in (near) real time - The Finale
This is the final entry in the 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 11 here:
---
As mentioned in the previous edition, this will be the final entry in the series as we have completed a full year together. I hope you have found this useful and enjoyable. This edition is also a clips show (not really!) - a look back and reflection on the state of product operations, product management and all teams product ops has impacted this past year, from where things were a year ago.
Without a doubt, the key challenge to be solved was a lack of visibility - specifically, business leadership lacked the necessary visibility and insight into exactly what the product division was working on, and more importantly, why, and what progress was being made. As a result, there was a level of discomfort felt in trusting the plans leadership did see, because of an opaque track record, leading to occasions where assumptions, mitigations or whole product plan changes were made misaligned to the efforts product teams had made.
Trust is earned through past actions and experiences, and so quite simply with a lack of information to demonstrate success, trust was not being earned. It should be said that, of course, the product division had 10 years of success - without it, the business, an online pharmacy and e-commerce facility, would not be thriving! But as a rapidly scaling business, the founder and subsequently the CEO were no longer able to be close enough to the day-to-day digital operations, relying on updates and reports much more from then on. was a critical aspect for Product Ops to address, with more comprehensive and reliable reporting, access to information and greater visibility into our planning cycles.
Better reporting to leadership
At the start of the year (spanning this series), reporting to leadership was qualitative, irregular, lacked metrics and time-consuming to produce, with each PM adding comments on progress into a document, which was posted around the leadership team. And the visibility of initiatives was only after release, not showing much in the way of progress, upcoming plans, or anything on the performance of teams in terms of success, velocity, trends, patterns or flags to indicate areas for intervention or investment.
Across the year, I have worked to both provide comprehensive metrics for every squad for every sprint, showing the plans, the success of the execution of those plans, and the trending performance of each squad to forecast their future ability to execute on a plan, taking into account their engineering capacity at any moment in time (put simply, based on performance to date, how much work should you plan on completing in the next sprint).
Also, this has significantly trained leadership to be more aware of the reality of software development - things happen, things change, plans change. And, understand that if they change plans, demand something else urgently (See Bets, below), that this has an impact on the original plans - you cannot have both!
This information, pulled as raw data from the likes of Jira, sliced and diced automatically with essentially an exec summary from each PM added, is provided, reviewed and discussed as a bi-weekly routine for business leadership (particularly those on the tech side, including the CEO). The end result - leadership sees what was planned, what was delivered, a trending-up line of success in delivering, and sees what is next with trust that squads will hit those targets. More recently, that trust has been manifested by leadership now feeling there is less need for detailed scrutiny on the stats; that the division is working right and with middle-level oversight suitable to intervene as needed, and leadership is now focused on the bigger rocks to move, the progress against the key objectives. There is trust we are doing things right - and now we need to focus on doing (building) the right things.
What is missing currently is regular reporting of the success of key initiatives - what did we forecast in terms of value (revenue, etc) and did we hit or exceed that forecast? This is a focus for 2026
Better sharing of information
Similar to reporting, the sharing of information both to leadership and across the business was fragmented, often living in Google Docs in personal drives, or sometimes on Confluence simply as a place to store, without much thought as to access of sharing. There was no single location for even leaders within the product division to see everything in flight or planned.
The solution: Airtable... regular readers will not be shocked by this (and if you are in my teams, stop rolling your eyes at me!)
For the Product function, this has largely been an extension and refinement of what was already happening - putting all relevant high-level information into our Airtable setup. Initiatives, their core details, the ICE scores, links to more detailed documents (PRDs, designs, etc), making Airtable the landing page and signposting point for anything we are working on. And despite some over-engineering on my part over the year (I freely admit - and yet - sorry, not sorry!), we have a good rhythm on this for the most part. And some of our senior leaders not only utilise this for async, on-demand updates and progress checking, they now expect and demand this.
Moving outside of just Product and to one of my most recent projects has been to build a HeliosX-specific strategy planning platform, something akin to an OKR management system (with a few more layers), with reporting and alerting features and capacity for meetings and actions recording linked to these layers. Similar to early product planning, the business lacked a unified way and tooling to both plan and monitor strategy across all divisions.
With a lot of consultation, architecture thinking, design, scope creep (of course!) and iterations, we produced a no-code app designed for data entry and reporting of strategy progress from the highest levels of the business down to the individual initiatives within each division (interestingly, allowing each division to continue using their own databases within Airtable as is, and syncing the required information up).
Highlights of this include the ability to ‘flag’ progress issues up through the levels, to help identify problems no matter where you are reviewing things and see what is slowing your progress (and ergo, exactly who to speak to, and about what). This is also a one-stop-shop platform for everything related to an Objective or Initiative, linking to all key meetings, actions (both visualised via a calendar), risks, changes and who owns what (with staff synced in from our new central staff database used by every other database in Airtable).
But, regardless of the tech and the data to be stored, the overriding advantage this will provide is one place for anyone to see and review everything relating to our strategy, what we are delivering, when and by whom - something we previously just did not have.
At the time of writing, this is being finalised and will be fully rolled out across the business by the end of the year, and I am sure I’ll be writing more on this project in the coming months.
Better planning
Product planning is always a contentious issue within our profession - too much and we are (apparently) stifling innovation or micromanaging. Too little and we are unprepared, under-researching. Something that is constantly misinterpreted within this sphere is: Just because you have planned something, you are not held to that. The world changes, the business changes, people change, and customers change. Being agile (little a, not big A!) is as important as ever for product managers.
Planning is vital, for many reasons, which I will not recount in detail as there are whole books on the topics, but resource/capacity management, business alignment, stakeholder engagement... are top of mind. And yet in many businesses, we tend to treat it as an afterthought to execution, often scurrying around at the eleventh hour to come up with the next month’s/quarter’s plans. Perhaps this is harsh, and I am sure there are businesses and teams out there that have this nailed, and indeed, at HeliosX, the thinking part happens much earlier. But regardless, this typically means research is insufficient, stakeholders have had little consultation (and if they have, they have had little time to digest, and rely on immediate reactions for decisions) and little, if any, forecasting of success has been done.
One may argue that product managers in particular are always planning, thinking ahead, and know what the end state is they are working towards - and for many PMs I have worked with over the years, I would agree. However, if the rest of the business doesn’t know, understand or agree with those plans, how can it support and develop in line with them?
Our teams, candidly, were somewhere within this scenario, with two key aspects to improve upon:
1. Gain stakeholder buy-in on their plans (ergo, co-create plans with key internal stakeholders)
2. Define the end-state or long-term outcome of key initiatives, to show the value of short-term features and enhancements.
We are doing much better (still with room for improvement) on the former today, and the second is a key focus and outcome for the next 3-6 months.
But what have we changed in the past year?
Predominantly, 2 key logistical things:
We implemented a new timeline for our quarterly planning, spanning the entire previous quarter. This is not constant, so put down your pitchforks (!), but with key checkpoints and milestones throughout the quarter to encourage the right conversations, research and data recording is done and shared with product and business leadership, to then provide guidance and feedback on. The teams actually do very little additional work or new tasks; it is just spaced out across more weeks in smaller chunks. So rather than trying to do all of this with 2 weeks under pressure at the end of the quarter, trying to get hold of stakeholders who are themselves busy/on holiday/already have fixed, dependent plans, the teams and stakeholders have more time, flexibility, space and opportunities to reflect and refine before things become ‘more locked in’. Read more about this here:
We have refined the checklist of data requirements needed for roadmaps and initiatives to the things that matter, particularly for the planning phase. What is the problem to solve, the solution, the success measures, the value (in £ usually), the end state (Newly introduced) and links to the overall business objectives.
Feedback from PMs has been very positive, with them having direction and a framework of what to be doing and when, which also sets out expectations with the stakeholders as well to encourage their participation. Additionally, everyone is on the same page about what they will see and when, when it comes to planning reviews during the cycle. This is not stifling innovation; it is allowing it to flourish with scaffolding to help it along. And in true agile fashion, we recently relaxed the timeline framework to focus less on a structured set of actions to take and meetings to have, to just ensuring the right assets are produced with the right quality at the right time in time for the key checkpoints - outside of that, PMs and their directors have the autonomy to proceed as they see best.
There is more to do, but to quote a repeated sentiment, it is a marked improvement from a year ago.
Bets
If you speak to some of our longer-tenured PMs or Engineering Managers (EMs), they will undoubtedly say one of the biggest issues prior to 2025 (and into early 2025), for them, was unplanned work - new requests coming in from the side from leadership and wiping out their plans. It’s a common occurrence, particularly amongst startups. I resist using the word ‘problem’ because this is often not a problem in that world - this agility and responsiveness to new learnings is positively beneficial. But, at a business now fully in ‘scaling’ mode, the impact of last-minute changes, often significant undertakings, is much more substantial.
However, this in itself is not always a net-negative result, particularly in a rapidly changing market with plenty of opportunities - in our case, the rapid rise of GLP-1 weight-loss medication. The challenge our teams faced, related to the aforementioned lack of bi-directional information and communication, was an understanding of the impact.
Impact the changes will have on the already planned (and often part-executed) work, with, at times, an expectation to continue to deliver those original plans (or more often, simply not knowing what work was being impacted).
But also, the impact and value of the opportunities we are going after (that cause the change in plans) for the business. On both sides, there was a lack of knowledge of the trade-offs, the decisions being made without understanding the value of the displaced work, but also the new opportunities, which, for the product teams, left them feeling out of the loop, a little like order takers.
So what could be done here?
I implemented ‘our’ Bets process (not to be confused with the more popular use of Product Bets - we didn’t have a better name, and we have just not changed it!).
You can read more about Bets here:
We have had mixed success with Bets this year. We are aligned on the process - business leaders discuss changes to planned work in favour of a new initiative, discuss the value, the trade-offs offs and impact, even authorise time-boxed research (by a Squad) to validate thinking, before collectively agreeing to the change in plans. And this is essentially ‘agreed by committee’, whereas previously we had been guilty of a single leader going directly to product teams and directing changes.
Interestingly, though, the creation of the bets process has instilled the necessary discipline and caused ‘bets’ themselves to become infrequent. We instead often now defer new ideas to the improved, more collaborative and transparent quarterly planning discussions, except when the whole industry experiences a massive upheaval, obliging all our plans to be put on hold (for us recently, in mid-2025, after a significant pricing shift by a major supplier, as a result of geopolitical involvement).
Rhythm of the teams, and expectations
Pulling a lot of the above together, one underlying theme and reason for implementing such tools and ways of working is to provide information and updates on a regular cadence, and force teams to be thinking about what they have done, and what is coming next, regularly. Reporting is not the glamorous part of product management (or any role), but keeping others informed, in a way that works for them, is so very important that it cannot be understated. Decisions should be/are based on knowledge, and so gaps in that knowledge can lead to decisions being made unexpectedly or incorrectly. The more we can share, the better, more accurate decisions can be made. And with this comes more robust relationships and greater trust in the team’s abilities and the choices they are making - in technical decisions, trade-offs, and opportunities to go after.
Further to this, it reinforced the expectations on others - on the stakeholders feeding into the product division, their responsibilities to be present, attend reviews, take responsibility for decisions made and opportunities they want to go after. Ultimately, bringing different parts of the business closer together, ensuring all sides know what to expect from each other, and collaborating effectively.
Have we succeeded here?
In many ways, yes. We are certainly a lot better than a year ago - more regular updates, more professional conversations and cadence of reviews, and a greater shared responsibility of the strategy. Absolutely, this is not all down to Product Ops, but everyone involved (and has been an overall and aligned theme everywhere, particularly pushed hard by our strategy team). Is there still room for improvement? Sure, there always is. In particular, we are still learning how to adapt to larger pivots often brought on by external influences such as suppliers, regulatory changes, global political issues, and, in particular, getting used to the fact that these will always hit us and accept that (rather than try to fight with processes). But given this itself was a big distraction a year ago, I personally feel the improvements across the board mean there are fewer today, and they are managed, mitigated and processed more smoothly and professionally than ever.
Product Ops Beyond Product
I have spent considerable time with some of the other divisions around the business, which has been a pleasure to do. Product Ops often gets involved with connected parts of the business, bringing the same skills and capabilities to similar contexts and teams to help them become more efficient.
One of these teams is our Medical Operations team (they have a variety of names, but this is a good unifying one), where predominantly I have supported their efforts in using Jira (yuk!) Service Manager is the business triage and escalation management system for our customers. While not the best choice of platform for this task, it has served its role well (we are moving off of this in early 2026) and something that was originally adopted ‘because we already had Jira in the company, so a quick and cheap option’.
Much of this support work has been to introduce new workflows, forms and reports as the medical and customer support teams have grown (massively), become more comfortable with technology to solve challenges and have access to automations and even some AI tools to speed up notification, triaging and successful completion of tickets.
We have 3x the number of staff providing 3x more ticket types covering all aspects from complaints, escalations, feedback, incident management and requests. I absolutely cannot take credit for the creation and ideation of the processes for these teams, but I supported the technical implementation to make Jira do what the teams needed it to do. I have an excellent relationship with this business-critical team, and the often ad-hoc changes here and there are instant and tangible improvements that have culminated in a significantly more efficient part of the business.
“The Medical Operations and Quality-Governance teams greatly value the outstanding work and support provided by Product Ops, led by Graham Reed. The team’s responsiveness in implementing improvements to our reporting platforms, particularly JIRA (yes, one of our favourite projects!), has significantly enhanced the quality and safety of our reporting and data pathways.
Given that auditing and quality assurance are central to the medical function, ongoing iterative changes are often required. The Product Ops team consistently demonstrates that no request is beyond reach, supporting us with efficiency and expertise. We continue to learn a great deal from their approach and increasingly rely on our partnership to strengthen our internal processes.”
Dr Safia Hussain - Global Quality Lead & Medical Doctor, HeliosX
Summary
I have been incredibly grateful to have been supported on both building Product Ops at HeliosX, and in this continuing series of articles charting this journey, by my manager & VP Product, Joe Tarragano, who reviews (not censors) each one, often reminding me of things I have forgotten that are worth celebrating.
And so what better way to summarise this journey than hearing from him:
“The focus could have been training, strategy, customer insight, culture or any number of other things. But here, the best, first focus areas were on building transparency around the performance and the value creation, in order to establish trust. We had to be seen to be doing the right things and doing them right. So the plan of attack was our 3 B’s: better reporting, better sharing, and better planning. None was that dreadful to start with, and none is yet perfect, but with these as focus areas, Product Ops created the environment for Product to be ‘seen’ as successful as well, actually being so.”
What comes next
Moving into 2026, we have a capabilities framework we have assessed ourselves as a division against (Discussed here:)
with plenty of scope for improvement. My focus for H1 is on people development, continued planning, development and the implementation of additional automation and AI facilities to further reduce legwork and allow teams to do what they do best. With, I am sure, Airtable continuing to be my go-to platform, and Jira being the bane of my life.
It is often said that Product Operations is ‘Product Managing Product Management’, and that we (should) act like Product Managers in building and iterating on our product - the Art of Product Management. And just like a digital or SaaS product - Is there still work to do here? Yes. Is it perfect? No. But it is significantly better than a year ago, particularly in as Joe mentioned: reporting, sharing, planning, and in another year things will be markedly improved again.And with that, it is time to sign off from this ‘year in Product Ops’ series. I have found this reflective project valuable in reviewing my successes and challenges, and I hope regular readers have found it as valuable in your own way.
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.