EP 157 - Platform PM with Ashana Singhania

Narrator: M hello product people. Welcome to the Product for Product podcast hosted by Matt Green, data advocate and product manager, and Musha Mikanovsky, product leader and author. Our goal is to serve the product community by helping you find products that can help make your work in product management easier. Thanks for joining us on another episode of the Product for Product podcast.

Matt Green: Welcome back everyone. On today's episode, Mishae and I are excited to speak with product leader Ashana Singhanya about products for platform managers. So let's dive in. Welcome to the show.

Ashana Singhania: Thank you. Thanks Matt. Hey Moshe. So nice to be on the show with you guys.

Matt Green: It's a pleasure to have you. Hey Mishay.

Moshe Mikanovsky: Hey Matt. Hey Ashana. Thank you for joining us. Um, this is a topic, ah, that we might have touched on in the past, but ah, I'm really glad that you pitched it to us to see. Let's talk about that. Because I worked in the past with some platform, um, teams and uh, they had a product manager but that was my first position in product so I cared more about what I have to learn. So I don't think I've learned a lot from that. But uh, it's definitely an interesting one.

Matt Green: Yeah, myself, yeah, I worked with platform managers in the past and really excited to hear about your work. Internally keeping things up and running, but also externally how you work with external customers and stuff.

Ashana Singhania: Yeah, yeah, yeah, for sure, for sure. Uh, and I'm very excited about the topic.

Moshe Mikanovsky: Amazing. Uh, before we dive into it, because I think the first thing really we will have to do is to define what platform means because it's also a loaded term.

Matt Green: Yeah.

Moshe Mikanovsky: Before that, tell us about yourself. Uh, who is Asha and how did you get to product and to what you're doing today?

Ashana Singhania: I have been in product management since last 10 years, all my career in financial services and product management. I was with American Express for eight and a half years. Since last two years I've with Goldman Sachs. Uh, I worked on a variety of different products. Uh, during my tenure across multiple teams I've worked on servicing, onboarding, risk products, uh, lending, banking, you name it and I worked on it. From a finance perspective, my career has been a half and half where half of my career in different teams have worked on consumer products such as your credit cards, payments and other half has been on building large infrastructure platforms that scale across multiple different markets, multiple different product types. And that is why I was able to really hone in and understand the nuance between how consumer products and platform products differ from each other and how a uh, product Manager's role really is defined by the nature of the product that you're working on.

Matt Green: Both of those hemispheres, especially in financial services, is so important because they're so interconnected.

Ashana Singhania: Yeah, well, to your point, it's uh, a loaded term. If you guys are okay, I'd love to take a second to just, uh, dissect and explain how these two terms vary.

Moshe Mikanovsky: Absolutely. If you wouldn't have said it, I would have asked you.

Ashana Singhania: Okay, amazing. Well, to very clearly lay it out, a consumer product is what the user directly interacts with. Users like myself and you, for example, uh, we might want to get a credit card, we might want to sign up for a business account or a checking account. Those products that we directly interact with and use become consumer products. That is where as a product manager I'm really focused on the whole experience, how simple the onboarding experience is, how fast it moves, how the user gets approved, whether they get approved. That those are my guardrails which focus on one single product. But when I talk about a platform, the platform is what actually makes these products work behind these single user consumer products. How the flow works, how the platform is handling things like identity verification, decisioning, risk data, financial, uh, data collection, how these approvals even happen. The platform is an infrastructural layer which connects to a lot of these different backend systems. So the key is that the capabilities don't behave the same way across all of these different products. Taking maybe a real life example, a credit card application might get approved instantly, but a business account might require additional documentation from users. These nuances vary by each product. They also vary by each region. For example, the European region may have more regulations than us. Um, there might be some users which might be higher risk and we may require additional details. So the nuances also vary by user segment types. All of these different nuances are managed by the platform, which is the infrastructure layer for all of these different products when they come together. So it's the same underlying capability, but the behavior varies by the product type, by the geography, by user type and multiple other different nuances that might be there. So for me, uh, basically platform products are what ensure that a set of consumer product behaves in a coherent system. Even when we scale across these different nuances, these different geographies and regions.

