Building Platform Products That Scale: From Chaos to Structure with Aindra Misra

Introduction to Product Management and Aindra’s Journey

Rina Alexin | 00:04.19–00:57.272

Hi everyone. And welcome to Productside stories, the podcast where we reveal the very real and raw lessons learned from product leaders and thinkers all over the world. I’m your host, Rina Alexin, CEO of Productside. And today I’m joined by Aindra Misra, director of product at bill where he leads data platform, AI platform and developer experience initiatives. With the background that spans engineering at Dell to platform leadership roles at Twitter.

or X, and TapJoy, Aindra brings a unique lens to product leadership, blending engineering, and systems thinking with business strategy. Today, we’ll dive into what it takes to build scalable self-service platform and data products that serve multiple personas and organizations. Excited to have you on the pod. Welcome, Aindra.

Aindra Misra | 00:57.272–01:01.042

Thanks, Rina, for having me. I’m really excited about this conversation.

Rina Alexin | 01:01.042–01:40.27

Me too. Honestly, I’ve had other data platform product managers and product leaders on the show. And I always find that it’s the most complex of products, right? Because I like to think there is a hierarchy tends to be B2C, then there’s the B2B, but then platform kind of takes it all because you’re just serving so many different types of personas, markets, so many use cases. So excited to have you on and chat a little bit more about it.

And with that, always like to ask my first question to product leaders is how did you get into product? Let’s hear your story.

Aindra Misra | 01:40.27–04:02.018

Great question and I have a fascinating story about it. So at the time I was building full stack observability product for Dell Technologies in their storage division. And this was back in 2014ish when Dell acquired EMC systems, which EMC corporations, which was a big storage provider in on-prem and cloud.

space and that was the moment where I kind of interacted. had my first interaction with a product manager working on building this joint or collaborative fused product, observability product, both for Dell and EMC systems. So both Dell Storage and EMC at the time of acquisition, post acquisition, they were trying to

understand the lay of the land of their customers. There are a lot of overlapping customers who had storage products in their data centers of Dell and EMC. So this observability product, which we had on both sides, we wanted to combine those. And there were these two software engineering teams working on like kind of having this consolidated observability product.

And there was this one PM just on EMC side. We didn’t have the PM on the Dell side who was trying to do it all. Get the product thinking around this consolidated observability product. Think of this observability product like Datadog at the time for data center storage management where storage admins were our main customers using that. And there were

instances when this PM on the EMC side was asking lot of questions about the Dell side of the things. I was at the time kind of interacting with some of our customers due to the feature I was building on our Dell observability product. That was a lot of, it was a newer feature which had a lot of discovery happening at the time. So I was interacting with a lot of Dell customers.

Aindra Misra | 04:02.018–06:25.87

before the acquisition or at the time of acquisition. So I knew more than some of the other software engineering teams about how a product was actually impacting and what our customers are wanting and things like that. So my manager at the time told me, why don’t you partner with this PM on EMC side and you guys group together on writing requirements and the new vision for this combined observability product. So it was by coincidence when I kind of

got this view of the actual product management side of the house. And when I started talking to this PM and understanding more and more nuances of the PM role, it started opening my eyes that this was something which actually aligns with my interests. Because when I was building softwares and writing code in my black box,

my curiosity about how the product was impacting the customers on the ground or how it falls into the bigger picture of things was not being satisfied. So when I came across this role, I was like, okay, it’s technical enough that it will kind of scratch my curiosity on technical side of things and my skill set and how I’ve been trained academically in computer science.

but also helped me fulfill the curiosity on this macro environment around the product. So this was the time when I decided to make the shift officially into product management role. And I started telling my manager at the time that how can I be an official PM for our team and jointly working with this PM on the EMC side.

So it took some time for me to get there, but slowly and steadily my manager supported me to kind of split my capacity between writing code and doing this PM stuff. And over time, kind of unofficially was doing 80%, 70% of PM role and 30% of software engineering. Officially it didn’t happen.

The Complexity of Platform Products

Aindra Misra | 06:25.87–06:38.314

like till almost till the end when I decided to make a switch but I’m glad that I got to know about the role and was actually doing PM stuff for 70-80%

Rina Alexin | 06:38.314–06:55.146

Great. I’m going to pause this again right now because this is a good time for me to tell you you’re leaning into your mic. So you’re getting the back, but don’t worry. So we’re going to cut this part out. Not the everything you said is fine. We’re to cut this part out. I’m about to ask you the next question. Okay.

