Building Product Ops 0-1: Month 5 of 12
How I build Product Ops in (near) real time - part 5
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 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 4 here
Into March now, and I genuinely feel a palpable change in attitude and desire to be a more mature, more professional organisation as HeliosX has started to settle after the huge amount of hiring. Conversly, we are now entering our Q2 planning cycle post this settling period, so all eyes and expectations now sit on what we plan out for the next quarter and beyond.
For me, I purposefully took my foot off the gas a little in terms of rolling out a significant new structure or process, in reflection of the amount of change that has already happened in 2025 - letting that embed with the teams through some repetition - and the afore mentioned Q2 planning. This itself is something I want us to look at in 2025 and see how it can be chunked down from such a big job, but that is for another time.
But I am conscious of not overloading an already busy set of teams with more distractions just now - we have made great strides, lets feel the benefit there for a time… while I tinker and plot and scheme in the background (queue evil laughter!)…
‘Reports to be Done’ & Streamlining Regular Reporting
Reporting with the product teams has been an interesting ride. Historically, this has been messy, either with little standards or with new requests last minute for teams to jump on, find data and mash it together. A large part of the efforts within Airtable these past months has been to bring both order and regularity to this fundamentally ‘Product 101’ requirement.
And so we got there with the standardisation, the format, the volume and angle of the information. Now we have different reports, with some amount of overlap, required for different audiences and needed at different points throughout the week or month. What was needed now was a review of specifically what reports were needed (and asking that question up the chain), what in those reports was needed, where the overlap was, and who the audience was. We began to decouple the reporting outputs from the input of information (now exclusively in Airtable), meaning I could ask the teams for regular updates and information across a range of contexts, take their responses, split them out and reconstitute the data into the different outputs - reports, that were needed. Efficient inputs and outputs with automation, calculations and report design in the middle.
This ended up with a regular task (or tasks) to be completed by the end of each week to provide all the information all outputs needed, using as efficiently designed inputs as possible. Updating the roadmap dates, updates on initiatives, line management updates, and sprint goal reporting. These have been christened ‘Reports to be Done’*, and are now a singular focal point for information sharing, and something the teams are recommended to carve out a space every Friday to complete in 1 go.
*It was called Jobs to be Done, and then everyone asked if we were moving to that methodology!🤨
Later in the month, I also began a pilot with around half the squads, where 2 of the more time-consuming reports were combined into one (reflecting the fact that about 50% of 1 report was a copy of 100% of the other!). Using the same concepts as before - enter the raw data and let me figure out where it needs to be reused - if this embeds well with the piloting PMs, this will yield a decent amount of time saved. Additionally, with said reports both now being done in Airtable (ergo, are record-based), additional slicing and dicing allows me to provide a roll-up report automatically for product leadership, with zero effort.
Support Desk - Extending helpdesk workflows & automation
Checking in on our support desk improvements, we have begun utilising Jira automation to direct niche issues to particular, non-engineering teams in the business - for example where there may be a ticket raised (legitimately) that requires changes to customer/patient records, there are now automated tools to seek verification from our clinical professionals and allow them to take action if needed - whereas before such escalations needed manual intervention and communication.
We have implemented several of these workflows to both reduce and focus the efforts of our support desk staff (engineers who rotate in and out) on the most pressing challenges to solve. Bigger changes to support the prioritisation of non-obvious issues utilising our product managers, are due to come online in April (As per previously, allowing the teams to focus on Q2 planning before more changes are brought in).
This is a great example of iterating slowly through a problem and measuring the impact - many of the changes so far have been on monitoring and reporting on the support issues we have, which has seen success and allowed us to be reactive with the next set of improvements. We did not have all the answers to begin with - we still do not - but we know more than we did!
Specifying data dashboards
Attention has now begun to shift to our use of customer trends and platform usage in our planning and decision-making processes. Our product directors have a detailed specification of their wants and needs for each individual product squad - with a healthy desire that the PMs would be checking in on these daily, for habit-forming and to be as up-to-date as possible.
The relationship between dashboards and Product Ops is probably one of the most polarising in the role - either the creation and maintenance of these is the responsibility of Product Operations, or it is the responsibility of a data/insights team, as just another internal customer for their data domain. I have done both, and at HeliosX it is the latter for the most part. Our Insights team will be taking the requirements to provide a set of individualised dashboards to our squads, yet utilising as much reusable content as practical to reduce maintenance and forking of dashboard characteristics down the line.
Demos and comms
Ah yes my favorite - or rather most passionate - focus in Product Ops - how we communicate. Thoughout my time at Helios I have been gently but deliberately been pushing for an audience-led communications style, reminding teams to be clearly showing the value of what has been planned or build. This is now gathering pace as we adjust the thinking for our product demos and, next month, roll out new communications processes and standards (well, guidelines).
Demos have been tweaked here and there for a more standard approach in look and feel, ensuring key words are constant, such as ‘Opportunity, Solution and Value’ and relating all demoed features to business goals. This is deliberate and visual, so there is no ambiguity. Now, we are planning to shift the focus of the demos, and the features and releases demoed, to ‘what the business needs to hear, wants to hear, really cares about’, and pushing more technical or niche topics to a newly formed ‘Tech Demo’. With a growing number of squads, ergo, people and things to demo, time is even more precious here. So, focus is key, what will bring the most value to the audience. Our new Tech Demo will be more focused on items for engineers to share with other engineers or technical colleagues (open optionally to others around the business who wish to listen in), and still celebrate the work they have done.
The efforts to shift mindsets on communication to ‘what the audience needs’ rather than ‘what we want to tell them’ have now been formalised (if not yet rolled out) - and largely follow the guidelines I outlined last year:
More on this next month.
Feedback on Sprints
As mentioned last month, during the ‘Onsite-Offsite’ event we held for the product division, we received a large volume of feedback on our implementation of sprinting and scrum, which has now been collated, reviewed and prioritised for some short- and mid-term improvements.
Overall, the feedback was very focused on ‘how do we improve, do more, go further’ or clarifications on expectations and working practices. It was positive, and for the most part feedback wanted to continue getting better, and somewhat surprising to me, wanting more standardisation.
Some of this was on the basics, such as definitions of priorities, definitions of read/done, etc. Some was on wanting more time dedicated to discovery (with PM involvement), and some was to streamline what we have in terms of meetings, channels of communication etc that have organically built up over the years.
Around 40% of these prioritised items have already been implemented or closed. I have been grateful for this exercise and for the openness, honesty and ‘best for business’ thinking colleagues have responded with.
What is next?
April will see a number of new/revised ways of working being introduced, focused on communications and the support desk, which per above have been held while our teams are focused on Q2 planning. We’ll also begin to see our data dashboards coming online and be rolled out to the squads as a regular set of tools to be using.
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.
How are you delivering reporting? Are your teams sharing links to the Airtable views or are you leveraging some sort of email tool to deliver reports / summaries (esp. to executives)? Really enjoying this journey!