Matt Green: Mhm.

Moshe Mikanovsky: So if we're thinking about it, the consumer products are more of the front end and interaction user, um, even though they probably have their own backends as well, uh, that might be unique specifically for them. And the platforms are More of a backend, uh, that handles a layer, um, for all the different um, consumer uh, products. Right.

Ashana Singhania: Imagine, imagine a banking website, right? You're a banking customer, you go to a banking website. The banking website is a user interface which is a platform. But on that website you may be able to service your credit card, you may be able to service your um, checking accounts, you may be able to service your demand deposits, right, uh, your IRAs. So those individual things become products. But it's one single website, it's one single user experience, right?

Matt Green: And so, so the, that infrastructure layer has to accommodate for each of each new product line. So obviously with a lot of banking and financial services you have a lot of different revenue streams and a lot of different product lines. So you have to accommodate for that at uh, each individual level. At the infrastructure layer as a platform

Ashana Singhania: PM, I am the horizontal layer and these products are the vertical lines which touch the horizontal layer every single time.

Matt Green: I love analogies. So I'm like thinking of a plate and a plate has different foods on it and how it's all structured and the plate can, you know, the plate's got to be dynamic to what you're serving.

Ashana Singhania: Basically we are talking about the plates of the world today.

Matt Green: Yes. Awesome. Yeah, Very, very good.

Moshe Mikanovsky: Now there are platforms, we know that there are some, uh, companies that create their platforms that are externally consumed by third party, um, products. In the case of banks, I'm sure that it's more internally consuming by all of those different products that the bank is developing. Is that an accurate position there of banking? I never worked for a bank, so yeah, I'm just kind of thinking about my experience parallel from other places where I worked that were a bit similar to that, like a loyalty program system that had a layer, a platform layer that supported what we did very well and then different interfaces for each one of our partners that would integrate with us Financial services.

Ashana Singhania: Gets very interesting in that sense. So let me maybe break it down to you by user types and their internal and external. And I've worked on these for these variety of different user segments. And that's how it, how you get feedback and how you build things, how you improve on things really varies depending uh, on who you're building for. For example, my very first role, uh, within product was to build one single servicing platform that would service credit card customers across the globe. The scope was 20 international markets and United States. What happened uh, in that particular role is we had these disintegrated legacy systems. They were around 17 to 18 different platforms. Per market that were being used. And the goal was to decommission all of that so that we were able to save cost, we're uh, able to save the huge license fee we were paying to outside agencies to keep those platforms running. And we built something in house which was more secure, more authenticated. Now apparently who is using this platform? This is not something which was displayed to the core customer, the credit card user. This is something that was used by internal servicing teams, internal sales team teams to service these customers so that we can save cost, we can make our customer service more efficient, we can increase, uh, we can decrease our time to revenue because faster you serve the customers, faster they're able to use the products. Right. Um, so that is the internal population that you build for, you could build for bankers, you could build for risk teams, you can build for any team. Right? And then there are platforms that you build for external facing population. For example, uh, I built an onboarding platform for clients for Fortune 500 companies so that clients can onboard themselves using the platform instead of using paper forms, instead of using PDFs. Right. So that is something which is directly visible to these customers externally. But at the same time, because we sit in finance, it's heavily regulated, uh, it's very heavily guarded by compliance. You have to be very mindful about every single word that you display to the external internal population and how you turn these things, how you manage these journey. Well, you're explaining why you're collecting this data from your customers. So that, that is the bifurcation based on the customer population between internal and external. To your point, in financial services we try to make things in house as much as possible. Right? Because we want to keep the data secure. It's um, financial services, it's heavily regulated. We want to make sure that the authentication is right. We're not sharing that data externally with other users. But I've also been in situations where um, the entire banking experience of one of my companies was outsourced to another company. And eventually my job in that role was to decommission uh, that outsourced experience and bring it in house so that the customers don't have to step out to a different website to use credit cards and a different website to use their banking account. They can just step into one single website, log in and use all, any product that they've signed up for. So there can be different situations based on why these institutions take the decision to do something in house versus to outsource something. But I think at the same time it is Also what I've realized in financial institutions, large banks, the technology is still works on a legacy stack. So I think we are getting to a point where we are building cloud based solutions, we're building more agile solutions and we're, we're now not working in silos, but we are building once for many and we're thinking about scalable systems.

