Building Product Ops 0-1: Month 6 of 12
How I build Product Ops in (near) real time - part 6
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, £150m+ 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 5 here
At the end of March, I planned for April to focus on data dashboards, improvements to the support desk and our communications methods. In a more recent podcast, I spoke about the reactivity Product Ops can face, particularly when it comes to prioritising our work.
Only one of these was true!
Maturity Matrix & Transformation Monitoring
A key focus for a portion of April has been the development of an assessment to gauge where we are as a product division (reminder: Product = product, engineering, design and more to come). Assessment criteria to help us measure ourselves - honestly and objectively - in how we operate top to bottom, covering, among other things, our strategy formulation and delivery, our agile practices, engineering standards, culture, communications and collaboration routines. Around 70 individual aspects of how we think, work and operate, and score from ‘No Maturity’ through Low, Medium and High Maturity.
Why and why now?
The why is easy - to know where we are, where we want to be, and to help us assess our progress. Success Measurement 101.
Why now: We have seen a huge amount of transformation in my first 6 months, much of which was tactical and clear improvements to ensure the product division was functional and delivering, in line with the continually scaling business. There might have been less strategy behind this, but it was necessary - a key reality of Product Operations in particular, doing what is necessary day to day, sometimes.
Now is a good time to take stock and understand who and what we (the product division) want to be in 6 months, in 12 months, and allow us to plan more how we achieve this, and also start to assess the cost-benefit outcomes for those transformations. Another reality of developing high-functioning teams - becoming excellent and mature has different costs and varying levels of value depending on the aspect of the practice. Some are easy, quick, cheap to get to a good level - embedding agile ceremonies in teams for example, but there may be little additional value in mastering retros, while some are far more involved - implementing an experimentation mindset for example, but spending the time to embed experimentation-first thinking can be highly beneficial for innovation and delivery. Becoming highly mature in some aspects may not provide the returns. This is something we need to understand more.
As of the end of April, my CPO kicked off a framework (nicely utilising AI for the v1 bulk work), and Product Ops has taken on refining definitions to something more specific to HeliosX, and taken a first pass assessment of where we are today (more to come).
AI Experimentation
A key deliverable for Product Ops, and for me personally, in 2025 is to utilise more AI tools, primarily for efficiency and innovation. It almost seems pointless to explore the reasoning behind this further - AI tools are here to stay, they are proven to an extent, so let’s use them to help our teams. As a self-confessed luddite when it comes to AI, I really have been left behind in terms of using even the most basic AI tools, let alone embedding them into my life - I need to upskill.
So far, we have mainly been using built-in AI tools in the platforms we have available - Google Gemini for our meeting notes via Google Meet (which we have embraced quite well, actually, and I find it fairly accurate most of the time), formula suggestions in Airtable, and page summaries in Confluence.
Both my CPO and I have also experimented with using AI application builders such as Lovable, and workflow builders with AI connectors such as n8n. The focus of these has firmly been on providing new solutions to how we operate - custom to HeliosX, either because there are no platforms currently available to do what we need based on how we currently operate, or that integrate with the specific set of platforms we use.
What has been interesting about this is how easy it has been to produce PoCs and MVPs that actually work. Yes, they would need engineering support in some cases to connect it to our tech stack and fully embed it in how our teams work, but as a PoC, it does what it says on the tin. This has led us to consider how our product teams experiment and build Proof of Concepts, particularly with brand new functionality or features, to test ideas with our internal staff with virtually no engineering overhead.
Goals v2
‘Sprint Goals’ for our teams and our leadership team have quickly become an important staple of strategy and planning. There is a reason why I put ‘Sprint Goals’ in quotation marks, because our implementation of Sprint Goals is not quite the traditional definition or usage, and in April, we are diverging further - but for good reason.
Our Sprint Goals are the key outcomes from Sprints and relate to key strategic objectives. As much as to align the squads to the theme of work being implemented in a Sprint, they are for leadership to understand what is being worked on. We tentatively plan these +2 sprints in advance (with the expectation that things will change) so there is an opportunity to query prior to Sprints starting. Perhaps these should be renamed (Sprint Objectives?), but right now they are an important touchpoint for an invested SLT, regardless of what we call them.
In April, feedback was clear that there was a good deal of variety in detail, particularly quantitative detail, between the goals being produced by the squads, as well as some capacity vs planning hiccups. SLT wants to see more standardisation in the focus of the work, the comparative size, and the priority of delivery of goals, to allow them to plan and adjust strategy elsewhere, and be confident that teams can deliver on what they say they will deliver.
TL;DR, I re-engineered how we record Sprint Goals (in Airtable) from a single free-text field to a ‘record per goal’ database, and therefore able to specify metadata such as priority, FE/BE work, Discovery/Delivery and comparative size of the effort to meet the goal.
It is at this point that I am reminded of how far we have come in terms of planning and transparency of the work being carried out. From basically nothing to structure and details that key SLT staff can interpret and understand, and utilise in their own evaluation and planning. And it is healthy to ask if there is too much detail, too much structure - it has certainly been asked internally. My answer here is ‘It is what is necessary currently to provide key leaders the confidence in the plans, the outcomes and the teams executing those plans.’.
The leaders are excited to see the new format in action.
More workflow support for medical and distribution teams
There has been a resurgence of desire to improve how our internal operations for customer success, medical operations and dispensary and distribution services work. Improving how our staff use technology, automation and workflows to speed up resolutions to queries, highlight when medical intervention is required more easily and robustly, and allow our distribution teams to focus more time on getting orders out the door than on admin.
While the standard orders and distribution are catered for within our platform itself, queries, escalations and support issues are managed through Jira Service Management (I’ve written about this previously). Our implementation of Jira has been tweaked, customised and bodged considerably over the years into a spaghetti mess under the hood - and I suspect many readers can attest to such situations in their own or past roles too. This leaves me in the position of being the de facto Jira administrator for the business by virtue of, probably, understanding how everything is set up and what intersects with what across the whole org.
This does, in turn, make requests for improvements that much more involved as I need to be aware of every change and how it does or does not impact other projects, other teams around the business and the business-critical processes they carry out.
That said, the enthusiasm to want to improve our ways of working that have, at times, been very manual, is something I want to continue to support and push for. In these cases this month, the changes have been around making data collection forms more flexible, focusing more on those filling out the forms efficiently rather than those at the other end receiving the information. And with this, automations to categorise tickets in particular ways based on the inputs, which helps our staff quickly identify priorities, to funnel the right queries to the right teams rather than ‘1 big pot’.
Once again, I am reminded of just how far we have come in the 6 months I have been here, seeing how technology does help with repeatable actions and lets staff focus on the right things and see through the noise and volume of queries. There is coordination needed now with all these requests - more on that next month. If we are going to double down on the technology, let us do it right.
PM 1:1s
Hitting the 6-month mark has prompted me more than ever to reflect on how far we have come and what is next. While I speak with the PMs ad-hoc regularly, it is often on a transactional basis - rolling out something new, or taking on board specific wants and asks from them. I decided to put some time in diaries to speak 1:1 with each PM and provide space for them to reflect on the changes and what is working well, what is still needed, and what has not hit the mark. And I am so glad I did!
Aside from anything, it was a good opportunity to further build the relationship with each of them, and hear in their own words, unfiltered, their thoughts and feelings, and in doing so, get to understand them and their general perspectives better.
The feedback was almost universally aligned, too. There is recognition that we have come a long way in how we work as a division and our place within the business; the structure is good and appreciated, the pace of change, while fast, is understood, and teams know what is expected of them in much greater detail than ever. There were some projects to go after, too.
The big area of improvement, though, was to explain the value of the changes being asked of them, particularly reporting. Why are we providing x report? Who is consuming that information, and is it of value? It made total sense - after all, these are product managers who live day in-day out understanding the value of their products, and explaining changes and improvements to others - why should they not get the same courtesy? It is not that I have not explained the reasons and value, I need to do more.
Linked to this, and somewhat surprising if I am honest, was the desire to speak more to me. Much of our communication is async (Slack), which is hit and miss as to who is reading the announcements on changes to ways of working, and when. This was openly admitted, and a reflection not on me just droning on, but the relative priority and value of my words compared to delivery projects, for example. Which is very understandable.
TL;DR, we now have a regular group catch-up in the diary where everyone can dedicate some mental capacity to how we work, not just on THE WORK.
Scrum of Scrums
Probably not the most accurate term, either in its usage according to Agile or what it turns out to be in practice, but feedback for some time is our teams have had difficulty in carving out the time for cross-functional discussions, particularly when it comes to technical dependencies across squads. And so, we’re putting in place a ‘Scrum of Scrums’ meeting, where key folks from each squad brief the other squads on their near-future plans and everyone identifies possible dependencies and risks.
It’s basic, it’s fairly unstructured, but I hope effective. It is also augmenting an existing meeting space so not consuming any more time for the teams.
From this is an important, and undervalued aspect of Product Ops: Just get people into a room and let them talk. It doesn’t need to be pretty, it just needs to have value. The problem in our case is not the talking, it is organising teams to come together at the same time, and have that dedicated space away from distractions and other priorities. Product Ops here is carving out that space, and letting the professionals do their thing.
Tech Demo
Regular readers know all about my obsession with communicating the right content to the right audience in the right way. One of the issues we have had with our regular ‘Product Demos’, our bi-weekly show and tell to the wider business, is the volume and variety of content included by the teams. There has always been a mix of more typical front-end, user-focused improvements and deeply technical items, which on their own could bamboozle the audience, and together can feel jarring. This is no fault of the wonderful speakers we have, it’s just the wrong audience to celebrate some of these items.
So, we are spinning up a separate Tech Demo, monthly with a focus on the more technical items, and framed much more for the engineering staff and other technical staff. Not only will this provide the right audience for these topics, an audience that will take the most from the presentations, but also frees up more space for the front-facing work to presented.
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.