Aindra Misra | 06:55.146–06:57.066

OK, sounds good.

Rina Alexin | 06:57.066–08:08.686

You know, I love hearing that story because we like to say since Adele, you said, let me actually start again. One sec.

So Adele, you said that there were no product managers on your side and there was this one person on EMC side. I like that a lot because we often say that even when there are no product managers, there’s someone actually still doing the product management work. And it sounded like that was you. So that’s actually an interesting way to get into product is you’re kind of already doing some of it and you’re curious about those questions, the end user, the customer, and…

And I also like what you said about not being satisfied about some of the, like the outcomes of what was being worked on. So it just sounds like you had like essentially like an intuition almost about product management. And, I really liked that you also were honest about yourself in that you needed a product to work on that also honored your technical background. And so is that what drew you to more platform or data products?

Aindra Misra | 08:08.686–09:41.46

You, you, you spot on Rina. So I did not, I, I, I like coding. I like the technical aspect of software engineering, the problem solving aspects of it, the math behind it. But the, the shield of it that you are only focused on the feature development and the black box of it. That’s what I hated. So I wanted to find a,

role which had a good balance to satisfy my technical thinking and also give me an opportunity to be hands on sometimes, but also give me this visibility into the macro environment around the outcomes and the delivery of the product. So platform product management and something I would call it as is a sweet spot for people who are looking to be

on the technical side, but also act as a bridge towards the business side of the things. So generally, in my experience, I’ve seen people who have analytics or engineering background, they are more set up for success towards platform product management. But I’ve also seen a lot of people who do not have an academic background.

or history of being hands-on programmers or studying computer science, but they’re really good at it. So I feel it’s more like a mindset than the actual training of things. So there are so many tools nowadays that you can learn things. So I think the barrier to entry has become really low.

Rina Alexin | 09:41.46–09:48.126

Well, let’s go.

Rina Alexin | 09:48.126–10:44.262

Well, let’s actually talk about that a little bit, because I kind of mentioned it in our intro that I do view platform product, product, platform products is one of the more complex types of products that somebody can work on. I define the complexity around not just the technical backend, but also just the amount of use cases and personas that you have to just be aware of. And so, you know, I am curious because I’ve talked to

product leaders where more recently I’m starting to hear a trend of them saying, no, I really need somebody who has more of the soft skills of product management because the difficulty is not in the technical part. Like we can always hire for engineers. It’s more about understanding the business strategy and understanding these use cases. Can you maybe help define in your mind what makes somebody truly successful when they’re managing a platform product?

Key Components of Successful Platform Products

Aindra Misra | 10:44.262–13:06.53

Great question, Rina. I get this asked a lot of times from people, from upcoming PMs who want to get into platform product management. And how I would define a platform product is something which is self-serve, use case agnostic, and which is enabling business of feature teams at scale. So these are the three critical components which I feel is very important for

a platform product to be successful. Let me unpack these three components for you. So by self-serve, mean that this platform product team, in my case, it can be developer platform, data platform, AI platform, does not become the bottleneck of enabling these use cases. So to give you an example, we release a…

capability on a platform product. For example, data enrichment framework where feature teams, software engineering teams who are producing these events on their side of the house, they want to use some of the data events which are a part of our data lake and enrich them and combine them and aggregate them so that they can extract more insights.

through their data points. So this self-serve enrichment platform will not be successful if these feature teams have to come in and ask for capacity of data platform team to incorporate their requests or use cases. So we become the bottleneck. So if that happens, you hit a deadlock.

We want to make these platform products as much self-service as possible. We build a path path as for our customers, feature teams in this case, by having a solid documentation, by building automation and kind of telling the story of, like how an iPhone user can come in and use an app without having to give them training. We kind of make, try to make it as self-service as possible with these documentation, videos and automation.

Aindra Misra | 13:06.53–15:29.038

That’s when the actual value at scale of a platform product unlocks. Second component which I mentioned was use case agnostic. What do I mean by that? A challenge with platform products is we start off with something with a particular use case in mind. For example, a particular feature team coming in from growth side of things.

They only care about retention metrics, user metrics coming in from the products, instrumentation coming in, how the user is interacting with the product. So if this platform product is enabling only growth customers or growth events or growth data points, then it defeats the whole purpose. You need to build it agnostic of this use case and make sure that other feature teams

