Read the Full Transcript
The following transcript has been altered for readability.
Claire Erickson: Thanks so much. Excited to be here. I’ve always enjoyed joining Dragonboat events and am super excited to actually be able to speak at one. And great also to see some familiar faces on the panel. Robin Chiang was helping me to reminisce sort of back to some of our early days. But in any case, I will share I’ve got experience in my career, a long time in fintech and payments – seems like a little bit of a theme here with the group – and also in commerce. I actually began my career on the commercial side of the business, so marketing strategy, and as I often joke, moved to the dark side of product and tech but have not left because I love it so much. Being at the intersection of innovation, creativity, and my commercial roots also of business and business results. So just a little bit about me.
Step 1: Build a charter
Claire Erickson: I heard Carlos say: “I was doing this before product was cool.” – I think perhaps I was doing product ops before product ops was cool, if that’s a thing. Product ops seems to be more in the parlance, at least in product circles these days. I do think product ops has evolved in the 10 years that I have been in it. I think what has not changed, which we heard a little bit from Rob in a different way, is the need to actually build a charter, explain why you exist and explain what you’re going to do for the organization – I think product and the product teams are your customer.
I’ll basically just be sharing an approach of principles and concepts for product ops that I’ve implemented and am implementing in my current role, acknowledging it may look a little different at different companies.
As we also just heard about from Rob, building product is very complex and challenging. We heard about this from the audience, from the panel, so I don’t want to bottom this out but I think the key thing is: product ops has a customer, which are the product teams, and it is complex and challenging. So this function is really here to help with some of these challenges around communication and alignment, which it’s not on the page, but to me actually is a little bit centered implicitly around strategy – What is our strategy? Are we aligned on that? Are we communicating that?
We’ve talked a ton about data and analysis. I think as you build products and continue to scale, how do you know if what you’re doing is working? How are customers using my product? Are we getting results? All of those things. And kind of inefficient processes and workflows. What tool sets are we using? How are different teams working together differently? Lots of different things like that.
So there is a challenge. Product ops is maybe not the panacea but can really be a force multiplier as far as alleviating some of these pain points. So that’s the product ops value prop. You got to sell the vision and have a tagline. The simple version of this is: we are part of the ingredient to help product teams do really great work that drives results. So I think that’s kind of ultimately what it is all about.
I’m also sort of big on core values and a values person. Your values for this function or your team may look a little bit different, but the areas I like to center on are strategic – I do think this role is sort of all about scale, which we’ll talk about a little bit more in a minute. Again, continuing to enable our product managers to be as customer-centric as possible in how we’re thinking about things, and maybe not data-driven, I think, to Robin’s point about getting too myopic, but at least data-informed is a great value to keep in mind as we actually set up the function in a company.
You all may be thinking: “Hey, that sounds great! We’re going to have this function that empowers all of the teams, makes our lives easier and allows us to build and deliver great products in the market”. But, you know, what does this team actually do? There’s many people in that equation making that happen. What is this team’s kind of unique role in that?
These are a few pillars. You can bucket this in many different ways. Sometimes these functions are done by other teams in a company, again, if they exist or depending on the product operating model. But these are just some kind of common areas I’ve seen in the function and what I would advocate for.
So one around business data and insights, one around customer, more qualitative type of insights. I want to be very clear, I’m not advocating that product managers should not have direct access to customers, this is not outsourcing discovery or the need to ever look at data, it’s really meant as an enablement and scaling function. And then the third around kind of tools, methods, practices. How do we work? How do the teams work? How do they work together? What tool set do they use to do their work? So a few key responsibility areas for the function.
Step 2: Lay the groundwork
Claire Erickson: And then I think the next is: how do we actually set up the team to deliver value against those pillars? So that’s kind of laying the groundwork or hitting the road, however you want to look at it. So much like product teams, product ops also needs to have a team structure and roles. And of course, I will share, maybe you’re a team of one. Maybe it’s a team of many that you’re revamping or a team that you’re building. So you’ll typically have a head of product ops. I personally right now have a broader and shared scope, and we actually pair up with technology in that as well. But it really differs wherever you go and what makes sense. But you’re going to have a head of that. Maybe you have a team of analysts as you grow out in scale to deliver on those data functions. You have managers that are managing programs related to product ops, just as an example, but kind of laying that out. We’ll evolve over time. How are you going to work with others? That connection and collaboration piece with your stakeholders within product technology and the broader business. As we’ve heard about today, there are many of them in any business highly matrixed and building product.
I think about this team as often enabling the organization to have great metrics, KPIs, OKRs, whatever that system looks like. Having a strategy, identifying your key initiatives, doing that work. We don’t want to be the cobbler’s kid with no shoes. We also need to have a roadmap for our function. What initiatives are we driving? Even though our customer is internal, we’re an operational function. And how will we know if we are successful? We also need OKRs of our own to see if we’re succeeding and delivering on our mission. So these are many things to set up with a function and a team and is very helpful.
Step 3: Don’t go it alone
Claire Erickson: And what else is very helpful, as has also been talked about, is: do not go it alone. In that particularly tools and methods bucket, though it may spill out into the others, as well, around business and data insights, is a lot of this is really about people, process, and technology.
We have many wonderful tools today like Dragonboat that are there to really help product teams get their work done. How are we giving time back to our product managers so that they have one place to put their roadmaps, and KPIs? I think it’s hard to do great work when things are all over the place. Teams are doing things in different ways. So there’s really been, in my time with this, a big step change, I think, in terms of the tool sets that are available for these teams to do their work.
And Dragonboat has been really great in the early days at improving roadmap quality and also encouraging PMs to be more customer oriented and also outcome and data oriented in how they are articulating their work and roadmap. I think there’s much more that we will continue to embrace and do. But it’s been huge and being open of kind of getting out of PowerPoint and Excel and kind of things all over the place. So really wonderful for both the product teams as well as being able to look more broadly across the portfolio.
Operationalizing for Impact – Key Takeaways
Claire Erickson: The key takeaways here, as I’ve mentioned, are: if you’re standing up a product ops function, revamping one, scaling it, and I hate to say “think of it as a product”, but you’re almost like a product. You’ve got to build a charter, build that mission, sell it in, and operationalize for impact. And a great, great reminder to not go it alone. Definitely take advantage of great tools like Dragonboat. Thank you very much and excited for any questions.
Audience Q&A
Alisa Vaz: Thank you so much, Claire. I love that analogy of having product operations as its own product. I haven’t heard it quite like that, but I think it’s very clear. Let’s look to the Q&A, and we have a question: When people resist change, how do you motivate them?
Claire Erickson: That is definitely a great question. I think with any change like that, I suppose it to me at least comes back down to: you’ve got to have the customer empathy, whether internal or external. And maybe think: “maybe I’m not right. Maybe there’s a different way to go about this”. I need to really listen to this person, understand the challenges that they are having, in order to get to be open, potentially to a different solution. I think sometimes it’s to assume maybe the change I’m pushing isn’t right. And I need to actually understand the benefit statement better by understanding their pain point, and what we are doing about it. So that’s one.
And then I think also the second is to be very open. Patience is patience, and also patience and persistence in a way. I think there is a stat that I’m maybe going to get wrong that: “sometimes people need to hear something 17 times until they really hear it”. So patience really can be an asset sometimes where you need to have conversations many different times, in many different ways, until that kind of breaks down.
And my last favorite tidbit is that a very wise person on one of my teams shared with me, who is actually a change management expert, so I would seek that person out is that “resistance is engagement”. And I will be open in saying that sometimes if people are resisting a change, that is a sign that they are engaged, and that’s actually a good thing. I’d maybe be more worried if people are silent and not even resisting. So embrace that resistance and be willing to engage with the resistors.
Alisa Vaz: I like that. That sounds like a good daily reminder. A great question from Erica Pickens in the Q&A: How do you see product operations work with engineering operations? Where is the intersection of strategy and execution?
Claire Erickson: I do think they are a little bit different in terms of their focus. I think where they are overlapping is that it is a lot about enabling the teams to do things in a best in practice way, at scale, using modern tool sets. I think there’s a lot of goodness there. But I think a little bit different in terms of the focus, but definitely complementary. I think it depends a little bit, most companies that I’ve observed and worked with, have both. As I mentioned, I have a shared scope but if we’re thinking true like Devops, that’s often a little bit of a different function.
Alisa Vaz: We have a couple more. What are some common pitfalls that you would recommend to avoid when you’re standing up the product operations function or operationalizing product ops?
Claire Erickson: I think the first one or maybe even the main one, would be: if you’re standing it up, do not try to do everything at once. I shared 3 pillars, so maybe you start with one or something like that. I think especially because this function is often not a hugely staffed team, and I think that’s actually by design and is fine. But I think especially if you’re really just starting team of one, it can be very difficult to try to do everything at one time. So I think that may be a pitfall is in that reaching for the broader vision of what it can be, you know, kind of try to do too much at once. And I think within that, being savvy of kind of a solution with no problem. So kind of drrive what you’re trying to do by what you’re seeing and maybe what needs the most attention. And I think similarly, too, if there’s change involved and things like that, some of the common best practices of using pilot teams, trying in one area, kind of rolling it out. Practices like if I were launching an external product, I would never just go GA instantly to everyone, right? I would pilot it. So I think wouldn’t try to go too broad in terms of trying to do all the pillars or all the things at once, depending on your situation, and maybe not try to roll it to the entire organization at once. So just not boiling the ocean.
Alisa Vaz: So continuing with that product analogy, you’re really building the MVP of product operations, if you will. One other question that an attendee has is: what role does product operations play in bringing data to the game to inform decisions and trade offs? Another question potentially in the same realm is: how do you bring in tools to be able to support this function?
Claire Erickson: In the data area, what I would share is, I think a lot of that is seeing: do you have a utility set potentially around common dashboards with kind of your sort of usual suspect type KPIs for product. So that make it up, your PM is not having to go figure out how to access their data, figure out how to analyze the data, right? Sort of doing that off the side of their desk as well. And so I think it needs to be collaborative with those teams to be clear on what do we want to measure. So some of it is consistency and measurement and having the tools and utilities to bring to PMs, as well, and having it accessible and automated as sort of The North Star there. You know, being open, you may be entering an organization where there’s a built out product analytics function that is there and data is very much part of how the team are operating. I mean, that is probably a case where it’s like: “hey, I don’t need to duplicate this”. So I think it’s also just assessing that landscape of where things stand. But oftentimes, in terms of scaling the data, the systems, the instrumentation, sometimes have not even caught up with the growth of the company, and then there’s work to do to bring that in, to make sure that your product teams are not flying blind and your product managers are focused on looking at the data and getting insights from it versus finding the data. And the tools question. I just want to make sure I don’t miss it.
Alisa Vaz: The question is: how do you evaluate the tools and tech to use when you’re standing up a new product ops function?
Claire Erickson: I will actually be open to saying that “tools first” is probably not my approach, it’s sort of “diagnosis first and then tools”. You don’t want to miss the tool step because they can be a huge enabler with all that’s available and important to scale but you’ve got to be clear on what are we actually missing the ability to do? Where are we needing to do manual work and things are very complex? What do those things look like? So, again, very much a problem. What’s the right tool to solve it? Kind of a mindset and not getting too far into deciding you need a tool that’s actually going to, frankly, define your process, which may not be the right process. But yes, I think Dragonboat is fairly flexible, which is great as far as a partner to help us work through how are we using it? How can we use this differently for our organization? All of those things. But yes, looking for what we’re trying to solve and then bring in the tool options.
Alisa Vaz: I’ll just ask one more question. Some teams treat product ops as coordinators or program managers. You covered a bit about strategy. How do you grow from that program management mindset and really approach the strategic aspect of product operations?
Claire Erickson: I totally understand the comment that that’s maybe a model for product ops or a perception. I personally see actually program management or technical program management as its own discipline and own function, that has value. And I actually do have a program management team that is separate from the operations team for whatever it’s worth. So, definitely complementary, but I think a bit different there. I would see program managers there working with the product teams to get things delivered and make sure things are on track and getting results. And I personally see product ops, at least in the tools and methods space, looking at broader things like, what is our strategy? What is our product operating model? How do we need to then work across teams to actually deliver on that operating model of which program management and the product teams are another stakeholder? So, that’s how I see that.
And we talked a little bit about strategy, as well. And the great quote from “Good Strategy, Bad Strategy” that was raised, strategy really is about hard choices, and I’ll be open, I do think it’s pretty much the role of the chief product officer and product leaders to have a strategy and vision but strategy work is hard, so, I think this team definitely plays or can play, depending on the situation, a role, working with those stakeholders to make sure that it is articulated and communicated, soo, again, that amplifier role.
