Building Product Ops 0-1: Month 2 of 12
How I build Product Ops in (near) real time - part 2
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 1 here
Into December, month 2 - and despite a significant amount of time out of the day job through the Christmas festive period and hosting the PLA Product Ops Summit: London 2024, a fair amount of progress has happened in the Product Ops sphere.
I am certainly more settled into my role and where I fit within the business, and beginning to understand how to approach the changes we need to make with the product squads. The squads themselves are still undergoing significant change as more teams spin up and colleagues join, pulling on existing staff for information and onboarding needs - and so I am conscious of how much more cognitive load I am placing on the teams with the work I need to do. This is often understated as an unofficial responsibility of Product Ops in the discharge of our core duties.
Keep this in mind as we explore December
Launched ProductHUB
ProductHUB was launched with a pinch of fanfare. Usage has been as I expected and planned - a big spike as people looked at the shiny new thing, and then dropped off. But unlike past similar ProductHUB launches, I have largely left this alone for the moment focusing now on other projects.
Why you may ask? Because currently and unlike at other organisations I have built product operations, internal information sharing for the masses is not a huge issue. More accurately, the information we currently have available to share is not necessarily in the best shape or tuned for the right audiences. I pushed to have a ProductHUB available early as a named place to begin locating the forthcoming, important tools and information. My teams know what ProductHUB is, what is there now, and what will be coming - now delivering on the ‘what’s coming’ - rather than being stuck in a transition period of lots of dashboards, lists of links and disparate information while then needing to collate it all together (into a ProductHUB).
Now, I have individuals asking for x report or x interface, and already suggesting ProductHUB as the home for it (often correct, and even when not, it is good they are thinking in those terms!).
Scrum Implementation - Success?
Last month I mentioned the reintroduction of Scrum for most of our product squads. This largely happened with very little disruption, mostly due to the experience and adaptability of the teams, and with a significant number of new teams being spun up at the same time (They do not know any different). We are now several Sprints in for those original teams, and while it is too soon to understand if the data suggests a productivity and transparency increase, the overall sentiment is positive direction.
Implemented sprint reports
Coupled with reimplementing sprints has been reporting on the planning and delivery of the development tasks. Our sprints & our development tasks are managed through Jira, and while Jira has passable reports on the individual sprints, there is a lack of cross-project and multi-sprint analysis. This prompted me to look more widely at the data platforms we have already integrated with Jira, or other platforms in general.
Metabase, a dashboarding and analysis tool, pulls information from Jira automatically, but I quickly found the presentation of reports limited, particularly with an intended audience being more business-focused. Further, the requirements I have on the data to pull from Jira required significant development effort to implement - and requirements that are constantly evolving as I find more and more uses and connections with other data sources.
Most significantly, sprint reporting requires snapshots of information - a data warehouse showing the state’s tasks are in at specific periods of time in their lifecycle. Live links would not provide such a solution. Not many automation solutions would provide such a solution, meaning a solution would need to be a manual one.
Airtable is our product roadmap and initiative planning tool - and an incredibly flexible no-code solution allowing me to build exactly what I need in terms of data storage, plus the ability to build not only reporting dashboards, but also data entry interfaces for the teams to make this manual task as easy and user friendly as possible.
At the time of writing, I have created the database, records for each sprint for each team for the forthcoming year (possible because our sprints all align with each other) ready to fill in the details, and the basics of an interface to enter the data into. Reports for SLT will follow.
For those interested, I have a Sprints table as a master reference for the sprint date, sprint number, etc for all teams to share. I have a Sprint Reporting table that is ‘blank’, one record for each sprint for each team, where the metrics will go.
Initiative & Roadmap Reviews
Initiatives are our main roadmap items, the tangible delivery things people get excited about. As part of our ongoing roadmap review process, we want to ensure our key stakeholders have a clear, comprehensive understanding of what is being built and when, and provide informed opportunity to feed into any conversation on changing that plan.
To provide that, we need to provide the right information to stakeholders, covering the problem, the solution, the complexity, risks, effort and investment needed. While this information is known within the product teams (albeit more in their heads and across various documents), with our Initiative records living within Airtable, it is a natural location to house more of the contextual, as well as quantitative information.
But this information needs to be easy to enter into the database as well as viewable by business leaders as part of both synchronous conversations and asynchronous reviews. Airtable interfaces to the rescue again - allowing me to build an Initiative record page providing an ability to add new records, and quickly review and skip through many initiatives with all the information on one ‘page’ - our new 1 Pagers for our roadmap initiatives.
At the time of writing, I have begun to discover just how interconnected I can (I will) be making all information related to product data within Airtable - from Strategic Goals through Objectives, Initiatives, Bets (see below) and Sprints/Sprint reports. This seems so natural in one’s head, but few platforms commercially available seem to be flexible enough to provide this out of the box, without having to do it ‘their way’.
A lot more of this to come I am sure.
Implementing Bets
Like our Initiatives, we have introduced Bets. I am unsure if they are quite aligned with the currently popular idea in product circles of bets, but the name has felt right to use for our implementation.
Bets are ideas from our leadership that are just that - an idea that needs more research from specialist areas (physical and digital product, marketing, growth), but has a good deal of backing and thought put into it, meaning it is something that likely will be coming down the pipe in the medium-term. At this stage, it is a calculated Bet based on experience and understanding of many business and market factors, but has not yet had the usual due diligence done for it to be called an Initiative and be on the roadmap.
Airtable seems the logical place to store these, for alignment and linking to Initiaives, now for context and in the future when it transformed into an Initiaive itself. So once again, a database and an interface.
But outside of data and tables, is the need to introduce this to the product teams, and what their involvement will be and when. While Bets are coming, this is not yet the time to introduce this in any significant way to the squads, particularly with the festive period upon us. But watch this space…
MedOps service desk
Our internal clinical teams currently use Jira Service Desk to record and escalate issues and escalations related to order fulfilment, and a new division leader requested a wealth of changes to the fields used, forms filled in and queue management. The teams have doubled down on better information recording, automation and escalation processes - which with my process-nerd hat on is great.
NOTE: For the avoidance of any doubt or concern, we do not record ANY personal or patient information in Jira Service Desk! So put down your GDPR pitchforks.
Due to my experience and knowledge of Jira being more than most in the business (aside from the Engineering Managers), I got involved to support the planning and then execution of changes to the existing service desk implementation, with live changes during arranged windows (Because of how Jira works), recommending the use of automation to notify the right people with the right ticket generation. I wanted to be involved to ensure long-term considerations and the reportability of information through correct field choices etc, were realised. As well, to build good relationships with other divisions around the business.
This was useful to dive into the functionality of Service Desk again, as I am currently gearing up to do many of the same types of changes for the internal digital product Helpdesk too. Phase 1 urgent work was completed before the festive period started, with phase 2 to complete the transformation scheduled for mid-January, additionally providing settling time to see the impact of some changes and tweaks to things not yet considered.
December had a clear bias towards data and databases, and providing facilities for 2025 for the product teams to use, and use in a standard way - with tools they just use, not have to reinvent, or individually craft.
December was also when I fell in love all over again, I cannot hide it - with Airtable. I am still finding out all it can do, and there are some (sensible) limitations, but my word can I build a lot, interconnect a lot and provide so complex and joined-up reports! I’ll admit, I do need to slow down and prove the value of what we now have before investing more time, but any new data requirement within the product sphere instantly starts me thinking ‘how does it connect with everything else we have?’
Airtable was something already in place when I arrived used as spreadsheets and view to show basic roadmaps, built upon and build upon with too much thought to normalisation and reuse of data as it grew - and there would have been no need to. So between other tasks and the odd evening, I’ve taken to reworking the tables into a more database feel, improving accuracy, removing redundancy, and simplifying data entry. January will see a lot more and I have wanted the basics ready and in place for then.
Oh and if anyone reading is from Airtable and fancies sending me some swag, it will be well-advertised!
See you next month.
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.