who might have some different data assets, which probably might live in different data sources. So you need to make them as configurable as possible so that multiple use cases can be solved through this platform product. And we are not just solving for this growth team, which might, to give you an example specific, growth team might just have one data source, which events coming in from the product itself.

But another team like a machine learning team can have events coming in from multiple other different sources. So if your platform data product does not have the configuration to incorporate that, those data sources, then it defeats the whole purpose. So it needs to be use case agnostic. You can use this first use case and leverage it as a vehicle to build the first iteration of this platform product, but you should definitely have a vision to take this on to unlock more and more use cases.

Now coming to the third component is enabling business and feature teams at scale. Lot of times there’s a myth with engineering teams on the feature side is if they haven’t worked for a good platform company, they think that these platform products are not prime time ready. They won’t be able to handle scale. They can’t handle a lot of critical business use cases.

Aindra Misra | 15:29.038–16:14.986

These teams are kind of in a biased mindset where they come in only for their quote unquote offline or non-critical use cases. So if you are not building for the future and if you’re not building this platform product to handle scale at a production ready use case for critical use cases, then also it won’t be able to satisfy all these horizontal solutions for the company.

So these are the three critical components which a PM for a platform product needs to start thinking from day one on how he or she takes it to that level where we are building things at scale in a use case agnostic way and a self-service.

Prioritization Strategies for Platform PMs

Rina Alexin | 16:14.986–16:58.286

So, Indra, what you just described, I think if I can kind of boil it down to one word, it’s like ultimate flexibility, right? Because we’re talking about, it has to be irrelevant, like who’s gonna be using it, making sure that they’re able to use it themselves for whatever purpose that they need it for, and to make sure it’s production ready, especially when you’re building for enterprise. Now, that…

leads me to think, okay, this is what also makes it super challenging because you have so many different components to kind of think about. How do you even prioritize what to do first or what to do even next after you’ve done the first thing?

Aindra Misra | 16:58.286–19:23.166

Great question, Rina. So actually, in my day to day, I was facing a lot of challenges on balancing prioritization coming in from these different feature teams with their use cases. They were fighting amongst themselves, my use cases, my impact is more important than the other, please prioritize. And we were in the journey of maturing this platform, which was not mature enough to be self-serve and use case agnostic, to be honest.

How I kind of approach this problem was I built a matrix for myself where I had two different buckets. The first bucket was use case specific, business specific. And the second bucket was platform specific bucket. And how these weights and threshold and the things which are contributing and helping me prioritize for these two buckets.

were kind of basic PM101 things. Let me list them out for you. The first one was business impact. Dollar money saved, user acquisition, fraud savings, et cetera, et cetera. Second bucket was level of effort, which the engineering teams tell. How difficult this is to enable this use case.

or ask. The third one is strategic coefficient. So how I define strategic coefficient is how much it contributes to our long term platform thinking that will enable a very complex use case for this particular platform product. Maybe that use case is not there currently, but it can come in. So this is where you need to be very creative in thinking in your business context that

What is the most complex use case where this platform product can solve for your company, for your enterprise? And this strategic coefficient, need to start from there, not start, and then use this kind of metric to understand the weightage of how much of this use case is contributing towards your strategic coefficient. The other contributing factors to the strategic coefficient can also be

Aindra Misra | 19:23.166–21:25.258

exact level, C level priorities for the company that can contribute to this. So this is the third weightage matrix where which helped me in prioritization. And the fourth one is something around the complexity of the use case, which kind of ties in slightly with the strategic coefficient, but there might be used like scenarios where it definitely requires a separate bucket for it.

What do I mean by complexity? For to unpacking complexity, I feel that having a target state architecture of this Northstar platform product and what components it needs to build that platform product and what is the coverage of that. So to give you an example, if you are building an AI platform that requires vector databases, graph databases,

an online analytics database, and bunch of other complicated data structures to enable these AI use cases, agentic use cases. This is the ideal North Star metric for me. Now, how much of this use case is doing in terms of coverage and complexity of this ideal tech stack is what defines the complexity of this use case. Now, having these four factors,

I’ll re-state them for you. Business impact, level of effort, strategic coefficient, and the complexity of use case. Using these, I prioritize these into use case, specific priority, and the platform specific priority. And the weightage of these, for these different four factors, there’s a matrix for it, use case, platform, and these four horizontal components to it.

