The Roadmap to Success for Product Operations

Read the Full Transcript

The following transcript has been altered for readability.

Becky Flint: I’m very excited to lead this discussion around the roadmap to success for product operations. You may not know that product operations has been around for a long time. It started around the time when I joined PayPal almost 15/16 years ago. The first week when I started, there was a big binder on my desk called “The Launch Playbook”. PayPal was expanding back in the days, and they thought, “there has to be a way to manage it”. There are a lot of pieces, in part of bringing the product to the market.

The Playbook was built by one of the first product operations managers. And that became sort of the basis for the Roadmap to Success for Product Operations. Lots of companies that started a product operations function due to global expansion, such as Uber and Airbnb, follow this. So I’m excited to share the journeys that we learned on product operations. I learned that it’s not about making your team, it’s about driving the portfolio outcome across your entire product organization.

So how do you do that? What does it even mean to have a portfolio outcome? So a couple of things they realized after building and establishing product operations. We found out there are a couple of elements of driving portfolio outcomes. They surround the team, enabling the team, making them efficient, making them successful. And many of us think about product operations starting from there. The second part that is supercritical is around empowered vertical collaboration alignment between the executive and the team. And then last but not least is across the team, and function because the product takes a lot to build. So that’s three elements of effort around enabling and accelerating portfolio outcome.

So let’s take a first look at enabling teams. And I think the example we had earlier about the Country Playbook is a good example of that. Building a product is not easy. You start having multiple teams, multiple functions you want to expand, etc. How are you going to make sure that each of the teams doesn’t repeat and start learning from ground zero? So the playbook becomes super important to take the learning from one team and share it with the others. It’s continuous management and improvement on that.

There are templates and operating rhythms to make sure the team works well together and provides them with the data. This is a great starting point, but sometimes you realize your team is missing another ingredient. Which are the connection of top-down alignment and the bottoms-up innovation.

What does that mean? When I joined BigCommerce, today a multi-billion dollar unicorn, it was just starting to scale up. The original team was working very hard and they made a lot of progress, but the progress stopped. The progress stopped because there are a lot of different opinions on where to go next. Should we go upmarket? Or should we go free into the down market? Should we have a partnership? Every one of the executives has their views on how to take the company to the next level. So as a person running both the product, the strategy, and operations one of the key things is for me to observe that we had these different viewpoints. Therefore how are we going to go align the team if everyone has a different perspective?

One of the things that I did was set out a strategic alignment process. So we helped them with a workshop with different functional leaders and a little bit of a strategic poker if you will. And we decided everyone think about how to achieve growth. It turned out every function has different opinions. So we spent quite a bit of time on a painful discussion on where we should align. We decided that we will focus on the existing base. And that became a north star to drive the direction of our product roadmaps. As time goes on we evaluate the progress and the goals and then shift more.

The key thing to the Roadmap to Success for Product Operations is you enable your teams and provide the alignment. This is essential for companies starting to scaling to the next level to drive efficiency and results. And that’s really how we talk about the empower vertically around the product ops focus across the strategic alignment.

So we talk about team alignment, now what else is important to the Roadmap to Success for Product Operations? A very common theme about product operations is to be able to connect horizontally. Product managers tend to be working on their areas, but what about the others? A good example is Nium. Nium is a fast-growing payment unicorn. They are one of the customers of Dragonboat and it was exciting to watch them go from a scaling startup to a unicorn. And one of the key things I was talking to their chief product officer is around how they achieve that. As the team grows, as the product scale, there’s something inevitable, which is dependencies.

There are a lot of teams trying to organize their team structure to try to avoid dependencies. You can try to package your team in ways that are more work within themselves, but dependencies are inevitable. So the effective way to manage dependencies is instead of looking at cutting your portfolio into verticals and everyone has a slice, that means that sometimes some areas are not used as much as the others, you are looking at holistically to understand here are goals, how do we achieve these goals? How do we manage dependencies? So that you can make effective real-time trade-offs and manage dependencies effectively. So your team won’t be churning, then it will help you to drive the product launches and the product focuses as they evolve.