Matt Green: Yeah, yeah, that's great. Something I'm really interested in is embedded finance. And so taking it almost a step further, something like Stripe, which is API driven, uh, platform. So it's almost like another layer to that cake where you have a very large surface area as a platform pm where you're serving internal users, external users, but also you're taking it up another level where you're embedding yourself into other people's workflow. I think that's like really the future. You want to get to a workflow that someone's using you, but you have to maintain that and you have to service that.

Ashana Singhania: Right, right.

Moshe Mikanovsky: So now that we have the understanding of what is a platform, uh, let's move now into what does a product manager that is building platform, um, need to know about that is a bit different uh, than other type of product. And then after that we can also talk about what tools they can use to help them with that.

Ashana Singhania: Yeah, yeah, for sure. Um, I think, uh, since my very first start was a platform role and then I transitioned into consumer products, I had my baseline right. I was already building once. For many I was already building large scale systems and then it was easier to transition into building a very focused, singular consumer product. But if somebody is doing it the other way around, I think that might be a little more challenging and you might need to think through the nuances a little more. I think the biggest shift is you're no longer making decisions for just one experience. You have to take a step back and you have to think through multiple different use cases and multiple different product lines. You need to make sure that you know stakeholders who your platform impacts and you have them on board from the very start as you're making decisions. Those would be some of the most crucial things to ensure as you start on the road. But also talking about it, about how the world differs for a product manager, for a single product, for a consumer product, if you change something, you see the impact right there. But in a platform context, the same capability shows up across different products and it's not always the same requirements. For example, let's take something very basic like user login for one product. We might allow Users to log in with just their credentials. But another product might be more restrictive, more regulated, for which we may need an in platform step up OTP authentication for the users. Right. Because of regulatory requirements or because of risk requirements. Now, both of these situations are correct, but ultimately the user is using one single website and we are displaying two different experiences. So I think it is very important to handle it right, to message it right, to tell the users at every step. Why have we added a difference in experience as we. Even if you're on the same website. So our job as platform PM shifts. We're not just deciding what works for one particular product or one particular flow, but we are deciding how that capability should behave across so many different conditions. It also changes. Yeah, go ahead. Sorry. It also changes for me how I prioritize. A lot of the time the issue is not that something is broken. It is also that it works slightly different. Depending on where I am, which region I'm probably, um, servicing which customers I'm building for and fixing the inconsistency can have a bigger impact than adding just something new. I might think that the solution works absolutely well for this particular product line, but it might just create an edge case for a third product, which I'm not even thinking about. So I think it's very important to wear multiple hats, to be very aware of every single thing that you're touching, anything that you're changing. Aligning with stakeholders early on, um, that becomes a major part. Also, one thing I've realized in platform roles, um, that compliance, risk, privacy, all of these teams cannot be an afterthought. They become your design partners. You engage them early on, um, even before you start scoping your requirements, before you start going through the designs, you make sure that these teams are on board and they're reviewing every single thing so that they can guide you. And as a PM, you're more confident on what you're building.

Matt Green: As all PMs know, alignment is one of the hardest things, you know, you encounter. So I can see as a platform pm, you know, you have a large surface area and you have a lot of different, um, owners of product lines. So is there like tools or ways or frameworks that you use as a platform PM to help wrangle all them, uh, into a spot and make sure everybody's lined up?

