This article was taken from a presentation given at the Product Ops Summit in Sept 2022. Get the full talk on demand here.
Diana Soler is the Director of Product Operations at Assent, the leading supply chain sustainability management solution dedicated to helping complex manufacturers bring responsible products to the world.
In this Q&A, Diana breaks down what product operations looks like at Assent; from the main focus and responsibilities of the function to the key challenges and getting buy-in from other teams...
Could you tell us what Assent does and what product ops looks like at Assent?
Product operations has existed at Assent for several years. Until recently, it sat under product management. It now stands as an independent function reporting directly to the Chief Product Officer, and sits beside the rest of the product teams.
Unlike most organizations where product operations sits at the center of product management, engineering, and customer success, the product operations function at Assent partners with and supports all the product teams, including product engineering, product design, product management, product support, and product infrastructure.
We also collaborate daily with the customer-facing teams, which includes our professional services and customer success teams. We partner with product marketing and other key stakeholder groups that work closely with the product groups to ensure they have what they need from the product organization.
Our mission is to drive cohesion and enable the product teams to be more efficient through the orchestration of people, process, tools, and information. I look at how the product teams are operating and how they work across the organization. For example, how we provide the customer-facing teams with product knowledge so they can answer customer questions.
Product ops has three key focus areas and responsibilities, which are:
Product enablement
This includes product team onboarding with the goal of ramping up new joiners as quickly as possible with the most comprehensive product in company knowledge as possible.
We partner with product leadership on continuous professional development for the product team members, with the aim to continue upskilling the team and increase their talent density.
We also partner with our learning and development team as well as other enablement functions across the organization to build a robust product enablement program.
Product operational excellence
In this bucket, we focus on product planning and prioritization, and product lifecycle phases and transitions.
Product engagement and collaboration
This is the most cross-functional area of work, where the product ops team is responsible for the end-to-end product communication plan. This includes what we're communicating, to who, and how. It needs to be the right time, the right content, and the right audience.
We also look at information management, which is a library of products, knowledge, and documentation accessible to all employees within the organization.
Could you tell us a bit more about what inspired you to select this topic for discussion today?
Getting buy-in from product managers, engineering managers, and design managers is something we tend to overlook as we focus on establishing the product ops function.
However, without the early buy-in and support of the key stakeholders, our job and the job of a product operations team member is going to be very challenging.
Product operations as a function can be disruptive as we introduce new processes and frameworks or change existing ones. We also know that people don't like change by nature. So the puzzle we face is how product operations can enter an organization with a well-established product team and get buy-in from those that product operations will impact the most.
I realized that while leadership understood the value that product operations could bring to a growing product team and scaling organization, the efforts of product operations wouldn’t be successful if the individuals doing the work day to day and changing their ways of working didn’t see the value.
Therefore, back when I was a product ops team of one, I shifted my efforts in showing the value of product ops from leadership and the other teams across the work, to the individual team members that would be impacted by my work.
I'll reference three initiatives that I worked on early in my product ops journey. These projects were large, cross-functional, and involved several product teams:
The adoption of Jira as a road mapping tool
I wanted to create a consolidated roadmap view for all the product teams and so that anyone in the organization could have real-time access to what the product teams were building. This alleviated some of the frustration among leadership and the cross-functional teams that came from not knowing what product was being worked on.
Restructuring and redesigning the quarterly planning process
The goal was to introduce uniformity and adoption of best practices across all the product teams. We introduced a new epic write-up template and created a dependencies review checkpoint among other activities.
In return, this increased the level of confidence in the delivery of the solutions selected for development in any given timeframe. We also better communicated with both internal and external customers.
Redesigning the voice of the customer program
We wanted to improve communication and collaboration between the customer success team and the product managers, as well as improve feedback loops between the company and the customers.
We redesigned the process to improve documentation and applied a response time to the product managers and from the customer success manager back to the customer. In return, we saw many more customer requests get attention and get prioritized by the product managers. We also saw less skepticism among our customers about the program.
What challenges did you come across when executing these projects?
The three projects required significant buy-in and adoption by the product and engineering managers among many other team members. Though the benefit was clear, the lift to get these initiatives in place was significant. These individuals had the power to slow them down or outright stop them, and consequently impact the product operation schools.
After I completed my scoping phase and created my project timeline, it was time to share with and get buy-in from the senior leadership team. This was easy to do because the outcome and value was clear to them and I had the data to support our prioritization of these initiatives.
The hard part came when it was time to implement these changes. During the scoping and planning phase, I spent lots of time speaking with other teams across the organization about their pain and listening to their ideas on how to fix the root cause of the problem.
For example, the product marketing team expressed frustration with how the product managers were communicating what they were going to deliver in the next quarter. It was too feature-focused and instead, product marketing wanted the product manager to speak about the value to the customer.
Another example was listening to the customer success managers describe how they had to request the release plan and roadmap from the individual product managers, and how they’d receive various sources. Some of the product managers used Google Sheets, some used Productboard, and others used other tools for roadmapping.
So when the time came to implement these well-scoped initiatives, some of the team members that had to adopt these new ways of working were not warm to the idea. I should’ve listened to the product managers and gotten their side of the story before applying a response to the voice of the customer tickets.
I could also have spoken to engineering managers earlier on to understand that each scrum team had their own Jira board configured differently. So it was some of these early missteps that made me realize that product operations can be more intentional in how we work with and get buy-in from key stakeholders before moving forward with everything we do.
Can you tell us more about how you get buy-in from these teams?
I have six best practices for success, which will help product operations people establish trust and get buy-in from key stakeholders, product managers, engineering managers, and design managers.
Listen
I regularly meet with team members and do a listening discovery session. I learn about their day-to-day work, what tools they use, what processes they follow, and what documents they reference. I get a better understanding of their pain points and needs, but I also gain their trust as they gain familiarity with me and my goals.
As the relationship develops, I also show them what I'm working on. I'll have prototypes of the work I'm going to propose and I'll walk them through it. I'll then ask for honest feedback and they always have something to propose to make the product operations solution better.
Tools
One of my operating principles is to remove redundancies and simplify where possible. This includes using existing tools at our disposition and exploring their functionality to fit our needs.
In the past, I've seen some designers in one scrum team use Figma, and the designers on another scrum team use Lucidchart for prototypes. This drives me crazy as a stakeholder because I have to flip back and forth between these two tools.
When I was selecting tools to use for my work, I asked the team members what they use. I then adopted Jira Advanced Roadmap for myself and my team's work instead of a project management tool like Asana or monday.com.
When it was time to show the product managers a prototype of how to use Jira for roadmaps, I simply showcased my roadmap during a four-hour quarterly product planning session where the product team members, product managers, engineering managers, tech leads, QAs, and designers were all present.
I used the plans view in Jira to show them my two objectives displayed as a legends issue type. I then clicked on the legend and the four initiatives that rolled up or that were associated to that larger objective rolled down. I then clicked on the individual initiative, and the epics associated to that rolled down. They could also easily see in which quarter the work was going to take place.
For leadership members present in the planning session, I wanted to show a different view which was by quarter instead of by goal. With one click, I was able to pivot views, and they bought into it right away. So we successfully adopted JIRA Advanced Roadmaps as our product roadmap tool.
Language
I try to adopt the terminology that the team uses day to day. For example, the work of my team is organized in sprints and we tackle tech debts. This could look like migrating work into a new tool or consolidating all work into a single tool.
We also talk about the why and the customer's pain. We do discovery work by speaking with our customers, the product managers, engineering managers, and customer success people, and then we design our solutions and show prototypes.
We measure adoption in the form of how many team members use our templates, and we then iterate and enhance that.
We've adopted very standard product language which helps us with attention and engagement when presenting our ideas.
Co-create
The key takeaway here is that you should partner with your key stakeholders and co-create the new solutions or programs, even if this means giving them access and letting them create the mock-up. They’ll be much more excited about the solution if they’ve had a direct hand in designing it.
Find allies
There are a few moments in my journey and implementing initiatives, particularly when implementing Jira as the roadmap, where I didn't have the buy-in of some of the product directors. While I attempted to speak with them one on one to understand the concerns and objectives and better explain my ‘why’, I still wasn’t getting the agreement I needed to move forward.
As such, I enlisted the help of two of my closest allies. Both were directors of engineering and had been with the company for several years, and therefore had the trust of the product directors. I’d worked very closely with the two directors and engineering to design the solution and they were big supporters of getting the product managers to adopt Jira.
They helped me reach my goal of getting 100% buy-in from the five directors of product I was working with. I observed how they communicated, how they answered questions, and I learned a lot.
We need allies to help us amplify our ideas and push our product operations mission and outcomes forward.
Resistors
You should identify your naysayers early on and use them. Definitely don't ignore or alienate them because they can be great at helping you identify potential blind spots.
During the redesign of the voice of the customer program, one of my naysayers kept pushing the same topic over and over. I scheduled a one-hour review session with him and he walked me through his journey and pointed out a gap in the process I was proposing. It's something I never would have seen myself, nor would any other person have been able to point it out.
After that, I would go directly to him to sanity check anything related to this initiative, and in the end he was accepting of the process change even though it meant more work for him. He understood the value, but he also felt heard and his experience was respected.
How did you measure the impact of these product ops initiatives?
In a previous organization I worked for, we measured it in two ways. The first was the product manager's sentiment. I worked with product leadership on what ended up being a survey that was sent out every six months.
We grounded the product managers on the activities they were working on and what they wanted to work on. If we could see in the last survey they wanted to spend less time on triaging customer support tickets and more on professional development, we looked for a shift in this and if the managers were happy. And that was something that I created.
The other way we measured impact was sponsored at the company level. We sent out an engagement survey every six months where the teams across the organization provided feedback on what it was like to work with the other teams.
I looked specifically at the collaboration scores for the product managers. Every six months I could look and see for example if we’d addressed the pain of the customer success team or the needs of the product marketing team and our professional services.
I'm in my 10th week at Assent, and right now I'm still working to identify what those success measures are for my team.