The other part is about orchestrating, the cross-functional team across teams and more than just across products, a lot of product operations are also taking on working with the stakeholders and going back sort of the country launch example. And it happens a lot for all the other areas is that building product is the middle, but there’s a part of taking the product to market. There’s a part of taking customers’ feedback into it. So driving that alignment and the collaboration is essential, and frankly, nobody else is their role, right? It’s the only operations role to help that cross-team collaboration and alignment.

So with that, we kind of go through a couple of spaces and, think about product operations. The purpose of product operations is to drive and accelerate portfolio outcomes. And this takes into a couple of elements that enable teams to drive team efficiency. So your team can have the resources, the need, and the foundation to be able to achieve what they need. The second part is the vertical alignment to make sure your executives and your teams are working well together and cross-team collaboration. They are all three-pillar, they’re not sequential. You need all three of them at once. And finally is the foundation is enabling everything. If you don’t have an outcome-driven culture, it will just be a feature factory and very hard to drive portfolio outcomes.

If you are not responsive, you kind of have things all over the place. It will be also very challenging to tie things together, both across teams and across teams, and organizational functions, as well as different functions, are working together. So you can almost think about it that, if the product is a house that you need the pillars coming together, and so that you can have a, you have a pillar coming together on top of a strong foundation so that you can accelerate portfolio outcome. I know I covered a lot of a topic very quickly. So before I go too much deeper into each of the areas, I want to just, pause to say, hey, if I am new to a company, just start building out product operations, where should I focus? Where should I get started?

And then when we go to the next level, it’s how do we evolve? Because I think if 1/2 of the team wants to know how we’ve grown in scale part of operations and how some part of the members want to know where we get started. So I wanted to just talk a little bit about where we get started. And some of the observations I want to share through working with the tons of teams are when they’re first thinking about building product operations, quite often they are focusing on one pillar for a very extended depth. And some of the other pillars are not quite being looked at. So, I hope this Roadmap to Success for Product Operations will provide a little bit of context on the different levels of product operations.

The first pillar of the Roadmap to Success for Product Operations is around enabling the team with a foundation. If your teams have different processes and terminologies it’s going to be challenging for your stakeholders to even know where everything is. We have run into scenarios where there’s a lot of terminology and a phase definition that wasn’t, on top of the mind for the startup companies.

So defining a foundation on how we work together, how we communicate, how the interaction happens is really critical. The middle part of starting of connecting your goal system with product initiatives is actually fairly critical.

Sometimes team lets it run on its own. So what this means, we could have a different topic around it, which is sort of like something we call strategic planning. What it means is that when you have a business goal, the business goal doesn’t just translate to tasks. There’s a whole part of business goals translating to product strategy, product strategy then will help the rest of the product teams on how I prioritize how I work with each other. So that’s something you quite often, you can hear things like strategic context.

Product operations would have to focus on defining a strategy to achieve the business goals. And then the third part of that is stakeholder management. Provide visibility as the most basic foundation.

Therefore it seems boring, provides weekly updates and so on, but it’s very essential to the others. Now, if you have a platform, then you don’t have to take on time-consuming meetings to communicate information, but stakeholder visibility is fairly essential.

Having these three foundations for your Roadmap to Success for Product Operations enables our team, top-down and bottom-up alignment, as well as stakeholders. That is the first part of your journey to product operations. Most of the teams started, I would say, within the first year or sooner should be able to achieve that goal.

The second part of the Roadmap to Success for Product Operations is growth. Now when I say growing here it doesn’t mean growing in size. It growing in your organization’s capability, to deliver and accelerate portfolio outcome. And in this space you are looking at some of the blockers of your product teams, decision making for example, here the first part of enable team is around the data and inputs and the customer interactions because you have the foundation to be able to deliver and prioritize and have the foundation to connect them to initiatives and so on.

