Chris Butler | Product Ops at GitHub
Building trust, driving change, and navigating the challenges of Product Ops leadership
Hi, I’m Josh. Welcome to a special edition of my Product Ops interview series where I interview Product Ops professionals to uncover insights from their day-to-day work so you can apply them to your daily routines.
My guest today is Chris Butler, Staff Product Operations Manager at GitHub.
Current company and team:
Current company: GitHub supporting Copilot and RAI initiatives, The Uncertainty Project, Product Lead Alliance teacher for the Product Ops Masters, and more.
Size of your current Product Ops team: ~30
Size of the Product development team your Product Ops function supports: Personally I support ~25 product managers under two product leaders focused on AI-powered features at GitHub.
Experience:
Years worked in Product Ops: My first official product operations role was at Cognizant in 2021 but I’ve probably done this type of work since 2017 at Philosophie. Since then I’ve gone back and forth between product management and product operations roles.
Role prior to Product Ops: A lot of product management (total years redacted, haha) since I graduated from college. I’ve also done roles that were hybrid business development and product management roles which got me a lot of experience working across orgs. I’ve also done consulting in small and large groups.
Getting used to working across organizational contexts has been a real benefit to my current product operations practice.
Career choice & first big project
Q: Let's start from the beginning. What led you to choose a career in Product Ops? Was there a specific moment or experience that sparked your interest?
After working as a PM for a long time, I realized that the ability to execute was innately tied to the way we did our work. This was because of the interaction between the complex relationships we have in teams and the fact that Conway’s Law says we ship our org chart.
At Philosophie, I learned a lot about qualitative user research and facilitation in the innovation consulting practice. This took me down the rabbit hole of learning lots of frameworks, processes, workshops, etc. I even started creating canvases like the Strategy Kernel Canvas and workshops like Empathy Mapping for the Machine. Through the design consultancy I’d see many different ways that teams organized themselves. It was a speedrun through understanding organizational dynamics and psychology.
Then I started to see how teams that were highly certain about what they thought was “right” usually got caught up into various biases of their leaders. When I start working with someone I like to observe what they tend to spend their time on and how they build a culture of incentivisation in a team. A lot of the time asking every PM 1:1 what is success and failure in the org will give you interesting results.
There was a really interesting study referenced in The Problem with Change (my new favorite book) that talks about how the more unified people’s descriptions of leaders lead to a better understanding of them. However, this can be less ideal if they are biased in a way that doesn’t help the org deliver value to their customers.
Since we live in a highly uncertain world it is hard to find true certainty. The world is becoming more complex and uncertain over time because of the way technology has continued to connect us in ways that we have never seen before.
Embracing that uncertainty has become a key component of my practice and the mission I work on. I believe that most bad things in the world happen because people are too certain–about situations, people, and what is right.
It has been a long road of learning over the last years to get to this point. I feel that the product operations role has the opportunity to really change the way these teams build in this uncertain world.
The way I’ve tried to do this is in a couple ways. First, it is really important to ask questions that open up possibilities and consider the assumptions we are working with. Second, I try to find the “shape” of what is going on by asking what might be a “bad” way to deal with something. And third, I create opportunities (when I’m able to) for more equal sharing of what is going on rather than doing what seems like the “right” way to do something. It can be really hard to get people to open up but it requires a lot of hard and slow work to do it with real change.
Q: What was your first big Product Ops project? How did it come about, what actions did you take, and what was the outcome? What learnings did you take away from that project?
My first official, big product ops project was to help retool the way that senior leadership at Cognizant would work with the PMs on various projects. I’d been hired by someone I’d known for a long time to really help build out the team and apply new practices as Assistant Vice President of Product Operations. It was a really new role and I think the first product ops person at Cognizant at the time.
The centerpoint of that was a “council” meeting where leaders would hear about the project from the PM. When I got there, this was a huge set of slides that took the PM hours to complete sometimes. It wasn’t a very helpful meeting because the majority of it was spent on status updates rather than coaching and discussion. With that I looked at the three key things the meeting was meant to address: 1) status, 2) upsell opportunities, and 3) giving help to PMs.
We broke this into three different processes rather than trying to jam them into a 30-minute monthly meeting. The way I did this was to consider what was required from each of the goals. In the case of status, it is something that requires a regular cadence but not live discussion. The upsell opportunities needed to be handled immediately so they required a just-in-time escalation. Whereas the last component of coaching required the actual time to discuss and learn more about context. All three of these were very different and could be broken into: 1) an async weekly status form, 2) a request to immediately email the account manager, and 3) focus the 30 minutes on coaching.
Everyone, including the leaders felt they were getting much more out of that new process. It really showed me that sometimes we just keep doing a process even when we shouldn’t. No one had asked the reason why we needed to keep doing it to make a change.
After that I helped create the first PM consultant career ladder, performance review process, and everything that goes with it for the PM practice at Cognizant. Which was a huge project. Then I ended up managing a huge number of PMs when a leader left and there were a bunch of reorgs. I joined Google in a strategy, product ops, and special projects role after. This is a story for another time!
Defining your role
Q: We've seen Product Ops take on various forms in different organizations. How do you define the role of Product Ops within your team, and what specific responsibilities fall under this function?
The wider product operations team at GitHub exists to help product management be more effective through various programs. My particular role, as a portfolio operations manager, is a bit different because we are embedded with particular leaders and their orgs. Our goal is to help those leaders be clear, confident, and calm. We also see every PM in their team as a customer of ours but we have had a lot of conversations internally about how enabling those leaders helps the entire team. Centralized vs. embedded is something that is asked about product ops all the time. Both are valuable but they serve different problems.
Centralization is ideal for cases where you need apples-to-apples comparison. Release tracking and GTM is great for this because of all the downstream teams, like customer support, that want to get a more standardized understanding of every feature coming through.
Embedded product ops solves problems within an org that might not transfer across the other orgs in the wider group. The difference between a very customer-centric team vs. a platform team would be one of those differentiations. Or a team that is in a very volatile environment/marketplace vs. one that is stable and can plan further ahead. There is also sometimes a need to help build enablement of the centralized programs that an embedded product ops person could help. Each of those teams has a culture that will adapt to those centralized programs differently.
My main ownership is connecting the overall organization's strategy and priorities with the leaders and their teams. This will include roadmaps, product reviews, and various activities to increase alignment for those teams.
Since we are embedded with particular leaders we look to other portfolio operations managers to find common programs that we can adapt between org. We also figure out how to adapt centralized programs for those orgs. Most recently that was a new product review process.
Q: Can you walk me through your org chart at a high-level, describing how your team is currently structured and how the Product Ops function fits into your broader organization?
All of the product operations org fall under our head of product, which is a SVP. I report to a manager that owns portfolio and design operations who reports into a VP of product operations. There are a lot of centralized teams that handle things like feedback management, release tracking, etc. under this VP of product operations.
As a portfolio ops person embedded with the AI team I work very closely with our centralized ops teams. I’d argue that we should have both in any sizable organization. If you have one but not the other you end up getting really good at forcing process but not adapting it (central but no embedded ops). Or you solve a lot of the team's problems but don’t standardize across the larger org (embedded but no centralization).
I think that the size of the team is an interesting question for product ops. I don’t think they should be too large and they should manage their own work-in-progress (WIP) to be steady. If there are too many people pushing changes from different aspects this puts the team into a “blender” as Goodall would say. With the pure centralized model you can sometimes start to overwhelm the team with too much change because you aren’t coordinating what they can adapt to in a healthy way over time. It is a constant struggle to get that right since our work should be in service to them delivering great products. If we are just shipping change and process for ourselves (or even worse for leaders only) then we are working against them in some ways.
Q: In the discipline of Product Operations, how do you define success, and what key performance indicators (KPIs) do you believe are crucial to measure and optimize? How do these metrics align with broader organizational goals?
As I said earlier, we are here to enable these product leaders to be clear, confident, and calm in their work. This is particularly hard in a highly volatile industry and technology space we exist within (AI for development).
We haven’t explicitly put metrics on this and I think it will always be hard to. We don’t want to just go faster, we want to go to the right place. We want people to be resilient in this volatility, not constantly reacting.
In fact, I’ve joked with people inside and outside the organization that I’m really looking to build a dashboard that tracks the “vibes” of the leaders and PMs that we help. When I was at Google I always looked at the internal meme-sharing site called memegen as something like the vibes dashboard. We have something similar in a Slack channel at GitHub. The real feelings of people come out in a place they can feel safe making fun of the people in power.
Q: Do you have any core principles that you tend to abide by within Product Ops?
My personal values are connection, learning, and discovery. I find that I leverage these in the way I do my practice to be a helpful product operations person.
We have organization values as well. Part of my role is to help the leaders not only live by those values but to help their teams live by those values too. Sometimes there is a gap between where we think we are with those values in reality vs. the aspiration. I see product operations as being key in helping bring those into alignment over time and constantly adjusting as the org circumstance changes over time.
Q: There’s a popular way of describing the role of Product Ops as “PM-ing the Product team.” Do you buy into that description of Product Ops, why or why not?
Yes, I agree! I think I was the first person to say product ops is “PM’ing the PM experience” back in 2020, haha!
In this role, we also think about the impact of leaders on the team as a high leverage way to help those PMs do their daily work. But I feel like we have to balance that against the lived experience of each PM and the overall community of practice the PMs are part of.
Tools and technology:
Q: What’s your product team’s product development stack? (Which tools does your team use for roadmapping, product analytics, collaboration, deployment, etc.)
We use GitHub to build GitHub. That means we leverage GitHub repos, issues, discussions, and projects at the team level. We also leverage Slack for async comm, Zoom for sync meetings, and Google Drive for collaborative documents. When I work with people in Microsoft proper for my lead responsible AI champ role we use Office and Teams.
Q: What are some of the must-have tools or technologies you use in your day-to-day role as Product Operations (separate from the broader team’s tech stack), and how have they streamlined your workflow or decision-making processes?
Beyond the regular stack, I’ve been starting to experiment with using various generative tools. This includes ChatGPT, directly accessing LLM models, Copilot, and Workspace to help with various operations tasks.
We have been starting to think about the library of patterns we want to use on a regular basis to share between the various groups in product operations. I’ve been really excited by things like great meeting summarization, creating automations, and using it as a provocator in conversations. I wrote about the last one in my post Creativity requires just enough confusion. There is a lot to explore here. Using these tools are really great when you want a sparring partner.
Morning routine
Q: How do you begin your workday? Are there any specific habits or routines you’ve adopted for your role? Are there any tools or dashboards you look at before jumping into your day? Meetings you start your day with?
We are a fully remote org and my team is very distributed so I work from home most of the time. Every now and then I’ll go into the office in San Francisco to get out of the house.
There are a few things I review first: email (which include GitHub notifications), new Slack messages, saved for later Slack messages, and new Teams messages. I also do a lot of networking through LinkedIn as well so I check that.
I have most meetings in the morning since our team is distributed in the West Coast, East Coast, and Europe. Then I tend to meet with people in Australia in the afternoon. I try to do as much as possible async but know that getting into a meeting is best to hash out issues (I did a talk at Agile Alliance this year about how meetings are good with a meeting planner template available here). Most status updates and discussions go to async methods like GitHub discussion posts.
I spend a lot of time reading and writing. Part of my practice includes pulling ideas and concepts from other domains which requires a lot of reading, watching, and meeting with people outside of GitHub. This comes in the form of academic papers, newsletters of influencers, links from Slack/Discord communities I’m part of, category Medium posts, an old-school RSS feed list in Feedly, and random Twitter garbage.
If I’m reading a book I tend to not read those specifically about product management though. They are more likely to be from fields that might provide some insight (e.g. architecture and the adaptation of space for people to point to usability).
Frameworks and practices:
Q: In your role, you are likely to encounter numerous decisions daily. Do you have a specific decision-making framework or process to ensure optimal outcomes?
Decision making is something I think about a lot. Most of the time, I use a combination of intuition, research, and an experimental process to help guide me on what is best for the current context. Data can be helpful, when available, but it isn’t always for brand new things. Especially in the context of org design or change.
There are lots of ways to make decisions though. I’ve seen a lot of orgs that get stuck in consensus-driven decision making and I try to avoid it when possible. I’d prefer that there was one person making a decision, in their domain of practice, because they will get impacted, after having a good discussion.
The key part is allowing for the discourse to happen and then having the right person (or people) make the decision. I’ve given talks and written about this if you want to hear more.
Q: When a project wraps, how do you determine what to work/focus on next? What does this process look like for you?
I would say that like product development we are usually not at a point where something stops fully and you start something brand new from scratch. There are many different pots that I have something stewing in my mind, docs, and early initiatives.
That being said, I’m always looking to take on something that would have the biggest impact on the leader’s and team’s ability to build the best thing possible. Sometimes it is a smaller program to get some new process set up. Other times, it is removing or changing a process we have had for a while.
Q: With the multitude of tasks and responsibilities in Product Ops, how do you prioritize your time to ensure you're focusing on high-impact activities?
There is a set of initiatives that I set with my manager and product leads every couple of months that I use to guide me. However, this will always change over time so we have to prepare to let someone know when I think that the priorities have changed or I can’t work on something.
Q: Do you use a Project Requirements Document (PRD) or equivalent artifact within the Product Ops function?
Kinda, but they are probably more like “policy requirement documents.” These are almost like working agreements for a new way of doing things.
There is a format that I use when introducing new product operations initiatives that tends to focus on the goals (and non-goals), people involved, processes/meetings, the tools that enable it, and how we will enable the change in the teams (including comms). It is very much a consultant playbook for people, process, and tech. Tech comes last because it should always support the people and processes. Sometimes it is as simple as an automated Slack message.
I’ve also been adding experimental sunset clauses to these initiatives. It will usually cover a timeframe that we will try out a process (e.g. “eight weeks of weekly status updates”). After that timeframe we will gather feedback and thoughts on the process. Usually the most important times to get feedback are after the first version of something and after some time to settle in. It also shows that everything we do is an experiment and not set in stone. It helps lower the anxiety about changes to the way people work.
The role of data in Product Ops
Q: What role does your Product Ops function play in facilitating the use of data across the product development teams? Which data is your function responsible for, and how does that fit into the larger role of data usage across the teams you support?
We are looking to become experts in the data that each team uses for their decision making at a leader level. There are key metrics that help us focus usually around revenue, engagement, and satisfaction. We work with the data teams a lot to make sure that we are getting the right data into the discussions and decisions that we help the team make.
However, there is still a lot to learn in this domain. It is very early for the way that AI will change the way developers (and the wider development teams) do their work.
Effective team collaboration & communication
Q: Given the collaborative nature of Product Operations, how do you foster strong cross-functional relationships within your team? Are there specific strategies or rituals you've implemented to ensure smooth collaboration between product, engineering, design, and other departments?
The key is sometimes to over communicate, especially with the leaders and PMs, as we adopt new processes. I’ve been thinking a lot about how much change the team can take over time. Almost like a work-in-progress (WIP) limit for change. It is often much lower than you’d think.
There is a great summary by Charter about The Problem with Change by Ashley Goodall. I’m starting to read that while I read The Friction Project. These two books have made me think a lot about how much we push the teams to take on new things over time. There may be some limits to the number of channels, meetings, and decision processes that people can feel comfortable with. Doing an audit of everything a leader or PM has to deal with is the first step to making this visible.
Q: How does your Product org share what they’re working on across teams within product development? What about across the company at large?
As I said before, we use GitHub to build GitHub. I use a combination of discussion posts for weekly status and issues for tracking the work that I do. This allows me to put those issues into various boards, including the ones where the overall operations team for Copilot include TPMs, business ops people, etc. It is our goal to get anything that we want to tell someone else into a URL.
Influencing without authority
Q: Product Operations often involves working with diverse teams where direct authority might be limited. How do you go about influencing decisions and driving initiatives without having direct authority over every stakeholder?
It isn’t much different than being a PM. We are trying to help people, so if we can align on the values that they have, create something that is useful, and execute it in a way that is clear, people will come along.
I’ve started to look at non-compliance with a new process as a signal that it isn’t quite right yet. It may be missing something in the context of the team, the way they work or struggling with balancing all of the different demands of their role. We need to see non-compliance as something to work on actively rather than seeing it as something we need to push harder and convince more people.
Understanding the personal context of PMs is an important part of this job because we don’t always know what type of past experience people are bringing to their roles. If we don’t take care in understanding the people and their relationships with others, we will miss out from being able to make things that are truly transformational in the way they do their work.
Also, I’ve seen large scale changes to processes as going to fail more often than not. Taking small changes, trying them out, and adjusting is more likely to succeed. If we try to roll out a huge program and it needs adjustment it can look like failure inside the org when it should have been considered a first step.
Q: Can you share a communication strategy or technique that has proven effective in conveying complex information to different stakeholders?
I’ve been trying to over-communicate but I still don’t think I do it enough. I tend to believe that people will read everything that is posted to a key channel but they just don’t. I came from a culture at Microsoft early in my career where being on top of your email was incredibly important. With more async channels available, like Slack, I think it means people can lose track or just ignore messages. It takes a lot more to get people to notice and internalize our message.
Sometimes getting a working meeting to try out the thing you want people to adopt is the simplest way to get it done. I’ve been using this more often to help sell the benefits of a program and get feedback from people. Feedback is something I’m always looking for.
The book Thanks for the Feedback was a game changer for me. I’m always open to hearing the feedback on a program or myself but it doesn’t mean we have to agree with it. The book spends most of the time on how you can parse feedback. Sometimes feedback is about personal preference more than the benefits of a program. Keeping this in mind means we can always be open to someone expressing their feedback in a non-judgemental way but then deciding what to do with it later.
Adapting to change
Q: The business landscape, especially in tech, is constantly evolving. How do you stay current with industry trends, and what strategies do you employ to adapt your product operations processes accordingly?
I do this by reading a lot and talking to people as much as I can. We can learn so much information that is freely available on the internet or in communities. Since there is so much, I’ve gotten really fast at scanning posts and articles for the key information and discarding the parts that feel like fluff (or just straight up wrong IMHO).
Also, I’ve tried to reserve time in my schedule to meet a lot of people inside and outside of the org. Inside GitHub we have a service that will randomly introduce me specifically to other PMs and those that are in the wider org. I also do this through services like Lunchclub to hear outside perspectives.
When it comes to carving out time for reading and writing I will usually put blocks of time on my calendar to avoid meetings. I’ve been worse about that recently but I’ve found it really helps with the focused work I need to do.
The biggest issue that I’ve seen large orgs have is that they start to become insular in their thinking over time. Sometimes I’ve joined an org and it feels like the product way was calcified when a product leader thought there needed to be a big change a few years ago. After that it doesn’t really change. You should “get out of the building,” as Steve Blank would say, when it comes to customers AND practice.
Process optimization
Q: In terms of process optimization, what methodologies or frameworks do you find most effective in streamlining Product Operations and enhancing efficiency? How do you balance the need for agility with the importance of maintaining a structured workflow?
I’d say I’m not really looking for efficiency. I’m looking for efficacy. It is an important distinction for product operations people. Processes don’t do work, people do. If we lose sight of the fact that people need to adopt and utilize standardization we will create things that are there for management rather than the people doing the work.
I’ve thought a lot about the Cynefin framework as a set of lenses we can use. I could think that status reporting is in the “clear” domain which means we standardize the process. But we could also consider it in the complex domain where we need to look for emergent ways for people to share what they are working on. Neither is absolutely right or wrong. It is just a way we look at things.
Every org I’ve joined there is a time that we need to create a new way of doing status (or adjust the one we currently have). Since I know this happens everywhere and it eventually morphs over time (or gets abandoned), it means I take a different stance in setting them up. I try to focus on what we are really trying to get out of the goals we have for the process. And I’ve started to think more about how something like a process is a two way street.
This means that I have asks for the PMs and the leaders of the PMs. PMs should be giving nuance or escalations up to the leaders (who usually need to report it to other leaders). But the leaders should also give kudos and engagement with this content to provide signals of success to their teams (which is “the culture” as far as I’m concerned). We also want to get context from the people that they provide our nuance to, so getting that passed back down is ideal.
The key questions usually look like the nuance of status outside of task tracking, successes we are celebrating, and issues we need help with. All of this ideally includes either quant or qual data to back it up. However, it should be pretty short pointing to other places that the information can be found (which we follow inside of GitHub based on Why everything should have a URL).
I believe these types of processes are a two way street between leaders and PMs. There is a need for leaders to feel comfortable they know what is going on and build trust with their people. The reverse is true too: we need leaders to show people what they are thinking and why so they can build trust with them.
Building a high-performance Product Ops function
Q: What’s the #1 thing you’re struggling with related to product ops right now?
It is probably some of the project management aspects of the role. I started in program management at Microsoft which was some type of unholy combination of project and product management. But I don’t think I’ve really been a schedule details type of person so I have to set a lot of reminders for myself to do this. I really like to dive into the details of how we do the work but the follow up is something I’m constantly working on getting better at.
Besides my own idiosyncrasies, I think sometimes product operations people really have to prove themselves to their leaders and teams more than a new PM joining the team would need to. When I start to work with a new team there is a struggle to get to the point that they start to ask for help. It can feel like I’m inserting myself into their team's practices in a pushy way sometimes.
This usually means I provide context about “why” we need to do something and give the ability for people to give feedback and simply disagree with the implementation. There will be some things that are perceived as “must have” by the leaders and I then work to make those things as beneficial as possible and communicate those benefits when working with the team. But it can be very hard sometimes.
In reality though they don’t always know what they need and we are more likely to see that with our viewpoint. Especially, if people haven’t worked with product ops people before.
I build this trust by taking processes and making them easier for the team. Another way I do smaller trust-building is just being there to help, like being the first reviewer on a doc someone isn’t ready to show to their team. Being open in team meetings to healthy disagreement and not throwing people under the bus is another aspect to build that trust.
Q: Have there been any hurdles in incorporating this role within the larger product development ecosystem, and how did you overcome them? What strategies have you found effective in gaining buy-in from the broader team?
As product ops people, we see a lot of places that people might rush through planning a meeting cadence, process, document template, etc. It is our job to keep pushing for something slightly better than just sleepwalking through what “seems like the best thing to do.” I tend to hang back as I learn about the team and the problems they have but this can also make me seem aloof in some ways. I’m always looking for high leverage places I can help that won’t do more harm to the team than the way they are now. My stance of trying smaller experiments has been helpful in showing the value earlier on.
Q: How do you think about expanding the Product Operations function in your organization? How do you think about assembling and developing a high-performance team? Are there specific personal attributes or qualities that you believe make someone particularly effective in Product Operations?
I do think that we need a variety of people focused on product ops work. At its core, people that are really passionate about helping people be as effective as possible are very important.
There is a need to push back sometimes though. Sometimes product ops can be a dumping ground for work that the PMs can’t do due to time constraints or don’t want to do because they dislike it. We shouldn’t be doing the actual PM work and focusing on the end customer. We should be passionate about the customer we have: the PM.
Beyond that I think knowing a lot about a product (and other practices) can be a real help in the role because you can draw from that experience. If you don’t have that experience already you can learn it by listening to the people doing the role. They often know that something isn’t working the way it should and you can take that to work through the removal of friction.
Q: How do you (or your team) iterate on Product Operations strategies? Are there regular feedback loops, retrospectives, or mechanisms in place to ensure that the role evolves alongside the changing needs of the company?
Yes, we are a big believer as a team in looking backwards to see what we could have done better. This is prevalent in everything including internal product ops team retros and collecting feedback from the teams we serve.
I don’t agree with people that retros lead to a “complaint culture.” If we don’t take the time to discuss how things worked out (separating it from the people) then we aren’t going to grow.
Maybe the hardest part is helping leaders to look at themselves in a mirror. They may get feedback from their managers but as you get more senior it is less and less likely you will get feedback from the people that work for you. I think it is part of our job as product operations to be the ears for the leader and to side-channel feedback to them. It isn’t about specific issues necessarily but about patterns that they can then recognize and change their behavior in the moment.
It can be hard for a leader to accept but I’ve found that if I talk to them in private about the patterns I’m seeing and how it makes them and their team less effective they are rarely resistant. This is especially the case if I’ve done the work to interview a lot of people and come back with a synthesis. Even if they do disagree with the feedback I’ve opened their eyes (even just a tiny bit) to the possibility that they should change.
A lot of leaders don’t always know what they are getting into when they bring in product ops into their teams or organization. They tend to think of them to “help set up the team” or “get the teams in line” or “be more dependable.” This is usually because the teams are doing work the way they think is best but not the way that the leader thinks is best. However, it is more often that the environment itself has led to the way it is. As Deming would say: “Every system is perfectly designed to get the result that it does.”
The hardest part of a product ops person’s job is getting leaders to change.
Q: Are there specific professional development initiatives or training programs that you've found beneficial?
I’ve found a lot of great people that are teaching and coaching in the product ops world but I haven’t found them as helpful for my practice. The way I learn is by trying out some new thing and seeing if it might help the team (or me). This means that my learning program tends to be through being junior in a lot of different domains and fields outside of product operations.
I do find a lot of meaning in teaching and mentoring. I always learn something from people that I work with, whether it is the problems they struggle with, approaches they have tried, or just how to help make my aid more effective.
How do you leverage data to inform decision-making within Product Operations, and what role does data play in optimizing team performance?
I see myself as an advisor for the way that decisions are made but the decisions are still made by product leaders and PMs. This means I’ll try to ask provocative and harder questions to leaders to get them to think through what they are doing. The leaders I work with really care about making great decisions but it has to be through the systems that are in place so this means that we can’t always be as definitive as we want. I’m there to push them a little bit more on being decisive which makes their team’s jobs a bit easier. This is especially true when there are hard decisions to make.
Work-life integration
Q: Balancing a demanding role with personal life can be challenging. How do you approach work-life integration, and do you have any strategies for maintaining a healthy balance?
I try to let it ebb and flow. Everything has cycles so we need to ride those. At work there will be cycles where it takes up a lot of time. Having flexibility in what I consider to be the right amount is key to adjusting to this.
That being said, my family is my top priority. I have four children that are ranging from nine to two. And my wife works at a startup that requires a lot of travel. We thankfully have my mother-in-law to help out but it can be challenging. I’m always trying to make sure that my family knows they are a top priority to me even with all of the crazy amount of work and side-projects I do.
I’ve also started to think about my career as an individual rather than being connected to any particular role or organization. This has partially stemmed from times that I felt an organization wasn’t fair to me or let me go at a time that was a surprise. I’ve learned over time that if I can build a career focused on myself it makes me more effective overall (including for my org).
Product Ops at large
Q: What resources/communities outside of your company do you use to stay connected with trends in the Product Ops space?
I’ve been a contributor to the Product-Led Alliance’s blog, courses, Slack channel, and conferences so I always recommend that. There are also a few Slack communities like Mind The Product, Product School, and Product Ops HQ that I participate in regularly.
Q: What’s the biggest challenge in Product Ops today?
Getting leaders to change. Generally, the PMs are in an org that has ways of celebrating or incentivising behavior and it is the leader’s job to create that environment. If the leader isn’t able to change themselves that means the culture of the work will have a very hard time changing through the group.
Q: What's the biggest need in the Prod Ops space today?
I think I'd want to be closer to the HR role. This may sound weird because usually their role is to protect the company from the employees but they do a lot with the leaders to set how success is perceived in the organization. I’m looking forward to better relationships with those types of roles. I think this eventually leads to cross-functional teams that have the job to make the work better. Often these types of teams today are just tool builders but they should be involved in the experience of work for the teams overall.
Q: For individuals aspiring to enter the field of Product Ops, what advice would you offer to help them build a strong foundation and succeed in their roles?
I’d say that doing the practice is most important and you can do this from other roles. If you are a PM, think about how the work is done within your team and how to improve it. If you are in customer success, think about how you might make PMs more effective in using the feedback you collect. If you are in project management (or TPM), think about the risk-reduction you do to organize as a way to include a balance of effectiveness. There is always the possibility of thinking about how work is done from any role that is adjacent to PM.
Q: Are there resources, books, or learning materials that you found particularly valuable in your own journey in Product Operations?
Look to other domains to learn. While there is a lot we can learn from each other through blogs, meetups, and conferences, we need to get out of this specific practice. We should be learning from organizational designers and case workers, for example.
There are a bunch of books that have formed the way I do my work and I’ve put it into an Amazon book list for people to check out. In particular, Why Greatness Cannot be Planned is a great book to understand the uncertainty of the work we do and Creative, Inc. and The Uncertainty Mindset are great for thinking about other ways of working.
Most importantly we should be learning from our teams. Don’t get too far away from the customer: the PM.
Wrap up
Q: How can people get in touch or follow along with you?
I’m always happy to connect with people on LinkedIn. I’d love to hear if you try anything I’ve talked about and how it worked out for you in your context. I’m constantly learning from other people’s experiences.
Thank you!
Thanks for reading this special edition of my Product Ops interview series! I hope you enjoyed getting to know more about Chris and the Product Ops function at GitHub. If you did, please consider following Chris on LinkedIn.
Until next time! 👋
-Josh
If you found this Q&A valuable, please share it with a friend and consider subscribing (if you haven’t already).