For the platform side, the complexity and the strategic coefficient is highly ran. And for use case specific, the level of impact and the level of effort is more higher than now having a balanced matrix for kind of having a mix of these use case business impact capabilities versus these platform capabilities is where you need to land with a sweet spot. And that is my final roadmap for a platform.

Stakeholder Management and Communication

Rina Alexin | 21:25.258–21:49.784

Hmm.

Aindra Misra | 21:49.784–21:55.956

So building this helped me solve my day-to-day challenge with these businesses.

Rina Alexin | 21:55.956–22:37.07

So the way that you’re describing it, I’m getting to know you a little bit better. It really does marry a lot of the strategic and also the technical because you just broke down some of the more, I would say, softer components like strategic coefficient into something that you can make a little bit more tangible. There’s still, I’m sure, objective or sorry, subjective measurements that you’re having to make as a product leader with or even a product manager in some cases.

with some of these coefficients of what do you weigh, but at the very least you have like a structured way to approach it that helps you also not just make the decision, but back it up, right? Yeah.

Aindra Misra | 22:37.07–23:03.636

100%. That’s very critical for platform products because you have multiple stakeholders who are there to question your decision because they feel that their use case is much more important than the other. So unless you have a transparent in a structured way of backing your decision, it becomes really, really hard. And this is one of the soft skills that is very important for a platform PM.

Rina Alexin | 23:03.636–23:30.158

Well, let’s actually talk about that in terms of stakeholders. So you have obviously a variety of different personas that you serve, but you also have the internal stakeholders. let’s, I mean, do you have any just ways in which outside of this structured approach of here’s how I’m making the decision, how do you approach these kinds of discussions? How do you communicate trade-offs to stakeholders?

Aindra Misra | 23:30.158–25:32.322

I have a two pronged approach which I generally try to follow and sometimes there are cases where we have to make exceptions for certain decisions. whenever I start my role as a PM for a platform team, I first and foremost start building my relationship with my stakeholders.

Who are the consumers? What are their pain points? What are the jobs to be done there trying to achieve? And what do they want from us? How can we unlock value from them? I capture all this information, take this opportunity to build a connection with them, get to know them, get to know their teams and what they’re trying to solve for the business. The second step is trying to get a deeper vision into their roadmap.

on why they are doing it, what is the impact of it to the business? How does it tie into the company priorities? So these questions, I try to make my stakeholders more accountable. And when they come to me for a request or for a roadmap item which they want our teams to solve for, I ask them for three things. What is the impact of this product?

which you want us to deliver. How does it tie into the company priorities? And what are the timeline expectations and why? Once I get this information from them, I try to consume it and compare it with the other stakeholders. And this is where things start getting a little bit messy and gray area start coming in. But how I’ve tackled this

Once I have all this information, I’ll come up with my proposed priority for these different stakeholders and kind of try to tie into my platform vision of that product.

Aindra Misra | 25:32.322–26:09.13

Then I align, then I get all these stakeholders who have these competing expectations in one room. And I get them together, I propose my plan to them, and then I open up the floor and tell them, now it’s your opportunity to challenge my plan, make your pitch if you want me to adjust the priorities and fight it out. Everybody’s here, fight it out and we are the consumers.

or the platform team who will kind of reprioritize these things based on the input received here.

Rina Alexin | 26:09.13–26:39.505

So how does that actually work for you? Because one, I agree with a lot of what you just said in the sense of you have to have a where, let me put it this way, where product managers sometimes struggle in working with or collaborating with their stakeholders. I feel like there is room for product managers to also educate their stakeholders on how to work together. So what you’re describing in terms of like, here are the things that are gonna be really important for me to make a decision on whether or not we can actually help.

So you’re training them on how to work better together and you’re making it consistent with your stakeholders. I love bringing them into a room together, but the way that you described it, I’m like, here, battle it out. It seems very unstructured. How has that actually worked out in practice?

Aindra Misra | 26:39.505–26:56.088

Yep.

Horizontal Thinking in Product Management

Aindra Misra | 26:56.088–27:55.7

Yeah, it depends on the maturity of the organization. Sometimes teams are very data oriented and they actually come to these meetings with very solid arguments. But I’ve seen some teams who do not have that data and they are on the back foot during these meetings. However, their use case might be important and then they can come back to me.

