This article was taken from a presentation given at the Product Ops Festival in Sept 2022. Get the full talk on demand here.
Hi everybody, I’m Gabby Peralta. I'm so excited to be here with you all today, talking about how to start and build a product operations team.
I'm going to give a short introduction about myself and why I feel qualified to be talking about starting and building product operations teams. Then I'll spend most of the time talking about how to take your team from zero to one, and then from one to many.
So let's go ahead and get started.
About me
My pronouns are she, her, and hers. I'm currently a Product Operations Manager at Tealium, and I'm calling in from Fort Worth, Texas, where it’s 97 degrees today. It's my first summer here in Texas and it’ll also be my last one because of how hot it gets.
I'm also a product operations pioneer. If you're in product operations at all, you’re very much a trailblazer. We're all figuring it out and defining what product operations will look like at our organizations. So you’re very much a pioneer, and I hope that you take that term with you.
The reason why I feel qualified to be giving today's talk is because I've contributed to the growth of two product operations teams. I've been the first product operations hire at two startups and I'm very familiar with working as a team of one, and I'm now part of a team where I have three other people that I'm able to lean on, which has been incredible.
My hope today is that you learn from my successes, but you also learn from my mistakes and that you're able to get your team to success quicker than I ever could.
I do want to say that I borrowed the titles in this talk from Josh McLaughlin. He has great articles titled, ‘From Zero to One’ and ‘From One to Many. I’ll reference them several times throughout this talk, to the point that you’re going to get so sick of me mentioning them.
But really, those articles were so incredible for me as I joined those two teams as a team of one and was building out the function. He really spent a lot of time and put a lot of great effort into those articles, and there are a lot of great takeaways. So shout out to Josh.
Going from zero to one in three phases
As you take your team from zero to one and you're starting your team, the first phase I want to focus on is discover.
So you have your new team, maybe you're at a new company or maybe you've transitioned roles internally. But I think that the most important phase is discovery. It also might be one of the longer phases, and there'll be three phases that we'll talk about today.
Because product operations requires diligence, patience, and investment from leadership, we really want to spend some time on discovery and put emphasis on patience. It'll take time to build out your team and to decide where you need to focus on.
After we're done with discover, we'll go into our defining stage. During this stage, we're going to talk about where we want to focus. You'll set your product operations vision and then you'll start getting into the nitty gritty of what projects you want to work on. The defining stage will be a little shorter than the discovery phase, and will also be shorter than the delivery phase.
The delivery phase is the last phase and ideally is the phase that you’ll never leave because you'll constantly be delivering great value from your product operations team.
You can't have deliver without define, and you can't have define or deliver without discover, so you really want to be spending time on discover. I'll talk a little bit more about how much time I think you should take. It’s going to be different from company to company and person to person, but let's go ahead and get into it.
Discover
During the discover phase, the most important thing is to learn and understand. You're going to want to set clear expectations. And the reason why I say this is because whether you're new to a company or you've moved over internally, it's really important to say, “This is what I've been brought in to do and this is how much time I think it's going to take.” And I mean that specifically for the discovery phase.
I've made the mistake of rushing discover, and what happens is you end up focusing on the wrong areas. So you really want to say, “Hey, now that I'm here, I'm excited, but it's going to take some time. So here's what to expect from me as I get used to my role.” And then build out what product operations looks like.
With that, I like to have an elevator pitch. You might be meeting with people who have never heard of product operations. That’s not unusual. I’d say that 99% of the people I work with have never heard of it. So have that elevator pitch and say, “This is what I think product operations is, this is the value that I think it brings, and this is why I'm excited to be on this team.”
A 30-second elevator pitch of why product operations is the best and what you’re here to do is really important as you're in the discover, learn, and understand phase.
I also think that it's really important to ask questions. So when you're new at a company or new in the role, meet one-on-one with everybody. That can be everybody in the product department, the engineering department, people in sales, customer success, support, you name it, any team that you might be interacting with. I think it's really important to take the time to sit down and talk with them.
If you can't talk with all the individual contributors, at least talk with the leadership. And if you can't meet with everybody, (it happens, some of us are in really large organizations), I’d also recommend sending out a survey. That'll be Josh's survey which he details in his article.
That survey helped me tremendously when I joined a new company. It helped me to understand from a more quantitative perspective of, “Hey, I surveyed the entire team, and 90% said that I need to focus here and that this is the largest problem.”
So really dig in when you're meeting one-on-one with people and get that qualitative feedback, but also get the quantitative feedback with the survey.
I think having those two hand in hand is a really great way to start your discovery phase, and as you get further into the defining stage, being able to come back and say, “no,” when you're asked to take on other projects because you spent your time in discovery and this is what you found out is the most important.
So I think that asking those questions is the best way to do it, along with relationship building and setting those clear expectations.
And last but not least, listening as you're doing all of these things. The most important part of discovery is listening and being an active listener as people are telling you about their problems and what's working well for them.
In addition to that, as you start to hear common themes among people, start a dialogue between those leaders. If two leaders are having the same problem, for example, customer success and sales are saying, “Hey, we don't know when product is launching features,” get them in a room with you and start that dialogue.
This way, we can really uncover what the problem is and how sales are facing it differently than customer success. The more people you can get in a room and start an open dialogue with, the more problems you're going to be able to discover so that you can come in and fix them.
So there are three easy steps to discover. A lot more can go into this phase, but these are what I think are the top three most important things to focus on: setting clear expectations, asking questions, and listening as you ask those questions.
Define
During this stage, you're going to decide where you want to focus and prioritize. I think this can be the toughest stage because there are lots of areas you might want to focus on. I've been brought into companies and thought, Oh my gosh, there are so many fires to put out. But it can be really hard to say, “no, I can't do everything all at once. I’m not Superwoman, I'm just one person.”
So I really have to hone in and decide, based on my discovery phase, what areas I want to focus on. I've seen this called ‘product operations pillars.’ So you could say, “Here are the pillars I want to focus on and here's the vision that I want to create.”
So start with the working backward approach of, “This is what success looks like for my team. This is the vision of what I think we should focus on and what I think the value that this team brings is.” And then from there, narrow that scope down and determine what's most important project-wise.
In a moment, I'll share some different examples of what the pillars could be for product operations. These will look different at every company. This is my third product operations role, and product operations has been a bit different in each role I've had. And I think that's also the beauty of it because you get to define and decide how product operations will work for your company and your team.
So as you're narrowing the scope, I come back to that word ‘no.’ ‘No’ is going to be a large part of your vocabulary as a product operations person because there are so many things that we can focus on.
So when you do say yes to something, you need to identify what the opportunity cost of saying yes is. Then as you're defining your vision and narrowing that scope, you can come back to it and say, “Actually, no, I can't take on that other project because here's what I found out during discovery, and this is where the team needs my focus.”
Spending time on discovery allows you to say no in the future. It's something that I've had to learn to say and it doesn't really get easier, but having a defined vision and defined project really helps to enable success for the future.
The different pillars of product operations
Here are some examples of what product operations can look like.
Blake Bassett's pillars are ‘quality’, ‘strategy and operations’, and ‘organizational communication.’
During the discover and define stage, you don't want to come in with solutions. You're only looking to identify the problems. We’ll focus on solutions during the delivery phase.
This is just one example. You can always come back to it and decide whether or not this looks right for your team.
You can also see at the bottom of the pillars that his vision is to ‘enable product teams to achieve better outcomes.’ So when you're thinking about your vision, it doesn't have to be a four-page document, it can be one sentence saying, ‘This is my vision for product operations, and here's how I'm defining what it's going to look like.’
The beauty of it too is if in two or three years you don’t think it’s working anymore, you can come back and revise it.
Here's another great example from Becky Flynn. You can see that her pillars are ‘enable teams,’ ‘align vertically,’ and ‘collaborate cross-functionally.’ And then you have all this good stuff in the middle.
You can see there are some common themes across both of these examples. Organizational communication and being able to communicate cross-functionally have been common themes that I've seen at all the companies I've worked at.
There are lots of great resources on how you can define product operations. My word of advice would be to take the time to figure out what's going to work for you.
And then last but not least is Marty Cagan's product operations overview. He thinks product operations should focus on ‘quantitative insights,’ ‘qualitative insights,’ and ‘tools and best practices evangelism.’
Going back to the discover phase, when you're trying to discover what product operations should be, I do think it's really important to have both quantitative feedback and qualitative feedback.
There are lots of ways that you can set up product operations for your company, and these are just some of the ways that people have made it work.
Deliver
After you've discovered and defined what product operations should be, it’s time for the longest and probably the most fun phase, the deliver phase, or the phase in which you execute on what your vision and your mission are, and what you've defined product operations to be.
During deliver, you're likely going to be under a lot of scrutiny, especially if you're new to the company. This is a new function so people likely don't know who you are, so you want to be able to come in and hit the ground running.
If you're someone who's transferred internally, which is something I've done, the pressure’s off a little bit, but it’s still a new function and you have to show value fast.
What I recommend doing is starting small. So during your discovery phase, you’ve likely heard a lot of the same problems come up. What's something that you can fix or what process could you remove that takes minimal impact or effort on your end, but has high impact? So define those quick wins.
Then within that starting small step, create 30-60-90-day goals and sprinkle those wins throughout.
The quicker that you can show value, the better off your team is going to be in the long run.
Additionally, as you start delivering on those larger projects that you have at 90 days and onwards, I'd highly recommend practicing change management. As you're delivering on projects, make sure that you truly understand the change before you roll it out, and then plan for that change.
Provide timelines, be really clear about what change is coming and when the team can expect it to come in, and then as you implement the change, make sure that you reinforce the change. And again, start small. But once you've put that change into place, maybe it's a process that you've improved, close that loop and say, “This is the value that this process has brought to the board.”
For example, I was brought onto a project and found that our bug board SLAs were just not up to where our customers needed them to be. It was really frustrating for the product team, but it was also frustrating for customer success, support, and everybody else in the organization because bugs were coming up but nobody was looking at them. It was taking way too long.
What I found was that it took 10 days to look at a bug that came in, but then we rolled out this new process and it only took five hours to look at one.
So it’s being able to take that information back to the team and say, “Hey, this is the value that this process brought. Thank you all so much for being involved in collaborating and contributing towards this change and participating in it.” I think that's really, really important. So close the loop on all the changes that you make and the projects that you're executing on.
Also in the deliver phase is iterating as you deliver on projects. Ask the teams for feedback as you go. For example, when I was rolling out the bug board process, I went to the team and said, “Hey, this is what I'm thinking of as my process. What do you think? What am I missing that's important to you?”
That's definitely a mistake that I’ve made. I‘ve rolled out this whole process without thinking about the fact that we had people in different time zones. I said, “We need people monitoring this bug board at 5 am CT.” But that means 3 am for people in California.
So ask for feedback as you go, and then iterate and improve for the next time. Ask your teams, “Has this change been impactful? Was it helpful? If not, where can we improve?”
I’ve also added ‘make mistakes’ in this phase, and I'll touch on that a little bit later too. But making mistakes and having a culture where you're able to experiment, fail, and fail forward is really important. This is a new function and you're human, so it's going to take some time.
Going back to those small wins, that's also where it's important to have those really solid wins at the beginning because it's very likely that you're going to make mistakes as you go through this role. And as you bring on new people, and especially if you're a team of one, it's a lot for one person to be taking on as a product operations person and supporting an entire organization.
So don’t be afraid to make mistakes and own those mistakes as you make them.
So that sums up the three stages for taking your team from zero to one. And just to recap, that’s discover, where you're digging, in asking questions, meeting with people one-on-one, and really understanding the organization and the problems that they're facing.
Then it's define, where you're spending time and saying, “Hey, this is all the feedback I got, and this is where I think we should focus and why.”
And then it’s the deliver phase, where you're able to deliver on those projects that you think are the most important, and you're able to iterate, get feedback, and make those mistakes as you go.
As you grow, you're constantly going to come back to these and always be discovering and redefining product operations, what the projects are that you're working on, and then delivering on those projects.
Taking your team from one to many
As you take your team from one to many, I'm going to talk about four things I've personally faced that I think are important. And I think without these things, you can potentially run into some problems.
Number one is to start planning for your team very early. So as you go from one to many, think about that as soon as you're a team of one because it's a lot for one person to take on. It doesn't matter about the size of your company or the size of the product team. Because of our role, there are so many things that operational people can focus on.
It’s really important to plan ahead and say, “Based on our vision, these pillars, and these projects that we've identified, I'm going to need three more people by the end of 2023. Or I'm at least going to need one person who can help me in this capacity.” I think that's really important to talk about as soon as you're brought onto a team.
And then from there, define career paths. This is very, very important. There was a recent study that said ‘the majority of workers (63%) who quit a job in 2021 cited no opportunities for advancement.’
So as you're growing your team, think about what levels they can be on. Maybe they can come in as an associate product operations person and then move up to level two or level three. Maybe your Senior Product Operations Manager could move up to being Head of Product Operations.
Have clear career paths defined as well as what the duties are in each of those paths and how to get from one level to the next.
But as you're thinking about growing your team and defining what they’re going to look like as you start hiring, something that I think is really important is to think about those pillars you have. If you have qualitative, quantitative, and tools and best practices, and you have someone who's really good at the qualitative work, hire someone who's going to fill out your team.
So if you have a person who's great at qualitative, hire someone who has experience with the quantitative side of the house. If your product team is shipping features but they have no idea if they're successful or not, hire someone who has experience in saying, “The feature’s launched, here's how many people have looked at it, and here's the value that it's brought,” and just painting that picture.
I think that's the best way to go so you can have a fully functional and well-built team.
Then if you can't find experts, or even if you can, I think one of the three most important skills for a product operations person to have is being collaborative. They like to work as a team and they like to help other people.
Great communication is another one. Being able to communicate cross-functionally is something I’ve seen across all my roles. You have to be a good communicator to be a good product operations person.
And then last but not least, leadership. Product operations people often have to lead without authority. And these are all skills that are harder to teach. The soft skills are typically harder, but the hard skills are a little bit easier.
So if you can't find someone who’s a data expert, maybe find someone who has the potential to get there and hire based on that, and you'll see a lot of success.
Because product operations is so new, it can be hard to find someone with five-plus years of experience. We haven't really even been around that long, or we have but in other titles or capacities. So be flexible about that too.
To recap, hiring based on those pillars and soft skills is crucial to getting your team from one to many and being successful in doing so.
And then last but most important is creating psychological safety. If you want to grow your team and get to that next level, you want to make sure your team feels safe enough to take the risk to get you there.
Create an environment where it's okay to fail and it's okay to make mistakes. As long as we're learning and failing forward and iterating the next time, creating that sort of environment is going to take your product operations team to levels that you wouldn't be able to reach if you didn't have that safety there.
So to cap it off, those are the four most important things to think about as you take your team from one to many.