Ashana Singhania: Yeah, I think one of the things I found which is very, um, funny between these two products is, um, sort of products is the tools that we use are largely the same. It's essentially the same tools. But we ask different questions. We bring up different nuances. For example, um, most product management tools you would see are designed for clean, linear products. But platform work like we've been discussing is not very clean, it's not very linear, it gets messy. With so many different cooks in the kitchen, so many different product lines, you have to be very intentional in how you use these products. You cannot just use them for their face value. For example, let's take something very basic like roadmaps. Tools like Product Board or Jira, uh, they push you towards one feature, one timeline. But something like onboarding or payments, which is so massive, which touches so many different vertical product layers, doesn't behave the same way everywhere. It varies by the vertical product line, it varies by the geography, by the risk level, uh, the state of the user, whether they're active, they're still onboarding. So instead of treating it as one line item in my roadmap, I make sure that I'm making the variation very explicit. I'm calling it out as separate line items. I am calling out how user behavior differs. I'm uh, spreading it across multiple different feature items so that I'm very clearly telling my engineering teams, I'm very clearly telling my design teams that do not assume that things would work in the same way. That is my job as a PM to really highlight those nuances. Another very important tool that product managers use is prioritization. So frameworks like Rice assume a single score impact, but with platform work, impact is not uniform. I might want to make a very small change that impacts one product, but it might do nothing for another and it might create an edge case for the third product. So I have to break down my use case from a prioritization perspective so that I'm very conscious about how I'm making trade offs. What is my total scope of work? Uh, so that I'm not going by one number, but I'm going by the holistic scope that I meet. I may need resources for M. Another thing, um, another very small thing I'd cover is analytics maybe. So I've used things like Mixpanel dashboards that show one journey at a particular point in time. But for platform PMs, the user behavior changes based on the entry point. Is it a new user, is it a returning user, what channels are they, um, logging in with, Whether it's mobile, it's a web, it's different product services. So I make sure that I'm comparing all of those different entry points, I'm comparing all of those different funnel points. It's not just one flow, it's multiple flows with multiple nuances. The most important thing I would cover in terms of tools is documentation, which becomes even more critical. Uh, when you are a platform pm, if you do not write all the differences down very clearly, the teams are going to assume the differences do not exist, which is not true.

Matt Green: Yeah.

Ashana Singhania: So it's not about changing the tools, it's exact same tools, but it's about asking the right set of questions. Because almost all the times, if you have a very clean view, it doesn't mean that you will have a very consistent product.

Matt Green: Mm. This leads me into one question that always comes up. How is AI AI impacting your work as a platform pm? Because you just mentioned the word documentation, as we all know as PMs, it's really changing our perception of how we handle documentation. But from what, what you're describing, you have to like, know all the details, which AI is not going to be great at. So I'd be curious to hear how you're handling that.

Ashana Singhania: I think I mentioned a couple of things there. First, to start with, people always compare how tech is working, uh, with AI and how finance is working with AI. And I always mention finance will always take AI with a grain of salt because of the sensitivity of transactions that we manage. If it's a user app and AI gives you a different algorithm, you might just switch to another app. But if it's finance and you're authorizing a transaction to an agent, I need to make sure I have your consent. And, uh, you have to make sure you trust the system enough. I cannot send your money somewhere else. So the sensitivity around financial products is very, very high. So I think finance is going to be a slow adopter with AI. But we are getting there. Not just the company I work for, but every single financial institution is trying to leverage AI in any and every way that they can. But I think where Most of the PMs, uh, including me, where we are focused on currently is improving redundancies, removing any manual work that we can, starting small, testing it internally and then exposing it to the users. That is where I think AI is playing a very big role. Now to our topic today. In terms of the platform work, I think AI works great on work which has very heavy patterns, data or repeated decisions. For example, where we're dealing with a lot of user signals, user data, uh, user behavior history. And AI can help with things like smart decisioning, it can help with identifying anomalies if user is making a transaction which is not, which is not in sync with their traditional behavior. AI can help that like credit cards, like bank transactions, wires, and we can send user notifications more proactively, we can reduce fraud, uh, more proactively or even guiding what is the next best step that it should be right. I think AI is also really helping with insights. It has the ability to read through multiple thousands of transactions in one go and identify user behavior patterns so that we're able to suggest the right sort of products, right sort of promotions to users. Um, I think those are places where we really need to skim through data. AI is really, really going to help. Uh, another example, uh, we were speaking about documentation. Finance is still very manual in terms of documentation. Right. So I can really help with ingesting all of that data right into our platforms from documentation. You upload something, the data gets ingested, it reduces a lot of work for operations and servicing teams. Those are use cases where AI has been helpful to us. But where I think it becomes noise is when you try to add it as an additional layer without changing the underlying system. If you just try to add it as a top up to a legacy system, it would not work. For example, you have fragmented data, you have inconsistent workflows and you just add AI to it. It's not going to fix anything, but it would just make your output less predictable which is going to then hamper trust with the consumers. So I think to sum up my response, AI works well with where there are structures, there are patterns, there are clear uh, feedback loops. But it really struggles where the systems itself are not very well defined in today's time.

