Building Product Ops 0-1: Month 1 of 12
How I build Product Ops in (near) real time.
This is the start of 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.
First Days
Take away the pomp of first-day lunches, swag and tours around the ping-pong tables & comfy sofas, the first days and weeks in any business are exactly the same - a lot of new names, new faces, new products, new politics and new processes. And when you are there in a Product Ops capacity (and I suspect other xx Ops roles too) - a lot of feedback right away about what can be improved, what is and isn’t working, and the hopes and dreams of many, particularly in the tech side of the business.
Month 1 at HeliosX was no different. And this is no bad thing, at all. The leadership at HeliosX recognise their incredible success and growth, particularly in the last couple of years, but also recognises that growth, and the opportunities they were perfectly placed to grasp, would have, and did, come with an operational shortfall in certain teams to make up. While the situation is identical to many successful hypergrowth businesses, HeliosX has acted quickly. Enter Product Operations *Plays superhero theme*
Month 1 has been full-on learning - on two significant tracks. The first has been to understand enough about the health/medical/pharma sector in which the business operates. For me, all brand new, with complexity and surprising simplicity in equal measure. I say ‘understand enough’, because as closely as I work with the digital product teams providing the e-commerce and consultation platforms, I do not need to understand the inner workings of medication prescribing, sales and delivery - at least in a structured way and immediately. Natural osmosis of information will happen over the coming months. I have always maintained that with Product Ops, I don’t really care what we build (physically or digitally) - other professionals are employed to focus on the ‘what’. I care about ‘how’ we build, that we are building the right, most valuable solutions for both business and customer, using all the qualitative and quantitative information available, in a sustainable, measurable way. If the teams are doing everything correctly up to the decision-making moment, who am I to argue with the decision itself!
The second track is naturally about the job to be done - how are the product teams operating, how is the wider business and the product division collaborating, what can be improved, and where is the greatest appetite or demand. This is Product Ops 101 - a talking tour of the business to understand the unique ways of working, the interactions, the touchpoints, the opportunities and the sensitivities.
For reference, in general whenever I talk about ‘Product’, I refer to the product teams and the wider tech side of the business (Product management, design, product marketing, CRO, engineering, data). For me, Product Ops supports all these teams despite the name. At HeliosX too, I mean ‘Product’ in terms of the digital product and teams - noting that the business sells physical products (medication).
The business is fast-moving and has a desire for change, which honestly is a dream set up for Product Operations. The business is conscious of where to improve, has taken action, and has also prepared the business that change and improvement are both coming and supported. My conversations in the first weeks have been universally met with relief and excitement from across the business. Ideas have been flowing, opportunities identified and support pledged to see meaningful improvements to ways of working and collaborating - and these are from colleagues after hearing my pitch on what Product Ops is here to achieve.
Early Research Outcomes
Within the ProductOps sphere of influence, I have:
Identified, through both observation and consultation, the need for improved access to key, current information relating to product development plans (roadmaps, releases).
This is ProductHUB through and through for me:
ProductHUB: A single central landing page and a library containing the latest information on the digital product - roadmaps, releases, request forms, team topology and responsibilities, ways of working and expectations.
By the end of this month (Month 1), I have a finished v1 of ProductHUB ready to activate with the wider business, pending some cosmetic changes.
ProductHUB will not only provide an on-demand one-stop-shop for all important product-related information but also as a location to redirect requests and conversations to, away from Slack (See below).
Reducing the ‘noise’ on Slack. Slack is used extensively and positively, but with so many conversations, particularly where product management has even a passing interest, it has become difficult for PMs in particular to know what needs their attention now vs later vs ever.
This is a tricky issue to solve as solutions can be both personal and require individual discipline.
I have investigated the landscape and drafted guidance for product folks on how to self-manage their time, what channels do and do not need jumping on quickly, as well as a rationalisation plan for the channels in place now.
A portion of the conversations will also be redirected to the new ProductHUB, which is needed first to have a central place to send people to!
This will be an ongoing maintenance and vigilance exercise as it is not practical to mandate details of Slack usage across a company of 1000+ people, so the focus will be on product discipline and self-care to begin with.
Identified the need for improved product progress and performance reporting for leadership; sprint reports, quarterly reflections, initiatives progress.
There is a continuing need to enhance trust between the product division and the wider business, and the leadership within the business. Surfacing information to support conversations on what we planned and what we achieved goes a long way toward furthering that trust. The reports also serve as a good retrospective and reflective document for the teams themselves.
I am carefully considering the ability to automate much or all of the aspects for each of these reports using existing technology (Confluence, Jira, Airtable, Metabase) to provide something of value to end users while reusing data already captured and not putting more demand on product managers.
Currently, Sprint reports are almost complete in an automated way, pulling information from Jira into a dashboard in Metabase
Been asked to lead on the re-implementation of Scrum (from Kanban) across approximately half our product squads.
This was underway as I arrived, and was asked to take on the logistical and practical rollout elements.
The product managers, designers and engineers are all fully versed and experienced in running Scrum, and their ability to pick this directive up and get on has very much impressed me.
At the time of writing this article, the first Sprints for several teams have just been completed and the outcomes and analysis are now being reviewed. Early signs are positive.
Lets see what month 2 has in store as we head into the festive holidays - downtime for some businesses but at HeliosX this is a peak period. See you then.
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.
Jotted down some new ideas for a product hub / homebase I've recently started on. Thank you!
I am new to the ProdOps world and very much appreciate this series. It is helping me see where I can help deliver value to our organization.