After my best friend had her second child, she said something I'll never forget.
And I have to say...
The episode you're about to hear has a lot of the same energy.
Turns out when a single product organization decides to introduce a second product or third or fourth, all the while protecting everything the first one has already earned.
The complexity doesn't just double, it compounds.
And that's where a lot of product leaders start getting some harsh reality checks.
When to place the bet, where to put the resources and how to know whether you're building towards something transformational or quietly turning away from what's already working.
My guest today is Anika Gupta, Chief Product Officer at Rubrik, where she spent the last five years steering a portfolio that spans data protection, cyber recovery and identity resilience.
Before that, she helped scale LiveRamp from an 11-person startup to a data connectivity powerhouse.
And in this conversation she's sharing the frameworks she actually uses to stack rank products the real cost of starving your core to fund innovation, and the Rubrik acquisition that didn't go as planned, but what it unlocked anyway.
Let's jump in.
Welcome back to the Product Manager Podcast.
I am joined today by Annika Gupta.
She's the CPO of Rubrik.
Thank you so much, Annika, for making some time to talk to us today.
Thanks for having me.
We'll start the way we always started off.
Can you tell us a little bit about your background and how you got to where you are today as the CPO of such a huge company?
I have been Chief Product Officer of Rubrik for coming on five years now.
It's gone by very fast, so I didn't expect time to fly by this quickly.
Before Rubrik, I was at a company in the marketing technology space called LiveRamp for 11 years, from when it was 11-person startup pre-product market fit.
I started as a software engineer, then moved into product management.
And by the time I left, I was leading product engineering, security, as well as customer support.
So it was an incredible journey.
Very different than Rubrik's product, but the through line in all of it is data.
And that has been central to Rubrik's product and our strategy and our portfolio strategy, as well as LiveRamp, in the past.
I'm glad that you touched on portfolio because we're going to be focusing exactly on that today.
Today's episode is going to be focusing on what goes into leading a multi-product portfolio.
It's a topic that we have surprisingly not covered on the show before.
So, to start us off, what makes this specific challenge fundamentally different versus having a single product that the whole company is behind?
And what do you wish more product leaders understood about this challenge?
So I think going from a one product to two product, to three product, it doesn't just get twice as complex or three times as complex.
It actually gets exponentially more complex to execute on a multi-product strategy.
And I think often, when you're going about trying to launch your second product or your third product, you have to come back, as a product leader, to why, as a company, is now the right time to be launching this next product.
And hopefully that reason is something that is quite existential to the future of the company.
Maybe not for this year or next year, but certainly when you're thinking five to 10 years down the line.
I think that's commonly misunderstood.
A lot of companies might try to go multi-product too early by saying, hey look, I feel like there's this big opportunity now and we should do this.
Not really recognizing that that might be very challenging to execute on and what the trade-offs might incur, and whether at that time in the market and the time in the company, is it the right time to actually go on to the next thing.
Of course, choosing what that next thing is, is also equally as challenging and complex.
But I think the really misunderstood piece of it is that you're not just slapping on something onto your portfolio that's going to add two times the complexity.
It can truly be exponential complexity when you talk about how you actually go to market, how do you execute internally and how do you get your message out externally to customers and really sell multiple products at the same?
Yeah, absolutely.
I guess it's almost like a challenge of should we have another child?
Like they're talking about the life cycle of something that's going to be with a company, ideally for the rest of its lifespan.
Just briefly.
I'm just curious because you're framing this as something that could be existential for the company in the future.
What does that kind of evaluation process look like?
Just in brief.
I'm curious, kind of like, what are the kinds of questions that have to kind of come across in order to make a decision of that magnitude?
So I think there's a couple of ways to look at it.
One is more of an inside out perspective of as a company.
Every company is expiring to be a high growth company.
And being able to set the wheels in motion early enough, understanding what is the TAM of your existing product.
How quickly can you really sell it?
How quickly can you continue to scale that?
And when do you actually need to add in another vector of growth in order for you to hit your growth ambitions?
And you have to do that early enough because it takes time for a new product to scale.
Very rarely do you have an overnight success that is going to be of equivalent scale as your core product in one, two or even three years.
So that foundation has to be laid quite early.
There's also an external perspective as well, when you're thinking about well, what does the market look like?
How is the competitive landscape evolving?
You know, in the world of AI of course that's throwing up a lot of questions about creating an existential threat to a lot of businesses if they don't adapt or change or add new product lines in.
That may be another factor that makes you think hey, now is the time that I need to launch my next product.
There's so many fascinating through lines that we could explore with this topic.
So we'll kind of bite things off in smaller pieces, starting with the organizational piece.
So, when you're managing multiple product pillars, how do you think about cross-functional engagement and dedication for each one?
And what does that structure really look like in practice?
I think what's really difficult in a multi-product portfolio especially when you're just starting with your second product, let's say, separate from your core if you don't have someone waking up every single day and thinking about the success of that product, then you're really setting yourself up for failure, because it is very hard to keep two things in your mind at the same time.
Oh, I'm trying to execute on something or I'm trying to scale it out.
I already have product market fit hopefully, and I'm hitting the next set of scaling challenges while also taking something that is completely starting from zero and trying to find early product market fit, taking that from zero to one.
So I think like obviously there is a point in time where you may not have fully committed to saying I want to do a second product, where you probably have people within the organization, maybe within the product team and in the engineering team, who are doing some early proofs of concept explanations.
Exploration, user research that you can do with like some amount of carved out time.
But when you have said hey, I definitely want to go do this.
At least, like in my experience, having a dedicated product person and then having some level of folks around that person whether they're dedicated out of the gate or at least like 50 of their time and energy is going towards this, are focused on this that is what it's going to take to get it off the ground.
And what we've done really well, I think, at Rubrik is often, when we're incubating a new product, we set up dedicated product, we set up dedicated engineering and then we also set up dedicated sales and sales engineering folks that are actually going to go and incubate this product and see where we can take it next to get that zero to one initial product market fit.
And that, I think, is a very powerful combination, especially in B2B enterprise, because often it's not just about building the best technology in order to deliver a solution to the customer.
It's how you sell it.
It's what the value proposition is, the positioning around it that's actually going to help make it successful.
OK, so I'm so glad that you talked about allocating resources and teams, because something I'm very interested in is how do we kind of think about resource allocation when we're talking about?
You know, we have to be early enough on the ball in order to make sure that we are hitting our revenue goals on time.
But that means that we're going to be allocating resources that won't necessarily be profitable for quite some time, while still wanting to make sure that we're taking care of our flagship products.
Thinking about.
You know, Rubrik obviously is a very well-resourced company and we might be talking to folks who are maybe starting on the journey of launching their second product.
Let's say,
How should leaders be thinking about how to break down their resource allocation between the products that are currently making the money and the ones that will be really important for them later?
There's no black and white answer to this.
The way that I think about it and the way that I advise my teams to think about it is for each of our product areas, especially the innovative areas where you're trying to do something new and you're trying to get that second product, find that product market fit.
Knowing what is the hypothesis that you need to go prove out at this point in time and how much of that.
What is the actual product roadmap that needs to be delivered versus the market validation around the messaging and the ICP?
And is this an urgent and important enough problem that people are willing to pay?
Hopefully you've done a bunch of that research before you've started building, but you're still continuing to refine your hypotheses around that.
And so often I think, like you actually don't need a massive number of resources to build the first version of your product in order to really test how big could this be and what's the next step we could take.
And I think that's especially true when you take an approach that hey, often you're.
You may be in a market where you're launching a product, where other companies have products that are solving this problem.
Hopefully you have a very unique and differentiated way just because you're entering.
And this is very true for Rubrik.
Often we're entering in a place where there is some other player in the space doing something similar, whether it's our traditional competitors or a new age competitor.
We have to say well, what is the one killer capability that's in this product that's going to make some percentage of companies want to buy this product?
Because of this one capability.
Even if we don't have all the bells and whistles of everything else, we have one killer capability that's solving a killer use case that no one else does as well as we do.
And if you know the answer to that question, it creates a lot of clarity in terms of what do you actually have to deliver?
To go prove out your hypothesis, to go prove the product market fit, versus saying like hey, I just because my competitor, who has had this product out for five years, and I'm launching a product for the first time, they have 100 features.
I'm only going to have five on the first day.
How am I possibly going to compete?
You actually have a structured way of thinking about it and you have one killer value proposition that you're banking on that you think is going to really make a difference.
And then that gives a lot of clarity to the resource allocation, especially on the product and engineering side.
I'd like to talk a little bit about more like the finance and sales ops as well, when we're planning resources around the portfolio.
So to your point.
You kind of mentioned the phrase banking on.
You know there are a lot of bets that go into developing a product, especially if you're trying to get ahead of the development and where you need to be in the future.
But how do you think about ROI and investment decisions, especially in an environment like we are right now, where you know development and the AI is causing a lot of uncertainty and a lot of instability in the market, where it's really difficult to make some of those long-term planning decisions?
So I think, on a resource allocation and planning, with finance and other functions, that might be part of the process of like helping you decide how many is, what is your total resource bucket and where are you getting additional resources.
It's really important to recognize that resources are fungible.
Now you might talk to an engineering leader and be like hey, don't say that, because resources are not obviously completely fungible from one area to another.
But in a sense, they are quite fungible.
Like how much you decide to put in one area.
You could always decide to shift one or two people to another area.
Now you don't want to be flip-flopping around and pulling people from one team to another very frequently, but you do have the ability to reallocate your existing resources based on what your current strategy, what the state of the market is, etc.
And that's a very powerful tool before you start saying, hey, let's add more resources.
Adding more resources, you know, is asking finance and it's asking the company to really make a bet that this is the right place.
So the first question is like hey, can you actually take your existing resource pool and allocate it better for your current strategic priorities?
And that is a hard decision to make.
It is not easy because it impacts real people.
It impacts real projects.
But when you take a mindset of hey, I can pull a couple from here, a couple from there, especially when you're talking about launching a new product, you don't need 50 people working on it.
You probably can get a lot out of just five people dedicated to this.
And you could pull one from each area and say hey, I'm willing to go slower in this part of my roadmap to accelerate the product discovery for this new area.
So I think that's one very powerful tool.
If you do have to end up going and making a case to the company, then it's really about understanding, first of all, what is the You should go in, knowing whether this is actually going to be something that's approved or not.
How existential is this for the business?
And what is the willingness to invest at this point in time, given the broader context of where your company is at right?
Your company might be private.
You might be hitting the stage where you're about to raise another round.
Well, maybe wait till the next round is raised before you're going and asking.
Or as a public company, it's like we're constantly looking at cash flow and profitability.
And that's something that we have to take into account.
And we're saying like, hey, what are we asking for?
I think, again, you can always start small and build from there.
What always helps is seeing proof points that your product is getting traction.
So maybe you start with five people and then if you start really seeing accelerated traction, then the willingness to invest in those areas is much higher.
So understanding that context and then working with the different partners to justify that.
I think it's a way to move fast without trying to predict out five years in the future what this product could be.
That's a much harder challenge.
And sometimes those are things that you have to do if you're working in hardware, if you're working in Areas.
Like you know, we're working on federal certifications.
Those things take years to pan out.
So you need to do a longer business plan.
But for the vast majority of decisions you can actually make decisions.
You know more micro decisions and realize that they're for a period of time and that you are willing to reevaluate that resource allocation in those decisions after you see how a few different milestones play out.
Yeah, it makes sense.
And I think that flexibility mindset is really important.
I would like to talk a little bit about speaking of decision making frameworks and rubrics that you personally use, especially when making trade offs or making really any major decisions with respect to the product portfolio.
Are there any kind of frameworks that you kind of find yourself kind of coming back to when making decisions that impact more than one product?
So I think one of the hard things about managing a multi-product portfolio is that it's very easy to make a decision to starve the core to pay for innovation.
Or the opposite way starve the innovation so you don't even give it a chance to breathe, to do things where there's like a more sure ROI on them.
And so I think this is like a very common trap to fall into and often in the moment.
You don't know if the decision you're making is actually going to starve the core or feed these other areas.
And one of the things that I really think about is what is the pace for each part of our portfolio?
What is the pace of innovation that we really need at this moment in time in order to ensure that we hit the next stage of what this product needs?
And also in my mind, I truly stack rank the product lines, not in terms of I mean, it's hard to stack rank things in terms of the overall importance to the company, because you can't say like hey, the core is not important at the extent of all of these other things.
But where are the places that there are the most unknown, unknowns that we need to invest more in, because we need to learn quickly so that we can figure out what we don't know and we can keep moving forward.
What are those places and what are those things that like, if we really don't get those things right, we don't figure out those unknown unknowns, that is gonna create a huge amount of risk for the company down the line.
And I think about that and I truly stack rank the products in the portfolio that way.
And that helps me say like, oh, if I could only invest in one area, what is that area going to be?
And then you layer that on with like, how fast do we need to be moving?
And that helps like with really a lot of the decisions, not just resource allocation, but even how do I spend my own time and thought process.
Where do we need to do more product discovery and UX research?
Where does marketing need to lean in more with us so that we can create more campaigns or refine the messaging, things like that.
And of course, we're doing all of these things across the entire portfolio.
But that clarity as a leader, of saying this is the thing that matters most right now, at least for like this quarter, that I think helps, with you know, create a lot of clarity, at least for me, in terms of how to make some decisions and where to surge the time.
I really like this way of thinking of things.
I'm curious whether you're able to provide sort of like an anecdote of this kind of framework in practice.
So if there was a situation maybe in the past that you're at liberty to speak about, when you did have to kind of make an evaluation around you know what are the unknowns, unknowns and like what kind of impact that that might have had, that we're kind of seeing the benefits of that today.
I'll give an example from Rubrik from many years ago.
So when I joined Rubrik, we were really on this journey of reframing the business from being a modern backup and recovery platform to a cyber recovery platform.
And that also meant changing our identity as we're not just like an infrastructure company.
We're a security, cybersecurity company.
And that was a really big bet to make.
But there was a lot of pull we were seeing in the market of organizations using our product to help them recover from ransomware attacks.
And so that was in the state that we were in.
And we had a lot of products around cyber recovery.
Specifically, that was the state that I came in to Rubrik with.
And when I looked at what our team looked like our future it was really interesting because we essentially had almost no one on the product team with any sort of security experience.
They've never built or sold products to a security persona.
We had a lot of people that sold to IT, but we didn't have that.
And one of the things I realized was like hey, we actually really need and I didn't come in with security expertise.
I came in with data expertise, but not security expertise.
I realized hey, we need at least like a product leader who comes from the security background, to help us frame up this strategy.
And I actually searched a lot of my time before even making that decision to say like let me go explore this space.
Like, we'll do conversations with our founders.
Let's go really understand where we want to go in the security space and try to frame a point of.
But I also realized that we were all kind of learning on the fly and we needed some experience in the room to move faster.
So we made a security hire and that really helped us start framing our thinking around where we were going and how did we want to approach this market.
And we made decisions.
We made some bets that didn't pan out the way that we thought.
We built products that didn't get traction.
Lots of learnings from that, but it started us on this journey of learning.
And finally, we did find a product that was really relevant to security personas.
That was very adjacent to what we did.
But it took us, you know, three or four years.
It took us trying and failing and doing you know lots of different things to try to understand this market better.
And understand like where do we fit in?
And you know, at the time it was a bit of a bold move to say hey, we're going to hire this person.
We don't know what exactly like.
We don't have a vision of what exactly this product strategy should be at this point, but we're going to get started.
I can see how that really amplified the efforts.
I'm sure that even just having someone who has that expertise in the room, we can really illuminate the opportunities that you wouldn't otherwise know that you have within reach.
Right.
Yeah.
I like to shift a little bit over to metrics and measurement.
Since we're talking about, we mentioned data, let's talk about data.
So across a portfolio of multiple products naturally, you're going to have products in different stages of their life cycle and success is going to look different for each of them, depending on a number of different factors.
How do you think about what to measure and how to compare performance across the different products in a portfolio, especially when they're in very different stages of development?
It's a lot easier to think about the metrics for your core products and the ones that already have traction.
You're looking at things like you know how much revenue, how much new business are they bringing in?
What does the churn look like on this product?
A lot of those business metrics that at scale, you monitor that.
You predict what it forecasts, what it's going to look like.
You test whether that's actually what happens.
And then you go investigate what's going on to try to fix it.
And so I think those are a lot of the core metrics that we look at for the at-scale businesses.
When you're talking about a really early scale business, what at the very earliest stages?
It's really about how you measure product market fit.
And part of product market fit is certainly.
You can see it in the numbers and you can feel it in the numbers, but a lot of it is actually a feeling.
It's like, Does it really feel like your product has pull?
Is it the thing that everyone wants to talk about?
Is your sales team leaning in?
Like there's so many kind of qualitative ways that you can tell you have product market fit.
And then there's the quantitative ways where you say like, how many customers do you have signed up?
Like how much are you selling this product for?
Are your betas fully subscribed or are you having a hard time recruiting people for betas?
Like there's a lot of things around the numbers of like just the adoption and traction, even deal cycle time that can really help tell you hey, do you have product market fit?
And should I make more investments versus less?
But even like, regardless of where your products are in your portfolio, at the end of the day you choose these metrics.
You forecast out one quarter, two quarters a year.
And very quickly, you see like, are you surpassing your estimates or are you falling short?
And It's kind of a good wave to say like, hey, I have a hypothesis.
Let me see how this actually plays out.
And you're not just in the meantime sitting there like waiting for things to play out.
You're doing everything you can to move those metrics forward and to get the traction and to move the ball forward, like looking at pipeline, looking at the leading indicators that are going to tell you are you actually going to hit these lagging indicators.
Okay, well, thank you for sharing that.
That's very interesting insight into kind of the nuances, because I think many of us are really thinking a lot about the metrics of success for a very specific product or a very limited portfolio.
So I can see where I can get very, like you said, exponentially more complicated.
Taking a little pivot here into moments where decisions have really impacted the company as a whole.
You know, let's think about this in terms of the butterfly effect.
Can you think of a moment where a decision about the portfolio really challenged assumptions or led to a breakthrough, and how Rubrik or even you just have thought about strategy and execution across multiple products?
There are many examples of this, because I think we're constantly learning from what has worked and, more importantly, what hasn't worked.
In the past so we back probably close to three or four years ago now we made a acquisition in the data security posture management space, which is an adjacent space to what we do, but it's still under the larger umbrella of data security.
Data security is a very broad umbrella, so it was in there.
And we had this hypothesis that maybe we could sell this other solution as a standalone solution to security and then pull through our core product.
And, you know, we had a lot of different hypotheses of why we would do this.
And we also felt like the underlying technology was something that was going to be valuable across the portfolio and the team was going to be great.
So we made this acquisition and we tried to go sell the product as a standalone product, separate from our core.
And what we realized was there wasn't really a fast path to selling this as a separate product.
Like it was too far away from the core of what we were doing in a different persona, that it would be too difficult for us to really go and sell the standalone.
And there wasn't it was still very early days for this market.
So people weren't saying, hey, I need to buy this today.
They were like, oh, this is kind of interesting.
And it was somewhat easy to attach it to existing customers because they were more willing to try new things with us, that they already used our product and they already had a contract with us.
So we had a lot of debates around like, okay, do we keep at it?
Do we keep trying to sell this as a standalone solution, or do we integrate it into the platform story and then figure out from there?
How do we take these components and repackage them into the rest of our products?
And we made the decision that we didn't think that there was a path forward to selling a standalone.
But then, as we thought about how do we pull it into the portfolio, there were still a lot of iterations that we had to do to figure out where was the value going to come from.
And I think along the way, what we learned was one is that if we can't provide both visibility and remediation together, then it's not a valuable solution.
So, whatever we're doing, it has to give both visibility and you have to be able to fix the problems that you're seeing.
The other thing that we started to realize was like okay, what?
Who are the person when you say security?
Security is big.
There's a lot of different people that work in a security organization.
How do we think about the personas that within that security organization that we are going to be best solving for, given the products we have and the adjacency like how far away is this from what is the core value proposition?
And so really like that whole experience like really sharpened our thinking as an organization of like how do we think about product adjacencies into completely new personas?
How do we go pursue those?
And what is the level of tieback that we need to the story that we have now?
And fast forward to today.
We launched an identity campaign product around identity resilience and the core of our products around data resilience.
That has really taken off over the past year and has been remarkably successful and has been a bridge into security.
And what we have realized is that that value proposition is so tightly aligned with our core value proposition, but sold to a different persona, that it's way more natural to pull those two together than going like so far outside to another persona.
And we still got a lot of value from the acquisition.
We used a lot of the technology, empowering really interesting use cases for our core products.
But we realized that, hey, that doesn't have legs as a standalone product.
I love this thread of learnings from specific cases because I feel like we get so much value out of really hearing how things have kind of played out in real time.
So kind of following along that thread, I'd love to hear about some Kind of to your point.
Earlier you kind of mentioned sort of like misconceptions about taking bets around new products.
What are some of the other pitfalls or myths or kind of hard learnings that you think are really valuable for leaders who are kind of at the precipice of branching out into a multi product portfolio should hear.
Yeah, so one of the things I mentioned earlier was that it's very easy to make a decision to starve the core, to fund innovation or basically not even give your innovation a chance to try to be successful, because you're funding the core.
And I'll give you an example from my time at LiveRamp.
I think there was a time where we were so pressured to think about new growth avenues because we saw the core growth rate declining, or we needed new innovation and we needed new innovation fast that we put in an inordinate amount of resources in new areas.
And we tried a lot of new areas at the same time.
So I think there was also a learning around focus, but we put a lot of energy into new areas.
And what ended up happening is we actually took our eye off the ball with the core and we started seeing higher churn rates, higher customer dissatisfaction, because Some of the actual work that we needed to do in the core customer experience to make the experience better, more easy to use and to just deliver better outcomes for the customer we started to focus less on that as we were pouring new resources into new verticals or new kinds of solutions that could help prop up growth.
And the real challenge is is that once you start seeing churn in your core, that's like exacerbating the problem, and your new products are just not going to make up for that fast enough.
And so it was a real lesson and like thinking about and being really intentional about how much can you really take away from the core to fund new innovation?
And I think that was like one very valuable lesson of like just not taking your eye off the ball and like keeping control of the core as you're starting to like peel off for the bet.
Another pitfall related to like not investing enough in some of the innovation areas.
When I joined Rubrik, we had a business around protecting Microsoft 365 products.
Or actually, we didn't have a business.
We had zero business, but we had a product and engineering effort.
And we were trying to figure out how to go sell this product.
But we had had a few times where we tried to have the core team sell it.
It wasn't really getting off the ground.
It was one of those products where there were a lot of competitors in the space.
And we didn't have like the laundry list of 1000 features that the other competitors have.
So we were really struggling to get this product off the ground, even though we knew there was a market for it.
And that was a case where, once we got the focused go-to-market product engineering teams together to say hey, you guys are going to go incubate this and go figure it out and getting the right people right.
You need the right DNA of a seller who's going to be willing to say hey, I'm willing to sell like basically a half-baked product, and go to bat for this and iterate on the value proposition and figure out how we can sell this.
But you have to get that right DNA.
But once we got all those people together, we were really able to get it off the ground.
And it wasn't a massive investment.
It was like 10 people, maybe total, across the org that we put and we put the dedication on.
And that allowed us to actually find the product market fit and really see it at scale.
I'm really hearing this kind of trend of the value of having small but dedicated team to really push things forward into the direction that they need it.
And it's really putting it into perspective.
The real resources required.
So this is really interesting to hear.
As we kind of wrap up here, I'm curious about kind of building on the thread that you'd mentioned earlier about anticipating existential threats and often product decisions, kind of coming down to anticipating and being able to react early for that.
What like looking forward, and especially with your knowledge of the market today, are some of the mindsets or kind of muscles that product leaders should be building now in order to kind of make these decisions as far as expanding their operations or whether or not it's a good idea.
Well, I think today specifically, the key skills that a product leader needs is AI proficiency, like using hands-on, using the tools and really understanding the capabilities and the art of the possible with AI, both for how you operate as a business, as well as what it means for your own products and how is it going to radically change the experience, the way that you deliver your products to your customers.
I think it's so important for two reasons.
One.
Obviously that's where the world is moving and all products will eventually be AI native products.
But internally, what is so different about this area is the pace of change is also growing exponentially.
The changes in the market, the expectations around how much you are going to do with how many resources is also drastically changing.
Like a company starting today needs one one hundredth of the resources that a company started even 10 years ago probably needed to get to that, to a certain scale size, product maturity, etc.
So recognizing that that means that you know what is existential for all companies is how quickly can you innovate in a still in a disciplined way, but how quickly can you innovate and deliver and continue to grow your business and the expectations of growth are also changing.
So speed is essential.
It is existential.
And that is what I think every product leader needs to understand.
And we all need to be upskilling ourselves to figure out how do we deliver more with less as quickly as possible.
Anika, this has been such a fascinating conversation.
Thank you so much.
I feel like you've just given us so many valuable insights into the role that you hold.
Where can folks follow your work online to hear more from you?
You can follow me on LinkedIn, Annika Gupta.
Wonderful.
Well, thank you so much for being here.
Thank you.
Oh hey, before you go, make sure to subscribe to hear more great conversations on the Product Manager podcast brought to you by the CPO Club.
