Read the Full Transcript
Introduction
Alisa Vaz: Good morning, everyone. Welcome to this episode of the CPO Series. I’m Alyssa, I’m a Product Manager with Dragonboat, and we’re joined today by our special guest Hitesh Anand. Our webinar today is hosted by Dragonboat, and we’ll focus on up-leveling the product operating model. We want to learn about how this is done at various companies and what practical lessons product leaders can share with us from their experience.
Before we kick off, I want to mention a few things. First of all, this is a half-hour session that will be recorded and available on demand later with all our other webinars. Second, if you have questions during the presentation, you can submit those using the Q&A function, and we’ll either take them live or have a dedicated Q&A at the end. And finally, as you probably know, Dragonboat is a SaaS platform that enables product leaders to run their product operating model. So do check us out at dragonboat.io to learn more. Without further ado, I’d like to introduce today’s guest, Hitesh Anand. Hitesh is the Director of the Strategic Resource Group at Thomas H. Lee Partners. He works with portfolio companies and investment teams to improve operations and drive growth. Prior to his current role, Hitesh served as the CPO of Verify Visa Company and at Mobicon Asia. Before that, he held product leadership roles at Verifone and Citi Enterprise Payments. Welcome, Hitesh. We’re excited to have you here with us today.
Opening Remarks
Hitesh Anand: Thank you. Thank you, Alyssa. Welcome, you all. I’m excited to be part of this series. I know Dragonboat for a long time. I remember meeting Becky at Spaces when I was working on my own startup, and she was there as well. It’s interesting and very exciting to see the journey that Dragonboat has come through. Before I jump in on the dysfunctions or issues in the product operating model, I want to make sure that everybody is on the same page about what the product operating model is. This has existed for quite some time in the industry, but now it’s a lot more formal because of the breadth and the speed at which companies and teams are building products.
So what it is, essentially, is an underlying infrastructure or a working model ritual that a CPO and his or her team run to drive the success of the product organization, which in turn drives the success of the company. That’s what it essentially is. And as a company grows, it scales either in a portfolio or across geographies, and we see that there are signs that this is failing more often than not. How do you get that? We have a problem. One is building the product org is not optimal. Are you building across from a platform perspective, component perspective, persona perspective, or workflow perspective? You don’t know. Some teams work; some teams have a different model versus another team.
Hitesh Anand: So, it’s challenging in building the organization and having the right set of people who understand: are they functional experts, are they domain experts, or are they platform experts? That’s the first sign. People are always the first sign that you have a problem in your product operating model.
The second is the driving vision and strategy. Are you building because this is what you’ve done and are just incrementally going, or do you have an overarching product strategy? Do you have a notion of diagnosing a problem area and focusing for a year, next year, three years? Do you know how, across the organization, different teams are using the strategic lens to prioritize? If you don’t know, that’s a key sign to use a platform to run your product operating model.
The third is silos. Are teams cross-functional, or are they working in their own domain? For example, if you’re launching a new feature, do people understand that it starts from onboarding, from SEO to onboarding, all the way through to usage? Or are you simply launching a feature for its own sake? If it’s siloed, you have a problem and need a product operating model platform.
And then, are you leading with the customer journey? Like I said earlier, is it growth, retention, and customer journey, or is it feature-driven? A feature factory, like Marty Cagan used to call it. And last but not least, how are you driving innovation? Is it top-down, is it bottom-up, is it cross-functional? Is it problem-focused based on the industry or the customers? It’s all internal—a mix of all is needed.
Key Problem Areas in Product Operations
Hitesh Anand: If you’re using only one or the other, you have a problem. And so, I’ve listed a couple of areas where it’s a key sign, but then I want to bring this back to the industry. Sure, these are key signs. But why is it a problem? When we look at the industry, we found that 30% of product investments actually connect to revenue. That’s a problem. You’re wasting 70% of team capacity on building stuff that is not garnering revenue. Only 23% of companies, based on the survey, told us that they had accurate capacity planning—meaning they’re overcommitted or undercommitted. And so, that’s a problem. Critical resources in the product engineering team are going to waste.
Eighty-seven percent of companies—our product teams—miss delivery regularly. And 70% of companies and product teams cannot plan across the product portfolio because there’s no single source of truth. There are multiple roadmaps: a tech roadmap, a product roadmap, area B roadmap, area C roadmap. And so, that’s how it’s a problem. That’s how you can understand it’s a problem.
Audience Poll and Discussion
Alisa Vaz: So, we have a poll, and we’d like to ask the audience: does your product organization face any of the following? And we just want to give some options. But of course, we think this is likely a variety of experiences, and maybe you’ve seen more than one of these things. So, you’re going to see a poll in just a second. Hit your screen, and it would be lovely to see what the audience here thinks. So, either roadmap delays, team burnout, reactive management, unclear product ROI. It seems like we’re split across the board. Have you experienced these things, Hitesh? Do you want to give us some tips?
Hitesh Anand: Yeah, and I just want to add, right? Roadmap delays are the first one. Most companies look like we were promising to deliver A in this timeframe, but we’re not there. Why? And it leads to—this is actually serial. It leads to teams rushing to get to that objective. And then there’s reactive management. Well, there’s team burnout and reactive management. Let’s move these resources here because we promised, we did this to client A, and we want to release this in R. The reactive management takes over. The reactive management takes over, and then this product ROI is unclear.
And so, these four are the top four problem areas from a board perspective, from an investor perspective, from an ELT perspective. There are others, but these are the top four. And I want to understand, like Alyssa said, how you see this problem in your own product designation.
Alisa Vaz: So, what we’re seeing is that across the board, people—it looks like those are options for everybody, and those are symptoms for everybody that’s struggling with their product operating model. But the roadmap delays seem to be the first, as you mentioned. And of course, roadmapping is something that’s essential to a lot of product teams. But Hitesh, as I imagine you’ll tell us later, sometimes just hitting those roadmap goals is not sufficient, and the product operating model and implementing it is so much more. So, I will stop sharing that. Thank you, everybody, for participating.
Hitesh Anand: So, absolutely, Alisa, you are right. Roadmap—so roadmap, delivering the roadmap is not always the right approach. Delivering the right roadmap for the right values is the right approach. So, that’s why product teams need to start with, are we building the right stuff? Prioritize and build the right products, the right features, the right enhancements. Then make sure the customers have it in their hands at the right time so they can actually get value. Once it is in their hands, make sure they’re able to use it well. And then in the end, capture value. And value capture is both ways—for the customers, the clients, as well as for the company in terms of dollars.
So, let me add some more details here. Providing the right idea means you have to balance things. As any company, you have an existing product. If you’re a startup, then you don’t have product-market fit yet. But you have broad buckets. The first bucket is you’re building new value, new features, new products. The second bucket is you’re fixing things that have already been delivered. The third bucket is foundation. The foundation can be a platform, can be productivity increases, putting a CI/CD platform in place. And the last bucket is the future—things that you want to do in the future. Net new, new geography. You must balance these four appropriately for the right context of your company and the right concept of your product. And make sure that the customer—in the end, it’s about retention, it’s about growth, and it’s about keeping the lights on for them.
Delivery and Adoption Metrics
Hitesh Anand: That’s how you have to prioritize. But you need—you can use Excel. Excel is always great, but then after a while, you’ll get overwhelmed. The second is once you’ve figured out what to build, how to allocate, how much to allocate to these four buckets, what to build, you have to then deliver. You have to deliver it at the right time, in the appropriate chunks. A lot of teams think about delivery in a big bang. That doesn’t always work well. That doesn’t work well in most cases. So, you have to deliver it in chunks. To deliver it in chunks, you need to manage it. You need to appropriately sequence it. You need to figure out the dependencies between different teams, different products. And for that, you need a single source of truth.
The third one is around adoption by users. Like I said earlier, around 70% of products are launched very poorly. They had the right value, but the users don’t see the right value. The GTM team and the product team are disjointed. The marketing team is on its own track. The customer success team doesn’t have the right areas to help the client to be onboarded. So your product operating model needs to think about all of these together. It’s not enough to launch a product, meaning deploy. Launching doesn’t mean deploy. Launching means customers using it, using it incrementally. There was a Facebook metric, I think M7—how many customers, how many users use this product in the first week and then come back. Those are the types of metrics you need to be able to measure. So, you need to have telemetry in the product.
Capturing Value and Iteration
Hitesh Anand: You need to have metrics—what do you want to measure? And then lastly, capture value. So capture value, meaning see the product performance. Is it growing? Is it plateauing? If it’s what cohorts, what type of cost, what type of clients are using it more? Who are the power users? That gives you insight into adjusting the next increment, adding value in area A versus area B, invalidating your original hypothesis, and so on.
So, for all of that, you need an operating model to be functioning well. You can function—you can do that. When I was at Citi around 12 years ago, we had an army of BAs who were doing that. So, you can throw people—you can throw bodies—but then you can instead use a platform such as Dragonboat or others to enable you to do all these things in the right manner.
Signs of Operational Problems and Solutions
Hitesh Anand: So, we discussed the signs that something is wrong. We had delays; we talked about delays. How do you know it’s a delay when you have a buffer roadmap, right? You typically have something that says, “I will deliver this in X weeks,” product adds a buffer, and then sends that to sales.
A single source of truth—there’s no single source of truth, meaning Jira is not a single source of product. It is a single source of product for delivery, but it’s not a single source of product for the product itself. Meaning, where are we allocating? How much are we spending? Is the spend aligned to a metric? When that metric moves, what dollar value will we see? That is a single source of truth. Jira is part of it, Salesforce is part of it, but holistically, as a whole, they don’t match that.
ROI—I keep getting this question on and off. Like, “We spent X million dollars on product and engineering last year. What did we get? All we spent was on bug fixes. All we spent was on migration.” Now, more often than not, there’s an ROI to these two areas as well. You have to be able to explain it. You have to be able to state, “Hey, our strategy is to go upmarket. To go upmarket, we need to be able to service N number of clients on a daily basis. To do that, our current platform does not scale, hence we are migrating our database from A to B, and the ROI for that is incremental market in the upmarket space.” That’s an ROI.
To do that, you need to have a connection from vision to strategy to your plan and delivery. Today, if it doesn’t exist, something is wrong in your operating model.
Intake and Turnover Challenges
Hitesh Anand: Intake—this is the most common area where people fail, in my opinion. Why? Because they think having a backlog is an intake process. Absolutely not. Backlog is simply a tactical approach to intake. Real intake is: how much of that is coming from discovery or talking to clients? Where is the feedback on the product that your CSM team has? Where is that taken to? Is it in its own silo, or does it come back to the product? Are you doing a review every month to prune the feedback tree? That is your intake process. If you’re not doing it, then you have a wrong product operating model.
Turnover—even though it’s the fifth one, I would say it’s one of the highest in my opinion. Without the right people, you cannot build products. So, if you don’t have the right people or you have the right people and they’re getting burned out because they’re being reactive—after launch, you’re facing problems and you’re fixing it. You are prioritizing change on a weekly basis based on what the sales team is saying or what the CEO is saying, what I call the hippo effect (the highest-paid person’s opinion), or you are in this, what some people call the PM hamster wheel, meaning you just hire more PMs to deliver, to get delivery back on track.
But what that does is the more you add people, the more it delays. I think there’s an excellent book that some of you know about, The Mythical Man Month, and one of the values I got from reading that book—and then seeing it in real life—is sometimes less is more. So, it’s about the right people, the right number of people, the right process, the right enabler to get your product operating model in place to get the delivery of the product and the value in time.
Lessons from Experience
Hitesh Anand: I want to take you back—having explained and having told all this to you—back to my own prior life. I started my career as an engineer, then I moved over to the “dark side,” as my engineering friends tell me, to build products. When I started building products, the product operating model was at its infancy. It was about talking to a few customers, getting their insight, building a product, and then taking it from there. Since then, it has evolved tremendously.
But even today, when I look at companies—even my last startup and the companies that we work with at Thomas H. Lee Partners—one of the fundamental things that keeps me coming back is: where are we spending our money? How are we delivering on the promises that we said we would? When will those promises show an impact on the top line or the bottom line? Based on the learnings from those deliveries, what should we do next? That is a fundamental story across my journey of being a product manager and being a CPO at several companies.
One particular example comes to mind. I was looking at a company—they had a great team, a great product line, and a great CPO, but they lacked the process and the rituals. For them, a tool like Dragonboat was helpful in codifying those rituals. They had everything; they just were not working in an optimal way. For some other companies, a tool like Dragonboat will help in putting rituals in place—things like discovery, prioritization, allocation, delivery, and measuring metrics.
This can work both ways. For a company that has the right model of working but cannot scale because they’re either on Excel or manual, Dragonboat—or a tool like it—can help a lot. For a company that doesn’t have that, it gives you the underpinning structure of what to do right. You don’t have to be right in every pillar on day one. You can start by saying, “Hey, you know what? We see that our biggest problem is after launch—clients always come back. We have lots of bugs, which means we’re doing something wrong in discovery. Let’s make sure that is done really well, and Dragonboat or a tool like it can help.”
Key Takeaways
Hitesh Anand: So, to wrap it up: key takeaways. Look for signs that you are either dysfunctional or things are not working. Traditional roadmapping doesn’t cut it—meaning the whole notion of a Gantt chart as a roadmap doesn’t cut it. In the end, it’s about value tied to moving a metric that’s tied to delivering top-line or bottom-line growth. And then, like I said, a single source of truth across delivery, prioritization, allocation, and the outcome metrics itself.
Audience Q&A
Alisa Vaz: Wonderful. Thank you so much, Hitesh, and thanks for sharing your stories with us. It’s always good to see somebody that’s come through it and really has a lot of detailed experience to share.
I want to invite everyone that hasn’t already done so to please submit your questions using the Q&A function. While the audience is submitting their questions, I just want to mention a few words about our sponsor, Dragonboat. Dragonboat is the central hub for your entire product operating model. It enables everyone in your organization—from product leaders to product operations—to align on strategies, evaluate opportunities, and manage trade-offs, all driving maximum business impact. So, do check us out at dragonboat.io. For CPOs, visit dragonboat.io/cpo.
I’d also like to invite you to a free virtual summit hosted by Dragonboat on July 23rd. Join us to hear how leading product organizations accelerate revenue through world-class product execution and get exclusive access to powerful playbooks used by executives at Google, Toyota, US Bank, and others. This is an event designed specifically for product and product ops leaders. You can sign up today by scanning the QR code on the screen or visiting dragonboat.io/accelerate.
Alisa Vaz:: What are some positive signs that you’re running your product model well and that your product operating platform is a success?
Hitesh Anand: That’s a great one. I want to answer this question by saying there is no ideal product operating model. It is always contextual—what works best for you in your current setup. A few good signs are: one, you have a product strategy. Number two, you have defined outcome metrics like growth, usage, and cost. You have real outcome metrics, even though you still may be working in a feature mode like “build feature ABC.” But if you’re tracking outcomes, you have a great product strategy—or at least a product strategy that is not 100% baked but still provides a lens to prioritize. I think that’s a great sign. When prioritization is done with a rubric, even if it’s an imperfect rubric, that’s a great sign that you have a product operating model that is working or is on the path to working better.
Alisa Vaz: Great—adding a quantifiable element to it. Thanks so much. All right, I think at this moment, we don’t have any other questions. So, I will share Hitesh’s info. If you want to get in touch with Hitesh, connect with him on LinkedIn using the information that we’re displaying here. And if you’re curious about Dragonboat as being the platform to manage your entire product operating model, check us out at the link we’ll share in the chat and book a demo today.
Thank you, everybody. Thank you so much, Hitesh, for sharing your knowledge and experience. We look forward to having you again on the CPO Series. And thank you so much to our lovely audience.
Hitesh Anand: Thank you. Thanks, Alisa. Thanks, everybody. Take care. Bye.
