Transcription
Hi everybody! I'm super excited to be here today and talk to you about something that I'm very passionate about, which is product operations.
So today, we're gonna go deep into what product operations is and why it's important.
A little bit about me: my name is Melissa Perry, and I'm the CEO of Products Labs. We have a partnership with Insight Venture Partners, where we are accelerating their product teams in all of their portfolio companies so that they can grow and excel at what they do. I am the author of a book called "Escaping the Build Trap: How Effective Product Management Creates Real Value." What I'm really passionate about is creating great product organizations and great product managers so that they can thrive together and produce value for companies.
So today, we're going to talk about product operations. First, we're gonna go over what product operations is, and we're specifically diving in today about data and insights. Then, we're gonna talk a little bit about case studies, and we have here the Chief Product Officer of Binder, Kevin Broome, who's going to share his story with us about how he uses product operations.
Then, we're gonna get into the meat of how we get started with this, and we'll also talk about leveling up and where we go from there. So let's dive in!
What is product operations?
Product operations is the secret sauce to really making a product company run at scale. It pulls everything together and connects all the software development activities to the business outcomes.
If you've ever been in an organization and you're looking at where our vision is, where our mission is, and what our business goals are, and struggling to figure out how to connect those to what the teams are doing, this is what you're missing: you're missing product operations. It's absolutely essential for companies at scale.
Now, product operations includes a lot of different things. One of them is data and insights. How do I get the right information in order to really choose what I need to do with my product strategy? There's also setting up a customer research organization. How do I make sure that I know who to talk to in my customers or users and how to get feedback from them?
There's also market research and competitive analysis. How do I understand what my competitors are doing? How do I lay out that lovely SAM (Serviceable Available Market) that’s gonna make us grow?
Then, there's the product feedback programs, alpha and beta testing, and this is usually where agile and product coaching live as well. For today, we're going to hone in on data and insights and get really specific about what to do there because that is the make-or-break piece of product operations. While everything else can really help accelerate a company and help it scale, data and insights is the thing that's gonna get you to that next level. It's really the crucial piece.
So why do we need product operations, and when do we need product operations?
As we start off as a small software company, we're really small. We've got that founding team. When we go into early stage, we've got some sales, marketing, product, and tech, but we're usually big enough where we could just walk over to somebody next to us, ask them a couple of questions, and get an answer right away, especially as a leader.
But as you hit the growth stage, you're starting to scale so rapidly that you're starting to execute ahead of your product strategy. That's really where we have to stop and say, "Okay, how do we pull this together so that we can make sure that we are growing and accelerating?"
You're gonna get a lot more people involved. There are gonna be a lot more decision-makers, and you'll have many more teams working on things. That's really where it becomes crucial to figure out how to get the right product strategy and how to put the plumbing in place to make sure I get the right data to scale. This is absolutely crucial at the enterprise stage as well.
With a lot of my consulting, I've worked with enterprise-stage companies to do large transformations. When you set up things with product operations back in the growth stage, you can avoid a lot of that hurt when you get to the enterprise stage when you have to refigure out your strategies. You'll have all that product operations laid out, you'll be able to get your data, and you'll be able to make decisions.
So that's absolutely key that we catch it right there between the early stage and the growth stage, implement it so that we can make it to the enterprise stage and keep growing.
When we scale organizations, it brings new challenges. We have a lot more questions about how do we grow, how do we innovate, and how do we keep our costs down? So we have to make sure that we're answering them in the right way.
Some of those questions are around sustaining top-line growth. What are the right growth levers that are going to yield the highest return? Why are we innovating so much less than before? Why are we slowing down? How much of our existing revenue is at high risk next quarter? Will further monetizing our current market drive more growth than expanding to new ones?
Now we have to make decisions about where we want to go. Do we want to expand into new product lines? Do we want to expand geographically? What's going to cause our growth?
On the other side of that, we have to manage our bottom line, our costs. What is our product development spend? Are we missing some hidden costs that are slowing us down? Should we be spending to either optimize what we currently have or innovate around something new? What inefficiencies can we really tackle so that we can start scaling better?
Product operations, as the data and insights piece, provides the cross-functional visibility and insights needed to define winning product strategies. That's what this is all about. Everything we're doing here from the data and the insights is helping the team figure out what our product strategy should be, how we grow, and how we win. This gives you the tools necessary to make those decisions.
With that out of the way, let's dive into some awesome case studies.
We're really privileged today to have a story from the trench with Kevin Broome. He is the Chief Product Officer of Binder, a really fast-growing company in the SaaS marketing web domain space. They are expanding into new product lines, and he's faced with lots of challenges.
Kevin's gonna share with us a little bit about Binder, what it was like when he came in there, and how he's using product operations to scale it and grow it.
Thank you, Melissa, and I'm very happy to be here. I joined Binder three months ago, at the beginning of the year. One of the unique aspects of Binder was that its organic growth rate was sufficient to carry it from being an early to a growth stage company. Binder went even further with that by actually making a few transactions, which accelerated that growth even further.
So when you look at that organizational view or evolution view, it went even further into the growth stage while still needing to develop its supporting processes and develop its working stack forward.
Coming in, I've been focused on using product operations to hit two things off the bat. Those two things really are focused around prioritization of what we need to do and also making sure that we're utilizing our resources effectively.
Looking at that, as Melissa had said, it's around generating those data and insights. A lot of that is around normalizing the data using common terms everywhere in your systems, whether it be in how you define things in JIRA, making sure that things are defined in such a way that you can link it back to your financial systems, Salesforce, what-have-you, to give you a normalized view.
So we're normalizing a lot of the data in the various systems, and we're also normalizing the data around the goals. Being a SaaS-based company, the goals are, as you would expect, revenue growth, both through absolute growth in ARR as well as improvements in our retention numbers.
The other part of that is cost management. A lot of the effort early on is understanding those costs— which of those costs are the costs to operate the business versus the costs to develop new innovation? Very commonly, in the stage of the company, those costs are intertwined.
Being able to put these costs in individual buckets and understanding what is the cost of build and what is the ongoing cost to maintain is a very critical input into getting that prioritization process in place.
As we normalize it, we're looking at every initiative from the standpoint of how to deliver revenue growth. What's its impact on COGS (Cost of Goods Sold)? Whether it's increasing structurally or reducing it, and also common to the stage would be any platform-level improvements that will also help scale.
We typically prioritize our platform improvements based on how they're delivering more revenue and how they're delivering or reducing costs.
The second piece that's always a challenge at this stage is understanding your capacity to deliver. It's very easy to put an ambitious roadmap out into the market, creating sales debt if you're having difficulty as you're starting to grow and having more complexity around your delivery capacity.
I use this information to help prioritize cost-benefit analysis, knowing how much impact it's going to have, what kind of costs, and what other benefits are going to come from it. I look at each of those initiatives through the prism of the functions that I have, whether it be product, DevOps, engineering, front-end, or back-end.
Getting a very granular view on how many people I have and matching them up to these projects helps me get an early indicator on where I have a deficit in headcount. For example, I can look at my program work at a level now and say I have a deficiency in DevOps. The projects that have been committed to have a lower than likely chance of actually hitting their committed dates.
So it helps me to drive more predictability with my internal and external stakeholders. It also has a secondary benefit of informing my hiring plan and giving me a better view on how to actually treat attrition or opportunities to backfill.
The final thing I'd like to say on this is, you know, what I'm starting with is small. Coming into a company of this stage that hasn't been treating their data in this way, you could go to infinite levels of detail on these things. My final goal would be to look at these things through various pivots: product line, features, customer segments, personas, industries.
If I go out of the gate with the requirements for that level of specificity, I'm gonna get bogged down. So I'm trying to treat things at the highest level that I could actually generate good data, start to make the decisions there, and then generate more granularity as we evolve the business.
Awesome! Thanks so much, Kevin. That was really insightful.
As Kevin said, this is all about making decisions, and I want to tell you a little bit about another example of a company that we've worked with doing product operations, data, and insights.
This is a portfolio company of Insight. We've done this with a lot of portfolio companies so far, and I can tell you it works.
Let me give you another case study on this company and how these product operations helped get their product strategy. This was a larger company with multiple product lines, and they had just gone through many series of acquisitions to turn itself into the growth stage that it was. It was getting really large, getting very close to an IPO, and they had a few problems that they had to go through.
First, they realized that they had misallocated spend across their products. Just like Kevin was talking about, it's about the capacity planning—where are we investing in our different products? How do we put people across the different initiatives that we have going on?
They also had unaddressed customer issues following an acquisition. They saw that one of the product lines that they had recently acquired was turning at a really incredible rate, and they needed to figure out how to stem that churn, but also what's causing that churn? What's happening here?
The third problem that they were experiencing was an untapped growth opportunity. They had identified an issue in the market, they knew that they had experimented around it, and they had validated that it was a good way to go, but they just couldn't get their things in order to actually execute on it.
No matter what they tried at the time, they couldn't make anything really move there. It was all about execution—how do we execute to go after that growth opportunity that's sitting right in front of us?
Looking at these three different problems that they had, they turned to product operations to really help them figure out what to do.
They dove in to really look at where they were allocating their spend. How are we spending money on our teams and on our COGS across these products? How does that relate back to our goals? What are the retention metrics on these products?
They started to marry that conversation between what is the financial state of each of these product lines and then what are our engagement metrics and what is our spend? They started to put that picture together to figure out which way they should go.
Then, they also looked at where the retention issues were coming from or the problems with the unaddressed customer issues. They also looked at how the issue of the spend and the allocation of people across these products was affecting that untapped growth opportunity.
From this, they really optimized their R&D efficiencies. They went in, started reallocating people to the most important things that they could be doing, and they realized that they had a huge discrepancy in where they should be placing people and what was really needed to make this happen.
So they reorganized everybody into a more optimized R&D program. They addressed that churn and support calls. They went in, really dug down, and figured out why they were turning, what was going on, how to shore that up, and how to understand that customer problem.
Then they also discovered that to get into that new untapped growth opportunity, there was a cross-sell opportunity in their existing market. So to go into that growth opportunity, all it really took was getting that cross-sell ready to go to market.
With that, they had wildly drastic, amazing results going in the right direction. In the first year, they had that base case EBIT (Earnings Before Interest and Taxes) up; it was low, and they were struggling. They were trying to figure out what to do.
In three years' time, they were able to accelerate their growth significantly due to the insights that product operations gave them so that they could make the right decisions for product strategy.
So that's what we're really talking about here with product strategy and product operations. It's giving you the tools to make the right choices so that you can accelerate your teams.
How do we get started with that? There are a couple of different steps to get a baseline understanding of your products, and this is really important.
What we're doing here is building a current state of what's going on with our products. Where are we spending money? Where are we not? How do we get a full picture of our product portfolio?
Here's the step-by-step process to build a baseline:
1. Identify our total costs.
2. True up that data against detailed data sources.
3. Understand the other costs that may impact your products.
4. Assess your growth drivers and opportunities.
5. Consider all that data and then turn it into an action plan for your products.
That's where we really pull together that product strategy.
So let's get started. First, we're identifying our total costs. What does that mean? We have a lot of direct product costs that are related to running our business. We've got the cost to operate, and we also have the cost of sales debt.
So what does it mean? Our cost to operate is really where you put your people on your team. It's looking at your staff—who you've got in product engineering—and it's also looking at what we're spending to really address some of our sales debt.
We don't talk a lot about contract and product management, and we need to start doing that because it does cost us money in order to fill that.
What is the sales debt? What do we have to catch up on?
We turn this into a picture, really looking at two things: COGS and OpEx (Operating Expenses). Under COGS, we have hosting and licenses. What does it really take to run the products that we have today?
So not just the people, but the other things that it takes to actually execute on the product. That could be your hosting cost from Amazon Web Services; it could be the licenses and tools that you need to get things done.
Then we also have OpEx. We have our people—how much does it cost for the product team, the engineering teams, the design teams, and the teams that it actually takes to build the product?
Once we have those total costs, now we want to dive into them a little bit and understand what those mean.
So now we drill down and start to look at our labor allocation. This is where we start to look at how many people do we have around each major initiative in our company.
For example, do we have people around infrastructure, critical bugs, innovation, contractors, or onboarding?
As a product leader, what I'm trying to look for is: are we spending our money in the right places? Are we overestimating how much we really need for innovation? Are we putting everybody on support and bugs?
That's telling me that if I'm putting everybody around support and bugs, how do I make a plan to get that shored up so that we can move on to more innovation?
One of the other things that always comes up in a lot of companies that I've worked with previously is that you'll see that you'll be putting a few people here and there, and it's something that I call "peanut buttering."
You're spreading people thin across everything in the organization and not making a concerted effort to push towards one thing, like innovation or infrastructure or the things that really matter.
So you want to make sure that you're not spreading people too thin across all these different areas, but you need that current state to figure out if you are or not.
From this, we now start to get a total picture of what it costs to run our business.
Next, we're also looking at the other costs that impact our products. While we have R&D costs, there are other different costs that surround getting people up and running on our products.
For example, the cost of adding new logos. We have non-development resources doing onboarding. Who is onboarding our clients? How much does it cost to get somebody onto it?
Or the cost of retention: customer success, support time, and ticket time. How much are we spending there to make sure that we don't have people who are churning?
When we add all these up, we can start to get the full picture of what it costs to run our products and to bring them to market.
This is called indirect product costs—the cost to onboard customers post-contract. It's not the sales costs, and the cost to retain is what's the churn prevention.
Now that we have a picture of what those are, we need to go back and align that to our growth drivers and opportunities.
This is where we start to dive in and look at all right, what are the different metrics from a product standpoint and from a customer standpoint that can tell us if we're moving in the right direction or not?
What we do with that is build these dashboards so that we can see where our things are falling. Are we having really good metrics on NPS (Net Promoter Score), or is NPS really low and we have to deal with it?
When you surface all this data up to you, now you can start to make choices about where you want to invest.
We look at things like our annual contract value (ACV) or ARR, depending on how you run your different product lines. We look at churn, we look at your win rate in your pipeline, and why is that happening?
We look at NPS, we look at session times. You want to really take a picture of all the things that make your business run and tell you if it's healthy from a product perspective, and pull that into a way where you can look at it and assess if this is on track or if this is failing and I need to actually prevent it.
Once you have all of those things, now it's time to turn it into action.
What we typically do is get all this together in a dashboard so that as a product team or a product leader, you can start looking at this and start to make choices. You can monitor it.
If your NPS starts falling, you catch it in time so that you don't find out a year from now and you can't do anything with it.
Now that you have it, you start to assess it, align it back to the vision of where your company is going, and turn that into an actionable product strategy to get it done.
This is key to really getting that data to make those choices and those decisions.
Lastly, how do we level up our product operations data and insights?
Our vision for product operations and data and insights is that it's a virtuous feedback loop.
On one side, we've got those dashboards I just talked about with historical product operational performance, and that allows us to make decisions on customer needs and in-house resources based on our data.
Now we've got that operational predictability, and that helps us with executive visibility. This allows executives to look at these things and start to make choices about how do we maximize growth by effectively putting people in the right places around the right initiatives.
Then we turn that into strategy deployment. I've got a picture of where I am in a current state; now I can really understand what it takes to get to the next state. Let's create a new strategy and deploy it across the organization.
This is how, if you read my book, we create strategic intents in our strategy deployment and our product initiatives. This is what it really takes to do that.
Finally, this helps make team efficiency. This is what helps propel teams and aligns them up and down the organization so that everybody's moving in the right direction and you're not scattered around a bunch of initiatives and not making progress.
This really feeds into itself so that you can understand where you are, look at where you're going, fill in those gaps, deploy that strategy, and make sure everybody's working towards it.
We've usually built a dashboard for automation, and this is best done with a third-party BI tool. Those are things like Sisense, Tableau, or Looker.
What you want to do to get started here is start connecting it with all the different data sources and the different tools you use to make that happen.
For example, pulling in the win/loss from Salesforce or the workflow data from JIRA, the projects, the epics, tickets, and going into Pendo and taking out that user engagement metrics.
When you start to pull all these things and aggregate them into this BI tool, you can now make these dashboards that will allow you to glance at it and see if you're on track.
Once you do it once, you don't have to do this baselining every single time.
How does this actually work? Well, you're gonna need some people.
We want to dedicate some firepower to product operations, and that means that you're gonna have to hire somebody or choose somebody in your organization who's good at this to happen.
We have this role of a Product Operations Analyst who really oversees the data and insights. This person is the right hand to that Chief Product Officer or VP of Product, and they're responsible for providing a 360 view of the entire organization and removing those blockers to evidence-based decision-making.
This is how you make decisions with data.
This person is going to use that cross-functional data to really correlate the trends. They're going to go across the organization and work with engineering, customer success, marketing, and finance to gather that information and make sure it's up to date.
They're also advocating for best practices in the tools and instrumentation that we use. What are the data integrity issues that might come up there?
They're preparing reports on a weekly or monthly basis to help inform that product strategy, and then they're also automating that data correlation analysis and reporting at every opportunity.
What do you look for if you want a Product Operations Analyst?
First, you need to find somebody who's curious and has a passion for problem-solving. All of this stuff is all about problem-solving. You have to be interrogating data, trying to figure out what the problem is, and trying to understand the people who are gonna be looking at this dashboard.
Understand what problems they're facing, what they're trying to solve. Your Chief Product Officer, your VP of Product, is your customer here. Your product teams are your customers.
So what are the problems? What are the questions they're trying to answer?
They have to be highly analytical. They have to have that strong analytical toolkit. They need to be able to make financial models, correlate disparate data, clean the databases, and get their hands dirty. They have to be super analytical here.
Acceptable weaknesses: this is a new role; not everybody's gonna be perfect here. What can we really look for that we don't really need in somebody?
Deep product experience: they don't have to have deep product experience here. This person is not a product manager. They don't need to be a subject matter expert on the industry. They don't need to be a product manager; they have to be more of an analyst.
They really have to understand that analytical thinking. They have to have some product tendencies to really understand what problems they're solving from a product management standpoint, but they don't have to have deep product experience.
This might be a great stepping stone eventually to a product management role if you think about it as well.
Experience with specific tools: while preferred, not necessary. The best part about this is we need somebody who can get in there and figure out the different tools. Every single company has a different toolkit.
Some people use Pendo; some people use Amplitude. We need somebody who can really dive in, know what each one of these tools is, figure it out, and then put it all together.
So when you do product operations at scale, usually there's gonna be a team set up with this. If you want to get started, start with a Product Operations Analyst. Hire somebody to own the data and insights piece.
At least from there, you could start scaling up your team and have everybody working on this.
How do we get towards automated dashboards?
The first step here is that we develop processing governance. This is usually a four to six-week period for us, and we start with a regular cadence for manually baselining the data.
Here, we're identifying key data sources, hiring that product analyst, improving the data integrity and core loadability, and defining the process for sharing data.
For us, this typically takes four to six weeks. That's what you should budget. Make sure that you understand that this is not like a "we're gonna flip a switch, and it's gonna happen tomorrow."
So develop that process, do the governance, and get the manual baselining done.
Now we're going to refine architecture and data sources. Now we take the steps towards the automated dashboards. Now that we have a manual baseline, we're going to identify a third-party tool for automation.
You're going to choose between some of the ones that we mentioned: is that going to be Sisense, Looker, or Tableau? You build that reference architecture and then add those data sources to it.
Finally, you've got this scale-up, and this is an ongoing type of thing where your product analyst is always going to be looking at it. You're going to continue to make ongoing improvements towards full automation.
Just like Kevin said, this is like the first step that we're doing with these things. We want to manually baseline it; we want to get there, but there's so much more that you could be doing.
This is identifying the next correlations, adding more metrics into it, and refining your dashboards as your product strategy changes. This is all the things that that product analyst is really going to own.
So with that, what did you just learn about product operations, data, and insights?
This is key to setting product strategy. If you want to set and deploy an effective product strategy, this is what you need. You need the insights and the visibility to maximize your revenue and your profit and track progress against your goals.
This gives you the data and the tools that you need to make decisions about your product strategy.
Establishing product operations is an iterative process. The more time you can dedicate to this, the more people you can bring into this, or the person you can dedicate to it to own it, the better this is going to get.
This is not a one-time snapshot; this is an ongoing way to make your company data-driven. This is key to making your company data-driven.
Finally, each company is unique, so each dashboard is going to look different for every company. It all depends on how you run. Did you grow through acquisitions? Do you have multiple product lines? Do you have a geography strategy?
The things that you measure are going to be unique to your company, and that's fine. That's how this should work.
So you really want to make sure that you understand your strategic goals, you understand your vision, and you make a product operations dashboard that is great for you.
Remember, as we covered in the beginning, data and insights is only one piece of the product ops organization. Today, we still need everything to run, but it's the most critical piece.
This is what allows you to make decisions. This is going to be the coach to that Chief Product Officer, that VP of Product who's really running it. It helps them really make the right choices, but you still need some more to really get a fully functioning product organization set up at scale.
Thank you very much! We are here to answer questions. I also have Kevin with me still from Binder, who's happy to answer questions about how they set it up. I hope you enjoyed the webinar, and if you have any questions about product operations, feel free to reach out!