So when I say data here, there are multiple elements, again, depending on your teams and your company’s structure. If you have a dedicated data team, obviously it’s very much around how you get data, how you make it efficient, how it has good data definition, so that when we say a metric across different teams, we mean the same thing. Quite often this is coming through that the data definition is different by teams. So we’re looking at the apples and orange on the same deck, or dashboard which is very challenging. The second part to highlight here is feedbacks and requests and so on. Now, it’s definitely a big part of building a product having customer feedback, essentially being able to learn it. Product operation quite often gets involved in a couple of ways in this space.

The second pillar of the Roadmap to Success for Product Operations is in the maturity level of product operations role around responsive allocation and trade-offs. And this is one of the most impactful, product operations contributions to the product organization because product teams are typically focused on their own areas. The chances are the organizational needs and the customer business needs evolve. So imagine this for a second, if you have an investment portfolio, return in the portfolio, you will have some allocation to different things, as the market change you will rebalance.

And to say, I’m going to invest more in certain areas versus the others, the stock, and bonds. So the market changes will affect how you allocate and also as the time of your life journey goes on, you also change how much you’re going to invest, taking more risk is putting, more for less risk, the same thing for your product, right? What is very interesting, that some of the team may or may not recognize is that the allocation on the product team quite often does not change. So there are five product teams each one focuses on something. And in next month, next quarter, still five product teams they’re focusing on something, at the same time your business evolve. So, and this is where sometimes we call the peanut butter strategy.

If you Google it, you can find out what happened at Yahoo around the peanut butter strategy. What we are trying to talk about here is that as you become an outcome-focused product organization or organization in general, you will look at the outcome in your focus and your goals. Ask “Are we exceeding our projection, are we behind?” For us, a company has pretty much the same goals, right? You grow customers, grow revenue, reduce cost, and retain customers. Let’s just say we have two goals, right? We broke new customer and we retain our existing customer. So when you have these two goals and you set up a set of metrics to measure, you set up a set of initiatives to work on, that initiative could go expand across multiple teams and things go on.

And how do you do that? That’s the third pillar to the Roadmap to Success for Product Operations. Responsive allocation and a trade-out between each existing initiative and new things are key. Quarterly alignment, dynamic planning shows where we are in goals and how do we plan to achieve these goals? This means that some of the goals need to be done across multiple teams across multiple functions. By going through this process, we understand our focus. And by going through this process we understand which teams need to focus on what areas.

So the third level of product operations is quite often happening between the second and the third. And the mastering is, it’s not the checkboxes are done. The mastering means you have done really well in terms of setting up the foundation. You’ve done really well to scale your teams to work across the board. Now, the mastering really is around continuous improvement. How we find out things are working. How do we find out things are not working? And how do we standardize things that are already working?

What happens is a lot of times where organizations start to scale and they’ve done all the best practices. Then they stop. Things change as your company grows. So your template, your cadence all may need to be adjusted. That’s about understanding how the organization evolves to be able to improve on that as well.

So, in terms of cross-team collaboration and alignment on the third pillar at the mastering phase is around orchestrating launch. And then you will ask, say, hey, I already do this in the very beginning. Yes, you may but this is a lot more involved. It looks at how our entire portfolio works together. And that can be a feedback system used for your alignment and planning.

So think about that, your product organization is a living organism and a working in the moving environment. So product operations would, the focus really is to help the team to best navigate the changes internally and externally. Having a responsive approach is critical. That means looking holistically across your product and portfolio. And enabling your individual product teams as well as the product teams in different interfaces. Those are the ones that are really holding the organization towards the direction you need to go. So that’s pretty much it on the Roadmap to Success for Product Operations.

We talked about a couple of the focus areas. But there’s always more to unpack and I always look forward to hearing more from you.

Roadmap to Success for Product Operations Q&A:

See full clip here: https://youtu.be/9AmvkDf4aks

