Read the Full Transcript
The following transcript has been altered for readability.
Introduction – AMA with GitHub’s VP of Product Ops, Rick Porter
Becky Flint: Welcome everyone. Let’s give one more minute for our audience to join in. Again, it’s a shared session. If you have questions, please start putting them in. This is an AMA session. Feel free to type your question. We already have some, and by the way, for some of you who joined a little bit late, we are performing a live ‘Ask Me Anything’ session. We have gathered quite a few questions already, so you may see we merge both live questions and collected prep questions into one as we categorize them.
Now two minutes in, I want to officially kick it off. Welcome everyone to the CPO Series, we’re actually in a mini-series around product operating excellence. My name is Becky Flint from Dragonboat. For those of you who are not familiar with Dragonboat, it is an AI-native product operations platform that enables everyone in a product operating model, which includes from CPOs to product managers, product operations, their teams, engineering, and go-to-market teams to together, set strategies, build portfolio roadmaps and deliver products that delight customers and accelerate business outcomes. That’s why we’re here. Our product ops co-pilot has been running in production for over five years now for thousands of teams and billions of product and engineering investments running on the Dragonboat platform.
In addition to being a platform enabling the best decisions, we are also a partner to your success. That’s why we have these sessions to talk through how we can adopt best practices and learn from each other to drive better outcomes.
With that, I’m delighted to introduce our guest today, Rick Porter. Rick, welcome. For those unfamiliar, Rick is a seasoned business and product operations executive. Currently, he is the VP and Head of Product Operations at Github, where he focused on scaling operations and driving excellence. With leadership experience in New Relic, Adobe, and Marketo, Rick also co-founded nGame, Inc., leveraging social data to solve business challenges. He previously managed a portfolio of analytic applications at SAP, overseeing the entire product lifecycle from ideation to global launch and field enablement. Wow. Rick started his career as a “Big 5” consultant at Arthur Andersen LLP, and holds an MBA and a BBA in Corporate Finance from the Mays Business School at Texas A&M University. So excited to have you here.
How Did You Get Into Product and Product Operations?
Becky Flint: As a transition, I would love to hear from you, Rick, about how you got into product and product ops throughout your amazing background. With that, we’re going to kick off the rest of the Q&A. Off to you, please, Rick.
Rick Porter: Awesome. Yeah. I’m so excited to be here. This is a topic that is clearly near and dear to my heart. I’m happy to join and kind of add to the collective body of knowledge here. So as you already hit on, Becky, I started out consulting around the time that data warehousing, data marts and business intelligence was the term that was being thrown around. I was just fascinated with the power of data to drive decision-making and over time, how do you link that to strategy? And those things were just a part of my consulting progression.
I had an opportunity once I joined a smaller company that ultimately was acquired by SAP to make the transition into product management, which lit a different fire but it was still about data and performance management. I was so excited that I was like, I got to go start a company doing this kind of stuff.
After a seven-year journey, as I say, I spent too much of that time writing checks to myself. So I was like, I’ve got to go do something different. An opportunity at Marketo presented itself, and we didn’t even call it product operations back then, but the journey started there, and we were acquired by Adobe. I wish I could say all of that was architected but it wasn’t. The truth is that I really started to like the combination of data for problem-solving purposes and solving complex, cross-functional challenges that organizations faced–It was at the crux of all that I had been doing throughout my career. What better place to take that skill set and start to apply it? Once I got into the world of product operations, the rest is history. It’s such a rich space for problem-solving. So that’s why I’m so excited about doing what I do.
How Did GitHub Identify the Need for Product Operations, and What Challenges Did They Need to Address?
Becky Flint: This is awesome. So now you’re at Github, one of the leaders, not only in developers tools but almost everywhere, also around the AI. There are a lot of questions in today’s world on people’s mind. How does it all coming together in terms of, when you build a product that’s evolving so quickly and, with the market and technology changing every day, and at the same time, there are Github tools being used by a very large community of users. How do you get to a company in sometimes technology or dev product companies don’t necessarily kind of connect to the product ops? Tell us a little bit about the journey of, how the need was identified in terms of needed product ops and how, what are some of the challenges that the organization needed to address? And how do you see how things evolve? There were questions around when the company need the product operations and so forth. I’m going to just categorize into similar. When that need came around and how some of the challenges that you’re balancing.
Rick Porter: Yeah. Specifically in the case of Github, but I think there are general truths on what I’m about to say. When you are a fast growing, but pretty large enterprise, it really underscores the need for making sure that you have some level of consistency and that you actually have an operating model so that you can scale. And that was really a big part of what attracted Github to me. They knew that the PDLC processes, like we need to be better about how we launch products, we need to be consistent in how we do that, we need to have a roadmap that is continuous and we need to be able to communicate what we’re investing in to our customer base. And we need to solve for all of the underlying operating model dynamics that make for a large company.
Another parallel I’ve noticed in my journey is a lot of these companies are crossing the chasm from once having been like explosive growth startups into the world of, hey, we have as many big enterprise customers, so we have to show up in certain ways, right? Balancing that, I think is one of the markers of like, hey, we really have to get the factory, if you will, and good working order and making sure that it allows us to strike this balance where we have the velocity that we need to respond to a very dynamic market that we compete in, but we also have just enough of the lean process to give repeatable and great outcomes for our customer base.
How Do You Define Lean Processes and Strategic Velocity?
Becky Flint: This is so interesting that the pattern I also heard is the complexity of the organization is where you really need a dedicated mind to solve that need. And the other part you saw, the crossing the chasm, I think it’s also something I heard quite a bit as well in terms of organizations that they can make do and to a certain point that sort of the balance between make do at cost to the cost is so high that you cannot make do. So I think this is really cool.
Now, related question is how do you see, it sounds like you talk about the lean process a little bit, like we need to organize in the way to work. You also talked about velocity. That’s not necessarily velocity of like a sprint burndown, right? You already think about how organization. So double click on that a little bit because sometimes people tend to process it’s a word that has different meanings, right? Velocity is another thing that people feel like, oh, it feels like a feature factory. But I’m sure you have really good explanation and clarification on both of these terms.
Rick Porter: Sure. I think of velocity as strategic velocity. How quickly can we, and I’ll use agile but not in a pure agile sense, like how can we turn what is this kind of aircraft carrier at some point, and make sure that we can get to the right destination? One of the stories that I share frequently is back when I was at Adobe. We got a new president and he recognized there was a pretty massive gap in our portfolio that was a part of what was going to define the center of gravity for the digital marketing space, specifically for B2B. And he said, we have to go and solve this immediately. Well, this is really where resource management comes into the mix, because we had a discipline of understanding really where all of our engineers and product managers were working. And we were able to, in very short order, say to him, look, here’s the list of the things that as product leadership, we think could be trade-offs that we could make to go attack this new space. We literally, in two weeks, made the decision to move over 50 engineers onto this highly strategic project that was aimed at six-month delivery of a beta at Adobe Summit. I think in large part that understanding, that discipline of resource management, it seems kind of boring, on some level, but it is so incredibly important because as I used to say, as a consultant, put your money where your strategy is– In a product context, that’s more often than not, just the engineers and PMs. Those are the people, right? And so the more dynamic. So when I say velocity, that’s the velocity that I’m talking about, where you can shift on the fly.
If you fast forward to where we are in the market today and the rapid shifts and all of the investment that is flowing into AI, it creates a dynamic where we have to be pretty nimble as Github, even as one of the leaders in the space. Those disciplines are things that have been there forever, but they’re so incredibly important.
How Do You Enable Strategic Prioritization and Velocity as GitHub’s VP of Product Ops?
Becky Flint: I love it—”put your money where your strategy is”. I think some of our audience also agree with that as well. And that really showcases a little bit of your background, that’s how you carry your experience and knowledge into your new roles. I love the term you used here, which is called strategic velocity. I think a lot of times people think about processes for the sake of the process versus that’s the enabler for the strategic velocity. Strategic velocity is around prioritization, market opportunity and so forth.
I think you briefly touched upon two of the questions some of the audience ask, which is how do you help with strategic prioritization at Github and/or obviously previous roles. Let’s double click on that a little bit, You’ve talked about an Adobe example of how you identified a market opportunity and you were able to see how you reallocate your investment. Now at Github, how is that done? Is it very similar to before and after?
Rick Porter: There are common threads that you will pull through each of the company examples. At GitHub, we have semester planning, which is bi-annual in nature, and that’s where we look at what we’re doing strategically. I’m a big believer in not having strategy that is this thing that lives outside of the operational realities. Strategy gets translated and I don’t care if you use an OKR framework or if you have some other performance management system in place. But it’s important that you translate that strategy into kind of objective chunks. We spend a lot of time as part of our planning cycle, making sure that we outline the walk from these are the outcomes that we want to drive in the business to this is how we’re going to measure how we’re performing relative to those outcomes. And then these are the investments, this is where you put your money, where your strategy is.
If you have the line of sight from where you’re making investments to the expected outcomes that you hope to drive with those investments, that’s where Product Ops is the facilitator and making sure that that top down strategic meets the more bottom up granular initiative level and forces it into a cohesive plan that we can go and execute for that semester. And, I think that as we’ve seen, the market is so dynamic, we have to be ready to reevaluate those plans mid-semester as well.
The more you have a system in place for documenting, capturing, and monitoring over time, the better you can apply the same discipline I mentioned earlier in the Adobe example.
What Happens When Organizations Have OKRs and Roadmaps but Lack a Strategic Approach?
Becky Flint: This is really cool, and I’d like to double-click on that. A lot of times, people tend to use the term ‘OKR’ very superficially—almost as if they’re just checking a box. They’ll say, ‘Here are our OKRs,’ and then I just go. What you’re actually called out, though, is a much more advanced product portfolio management approach. You have your goals, which might take the form of OKRs—that’s great. Then you go beyond that to focus on initiatives and strategy, which many overlook.
I’ve noticed when talking to other Product Ops professionals, some stop at only having OKRs and a roadmap. They move to execution without considering resource allocation as part of the process, and this means there’s no real strategy in place. You’re shaking your head—what are you seeing in organizations that appear to have these elements on the surface but miss the true impact because they aren’t fully implementing the right approach?
Rick Porter: Yeah, that’s why OKR programs can collapse so quickly. Often, they’re more symbolic or driven by what executive leaders are asking for, rather than being part of a true operating system you’re trying to put in place.
I care about the strategic roadmap as a game plan for how we’re executing the strategy. Each line item on that roadmap represents our investments in the future, and they’re there for a specific reason. These items can influence multiple outcomes, but as a PM or PM leader, you really need to understand how each piece connects to the overall strategy and outcomes—whether it’s ARR, MAU, or something else.
Having the discipline to clearly understand those relationships is how you create an effective operating model. When you treat initiatives as the fuel, you can then ask:
- How are we doing from a feedback perspective?
- Are these initiatives consistent with the feedback we’re getting from our customers?
- What does our launch calendar look like?
- Are we driving the right discipline to ensure the work we’ve invested in connects across the business?
Because otherwise, it’s just the hard work of product and engineering without the right enablement or marketing support to back it up.
This is where Product Ops really shines—creating those connections to the broader organization. At the end of the day, it’s all about execution. The more that execution aligns with the strategy, the better off you are in achieving the goals you set for yourself.
How Do You Identify Your Key Stakeholders and Collaborate with Them Effectively?
Becky Flint: Wow, this is really cool. I want to unpack what you’ve shared because you’ve touched on so many things, and you’ve also approached some of the questions from a different angle.
One of the key aspects you call out is working with different people. Often, we see Product Ops teams gravitate toward working internally with product and engineering. There’s a bit of a service mentality—make my product managers more successful, give them the tools they need. That’s good, but it’s not enough. The bigger question is: how do you help them be truly successful when it comes to working with the broader business? I’d love to explore this further—specifically how you identify key stakeholders and collaborate with them effectively, especially at a more strategic level.
The second point you raised goes beyond just product software delivery. You mentioned launch calendars, the business, and the customer. I’d like to dig into that as well—how Product Ops connects these elements And last but not the least, it’s about customers. You’ve already touched on customer feedback, but I’d love to hear more about how you bring it all together—for your organization as a whole and within your Product Ops team.
Rick Porter: Yeah, keep me honest here to make sure I answer every part of this. I always say to my teams—and I say this everywhere I go—that execution fails in the seams. I want to establish with that because the collaboration model has to be at the center. I think of Product Ops as bridge builders and connectors.
If product could operate entirely on its own, without needing support from any other part of the organization, the world would be much simpler, right? And maybe in that case, ops wouldn’t be as relevant. But nothing could be further from the truth. So if we start with this mindset that execution fails in the seams, then we understand the importance of establishing and building strong bridges to CSM and support teams on one side, to revenue and GTM operations on the other, and, of course, to product and engineering teams, which are a big part of why ops exist in the first place.
It’s also up to the C-suite to ensure that cross-functional collaboration and alignment are prioritized. In a fast-growing, scaling environment, if you’re not mindful of these connections, that’s where things fall apart—that’s where the “balls hit the floor.” For me, that’s the starting point, and it actually shapes how my personal playbook works.
When I join an organization, I spend six months just building relationships, reaching out to all of the actors and the organization at the leadership level, and I go a couple of levels down from that just to make sure that we have a good mesh with those organizations. At the end of the day, that’s how you actually go about driving successful launches.
I just had a conversation this morning with my partner on the revenue side, and we were sharing some of the fruits of that collaboration that started when I joined Github. The dividends from that kind of cross-functional partnership are huge. I always say: we’re in the people business. Our job is to connect people across functions and teams. The more we prioritize this part of what we do, the more we’ll see the rewards—it’s the gift that keeps giving.
Becky, let me know if I missed any part of your question!
What Advice Would You Give to Someone Early in Their Product Ops Career to Help Them Stand Out and Drive Impact?
Becky Flint: Yes, 100%. I think one of the key things you’re really talking about is the impact of Product Ops, especially when it comes to execution—I love that. I’m definitely going to quote you on that. The team isn’t just a function; it operates at different levels. You could be an individual contributor, a manager, a director, or at the C-level. At each level, there are different contexts and responsibilities to consider. I want to take this opportunity to focus on the “how.” You have years of experience and regularly work with executives, but what advice would you give to someone who’s relatively new—maybe just a few years into their Product Ops journey—and working in an organization that isn’t yet at a high level of maturity? How can they improve, stand out, and begin driving the kind of impact you’ve achieved?
Rick Porter: Well, if I were to decode it—and I just had a similar conversation yesterday with someone I’m mentoring—I said the same thing: If you’re already managing some cross-functional teams as a program manager, that’s a great opportunity to learn about the different players, their roles, and what they care about. Frame your work through that lens, because that perspective is often missing, and program managers can bring it to the table. It’s a great foundation to build on.
The other piece of advice I shared is about the power of narrative and storytelling. This is an area of opportunity that’s often overlooked. If you’ve ever been a consultant, it forces you to develop this skill—but it’s a tool that is invaluable. Strong storytelling helps you navigate C-suite dynamics, sell ideas, and influence others, which is a big part of what we do in Product Ops.
For those earlier in their Product Ops careers, I would tell them: Take the time to truly understand—not superficially—what customer support cares about, dig into what the revenue team cares about. That understanding will serve you well and help you continue to advance in your career. And here’s the thing—invest in developing whatever it takes to stitch together strong, compelling stories. It’s not always easy, but storytelling is how the human brain processes information. When done right, it’s engaging and impactful. The better you are at bringing this to the table, the faster it can accelerate your growth as a Product Ops professional.
Final Thoughts: Enabling Business Outcomes with Product Operations
Becky Flint: This is super cool! Oh my gosh, we have so many questions, but we don’t have enough time. I’ll use this last moment to wrap up our conversation, and hopefully, we can continue to engage with you through other channels.
As you know, Dragonboat is a platform to run your entire product operating model and enable product operating excellence. This diagram illustrates how the different parts of your product operations connect—from strategy to customer feedback, resource management, PDLC, product portfolio roadmaps, and execution.
The reality is, there are seams between these areas. Sometimes they work well, and sometimes they don’t. Connecting these seams through data is key. Data allows you to see what might otherwise be missed, and it enables you to tell a stronger, more impactful story—whether it’s about execution, strategy, or resource allocation. So I’m super excited about how Dragonboat helps teams take this data-driven approach to make better decisions and share clear, compelling stories with their teams, stakeholders, and beyond.
Looking to the future, Rick, I’ve always believed that with AI and co-pilots emerging, we’ll have even more tools to help us make better decisions. That said, we’ll never lose the human part of it–building relationships and explaining ideas to people who may not yet understand the details as deeply. But when you have a platform that enables this level of data connection, you can communicate effectively with every role—whether it’s the business, finance, or other teams.
So, here’s where you can find Rick if you have any follow-up questions. And if you’d like to see how Dragonboat’s AI co-pilot can help you get the data you need, to make better decisions, and communicate across teams, scan the QR code to schedule a demo.
Rick, any parting words?
Rick Porter: Thank you so much for having me. The questions were fantastic. I think what Product Ops HQ and Dragonboat are doing for this space is critical in pushing the function forward, and I’m thrilled to play a small part in contributing to that. I hope this session was useful for everyone. As Becky mentioned, if you have any follow-up questions, I’d be happy to continue the conversation offline.
Becky Flint: Thank you so much, Rick, and thank you all for joining us today. One last thought I’d like to share: if you’re not yet in a Product Ops role, both Rick and I believe it’s a very enriching journey to be able to help so broadly—not just for one team or function, but across the entire business.
And if you’re a leader in product or technology, think about this: the power of your role can grow 10x or more when you have the right Product Ops function, processes, and tools in place. It accelerates your strategic velocity and helps drive the success of your business.
I’m super excited to see this community growing and to see leaders sharing their successes as well. Thanks again, everyone, for joining us. Until next time, have a great rest of your day. Bye-bye!
