Product Operations 101: in pursuit of betterness
Whatever your trade, the chances are you’ve heard someone use the phrase ‘spinning plates’ recently in your workplace.
We’ve all been there at some point in our working life — jobs coming in faster than you can prioritise them, all requiring complex decision-making, while somewhere in the back of your mind the Sabre Dance loops ever closer to a crescendo.
Actually, that last part might just be me. Hmm. Moving on …
Product management in particular can be prone to this kind of scenario because it sits at the junction where infinite ideas meet finite resources.
And when you’re busy optimising and building products, at what point do you sit everyone down to review, streamline and reinvent your processes, ensure colleagues are aligned and tools are optimised to work just so?
This is where the developing field of Product Operations just might ride in to save your day.
Product … Ops?
These days many disciplines have an associated ‘ops’ field — from DevOps to FinOps to MarketingOps and PeopleOps, you might think it’s a matter of time before OpsOps becomes a thing. Does Product really need ops?
Let’s start with a definition — or rather some definitions, because as with all new fields, this one is constantly evolving:
- The goal of Product Ops is to streamline and improve the product team’s work
- Product Operations acts as a conduit across teams, including product management, DevOps, sales, and marketing, to streamline […] processes, improve internal communication and create a feedback loop
- Product Operations roles facilitate the easy communication and sharing of resources and data between departments
- Product Ops operates differently at every company.
My product, then, is the Product Team — lucky me (and I do mean that)! It’s their job to answer the ‘who’, ‘why’ and ‘what’ questions; Product Ops answers the ‘how’.
If I can help them work more efficiently and happily — if I can help to build resilience, improve alignment and remove any frictions — then that will have a real, positive effect on the company’s performance, and of course in turn, a positive effect for our customers.
This all becomes particularly relevant when a business scales, at which point a consistent approach becomes much more important.
I’ve been Lead Product Operations Manager at MPB for something approaching a year now, so I can’t claim to offer you long-standing expertise or academic rigour.
But I’ve spent my time and energy setting up a new business function from scratch and this felt like a good point to introduce the topic — to share my experiences and point you towards some resources for further research. Just bear in mind the last bullet point above!
Starting out in Product Ops
I was already a Product Manager at MPB when we began looking seriously at introducing a Product Operations function. We were scaling quickly and wanted to refresh our ways of working, and investigate what we could optimise.
I wasn’t as familiar with the field as I was with Product Management, and had to upskill myself at the double. Fortunately I was already immersed in the Product team and familiar with the roles and expectations of the people I’d be working alongside.
I defined the ops role in terms of supporting and improving the ‘three Ps’ — product, people and processes:
- MPB is the largest global platform to buy, sell and trade used photo and video gear. Our products aren’t the cameras and lenses themselves but the online platform where we trade them, and the back-office systems we use for warehousing, inspection and distribution.
- The people — Product Managers and Product Designers — might be responsible for anything from integrating a new payment system or optimising overall UX to designing a product (kit) inspection workflow. That brings them into contact with customers, software engineers, third party suppliers, data analysts, finance experts … everyone, in fact.
- Our processes are changing rapidly as the company expands. We focus heavily on creating automated, efficient and optimised working patterns, backed by bespoke software built in-house.
All of which can look like a vast mountain of expectation for someone standing at its foot on day one. So my first task was to make a plan — a 30 days / 60 days / 90 days breakdown of how I aimed to tackle that difficult first stretch.
First let’s talk
The larger an organisation, the more complex the human machine at its heart; Product Ops, then, is a job for “people people”. If you can bring to work your natural empathy and the listening skills of a wise old long-eared bat, you’ll have a head start in the field.
I decided the best way to gather the information I needed was to speak to literally everyone in the Product Team. I set up one-to-one interviews and made it clear that they would happen in a ‘safe space’. People aren’t always comfortable speaking up in a group, so if I wanted to make improvements I knew I needed to hear honest answers. I needed people to understand that I was there for them.
These interviews were always interesting and provided a huge amount of feedback (12 hours and counting!). We talked about friction points, stakeholder alignment and their three wishes for an improved Product-life.
The three most frequent comments I heard are probably common to most similar-sized businesses — how to find time to do one’s best work (reduce WIP), how to prioritise consistently, and clarification of our decision-making processes throughout the product development lifecycle (which can often become less obvious as an organisation scales).
These were all things I felt we could start to address.
Meeting challenges
In some jobs — sales executive, for example — the important part of the working day consists of meetings. In others — taxi drivers, say, or sub-editors — a work meeting is more of an interruption.
Product people sit somewhere in the middle. Meetings are important opportunities to make progress; equally, they can take someone away from a busy discovery and delivery schedule, and result in unwelcome context-switching.
At MPB we identified two quick wins to give our product people a bit more control over their schedule.
First, a simple fix: an improved agenda format on meeting invitations now helps people judge more accurately the impact of attending or not — and gives them some basis to say “Sorry, I can’t make this session”.
Second, we standardised shorter meeting times — 50 minutes instead of an hour, 25 minutes instead of 30 etc. The point of these ‘speedy meetings’ is to give people time to prepare for (and reach) the next meeting. At the very worst, it makes more time to spend on other priority tasks.
One way tickets
As organisations scale, workflows need to evolve with them. For a busy Product team, a single work ‘funnel’ takes the stress out of tracking every request.
Our Product people use Jira for just this purpose, but initial requests have historically come from outside the team via many different routes — Monday board entries, meetings, Slack, ad hoc conversations at the coffee machine …
Adding these requests to the ticketing queue is no small task. Details may need to be teased out through further questioning. Getting the right information correctly prioritised and sent to the appropriate resolving team can be a distracting time sink.
I led a rather chunky project to audit and rationalise this workflow, creating a single submission form where colleagues can enter their ideas and feedback. These are triaged regularly and moved into the appropriate team’s backlog.
The result? More time freed up, a consistent approach for work requests and a clear submission route for stakeholders with guidance built in. Win-win.
So long, farewell
There can surely be no greater joy than consigning 1,000-plus Jira tickets to “Done/Won’t Do”.
Issue-tracking software is prone to ticket buildup — old requests that nobody wanted to close down at the time for any number of good reasons beyond mere forgetfulness. “Fast-follow” items that were sidelined, perhaps, or outstanding details to be discussed. Unfortunately, over time this ticket bloat can make it harder to find what you’re looking for, much like an old satellite TV recorder.
We realised that reviewing and cleaning up our Jira backlogs would be a lovely win. The work was handled sensitively and sensibly, of course — checking with those who had raised the tickets, understanding whether the reported value was still a thing, and explaining that the tickets would still exist in the depths of Jira. They just don’t hang about in the squads’ clean and tidy backlogs any more.
What now?
The Product Ops strategy and roadmap are in place; feedback mechanisms have been set up so I can keep on top of what’s important to my Product pals and partners.
I’m using a variety of techniques to capture feedback — all-team retros, my own Monday board, a drop-in “Pr’Ops Clinic” and one-to-one chats, typically at a seaside café near our Brighton office.
I’ve worked hard to ensure that Product colleagues’ feedback is captured and sorted. I can then edit, combine, prioritise and action, keeping track in the same way a Product Manager would. And much like that Product Manager, I live in hope that one day my backlog will be cleared … or at least reduced a wee bit.
While I’ve already been able to start influencing people’s work there is still plenty to do (hello roadmapping, identifying common training needs, useful dashboards …). But what I can say for sure is that I love doing this.
Having been a Product Manager I absolutely understand how hard the job can be. I also get how hard it can sometimes be for stakeholders to understand how decisions are made.
I’m very keen to do the right thing by people and I have had some lovely feedback that things are getting better. That’s not all down to me, of course, but I love being able to spend time fixing an issue that stopped someone from doing their best work.
And I’ve learned the value of review functions like Product Ops — making colleagues (my customers) happier and helping people ensure that they’re working on the right thing at the right time, and in the long run, how they can save money.
I’ll finish by listing some of the resources I’ve found helpful, from training courses and books to Product Management support forums.
Product Management is itself quite a new area for some businesses, so I think the growth of Product Operations is going to be a slow burn. Nevertheless, there’s no question in my mind that it’s very much here to stay.
Learn more about Product Ops
Starting points for those new to Product Operations.
Product Led Alliance
Many excellent resources, conferences and training courses.
productledalliance.com
Product Mind Community
A support community for Product professionals
https://productmindcommunity.substack.com/about
And some Product Ops thought leaders I follow and recommend:
Denise Tilles
Product leadership professional and co-author of the book Product Operations
www.denisetilles.com/blog
Antonia Landi
Product Ops coach with a must-read newsletter
www.antonialandi.com/the-product-ops-newsletter
Graham Reed
Product Ops pioneer and founder of Product Mind Community
substack.com/@practicalproductops
Helen Bird is Lead Product Operations Manager at MPB, the largest global platform to buy, sell and trade used photo and video gear.