Bhaji Illuminati: In a rapidly scaling product org, where do you recommend leadership start with implementing and scaling product ops?

Becky Flint: It’s a good question. And I’m glad this is actually being discussed at all. In a rapid scaling startup that you typically face three challenges. One is the product itself. Chances are you already have a product that’s already in the market and you already have users. And as the product hits the first product-market fit, you’re immediately facing the trade-offs and balances. And it’s also the time to start thinking about what’s next because that takes time. So the challenge of deciding on different product focuses is definitely one top of my own for product leaders.

The second part of that is around the product teams. How should the product team work together? How are they going to get interactions and dependencies and structures and all that in place. And the third one is how do I even keep everyone on the same page. To think about it is that the product alignment, which is in the middle, think about how teams should work together. That’s basically the three pillars of the Roadmap to Success for Product Operations right here.

So what does it mean in terms of how you are going to focus on this? I would say starting to hire product operations is very essential. It is a role right now that’s very in-demand today.

So my recommendation is a few things. Number one, you should always think about different elements of product operations, and then have whoever starting to look at all these areas. Secondly, that, some of them, think about the company, maybe you don’t have product operations present right away. And what do I do? I can’t wait until that’s coming, right? So the good news is, is not rocket science. Someone can take a little bit of their bandwidth and then start to implement some of the basic stuff. If you can use the tool you should. And I highly recommend it, if you use a tool, it solves half the problem.

So I would say having the right thought framework to cover the foundations of your rapid scaling product operations. And two is to have someone to oversee your that and your bandwidth. And third is, you should use a tool. We know there are tools to make it work and guide you through the process. So, that’s what I will recommend. Start now, even if it is part-time and then choose the right tool that would facilitate the process.

Bhaji Illuminati: What tools, templates, and documents do you recommend using across each pillar and level of product operations?

Becky Flint: So the way you think about product organization is you can think about the product like a coin. There’s the execution and deliveries side of things. But there’s also another side of, you can call the product portfolio management. If you should obviously today have a delivery side of the things, right?

I cannot have just the OKR tool that says, goals and tasks. There’s a big part in the middle missing. And I cannot just have something like my team wants to use, X, Y, Z. Things need to come together into one place. That’s why a product portfolio tool in a fast scaling company means you have multiple teams competing for goals and competing needs. And that’s what is needed. Dragonboat is purpose-built for responsive product portfolio management, a tool like that will enable you to pull all the moving pieces together from the feedback and reviews to best practice the process, and cadences connecting OKRs and across team visibility as well.

Bhaji Illuminati: Great. We have another question here around how do product operations engage effectively with engineering partners?

Becky Flint: I would answer this in maybe three angles. Angle number one is engineering and product are very integrated. So for us to better prioritize our roadmap, we need to get involved and understand the engineering effort. So that means is that you would interact with your engineering team in an additive way. When you have your goals and strategy, then you have product context and things you want to do.

Now, obviously, that cannot just turn into stories. It’s so expensive it’s so solution-driven. You want to do is to have a very high-level understanding of the effort involved. That’s the part that you actually partner with your engineer, to understand problems to create solutions.

So that will give you a general understanding of what it takes to achieve some of the product direction. When are you going to do our scrums, when are you going to do our books, and so on? So I think that’s something very understood. It’s just the earlier part of the interaction, having a strong partnership with your engineering lead is important. The second part of that. So that’s like the planning side.

The second part is the end-to-end customer and the product experience. If we have lots of bugs not good. So you can have the best product if you have lots of bugs it’s no good. So, from that, the product operation started to have extended partnership with engineering, truly understand the quality and the customer experience, both from product features as well as from the quality and the product and the speed of the go-to-market.

