Setting Up Product Ops — 101
An approach to introducing and setting up Product Ops in your Org
Intro
The world around us is changing rapidly and the last 2 years have been crazy, to say the least. Tons of new opportunities for Companies to solve for, and tons of new startups, and existing ones are forced to change their strategy and operations in months what they had anticipated changing in years.
It’s never been more important for companies to get better at how they work, in terms of synergies both within their Teams and also externally with Customers and other stakeholders.
Customer-centricity is something which is fast becoming the default mode of operation and is critical to do it right. Customer-centricity is not just a phase in the whole product development lifecycle, it needs to be a way of life, the way the whole Org and especially the whole Product team operates.
It starts from finding opportunities to picking the right ones, solving them right, delivering them right, ensuring users are using them, and feeding the inputs back to the Product lifecycle.
Rinse.
Repeat.
Customers never cared and will never care about how your Org chart is shaped, they only care how their Product is shaping up and how well and how fast it can be shipped, consistently.
For this to happen, Orgs can do better in how their various Functions like Design, Product, Engineering, Business, Support, Marketing, Finance, Legal, HR, etc can work together as One-Team rather than in silos.
Collaboration has never been more important and yet with rising expectations of shorter Release timelines, higher quality, consistent rapid growth (business objectives), retention, profitability, and innovation…it’s increasingly getting difficult to collaborate, align, and deliver.
There has to be a better or rather there needs to be a better way.
Enter — Product Ops.
Why this post?
Am increasingly seeing and feeling the importance of Product Ops growing, including several job opportunities in Companies for Product Ops. The drawback is that it’s a very nascent role and not much info exists out there.
When I started into this a little more than a year ago, I could count a handful of resources on this fascinating role. Those handfuls of resources helped me immensely to understand what Product Ops is, its potential and how Companies are benefiting from having Product Ops in their Org.
This is my way of evangelising and giving back to the Product Ops community so that collectively we grow this practice.
How did I identify the need for it?
I always had an innate and child-like curiosity which I seem to carry to date. So much so that I got an opportunity to venture into User Research from UX Design because my Manager noticed that I asked a lot of questions and was able to dig deeper beyond the surface.
In 2019, I moved into a full-time role as a Program Manager — User Research to drive Customer Obsession across Product Management and as time went by additionally to other Functions and eventually to the whole Org.
This role was reported and operated within PMO (Product Management Office) which was all about managing Releases, and managing the processes and operations (Product Ops was not a thing then) of the Product and Product Management as a Function.
This is when I got a very close view of opportunities to improve how the Product Management Function operated, both internally and cross-functionally with other Teams.
As I like to approach it, I took the concept of Product Ops akin to a product I wanted to build (or rather establish) and followed somewhat loosely, the entire product discovery, definition, design, build, delivery, and adoption process.
To get going, it was important to understand fit, and whether there is a need for it in the current scheme of things.
For that, I went deep into understanding the current frictions and problems on the ground, what PMs were struggling with, what other teams were struggling with when working with PMs, and so on.
Mere solving problems is not enough, identifying the right and the biggest problem and then solving it is what has always served me good.
The first step was to lay down the Product Lifecycle Process or Product Development Process as is currently happening, either by design or by chance (it’s been happening in a particular way for years).
Note — These are not necessarily sequential Waterfall styles but more of Agile where there are loops and regular iterations
These are not all stages of the lifecycle but more to give you an idea of what it looks like. Also, it's intentionally descriptive (one out of many ways to do it) than prescriptive (this is the way to do it) as this will likely change from Org to Org.
Thereafter I added the Descriptions for each step, why it exists, and what it's for.
Once that was done, I added in the Activities/Milestones associated with the Step.
Then the Gaps in the current way of doing it.
When should the Step happen in the whole lifecycle, some are time-bound and some are ongoing…
Taking stock of existing Processes/Framework
And then identifying the Owner, if one exists currently, if not to find one.
Note — The above steps (taking stock and assigning ownership) have not shown a representation as to its being highly subjective from Org to Org. Perhaps will have a separate post and share templates of Processes/Frameworks which you can use and get rolling.
And finally, the last step was to colour code the maturity level in terms of
Green highlight — In good shape, can be further optimised
Yellow highlight — Getting there
Orange highlight — Needs Immediate Action
The below colour code representation is only for illustrative purposes.
Color-coding helped a lot to intentionally prioritised and focus our attention on things that carried high leverage and could move the needle in terms of impact.
Above was all the preparatory step towards expanding and internalising my understanding of the way things were currently done and how can things get better towards building a case for Product Ops.
The next step was to combine all the learnings and present a Framework for Product Ops to Senior Leadership & Management.
Framework: WHAT, WHY, STAKEHOLDERS, PILLARS
WHAT
Product Ops is an operational function/role that increases the efficiency and effectiveness of collaboration of Product Teams with various cross-functional teams such as Design, Engineering, Support, Marketing, Sales, CIS (IT), etc.
It supports the Management, Leadership, and Product Team along with their cross-functional counterparts to improve alignment, communications, and processes around the product.
WHY
- Trusted advisor to Management, Leadership and Product Teams
- Strategic and Operational direction for PMs
-Increase the efficiency and effective Decision-making ( w.r.t Product, Processes, People) with better data
-Increase the efficiency and effectiveness of GTM
-Drive adoption - Take away Operational tasks off of Product Managers so that they can focus on building Delightful products
- Communication - Right communication and timely to all stakeholders
STAKEHOLDERS
PILLARS
Broadly speaking, there are 4 aspects or pillars, as I like to call them, of Product Ops. Though depending on your Org and maturity, you may modify as required.
- Product — optimising the whole product lifecycle process
- Processes & Templates — optimising each sub-process within the larger Product process
- People — effective people utilisation, strengthening people
- Communication & Collaboration — what to communicate, to whom to communicate, how often, how can collaboration be increased and a cadence been set up between different stakeholders
VISUAL REPRESENTATION
For keeping things simple, have expanded the Product pillar and how it fills into a Product Lifecycle which is just an example. Different Orgs are likely to have different Product Lifecycles.
Taking the above Product Lifecycle as an example,
Product Ops has the potential and is best suited to unlock and optimise the whole Product Lifecycle starting from Idea right to Launch, Adoption and circling back to ensure it's an iterative customer & market feedback loop to keep the Product relevant and fit (efficient & effective) at all times.
And it's not just in-theory, below will share the impact of Product Ops I have experienced first-hand.
SNAPSHOT — EXPANSION OF 4 PILLARS
SPEED BREAKERS — being reflective as to where Product Ops may impact adversely in the short-term
Italics denote how we intend to overcome
- Slow down existing processes and delivery — removing existing frictions without hampering the momentum
- Existing Team size may become an impediment considering the scope of work — ramp up ProductOps team
- Overlap of responsibilities, especially with PM — set clear boundaries and expectations
- Data constraint — access and principles (what we don’t track as a Company) — work with what we have and organize it better for ease of accessibility
- A balance between strategic & operational activities — Focus & optimize on both the present path and the direction we are going
- Time taken to show value may lead to negative initial impressions — pick small problems to solve to show value and build momentum, constantly move in the direction of wicked problems for higher impact (horizontal and vertical)
Principles of Product Ops
Summary of what are the Goals of Product Ops and what Methods do we apply to achieve the Goals —
We presented the whole initiative and the above framework to Management and Top Leadership (consisting of cross-functional Department/Functional heads) which was very well-appreciated and we got the go-ahead to set up Product Ops officially.
Talk about pulling above your weight and taking initiative. In the long run, these always pay off and you become better and more valuable.
Now since we got the buy-in, the real work of Product Ops starts!
Prioritisation needs to happen as to what needs to be picked up based on their maturity, impact and the outcome we want to chase.
Below are a few things which we prioritised and were able to create impact within the framework and driven by Product Ops.
Impact of Product Ops: What changed?
First things first, Product Ops to me is not a destination and is more of a journey or rather a mindset.
However, there were impactful milestones on this journey —
- Introduction of a new phase “Adoption” in the whole product lifecycle where after every release/launch, all teams who participated in the Release and especially Product Teams took part in Customer Centricity to understand how the new release is doing, any frictions users are facing, what are the areas of delight and so on.
- Active participation of the Product team in GTM was both an outcome and to enable and influence point no.1 above. I firmly believe Product Managers will greatly benefit from being cognisant of GTM and what it takes to take the product to the market. Many decisions and how decision-making happens changes, for the better when you start to work backwards.
- Greater clarity on the whole product lifecycle, milestones within it, which parts were running smoothly, which parts need improvement, which parts need fixing, and new processes to be introduced.
- Greater clarity on roles & responsibilities and which parts/milestones no one was owning and therefore was “leaking”.
- Greater clarity on who are the stakeholders and their level of involvement.
Note: I found the RACI matrix an excellent framework for this. It breaks the involvement into 4 buckets —
Responsible: Person who is completing the task
Accountable: Person who is making decisions and takes action on the task(s)
Consult the Person who will be communicated with regarding the decision-making process and specific tasks. Is a person who is likely to provide inputs as it may affect them/their team
Inform Person who will be updated on decisions and actions during the project. More of keeping in the loop.
That’s all for now folks!
Hope this article was helpful and has given you an idea of what Product Ops is, what all activities it consists of and how you can go about setting it up wherever you work.
If you found this helpful, do share it within your network. If you have any inputs or have set-up or setting-up Product Ops within your Org, more than happy to hear about your experience.
