Building Product Ops 0-1: Month 3 of 12
How I build Product Ops in (near) real time - part 3
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 2 here
New month, new year. January 2025. A great deal of this month was focused around the transformation of our Airtable implementation, evolving from a set of static spreadsheets with bells on, to an interconnected database of records, from the highs of business and product goals, down through OKRs, Initiatives and even into Sprints where the Initiatives are being worked on. Though not originally intended, this even trickles down into the Jira tasks (a byproduct of a revised sprint reporting process).
On top of this database is a set of no-code ‘interfaces’ that make interaction with the data considerably more friendly, particularly for the wider business who do not live in tables. Particularly as we are utilising longer-form text elements (what was the opportunity, what are the risks), small spreadsheet-like cells are not suitable. These interfaces allow me to display information to the masses in a variety of formats, from high-level roadmaps to detailed one-pager style documents beneficial for SLT reviews, and provide more interactive data entry and management tools for the product managers than is possible or intuitive with using tables.
Airtable for us has become a very bespoke product management database for everything in the planning phases, up to the point of a sprint kicking off (where items migrate to the engineering platform of choice - Jira). I am not ashamed to admit, that I am a little bit in love with Airtable right now - the flexibility it offers to provide exactly what we want in the want (for the most part) coupled with the ease of connecting tables, building dashboards and interfaces all from the now central data source, has both impressed me and saved me and many in the product side of the business a good deal of time.
At the time of writing, I have been asked by several Product Ops professionals to see how I have built this Product Database in Airtable and will be organising a demo of this (with suitably anonymised data) shortly - if this is of interest to you get in touch with me via LinkedIn.
Reporting
One of the key tenets to have achieved with this project has been to save time at the end of the funnel - making more use of all the data being entered than just for building a roadmap or managing a backlog. As a rapidly scaling and maturing business, accountability of resource deployment and investment is key, and leaders need to know what is being built, when, and how the squads are performing to allow for early intervention and support. Much of this information is there, but as I have learnt over the years in Product Ops: thinking about the audience is critical here - what do they need, what do they want, what can they understand - which is not the same and MUST NOT be assumed to be the same as what the product managers want to show or talk about.
And so, we have several interfaces dedicated to the wider business to show the appropriate (not all) details of what is being worked on - the one-pagers for initiatives, the delivery roadmaps, our Bets. We have a number also focused on performance (of sprints) and regular check-ins and summaries, that are condensed versions of other reports cherry-picking the information and reformatting it.
For the most part, this embraces the ‘write once, use many times’ mantra. I will admit that has taken some effort to convince the product managers of the long-term benefit when there has been a lot of upfront additional effort to populate certain areas (let’s call it a migration to Airtable), but by the end of January (and at the time of writing in February) the rewards are being felt.
Logistics of Data
There is an undeniable fact with all of this - data has to come from somewhere! The effort has to be put in somewhere. The trick is to reuse as much information as possible, particularly where the information is already mandatory and embedded into PMs (mainly) working practices. Jira is a good example, as is our Initiatives table (the main part of the database where the roadmap is derived from). We extract, stretch and pull as much information as we can from these central records, into reports, interfaces and queries. But where supplementary information is needed, it can only come from the minds of the PMs. So how can we reduce this load?
In terms of volume of work, we cannot. But we can help make this volume easier to manage
I have built additional interfaces in Airtable that are stripped back and focus on specific data entry tasks - removing distraction, and even just making it easier on the eyes. A PM can come in, bash out the data, possibly across several records, and move on. The context they need is available but no more. This takes the individual task at hand and says ‘How can this specific process be as efficient as possible’.
I have also begun to push the teams to look at this micro-tasking in the context of WHEN in the lifecycle of the process these tasks are completed. But what does this mean?
Consider when you might write a set of release notes. At the end of a sprint, it might take you an hour that you have to dedicate yourself to, reminding yourself of the key details to share, gathering images etc. This assumes you have an hour in one go to complete this.
The alternative is to write the individual feature notes as part of the Initiative record along the way - taking say 5 minutes per feature if that, and because your mind is in the weeds of this feature, your mind can more easily think of what to write. To be fair, PMs should know the output of the work on a feature before the work even starts, so the release notes can be written that far in advance. The result of this idea is that the release notes are just done, and while the physical volume of typing is the same, the cumulative cognitive load is a lot less, and so thinking time and overall time, are a lot less too.
We’re not quite there yet with this cumulative micro-tasking, but that is ok, it will happen organically.
Where have we ended January?
By the end of the month (work-wise cut short by my belated honeymoon), we have a database covering the roadmap of initiatives, sprint reporting, bets, objectives and a dozen lookup tables to help standardise common information. Interfaces are providing this information to the product division and product leadership, and the SLT have been introduced to some elements as part of their reporting needs. Further rollouts have been paused a) because I have not been around to support and answer questions for 2 weeks, but b) because I want to let the teams settle on the new ways of working for a time.
I am also listening to feedback on what we have pushed out. Of particular note has been the effort to manually enter information relating to Sprints - the stats on tasks and points etc, which is time-consuming for the PMs every 2 weeks. Originally this was both known and unavoidable, but was also the first element I built into Airtable. A thorough review of the information available in Jira (and that can be extracted) and much experimentation have led me to build a semi-automated process removing most of the need for the PMs to do anything when it comes to sprint reporting. In short, an extract and import at the end of each sprint, across all teams, managed centrally by Product Ops. The first trial of this occurs when I return with one team to ensure the figures they manually enter match the Jira import, and assuming all works, results in both a detailed report for leadership, and virtually zero additional effort on the PMs (technically, because they are cumulative micro-tasking!)
Looking forward, February will be a period of reflection on all this change and a focus on how we communicate as one division out to the rest of the business.
Graham
Have you got any questions on our implementation of Airtable, or anything else you have read in the first three episodes of this series? Get in touch and I’ll answer in an AMA article for Q1.
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.