The third part, I think, is that “tech debt”, it’s something very interesting where you hear the product team say, here’s a product roadmap, but how do I get tech debt onto the product roadmap? And that’s really something I would almost say in a harsh way, it’s a very feature-driven organization versus outcome-driven organization, meaning tech debt not only impact engineering, but it also impacts product even more, right? So if you have a tech debt that means you build products slower, then you have tech that may have more quality problems and then you cannot just become a trade-off for negotiation between product engineering. Really, you say, here’s our customer, here’s our customer needs, and how do most effectively deliver value to our customer and add the quality that accepts that could mean we are going to refactor our platform incrementally.

So, every company I went to that become, go from a team-based product versus engineering to a more collaborative team where tech debt is part of the product roadmap and that becomes much better in delivering value to our customers. So, I hope that’s a long answer to the question of how product should work with an engineer, which is a strong partnership in different faces that have different engagements. And there’s really not much of a tech roadmap versus the product roadmap. It is a customer roadmap.

See full clip here: https://youtu.be/NUf3iZxozYU

Bhaji Illuminati: And we had somebody ask for a reminder of what the three pillars of the Roadmap to Success for Product Operations.

Becky Flint: Yeah. So the three pillars of the Roadmap to Success for Product Operations is around your team. I would say product operations is working with the team all the time. And then the other one is to align vertically, which is the, with your executive team, as well as your team member. Now, when I say executive team it’s not just product executive, it is actually cross-functional leaders because they all have input in the impact on product decisions, and cross-functionally, which is really working across multiple product teams, which is all within product organization, as well as functions as the design functions, like the marketing function, like customer success, because all are strongly involved in designing, inputting, designing and planning and product and delivering and the servicing products. So everybody is involved.

Bhaji Illuminati: Perfect. So then switching gears, in a growing org what are the main roles of product ops team to scale?

Becky Flint: In the earlier days when you have just a couple of product operations, one or two quite often in reporting to chief product officer have of product sometimes reporting to a CTPO, which means someone actually runs both product and engineering. This becomes more and more frequent, in organizations that work really well together. Now, as the product team scale, you’re probably going to have a couple of VP of a product, under the chief product officer. So quite often product operations could have a, we call it a federated hybrid model, which means you could have ahead of the product ops reporting to the chief product officer. And this person could have multiple team members that each one of them aligns with one of the products VPs or product areas. But that person also aligned obviously reporting to the head of the product operations.

This federated model is really helpful. If everyone is just a direct line into the product operations leader, then there is somewhat of an alignment and a focus difference because each product area could be different. Now, if they are just reporting to individual product VPs, then it’s harder to have best practices and consistencies. So this federated model with one dotted line and then one solid line reporting would allow you to have better partnership in different areas of product VPs, and still have a portfolio view across the board as well as to have best practices across your portfolio. So it’s always a balance of how much you want to focus on one area versus how much we are going to focus cross-functionally. I’m only talking about product operations or structure. I’m not talking about the product and or engineering or structure.

Bhaji Illuminati: Great, thank you. We’ve had a couple of questions, what would you view as the ideal interaction between product ops and program management?

Becky Flint: That’s a very interesting question. I personally have gone through a lot in the past. So, when I started earlier, we have a role called product program management. So it’s like the product ops and also of program management. And then later on we’ve gone through the phases of where you have technical program management mostly working with engineering and scrums and so on. Then you have a product strategy and operations, which we’re doing a broader role and, more around the structure-function, strategic planning, and a launch less about the deliver. And then also ones with scenarios where, I run both functions, both program management, technical program management, and also product operations. So I think it varies often depending on the size of your team and the company.

When the companies are less than a couple of thousand people, having them under one umbrella makes more sense because there’s less specialization there’s a lot of crosses, in terms of coverage and specialty. But I also understand sometimes the technical program managers are really focusing on, sort the engineering loss state, but can release quality and around the tech side of things, then product ops really just be a really good partnership and complementary role in working on. So think about the sign, the calling, right? So execution, go to program management, the planning patronization, the fuzziness, alignment, strategic allocation to product operations. That’s one type of structure.