after seeing that, the other team was very competitive with their data. So then they go back and re kind of, re-prepare their pitch and come back again. So that has happened, where, they are not able to defend themselves as much as, they would have liked to, or, the criticality of their use cases. But I think this also helps them, become better as a team and accountability wise to

kind of portray or pitch or defend their requests. It used to…

Rina Alexin | 27:55.7–28:21.73

So it sounds like the stakeholders are almost learning as part of your process, but to that point, you really do need to have just a more mature team ready to go and defend their ideas. Is this something that you’ve installed new at organizations? Like how does a first meeting go?

Aindra Misra | 28:21.73–30:44.384

Yeah. So great question. So this idea actually came in from when I was working at Twitter. The teams there were very, very mature with their products and data-driven approach of their leaders, both on engineering and Productside. And when I started there and I was building some of the data platform for ads teams, growth team, personalization team, they were very, very

passionate about their products and they actually got into very healthy discussions and arguments of backing their kind of pitch and tying up with their top level company roadmap. this was a learning which I got at Twitter, which I have tried to carry out to the other organizations in my career, which I feel is very, very crucial for enterprise companies.

So yes, and obviously it doesn’t go well in all situations. I would be naive to say that every situation this has worked out very well, but it’s a learning curve. Sometimes the stakeholders are not happy about it. They said that we don’t have their context. I don’t know what they were talking about. It was a waste of time for me. I knew my stuff, but.

I did not know about their words, so how can I counter their argument? So things along those lines did come up in lot of those meetings. But I feel the intent of this, when I clarified it at the beginning of the meeting, and I did not actually have them together in one room right off without giving some context. I started this off with an async conversation on a Slack channel.

teams, whatever the companies use. So start off there, give them a context of what I’m looking for, what my intent is as a platform PM for this product, and then slowly make them ease into this setting where they are in a common sync environment in a meeting and kind of giving them a sneak peek beforehand. So it’s a learning curve with meetings over meetings over quarters. I think it has improved.

Aindra Misra | 30:44.384–30:57.416

in my experience on a lot of immature teams who are not in a habit of kind of defending or pitching their use cases or requests. But I feel it’s important.

Rina Alexin | 30:57.416–31:46.072

Yeah. So you said something here, which makes me feel a little bit less anxious about your process is that you’re actually, you know, giving context around the other potential other things that are on the table. You’re providing maybe a pre read or at least a, you know, a sync pre the meeting. Because with these meetings, especially because when you have a lot of, in some cases, I will call them characters, you know, loud voices in the room versus the soft voices and

There’s a lot of different dynamics that can happen. You want to, as a product manager, limit the amount of total surprises that people are reacting to because that doesn’t necessarily give enough space for true collaboration and understanding. So one, I’ll commend you that you do a lot of the good practices. It’s not just like here, come into the room and it’s Thunderdome or something.

Aindra Misra | 31:46.072–31:54.378

Yeah.

Rina Alexin | 31:54.378–32:01.07

If you were, actually let me ask this question first, like how frequently do these meetings happen?

Aindra Misra | 32:01.07–32:16.948

Yeah, I would say once a quarter when you are doing a roadmap planning and it depends on the cycle of how quickly teams are iterating and shipping solutions. But I think once a quarter is a good cadence.

Avoiding Common Pitfalls in Platform Products

Rina Alexin | 32:16.948–33:37.39

Yeah, I will say that when we obviously depends on the product organization, the maturity. When we do something similar with, some of our clients where we start getting them talking to each other for some of the times the first time we encourage more of a much more frequent meeting because you need to get that learning curve, right? Like once a quarter might not be sufficient to have all the leaders on a appropriate learning curve.

Um, so sometimes we carry it out, uh, every two weeks and see it just, obviously it depends. Uh, but I want to kind of bring it back right now. This conversation, this was very interesting, but I want to bring it back because, uh, at the start of our conversation, we talked about, well, what makes for a really good platform product manager? Like what kind of mindsets are really important. And, um, when we were talking earlier, you had actually mentioned something I want to bring up, which is, uh, the concept of horizontal thinking.

Because I think what you’ve been describing, like the matrixed approach, the various users, the various stakeholders, where I hope our listeners here, we’re underscoring the complexity here. So maybe you can go into a little bit about how horizontal thinking can help a product manager in this space.

Aindra Misra | 33:37.39–34:19.38

