Building Product Operations from Scratch
A few years ago I stepped into a role leading strategy and operations for an engineering organization within a large software company. This sort of effort within engineering organizations is typically called Product Operations or ProdOps for short. During my first sit-down with my manager I asked how well the organization understood what ProdOps is and does. Her response was, “Zero. We’re starting from scratch.” That caused me to raise an eyebrow. Before I could build, run or even tweak an effort, I needed to make the case for ProdOps value.
This case making would be no small feat. This engineering organization was positioned in the heart of the company’s chief product and platform. They had run for over 20 years with largely only engineers left to their own devices to deliver ‘Wow!’ products to users. Their strategy had resulted in a long stream of products that were so cool that adoption was counted in the millions and billions of users. In this world, if a product did not inspire that sort of organic adoption, they would discard it. The formula had worked for years. No one wanted to lose that magic. So why bring in overhead generators, such as a strategy & operations lead, that would likely cause extra work that might screw with the magic.
Additionally, the organization had, during the previous year, experienced some top-down process improvement efforts that, despite the engineering teams’ trying to support them, had struggled. A tool had been deployed to automate the commitment reporting process and the pilot that was not going well. As I discussed the pilot and the stumbles I heard plenty of gentle messages questioning the value of the process.
That I had a job meant that I had a senior executive sponsor. However, in this engineer-centric, grassroots oriented culture, sponsorship was not enough. I had to prove both my worth and the value of ProdOps, individual by individual. My work was cut out for me.
What ProdOps Is and Isn’t
Product Operations, just like any other operations framework, connects our daily work to business outcomes. ProdOps sits at the nexus of product, engineering and customer success. It provides an operating model that translates strategic intent into operational capabilities. Then it monitors the performance and progress of those capabilities to provide a closed loop for assessing the organization’s ability to achieve its desired outcomes.
ProdOps efforts collaborate closely with the engineering teams, product management, strategy, customer experience, marketing, finance, and partner teams to generate the ‘big picture,’ for organization leadership, marking progress and emerging challenges. This operating model is not, in and of itself, strategic. However, it frames and facilitates strategy development, management and reinforcement.
ProdOps is not product management or engineering sprint operations and does not monitor the day-to-day work required to roadmap, plan for, or execute on product generation to launch. Those arenas are managed by the product managers and engineering teams.
ProdOps provides the framework for developing and executing on strategy establishing the business operating cadence or business operating model. Key responsibilities include:
- Generating, aligning strategy to execution, and establishing a feedback loop.
- Building, optimizing and facilitating processes.
- Reporting and facilitating executive reviews.
- Building necessary infrastructure including guidance, templates and process/reporting automation tooling as appropriate.
Some of the areas that ProdOps covers includes:
- Strategy development
- Annual planning
- Periodic commitments [annual OKRs if that’s the method of choice]
- Portfolio management [valuation and dependencies]
- Budget planning [Finance collaboration]
- Resource planning [HR collaboration]
- Performance to commitments tracking [OKR tracking, again if that’s the method of choice]
- Broadcast communications [Comms team collaboration — executive missives, newsletters, etc.
- Org health monitoring [HR collaboration]
- Strategic program execution [special projects portfolio]
- Summit management [Chief of Staff collaboration — planning and facilitation]
- Org engagement [Chief of Staff collaboration — Periodic team meetings, AMAs, etc]
- Transformation and change management support.
ProdOps Value at the Informational Nexus
The above list represents numerous workflows that capture and curate a massive amount of information and data. As noted, some of the information and data is captured and framed either by or in collaboration with other functions such as HR and finance. But the lion’s share of this critical intelligence is drawn from the folks in three key roles — engineers, product manager [PMs], and TPgMs*. While ProdOps designs, facilitates, and sets cadence for the workflows, it is the engineers, PMs and TPgMs that bear the brunt of pulling the needed information and data together.
*NOTE: TPgM is a term that combines program managers [PgMs] that drive programs and technical program managers [TPMs] that drive programs requiring technical expertise.
Engineering organization culture is focused, skeptical, constructively contentious, and ultimate value-seeking in a quest to pursue a solution that:
- maximizes delivered value
- fitting within schedule constraints
- with the least possible risk.
Engineers are typically highly focused, intellectual problem solvers that are the workhorses of organization producing engineered solutions. Software companies, operating in an extremely competitive environment, among other things, value speed to launch. That means that engineering organizations put a premium on engineers being heads down doing engineering work. Anything else that they do better provide a high value to the organization.
Solutioning is based on the best available information, expert inputs, and choosing the most likely successful designs, with managed risks and unknowns. PMs are responsible for the solution requirements roadmap and fit with other solutions. They sift through mountains of information from many sources on their way to an elegant product framework. Once the work is planned, they want no distractions from the actual coding work. Anything that takes them away from coding is a bad thing. For contained programs the engineering manager typically serves as the project manager, sometimes shared with the designated scrum master and product manager, if the agile methodology is used to manage development sprints. The team acts as a contained unit focused completely on build and delivery.
For more complex and highly dependent build efforts, a TPgM serve two functions. Primarily, their responsibilities focus on managing the dependencies, challenges and risks, while keeping the team’s attention on the end-game. They also handle any tracking and reporting demands so the engineers are freed up to code, code, code. Having a TPgM on the team gives some room to absorb overhead. However, because their primary role is focused on delivery, that overhead must deliver high value.
With all this in mind, engineers are rightfully resistant to overhead that does not provide demonstrated organizational value. They are highly skeptical of concepts and marketed promises. They want proof. So to stand up a ProdOps structure, value has to be demonstrated at each step.
Defining the Problem
You do not have to solve everything at once. The first thing to consider, when developing ProdOps, or for that matter, any operations effort, is that the efforts for developing, aligning and facilitating strategy have already organically embedded themselves. Those efforts may be poorly drawn and deliver far less than desired value. But those nascent efforts are in play, relieving the pressure to solve everything at once.
The entirety of ProdOps scope can be overwhelming. Operations scope, as a set of overhead activities, can be overwhelming to any organization. ProdOps, with its demands on engineering can represent an existential risk. So framing up the effort in its entirety to the organization is both not necessary and likely to kill support. Better to demonstrate value a bit at a time. Which takes me to my next point.
There are two ways to drive change, revolution and evolution. Revolution means you are tackling everything at once. You are ripping off the bandaid and deploying the new way of doing things wholesale. The value of holistic change is that it’s fast, comprehensive and moves you into the new paradigm as quickly as possible. The downside is that it is quite disruptive, and risky. The risk is two fold. The first risk is cultural rejection. Culture rules. If the transformation you are driving does not bring culture along then it will be rejected. The other risk is that, if you have in any way misdiagnosed the problem, the comprehensive solution will result in at least operating issues if not operating failure. Revolution is a great choice if your organization is in a deep crisis. Organizational appetite for the pain of a major change is much higher when in a significant crisis. Otherwise, the disruption and potential risks of a major deployment outweigh the conceptual benefits.
Incremental solutioning builds credibility. Evolution requires incremental solutioning, tackling a more narrow problem and solutioning in a way that tests and fortifies the solution, engaging the organization in the development and growing team support even before the first improvement is delivered. This approach takes far more time and effort. However, this incremental extended effort results in an organizationally supported, working solution for which it is easier to demonstrate value. With this in mind identifying the most organizationally obvious problem that can be improved with obvious results is always a safe place to start.
Establishing the Build Phases
Given the stakes, phasing in ProdOps activities makes sense. The table below provides a simplified generic approach to design ProdOps from scratch.
While this generic approach is a helpful guide, it is only a rough sketch and must be customized to your situation. Your engineering organization will be dealing with their specific pain points and broken processes. You may have some existing highly mature workflows while other workflows are conspicuously absent. Look for the opportunities to demonstrate early value.
Early Opportunities to Demonstrate Value
In my case, fortune dumped the organizational obvious problem at my feet. The organization set its commitments via an OKR process, [objectives and key results] annually. Once the annual OKRs were in place performance was tracked with OKR updated every six weeks, mid- and end-of quarter. Prior to my arrival, a pilot effort was set up to test out tracking updates using the tool. Within a few months of my onboarding, the executive sponsor, business architect, and technical architect all left the organization. By default, I was handed ownership of an unsponsored pilot using a tool that was radically under-designed for tracking needs. The pilot teams were very unhappy with the effort that they were putting into the tracking effort, with little to show on the backend.
Automation works when it works. I am a big fan of automation when it results in toil reduction and accessible, clean data for performance reporting and trend analysis. I have managed enterprise platform tooling delivery many times in my career, in multiple operational arenas with powerful results. So my prejudices lean toward automation where practical and with clear value outcomes. On the other hand, I have also seen really poorly deployed platforms. A tool should work for the users, not the users for the tool. Every platform deployment failure that I have witnessed made the users work for the tool with too little output value.
What we needed was not served by what we had. A typical OKR tracking process requires a few key steps:
- Capturing the OKR updates.
- Curating the updates for leadership review via collaborative effort.
- Framing the reporting for executive review to focus on the hot spots.
- A method for addressing executive clarifying questions.
The messaging for each OKR had one of two flavors.
- Everything is fine and here is the proof. Links to reference docs demonstrating progress or results.
- We have a problem. Here are the steps we are taking to get back on track. And, here is the help we need.
For the tool we had, capture was manual and had to be done one update at a time. There was no ability to gracefully navigate the tool. Finding OKR updates required extensive scrolling to locate. Curation had to be done individually in the tool. The tool had no dashboard to identify hotspots. So it was a difficult to manage database from which updates had to be pulled and massaged. Anyone who has used a tool knows that data entry and manipulations are more difficult than doing them in individual documents and spreadsheets. The only reason to move to a tool is that it makes the entry and downstream work far easier and more useful.
While, in the world of process improvement removing automation seems counterintuitive, in this case it was the right move. The current pilot:
- Made all of the tracking work heavier.
- Two thirds of the entry work was to simply make finding and using updates possible.
- The output was structured far more poorly than could be accomplished in a presentation deck or spreadsheet.
The point of this example is that it is critical to step back and ask what is really needed and then simplify the ProdOps solution to the lowest common denominator. It’s best to start with the stripped down, most barebones approach, deliver initial high value, and then build to fill emerging performance gaps.
With that initial clean approach you establish credibility that allows you to amplify the bright spot and take your next step in delivering value to the organization.
The Take Aways
In summary, the ‘so what’ of this article includes:
ProdOps sits at the nexus of product, engineering and customer success. It provides an operating model that translates strategic intent into operational capabilities. Then it monitors the performance and progress of those capabilities to provide a closed loop for assessing the organization’s ability to achieve its desired outcomes.
ProdOps provides the framework for developing and executing on strategy establishing the business operating cadence or business operating model. Key responsibilities include:
- Generating, aligning strategy to execution, and establishing a feedback loop.
- Building, optimizing and facilitating processes.
- Reporting and facilitating executive reviews.
- Building necessary infrastructure including guidance, templates and process/reporting automation tooling as appropriate.
Engineers are generally skeptical, deeply focused on delivery, and demand to quickly see the value of any overhead effort. Getting the engineers on your side with a hard won effort. But, if you do, your ability to tackle large investment efforts will be underwritten by their support. That support is not good, it is necessary.
The entirety of the ProdOps remit is substantial and represents a large overhead investment. Each aspect of that investment, and more specifically each step, needs to demonstrate rapid value with the least amount of effort.
Quick wins are critical to developing credibility and fuel next step work. Every new thing you tackle requires early demonstration of value and a focus on process engagement with the least effort possible.
Deploying ProdOps can be phased, but opportunities must be custom identified to the urgent needs of the moment and tackled with aligned organizational support.
ProdOps work is not easy. It requires building a network of support with some of the most skeptical and demanding users. However, if you establish early credibility and deliver what you promise, the work is rewarding, challenging, and deeply engaging.
Find more articles from Sarah at: www.operations-architect.com.