Matt Green: Yeah, I'm really into the agentic commerce space but I, you know that's still

Ashana Singhania: very, I love that. Yeah, it's, I love agentic commerce.

Matt Green: The opportunity is great. But I still, I built payment products before and payment orchestration fund flows. You know getting people's money right the first time is so critical and like depending on AI, you really have to get it right.

Moshe Mikanovsky: So I can see how uh, financial institutions um, probably are going to, I don't know, maybe this is my bias against them. But correct me if I'm wrong there that um, IFIs are usually a bit behind on adopting um, emerging technologies. So they will probably be behind also with AI. But I do see how AI with some of the examples that you mentioned could be part of the platform that in the back end give those services to a lot of its um, consumer products.

Ashana Singhania: No, I agree. Um, I think the difference also is. So there are multiple differences why that happens. Right. So these Financial institutions are, a lot of them are over 180 years old and a lot of they have moved from paper trails to computer systems to from legacy to now cloud based systems. The transition is real. But in finance if you have to make even a single small change, you have to go through 20 different compliance teams. So the speed to market is never top of mind. Trust is top of mind for financial institutions where that is not the case for technical institutions. Right. And I think that is why we always see that finance is probably late adopters. But once they do, um, the impact is massive because these are things that the users use on a day to day basis. Your payments, your wires, your checks. Yeah.

Moshe Mikanovsky: And I think the nice thing about it, even though the impact is massive, I don't think necessarily that consumers in many cases will even know there is AI in the back. Um, you know, for fraud, you know, detection or things like that.

Matt Green: Until the AI gets it wrong. Yeah, that's part of it. That's where the trust, that trust layer is so key. You mess up one time and things can fall apart.

Moshe Mikanovsky: Yeah. But maybe they will talk with an AI agent. Um, maybe uh, they will have a robot in the the as a tailor speaking with them.

Ashana Singhania: Now that's hard too. That's hard too. So I'm very excited about the prospects of uh, merging finance with Agent E Commerce, which is AI agents that you're talking about. But at the same time I think AI agents also need to be trained. They need to be trained on user behavior, they need to be trained on user patterns and there have to be a lot of prerequisites to how a user get to the A.I. ah, agent. Right. I as a user need to first define these are my maximum transaction thresholds. These, this is what I am consenting for, this is what I'm not consenting for. This is what I need notifications for. This is what you just do on my behalf and I will be fine. So I think every flow is so minutely studied in finance before handing something to the agents. But I'm very excited about the prospects of it where I go online and I don't have to uh, add thousand things to my card. The agent just knows what I want. They just add it and in a single tap I'm able to check out. So I'm very excited for that world. I think we're in a transition phase, but we would get there for sure.

Moshe Mikanovsky: Yeah. On the other end, something that you said, um, the banks, they have so much data, they're sitting on so much data. That even if we don't think that they could, I think they probably can create models that will uh, know their clients, especially clients that they have for a long time, uh, patterns and understand how they behave. And they can also partner with other data providers to create more holistic view or other providers will partner with them to get their data uh, and create those understanding um, of the consumers.

Ashana Singhania: You're right. I was very excited about what PayPal was doing in this space. I think they were leading it um, up until like a few weeks ago I think with Agent E Commerce, the partnerships they've had with Google, OpenAI and so many different companies. I think definitely they were paving the way for AI.