So by horizontal thinking and I touched upon this earlier in some of my thoughts about the platform product as a whole. How I think about horizontal thinking is to have a North Star vision of your platform product can actually enable different feature teams across the organization.

who are trying to leverage data in my case to unlock value for their customers.

Aindra Misra | 34:19.38–35:20.312

One way to approach horizontal thinking is to start off with one use case where you have a starting point of this first iteration of a platform product and use that as a vehicle to kind of evangelize the value of your platform product and having a North Star ideal state of your platform product.

which comes back to the vision of where you want it to be in the most complex scenario out there. Now, filling this gap between the first use case which you’re using as a vehicle to build this first iteration of your platform product to the Northstar of the most complex use case or scenario, how do you get into these stairs to reach that Northstar?

That is the part where this prioritization matrix comes into place.

Aindra Misra | 35:20.312–36:02.506

What I’ve seen in my experience is a lot of times when platform PMs are trying to climb these quote unquote stairs to get to their North Star, they are cutting corners along the way to do these one-off solutions which are only relevant for that use case which they are solving for. And when you start into this repeat habit of cutting corners and solving for one-off things,

That’s when you start creating an ocean of tech debt which becomes very very expensive to migrate off of.

Aindra Misra | 36:02.506–37:44.084

I’m okay to have a purposeful tech debt where you need to unlock for faster go to market for these use cases. But you need to have this documented in your platform vision or strategy where you are taking on this purposeful tech debt to unlock this use case to meet the timeline expectations. But here’s the plan on how to migrate it and kind of converge it to the

paved path for the platform North Star Vision.

So the horizontal thinking comes into place where you are marrying these vertical use cases to this horizontal Northstar platform vision of your product.

And once you are on this path, you might divert somewhat to more vertical in some quarters, but you need to have a documented vision where you know where it converges back to that platform horizontal thinking. So it’s like a XY coordinate graph where you are trying to stay on a kind of a diagonal path and not getting too much into the platform side, but also not going too vertical.

If you’re going too much on the horizontal side, then you are just saying to your management and use cases that, hey, no, you have to wait for one year before we build this ideal state. Real world doesn’t work like that. You need to unlock these value added capabilities and quick wins along the way, but also not create this plethora of these tech debt.

Advice for Aspiring Platform Product Managers

Rina Alexin | 37:44.084–38:55.522

So I think what I’ve heard from different types of platform product leaders as well is you cannot underestimate how painful it is to migrate afterwards. I’ve seen even CEOs struggle with this where they’ve built a platform product and they haven’t paid down their tech debt and they created a lot of it where it took them, I think in one case that I’m thinking about two years to complete, and that’s two years of lost innovation time too.

I like your idea about thinking through the tech debt and having a plan, though I will, part of me also thinks, okay, yes, you might have a plan, you might have a document and then nobody’s going to pay it down anyway. Right? Like they might ignore it. But is there anything else maybe from just your experience to share about other, like outside of just, let’s not create too much tech debt. Is there any other failures or anything that you can draw on?

to kind of help product managers think through what to potentially avoid such that their platform products scale.

Aindra Misra | 38:55.522–40:07.714

There are a bunch of capabilities in your platform product, which kind of are table stakes nowadays for prime time critical use cases. But they take a backseat for platform products because every time PMs things about, for example, data quality in my case.

observability in my case, right? And it can be true for a lot of other use cases. Observability is very common. SLAs, right? How are you stress testing it? How are you integration testing it? So having that handshake with your feature teams about these horizontal table stake capabilities that will actually make your platform product prime time ready.

is you need to start from day one. If you don’t have a plan and you think, hey, it’s for future phases, it’s like down the road, we don’t need to think about data quality or observability now, we are still very mature.

Aindra Misra | 40:07.714–41:37.652

the solution which you are building will tend to not have these thinking around these good practices or best practices. It’s not infused as part of the roadmap because you’re not thinking about it. So then you are on a path where you will have to pivot altogether when you are too far on that road. So I’ve seen in my experience that we’ve

just focused on these capabilities, let’s continue building, let’s continue bringing value. And then data quality wasn’t thought through from day one. And then when we were kind of in prime time ready and we were like, yeah, let’s do it. Our data was not trustworthy enough to unlock those use cases. And then we had to kind of bring in and pivot that one quarter was only focused for kind of actually cleaning up our data.