The other type of structure is sort of like less specialization you can grow across the board to really go from the very beginning of the strategic alignment to the initiatives to the execution. Now there is another school of thought or practice is that product ops almost like act as a center of excellence, meaning they will be working with the program management team, who would be a lot focusing on the planning and delivery and the communication, but product ops will become a sort of the process, data and structure, sort of the focus to make sure that we have the best practice, to make sure with the team has the data and the voice customer access to it, and then really leave program management to do the cross-team collaboration, the launches, and then the planning and delivery.

So it really varies a lot by the organization. I think for a large part it’s really depending on your current program management functions focus, as well as the capacity of bandwidth, and that product ops will be kind of working with them to figure out what’s the best handoff as well as the partnership.

Bhaji Illuminati: Great. Thank you. And then we did have a follow-up question to where product operations sit in the org. So have you seen product operations teams reporting into operations and what are your thoughts on that structure?

Becky Flint: I think that some of the team, not very common, some of them, did have that kind of structure in a way that operations are, I mean the role operations can be defined very broadly. So some of the operations actually focus on strategic operations, are they focusing on business operations. It has things to do with the data and the launches and the strategy planning, and then product ops reporting to their function seems to make sense, especially if they have program managers do they deliver and then more of like, define the role and working with engineering more closely. Some of the operations also do like a budget and headcount and product ops could also expand into that function as well. So I would say it is not very common, but it does happen because the operations role is so varied.

I think that ultimately it’s to say, are these pieces in place in terms of enabling the team to align vertically and enable cross-functional collaboration? If these pieces are not in place, then it’s a good time to identify the gaps and to figure out who would be, and the functional team will be filling these gaps. And that would be a good indicator to say, should product operations report to product, because there are key gaps in this role that is not being fulfilled by operations outside the charter of the operations. So it really depends on the gaps, who are fulfilling the gaps, and then who is the best to fill these gaps.

See full clip here: https://youtu.be/GkYkfOLW1gQ

Bhaji Illuminati: Thank you, Becky. And then we’ve got time for a couple more questions. Somebody asked, is there a prioritization framework built into Dragonboat?

Becky Flint: Dragonboat is a product portfolio tool, meaning it supports both product management and portfolio management. So they are building product management, participation mechanism in Dragonboat, both the standard, that they can do very well rise and so on. And there are also ones that can be customized to build for you. But more importantly, it’s more than just the product prioritization it’s also around allocation.

So the concept in Dragonboat and as a product portfolio tool is that you can use the tool to do product prioritization. And more importantly, you can also align your product to various goals and focuses and then be able to not only prioritize with the focus but more importantly to be able to understand where you allocate your organization’s focus, your product team’s focus. So long answer is you need prioritization as well as allocation to drive effective portfolio outcomes. Both are supported in Dragonboat.

Bhaji Illuminati: And then final question, does our product operations team need to be in place to effectively run Dragonboat?

Becky Flint: The answer is not necessarily, that a tool really facilitates best practices. But when you have a tool in place, you can save a lot of time and effort.

An example will be something like, do you need a project manager to use a project management tool? No. Do you need a scrum master to use the agile tool? No. But these tools exist because they reduce the amount of work and effort in these areas. You don’t have the PMI certified, project manager to use the project management tool. Anyone can because it’s intuitive and building your best, best practices. You can just get off the ground and run, the same thing for agile tools and so on. So same thing for responsive PPM tool by using Dragonboat, best practice is already built-in. So you don’t have to be a professional, but obviously, you can always learn and improve in those areas. And the goal is to make it easier and the best practice is already built-in for you.

Bhaji Illuminati: Wonderful. And one thing I’ll just add quickly to that is that we do have a pretty robust resource center. We do a lot of webinars and we train and empower people to become part of the community so that it is more than just a tool. So with that, we’re out of time. Becky, thank you so much for walking us through this presentation. Thank you all for joining and the great questions that we got throughout. And as always we’re a resource so we’d love to hear any follow-up questions from you and continue the conversation around product operations and becoming more outcome-focused as a product org.