Narrator: Mhm. Mhm.

Moshe Mikanovsky: Yeah. Well, time will tell us what it's going to be because um, it's hard to tell.

Matt Green: And I think there's the trust layer with like a crypto space as well with the crypto currency, stable coins and things like that where you can add that uh, encrypted trust layer into it can really kind of like accelerate things. But you mentioned the platform, you mentioned legacy systems a lot too. So I've dealt with legacy systems. I think from a baking perspective a lot of them are still on legacy and I think to your point you're having to account for that. So you know, they might think like AI's AI is going to be great and we can adopt it. But I think to your point, uh, you know, it's going to be a longer tail than we expect.

Ashana Singhania: Yeah, for sure.

Matt Green: Mhm.

Moshe Mikanovsky: Great. Um, you did mention a few usages uh, or mindsets of ah, platform product manager with the tools that, that you're using. And um, what I wanted maybe to follow up on this is related to, I completely understand, you know, those many um, different places that are taking your attention and want to develop this for me. Develop this for me. We need this, we need that. Right. Um, that's exactly where I've been. I was on the other side where we had the platform team and we always came to it and we told her we just needed to develop this for us. It'll be fine. But we were all competent. I think we were like four or five product um, teams that were working with one platform team. But at the end of the day there is the company vision and the company strategy and then the product visions and product strategy and the platform by itself should also have that because it has, it's a layer in the company. Um, how do you usually see that actually play a role in the prioritization and all Those things that you mentioned in a way that, um, it elevates a bit of that mess.

Ashana Singhania: Let me break it down into a few things. If I understand it right, for, for the platform, like any, like any other consumer product, if I am a platform pm, the platform becomes my product right now. And like for any other product line, at the start of every year, I would also develop my business case and I would pitch it to executive leadership about this is my vision for the year. This is my vision for the next three years. I would do my financial modeling, I would do my forecasting for the next three years, how I can save costs for you or how I can bring, uh, you more revenue by building things on this platform, because any for profit institution cares about those two things the most. And then I would pitch for how many resources I would need, an anticipated version in partnership with engineering, with design, how many resources I would need for these teams and for the product team itself through this year to deliver on this vision that I've set. Um, we usually go through a variety of meetings. We set our, um, we set our vision right at the beginning. We get approved for resources. I then go about breaking all of these, the vision for the whole year, into different milestones so that I have a very clear heat map. These are the things I want to achieve in the first quarter and these are the ones that I have to achieve through the year, through quarter four, right? And then I have my stretch opportunities and stretch goals as a platform pm, things that I would love to achieve this year, but they may spill over into the next one because things may happen, right? Uh, other priorities may come up. Those are my internal priorities. Now, to your point that every product team that I work with, and not just product team risk, has their whole set of list. Operations have their list. Compliance teams have their list as well. Anybody who is a user to the platform in any capacity can have feedback and can have, um, you know, a list of things that they would want from you. And the biggest that comes in is the list of things that the customer wants from you. Because my job is not just to build and shift features in the market. My job is to really get that feedback from every single internal or external user about what is going well, what is not going well, and what is it that you need from me additionally and how can I improve on what I've just built? So I always maintain a line in my roadmap, which is called health of platform, where I have set reserves of capacity just to improve things that are built on, just to make Things easier, right? For uh, the users. But I always say that a roadmap is a living document. It's never stagnant. Every week over week I revisit it to see if anything needs a trade off. Anything needs uh, there needs to be any shift in prioritization. Do I need to bring anything up? Has um, something come from risk? Has there been an escalation? Has something come from compliance? Because those things trump everything. You never want to be out of compliance in finance. You never want to be in a situation where customers are impacted so badly that they cannot use your products. Right. So those things trump everything else. You descope everything and you work on those uh, things. But then there is definitely a North Star vision. For example, if I'm working on an onboarding product, my North Star vision becomes that I need to reduce my onboarding time as much as I can so that my customers can onboard and start using the product so that we get revenue. If I'm building a credit card product, um, my North Star vision becomes uh, that my customers need to be able to sign up for the credit card as soon as they can and as less steps as possible so that they can start using the product as soon as possible. Right. So I think um, it is very important to define that North Star metric and then track those smaller KPIs that help you achieve that North Star metric at the start of every year for your teams.