So if you don’t have that from day one, you’re not unlocking value and all this time you spent on building capabilities, it’s on hold now. So thinking about these horizontal or table stake best practices, which your platform product should have to be prime time ready is very critical to be thought through from day one. Even if you’re not working on it in day one, at least you should have it in your plan.

for day two or future iteration.

Rina Alexin | 41:37.652–42:05.25

So we’ve talked a lot and I feel like, again, in my mind, the word flexibility, it keeps coming up as being super important and predictability. It’s like you almost have to just always be thinking long-term of the downstream implications of your decision.

Aindra Misra | 42:05.25–42:12.777

Think I lost your audio.

Rina Alexin | 42:12.777–42:15.018

now? Can you hear me now?

Aindra Misra | 42:15.018–42:16.757

Yeah, I can hear you now.

Rina Alexin | 42:16.757–42:21.902

Thank you. My mic is very sensitive sometimes, so don’t worry. I’m going to redo it. And then we’re going to, I’m basically about to ask you the advice question because we need to wrap up.

Aindra Misra | 42:21.902–42:30.985

Yeah. Yeah.

Rina Alexin | 42:30.985–42:48.75

So if there’s something that comes to mind from this conversation, it’s one, I said it before, it’s the flexibility, like the importance of flexibility. And then the second is it just feels like you’re always thinking about the long-term, the downstream implications of your decisions today. So given how, again, flexible, predictive, complex data or platform products truly are.

Aindra Misra | 42:48.75–42:57.749

Give it.

Rina Alexin | 42:57.749–43:05.1

What advice do you have to share to a product manager who’s really interested in the space?

Aindra Misra | 43:05.1–44:15.32

I would have two advice. One is on the soft skill side and the other is on the hard skill side. On soft skill side, would say treat your stakeholders as a gold mine where they have plethora of information. Try to extract them as much as you can to understand their side of the world. So build a relationship with them where they feel

comfortable and trustworthy sharing their roadmap with you, their day-to-day with you and finding time to actually educate you about their products. This will help you think through the long-term capabilities which your platform Northstar would look like. So building this relationship with your stakeholders and thinking them as your day-to-day partners and not as like once in a while,

collaborators where you’re just going to them and asking for their request is very, critical as a soft skill for platform PM. Second, on the hard skill side, I would say.

Aindra Misra | 44:15.32–45:41.345

Try to create this structure in this, and you touched upon this on being flexible and complexity. Try to create a structure through processes and kind of way of operating with your engineering team, your stakeholders and your business leaders where you are trying to control this chaos around you.

I call this whole platform PM as a control chaos because there are so many moving parts and things happening in your world which will kind of push you to pivot sometimes or you need to kind of hold the fort. So you need to have a directionally outcome driven way of functioning or a process where you are trying to menu where you can maneuver through these different moving parts in your world.

So having this structure in your day-to-day would actually make this easier walk for you to manage expectations from all sides of the house. And also making this process and structure transparent with your engineering stakeholders, your business stakeholders, your upper management, and your customers will make it really, really easy for you to build these quote unquote platform products.

Rina Alexin | 45:41.345–46:08.11

So if I were to paraphrase that, would say, save this podcast episode for if you want to transition into platform products, because I think we really did just spend a lot of time talking about how do you structure your thinking, how do you create product process, and how do you work with your stakeholders? So wonderful to have you. How can our listeners follow you or your work after they’ve heard this recording?

Aindra Misra | 46:08.11–46:45.589

Thanks, Rina. Really great conversations. I love talking to you. Awesome questions. Your listeners can follow me on LinkedIn. They can search my first and last name and I’ll pop right up. And I’m also active on X. I share and retweet a lot of PM resources and good people to follow who sharing about platform, AI in general.

PM resources. So feel free to follow me on X and LinkedIn. And my handle is my first name and last name.

Rina Alexin | 46:45.589–46:45.589

Wonderful. Thank you so much, Andrea. Really glad to have you here today. And for you tuning in, if you found our conversation valuable, please don’t keep it to yourself. Share it with a friend and make sure to subscribe to Productside Stories so you don’t miss another episode. And thank you for tuning in. I hope today’s insights inspire you and propel your product journey forward.

Remember, every challenge is just a lesson waiting to be learned and you can visit us at Productside.com for more free resources, including webinars, templates, playbooks, and other product wisdom repackaged for you. I’m Rina Alexin and until next time, keep innovating, keep leading, and keep creating stories worth sharing.