Building Product Ops 0-1: Month 4 of 12

How I build Product Ops in (near) real time - part 4

This is the next edition of 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, £150m+ HealthTech. It is designed to show you the journey, it’s not a warts-and-all expose.

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 3 here

---

February - the month of love and a shorter month was even shorter for me as I took the first third off to enjoy my belated honeymoon.

As things have settled with our new colleagues and teams in place and Q1 plans in full swing, those same colleagues are understanding the processes and tools that are in place and asking for more, about the gaps, suggested improvements and what has worked well elsewhere. This is always golden to hear and my efforts have partly focused on using that enthusiasm to both build relationships and implement many of the new ways of working we have introduced.

Signing off on sprint reporting - success

In the January edition, I wrote about the moderate success of our sprint reporting, tainted somewhat in the eyes of the product managers by the relatively high effort of producing the metrics for the reports each time - something I agreed with. As I returned from leave, I switched this up to take 95% of the work away from PMs and crafted an export/import process that Product Ops (me) does for each spring covering all tasks for all sprints for all teams each 2-week iteration. End to end it is about 10 minutes of my time, and with a whole bunch of Airtable views, calculated fields and interfaces, the data just drops in and displays instantly. The appreciation amongst the teams has been both universal and high - we have to produce these reports, but we have reduced the effort to virtually nil for them.

Writing this in March but to finish this story off, I have additionally implemented a facility using virtually the same resources, to show the planned work for the forthcoming sprints of use to product leaders as we continue to evolve the squads and their focuses on valuable work.

Extending Airtable use to adjacent teams (Research, Design)

My Airtable re-implementation has become a minor success, in particular as a tool to standardise what people see and interact with, and as something to help align the teams around the common tasks, particularly reporting. While the jury is still out as to exactly how much time is currently being saved for the product managers specifically (the words still have to be written), the reusability of the information across different reporting needs, and by different stakeholders in different configurations, is already evident.

I believe this is an important and under-reported reality of product ops I am continually finding, and indeed have been talking about for a couple of years now - product ops is there to support the business first and foremost. While every effort is made to reduce the work of product teams and product managers, there are tasks that just need to be done, and asked for by the business and leadership. We can question, we can challenge the need, we can automate and reuse information, but ultimately the end result is a set quantity and volume that needs to be filled.

In this instance, several reports for different topics and different stakeholders on different cadences are required. The focus for me has been a) how much information can we reuse, and b) how easy can I make it for the information to be recorded where manual effort (by the PMs) is needed. Only the PMs can provide this…

And why are we providing all this information to stakeholders anyway? Well…

Mindset change - building more trust in the product teams etc

While much of this work has a primary outcome of providing the information stakeholders and leaders are interested in, a secondary function is to demonstrate that the teams are working, working well, working on the right things and doing so in the right way. There has been a lot of investment in the product division in the last 6 months (myself included), with much change in personnel, process and strategy - and naturally, there are eyes on the division to validate that that spend is yielding results. The push for transparency and demonstrating that value transparently is a big part in both proving that RoI, and building trust in those personnel, the processes and our strategy.

I talk a lot about the importance of building that trust, across the business and in leadership, to build an equity of trust that when times are tough, or indeed there is the desire to invest further or go after bigger and more ambitious bets, we can cash in on that equity. It starts here.

Extending ProductHUB to Research, copying for NPD, Data teams

ProductHUB is here to stay, with more and more people referencing it as the central location to both find information and store it for consumption by the masses. While I have a bit of an issue in measuring the impact currently (lack of page analytics with our version of Confluence, soon to be rectified!), the anecdotal evidence is positive. So much so, that I have both extended the sphere of departments within Product who are locating their documents, guides and presentations there - namely UX Research (and at the time of writing, Data Engineering too), and guided one other team on the production of their own Hub (our physical products team), and another in the diary to chat through. ProductHUB has become an exemplar of transparency and collaboration, sharing information, and celebrating the teams - all extremely positive. I cannot recommend enough the concept of a ProductHUB particularly given the simplicity of building one’s own using Confluence, Notion (or if your business really hates you - SharePoint!).

For more on this:

Strategy for Product Ops

I have quietly been pulling together a 2025 strategy for Product Ops at HeliosX, based on many conversations, the volume of tactical work I have been focused on, and alignment to the business strategy. The highlights of these are

Launching my Opportunity/Solution/Value Audience-Led framework for product communications - standardising how we vocalise and socialise our achievements and the value the teams have delivered.

Metrics and Dashboards - though there has been some specification by the product leadership on individual requirements, I will be collating this for standardisation where practical, for efficiency and reusability and easy maintenance down the road in pushing this to our insights team.

Define and Amplify the HeliosX Product Operating Model - as the processes, principles and ways of working are rolled out, write and combine these into our own POM that the items can rally behind, and the business can identify the product division with.

Define and Implement a Voice of the Customer programme amongst the teams, with processes, cadences and reporting.

This builds upon the work done to date aligning the teams on:

• Product tooling

• Reporting

• Roadmapping

• Sprint re-implementation

• Meeting planning, execution, purpose alignment

• ProductHUB

Shared ‘Product Reminders’ Calendar

An idea that seemed to come in from the team at the same time I was already planning it was the idea of a shared calendar for the division - to show key events, key tasks and key meetings to attend for awareness and to use reminders to prompt for regular actions.

The idea of this is sound, but in implementing this we have found it to be somewhat noisy, with many of the events being team-specific and conceptually of little interest to other teams - but even this is not consistent. There is certainly a desire to be aware of what is going on, and a want to ensure the teams know what is going on, but at this time I am not sure if this solution will be the winner with the teams. This is a great example though of experimenting and iterating, and we will have a solution that provides the right balance between alerts and reminders, and personalised events.

The First ‘Onsite/Offsite’ Division Event

This month too saw the product division coming together both physically and conceptually under our ‘OneTeam’ banner, for a full day offsite (that was in our office, so it was onsite!) of workshops, feedback sessions, presentations and demos. Keeping in mind the division is around two-thirds new staff in the space of 6 months, a critical element of this day for me was to enable the squads to spend some time together as groups, many meeting face to face for the first time, and more socially getting to know one another. This was facilitated further by feedback groups discussing and ideating on our recent return to Scrum and sprinting - which in itself yielded some fantastic ideas (more on that next month).

I took advantage of having the product and design folks all in one place together to chat about - yes, my favourite topic - communications, and lay the groundwork for the processes I am shortly to push out to the teams on how they advertise and celebrate the work they have done and the value it brings. Feedback here too was very useful, in as much in the content as it was to reflect on how I presented the ideas, what was understood and where the concerns were, and how I adapt my thinking for Product Ops overall moving forward.

Feedback

Festivities after our Onsite/Offsite were an additional enabler for relationship building amongst the teams, and it provided an opportunity for colleagues to voice feedback on my time implementing Product Ops at HeliosX, all very positive and gushing, mixed in with ideas they wanted to bring to the table for further improvements.

Most gratifying was ‘how much improvement there has been in the last few months’, ‘It's motivating to see long-standing issues resolved and better organisation and representation of the team's work’ and ‘things are actually changing, not just being talked about’.

While of course personally, this is lovely to hear, more important is the recognition that things have changed, and improved, and even with more standardisation, more guardrails, and even a little more needed in terms of reporting and comms than before, this has been absorbed and ratified to feel like a positive step.

---

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.

---