Matt Green: Mhm.

Ashana Singhania: Yeah. Did I answer your question?

Moshe Mikanovsky: Yeah, yeah. It's, it's basically um, just uh, emphasize even more the complexity and the chaos that you live in. Because you know usually in um, in one of the uh, more vertical products there will be um, one or two or three types of users. There will be maybe stakeholders that will be involved in that but it's not going to impact their life so much and stuff like that. Where here the many more um, uh products that are using the platform you have uh, the many more requirements uh, and stakeholders that you have. So it just makes things much more complex.

Matt Green: Quite a lot of uh, orchestration layers so, and levels of dependencies. So you might have your roadmap and you might have it like I need to do like onboarding is a great example. Like it's very horizontal. You have dependencies on other teams and so you have to have transparency on what are they working on, when is that going to be delivered. So are there any failure modes of like in the product space of the platform space that like that you just have to like work through as a team and get through?

Ashana Singhania: Yeah, yeah. For sure. I think it is really unique in the platform space because uh, the two most common failure modes are um, the opposite ends of the same problem. For example, uh, the very first one is over standardization. There are teams that try to force one way of doing things everywhere on the platform. They want everything to be standardized, everything to be consistent. For example, uh, a single onboarding flow or a fixed set of checks applied across all products without accounting for variances. Uh, it might not be a very regulated product, but you still have those 20 checks that users have to go through which they do not face when they're using competitor products. Right. That just makes your user experience bad. It looks consistent on paper, but in reality it creates a lot of friction. And then what happens is it creates experience debt which servicing teams and customers start to build workarounds for. They never tell you. You may hear those complaints, you may not hear those complaints, but at this point you're not running one single platform. You're back to those multiple versions that people are using for their own convenience. That is one end of the problem. The other end of the problem is you as a PM provide too much flexibility. You let every product team, m every stakeholder adapt things on their own. For example, you may be managing different vertical product lines that are collecting different onboarding data, completely different fields, completely different values at different points in time. Or um, you're handling users action differently across different product lines. In the short term it might work, but over time as you drift, you would find that the behavior is different everywhere. The users would find no consistency. They would, even if they log in once on one website, they would feel like, um, they would feel very confused while using multiple different products. And the reason both of these things happen is the same. There is no clear definition of what should stay consistent and what should adapt because teams are working in silos and teams are not working together. Or you do not have a very clear view of who exactly are your stakeholders. How one decision can have a domino effect on so many different teams and how you need to account for it. So I think platform work is really about getting that balance right between standardization and flexibility. You need a very strong core which is standardized with very controlled flexibility. Otherwise you will either end up with friction or fragmentation. Mhm.

Moshe Mikanovsky: Interesting. Yeah. And uh, do you find that you have to define the standards up front or this is something that moves as you go based on the needs?

Ashana Singhania: I think both happens. We try to define the standard upfront as much as possible. For example, if uh, something comes up, uh, MFA is not Working, um, user is unable to log in. I would try to make sure that I get all the teams right on, on board at the very start. I would try to see if there's an issue with entitlements, an issue with product and uh, issue with backend platforms, downstream platforms. I would try to make sure that I'm thinking through all the different edge cases for that particular problem. But you sometimes you only know what you know and there are things uh, beneath the surface that you do not realize and as you're building for it you realize that you have dependencies on some downstream systems, on some part teams and that is when you, but you make sure that you're always vigilant about those things and you're pulling teams, a lot of agility so that you have the right stakeholders taking the right decision, having the right prioritization conversations.

Moshe Mikanovsky: So maybe governance is also an important part of managing a partner, a platform.

Ashana Singhania: Very important part. I think, um, I run so many different forms. I always have in any of my platform roles more than my consumer products where I keep stakeholders informed, um, three months to six months out about what is going to come. So that uh, on a weekly basis so that if any team, whether it's uh, a governance team, a compliance team or a partner product team, uh, they foresee that there's anything that could really impact them, they would raise it to me early on if that's something that I haven't noticed as a platform pm. So I think it's very important to carve out that roadmap very clearly and make sure that you're going on a roadshow with your roadmap, with all of these different teams on a periodic basis so that everybody's aware of what you're doing.

Moshe Mikanovsky: Um, that's great. I don't know if I have any other questions. What about you Matt?

Matt Green: Your history at American Express, now at Goldman Sachs, you know, managing these things at scale, obviously you're dealing with a very large customer, uh, user base, whether it's internal customers or external product lines. How are you going about discovery? Are you using any kind of tools to do discovery work? I keep going back to the onboarding experience. Like onboarding with payments is so critical for success. Are you using any kind of tools to record those, document, uh, those, archive

Ashana Singhania: those for user feedback? I think it really depends on the user base you're dealing with. If it's consumers, small medium businesses, it's easier to get feedback. You can always run feedback emails, uh, um, email campaigns, you can have it embedded, um, A quicksight survey on the website itself so that the users can fill it and they can send direct feedback to you. And those users are a little more ag to send feedback to you. But when you're dealing with large corporates, everybody's very short on time. Right. And they want to get things done very quickly. Things are more formal, lines are more formal. So I think you depend more on sales and operations team to gather that feedback from corporate clients so that they can relay that back to you. So it really varies on the nature of the customer population that you're dealing with. But I think what has worked for me in the past is email campaigns after maybe an onboarding, uh, to really understand how the experience worked for the user, to embed um, surveys directly within my platform so that if a uh, user is frustrated at any point they can let me know. What really works for me is engagement data metrics so that I know when a user abandoned the journey, when they spend more time, when they should have probably completed the step in like two minutes, but they spent 20 minutes here. Maybe my page is not very clear, my messaging is not very clear. I'm not explaining things right to them. So I'm a very KPI data driven product manager. I stay in the weeds of my onboarding metrics for sure. In terms of recording. Yes. Um, for us, we across all my roles, I make sure that for sales and marketing teams I am recording my user journey. Uh, with different companies use different tools to make those recordings. But then we are publishing that on our website, we are sending that to our customers. Um, I am also very big on developing FAQs, product guides that I can send to my customers. I can, I can have it embedded in the platform, I can send it during the onboarding packet to these customers so that anything that can reduce touch points to your call centers and sales teams, you want to do that up front. You want to save their time so much that they focus on things that truly, truly matter.

Matt Green: Uh, that's great. Yeah. Having lived the payment experience like FAQs and all the different uh, hurdles that people face. Yeah. All the different things they have to go through and it's because it's such a regulated and compliance focused industry. Like there's a lot of questions that come up and a lot of like you really have to like people can get a lot of friction points is I guess is what I'm getting at. So that's super helpful.

Ashana Singhania: Yeah, for sure.

Moshe Mikanovsky: Great.

Matt Green: Now this has been a fascinating conversation, uh, and it's great to hear about uh, platform PM and financial services is, you know, such a great space to work in.

Moshe Mikanovsky: Where can people reach out to you? Ashana?

Ashana Singhania: Well, people can reach out to me

Moshe Mikanovsky: on LinkedIn if you, if there is anything else other places where they can reach out to you, you can also share it with us and we can put it on the, uh, episode notes.

Ashana Singhania: Amazing.

Matt Green: Perfect.

Ashana Singhania: Great.

Matt Green: Ashana, thank you so much for joining us today. It's been a pleasure. Thank, uh, you to all the listeners. Thank you to Moshe as always. And we'll talk to everybody next time. Take care.

Ashana Singhania: Thank you.

Moshe Mikanovsky: It was a great, uh, thank you, Matt.

Matt Green: Thank you to all the listeners. We really appreciate the feedback and support. Please leave us a review to help others find the show on Apple or Spotify or anywhere else you're listening to the show.