 Hi everyone. Thanks for joining today's session. I'm Neha Kicharia and today I'll be talking about how do we build the payment products into a marketplace. So before we get started, a little bit about myself. I've done my graduation in electrical engineering and I've got a total overall experience of 13 plus years where majority of my experience lies into payments and fintech domain. As a part of my current role at eBay as a senior product manager, I work onto the managed payments platform, which is a continuous attempt from our side to make sure there is a seamless and a very smooth payment experience from buyer and center perspective. Few of the earlier companies where I've worked with prior to eBay, I was working with PayPal where I focused mainly onto the finance transformation project and later part I moved on to the product owner area for the finance product from middle office integration perspective, where I worked with lots of marketplace integration, new bank and vendor processor integration, partnership, launch into the new areas, tax projects as well as certain key partnership with one of the few and the top most social media companies. My earlier role spread across SAP developer and analyst role in my earlier phase of the career where I was more focused on the development side of SAP platform and if you look at my career transition, it started from the software developer to analyst to product owner to the product team. So that had been my journey and what I'm really passionate about at this point of my career is to build strong and robust payment product which actually can enable and smoothen the life of millions of sellers, buyers, sender, receiver and also I strongly believe in the power of data analysis and I love digging the data and build my hypothesis around the same. So before we get started, let's just go through the agenda and the key points which I'll be talking today. So some of the key areas where I'll be throwing some light on would be the basic concept about e-commerce marketplace. What do they actually mean? What is the significance of payment in e-commerce? How do we build payment products? What is stakeholder management and how do you actually handle your day to day engagement with your stakeholder and partners? And what are the key areas from my perspective to actually excel in the day to day cadence as a product PM in the PM role? Okay, so let's get started. Let's just go a little bit basic about what is an e-commerce and why is it being used? What is the significance of it? Whenever there is a term of online shopping, this word and terminology is very commonly used about e-commerce platform. What I want to actually showcase in this particular slide and talk about is electronic commerce or e-commerce actually refers to buying and selling online. Any form of business transaction which is done online is falling under e-commerce. Now, one distinct feature which kind of is unknown to most of us is an e-commerce doesn't necessarily means a seller, sellers and a buyer group. e-commerce mainly signifies whenever there is one seller or a one vendor who has different list of items listed online and then there's a group of buyer who buys it there. A plain example would be a Nike store where they have their online Nike.com where they have hundreds of sneakers and shoes and then as a buyer, you just go and do a checkout. So that is something which will fit under the e-commerce definition. Next, going to marketplace. What is a marketplace? Marketplace in a very simple term is a market of the current world where there's a group of sellers, there's a group of buyers, there's one single common platform where there's a listing from multiple sellers and then as a buyer, you just go browse the items, go through the stuff, you like something, you go check out and then you just complete your transaction and then the next few days you receive your merchandise. So that's pretty much what a marketplace in a very high level and a very simplistic term means about. Now very commonly, the marketplace and e-commerce are used interchangeably, very frequently. And with these slides, I just wanted to make sure that we know the distinction of an e-commerce versus a marketplace. To name a few, in the screenshot below, there are some of the key common most popular marketplaces including eBay, which makes it more exciting for me to present this topic here because eBay is the oldest marketplace known and one of the oldest marketplace which was invented. So that's about the marketplace and the e-commerce distinction. In the next slide, let's just talk about what are the type of transaction and when we talk about an online transaction, what are the different categories by which these fall under? So broadly, there are four key types of transaction or a mode of, I would say, different types. Some places might call it four types of e-commerce, some might call it the four types of transaction, but then ultimately these are the key terminologies which are being used when you want to denote the mode of the transaction or the business model. So the first one is B2B, if you will, or business to business. What it actually means is when the seller party and the buyer party, they both belong to an organization or an enterprise. Simplistic example would be the seller might be like a small factory owner who actually manufactures like a metal bold and the buyer could be a car manufacturing company who actually wants thousands and hundreds of thousands of those bold who actually buys that from the small time factory owner. So that is a classic B2B example. The second one is B2C or business to consumer which is the most commonly used mode of counter parties under the payment model in the online transaction model and where one party is your organization or merchant or a vendor and the other party is the consumer. So that is the B2C where and say for simple example would be me being a buyer going to an online marketplace and then searching for a camera, I got it from say Canon store or Nikon store and I buy that. That is a B2C transaction. The third one is consumer to consumer where both the parties are consumer. They are not merchant. They are not known seller or belong to an enterprise. They are just consumer to consumer. Maybe simplistic example would be you list a second hand used refrigerator in a common marketplace and then somebody else, one of your neighbor comes and interests and buys that. So that is a C2C. The fourth one is consumer to business which is not too popular and too commonly used but it still happened. It is a mode of transaction which is consumer to business where actually you as a consumer for example you are a painter, you have good sense of painting and you are good at it and then you list some of your homemade painting into a website and then a business wants to an art gallery wants to purchase that which is a known organization. So that will actually fall under the consumer to business mode of the payment transaction. The next before deep diving on to the what's and what's of marketplace and how the payment work, I want to spend some time and focus on what is the future in terms of the market capital size and what is the monetization aspect behind the e-commerce or marketplace. If you will, if you see this current chart, there had been the values of market capital size from the past trend as well as it's a future forecast for the next three years how it will go. So it's a within a span of five years. This actually shows the breakdown of what had been the market cap year over year and as of 2021 we actually stand on to 4.8 trillion dollar of market size which is quite significant in a way if you see from the dollar impact value. But where the actual opportunity lies on to is globally if you see only 3% trade occur online. So that actually opens a huge leap of growth potential to actually dive into this area and explore the market where the presence of online shopping experience is pretty low and then where people are still learning to adapt for the concept of online shopping. So there's a huge potential for this area to actually be having more growth and more future prospect into lots of countries where it's not actually have a very significant on dominant presence. The next I want to talk about why payment is important when we talk in terms of marketplace or online shopping experience. Why is it payment important? The reason it is important is because one of the significant reason is when you're talking about a transaction an online transaction for many of the sellers specifically in the context of marketplace. This is their livelihood. This is their bread and butter in terms of that's how when they are being paid out that's when they actually run their houses. That's what their mode of living is and any glitch or any kind of secrecy or failure or latency onto the payment model actually impacts the monetization aspect not from just from the seller perspective but from the buyer perspective it gives an unpleasant experience from the buyer checkout perspective. From a seller perspective if the transaction is not completed successfully that means that item is not being sold and then he cannot actually make money out of it and from the organization perspective you are not actually catering a good sense of customer experience a buyer experience and the seller experience and this is not just related to marketplace it's an even outside of marketplace. If you talk in terms of digital wallet or peer-to-peer money transfer even from that perspective if somebody wants to send some funds to a friend or a family if that online transaction is not completed if that payment is not completed that means the money cannot be sent right. So that's where it makes it like a collarbone or a backbone for the overall like a transaction model that if the payment in itself is not completed it is just a so let's just go through what actually is a high-level mechanism when you try to check out something on a marketplace what actually happens behind the scene and this is not just limited to these five steps it might actually consist of many more layers and platform and integration but then at a very high level when somebody tries to check out an item on a marketplace or an online shopping this is what happens a customer triggers a payment and a step one which actually goes to the checkout platform and from there on it gets connected to the payment gateway which is kind of an interface from the PSP which is the payment service provider what it actually does is it actually links a communication and constant communication with the issuing bank assuming that this checkout was made using a credit card and then when the issuing bank actually gets back with the confirmation of the authentication and the capture request was successful and that's when the PSP actually sends the fund to the marketplace account and not the merchant account but the marketplace account and then depending on what is the frequency of dispersing the funds to the seller or the vendor deducting some fee some sort of fee or some sort of charges or some sort of like you know any other miscellaneous fee like any kind of depending on what platform is it being supported with deducting the fee the money is being deposited to the merchant bank account or merchant's account where they can actually be able to withdraw it so why it is important is because this is this whole payment pipeline is something which is actually responsible to change the economics and enable people to live with a smooth payment experience if as a buyer if I'm not able to complete my transaction there is some glitch in the credit card or some risk quality some risk rule are being triggered on my transaction or it is not being authenticated for whatever reason with my bank I will not be able to purchase an item from the seller perspective he's not going to earn the money and from the organization perspective it's just an unsatisfactory way of experience from both buyer and seller so that's what it actually makes it's not just monetization aspect but it's also that this is a checkout and this is this whole transaction completion a transaction cannot be deemed complete until the payment is completed so that's what it actually makes it so crucial and important for multiple reasons now let's talk about what is a payment product manager what do they do what are the difference between a generic any UX UI or cloud for cloud pm versus a payment pm so I have divided this topic into two part one is what are the domains where a payment pm actually works very closely on a day-to-day basis and then at the first site I have actually tried to list down some of the key responsibilities or day-to-day job which we actually do as a part of payment pm agnostic of the companies or organization or the mode of payment that's included in their companies so the first in the foremost in my opinion what I have seen as the payment pm is expected to have a product vision to cater the definition of the customer journey what do you actually want the customer journey to be like you have to wear the hat both from the end user perspective because in any payment transaction there are two parties involved either the sender or a receiver or a seller or a buyer so you have to not just think from one perspective but you have to like look at from end-to-end user perspective be able to define the buyer frames be able to actually create the interface plan features MVP what is going to be the most valued product as a part of your launch do you want to cater a bcde all the five things which is spread across your one-year vision or you want to launch a particular product with the bare minimum which is actually sustainable to make the product go and then you have your additional value enhancement on the top of it collaborate with cross-function team to develop strategic product and feature roadmap that is one of the very crucial responsibility you are expected to do as a payment product pm and which is something you just not are expected to focus on a platform or a portfolio which you are working on but you actually have to holistically look end-to-end define detail use case intended for engineering and design depending on again what methodology an organization uses is it going to be agile or waterfall or you have your sprint scrum whatnot whatever is the mode of requirement submission to the engineering team it has to be as detailed and as full fill as possible in terms of capturing all the different use cases the timeline the prototype the MVPs what is going to be usp what is going to be the success criteria there are a lot of things the more detailed you are specifically in terms of the use cases the better it is because when it's talking about the money and the dollar and like you know the money moving from one place to the other the better the the most use cases can you capture is the better for engineering to actually ingest and understand and interpret in a better in a very practical way work with the program management to communicate project status resolve issues so this is again not just your stakeholder and your key partners and your neighboring teams PMS and your other like you know teammates or BU partners you also integrate very closely with the program managers to actually show the health check of your product life cycle right I mean are you actually on track is there any broker is there any kind of discrepancy is there any discoveries is there any late discovery is there any glitch in the requirement those kind of things you have to very closely work with your program managers to actually make sure that the health check for your product launches pretty much on the track measure and report on the efficiency of initiative and develop action plans occur accordingly you just cannot be having one simple goal of launching a project and then not having a failover or a disaster recovery plan you have to have like a plan B and plan C so that if like okay in a best scenario everything goes well plan you launch and you ship the project but if not then what is your plan B and C if you if you hit a roadblock what what is your exit strategy how are you going to recover that will it would are you going to buy some more time are you buying to negotiate with your stakeholder what are the plan B and C always always have to have that handy in order to be able to cover all the all the use cases positive and negative votes now the next one I'll be talking about is what are the different payment domains not just limited to these ones but then there are much much more but I just listed a few of the domains just to create a sense of familiarity when you are working on the payment domain you work with different type of laterals different parallel teams and platform and domain so to name a few on a day to day basis these are the key teams you actually engage with like again in terms of the marketplace you might have checkout team you can have payout team your gateway team legal compliance treasury tax risk identity accounting billing so every every team every domain has their own specific set of layer of platforms and their own way of passing processing the product and launching the key features so you have to work very closely you just cannot say I am working on this particular domain so my boundaries are confined to just this area you have to work end to end what my work for you might actually be a breaking point for some other platforms you have to work end to end holistically with a proper handshake and make sure that whatever somebody's building should not be a breaking point for somebody else one color I just wanted to make in general was a payment PM can either own a platform or execute end to end product this is very subjective to the organization and their work model now the next important thing which I wanted to talk about is payment KPI or key performance indicator it's always a like a must have criteria while you are defining and strategizing for your product to have a success metrics for your product you need to have certain parameters where you say that when my product reaches these milestone a b c d these are the ones which will define if my product is successfully launched or there is something else need to be done to actually make it a successful launch some of the key not again just limited to but some of the key areas where if you launch specifically in the context of payment products when you actually launch a feature or you are going to altogether a new market or launching into a given new country there are different depending on the segment of what kind of product are you launching there are different set of KPIs but to name a few few things which you actually check generically most of the times are successful checkout has your product launch created a good graph on the successful checkout what is the latency these are the numbers and the parameters which you actually define like has the latency drop are you talking are you very interested about the transaction per second after the product launch has it been x before the launch and now is it like x by 2 has it decreased has increased has it been stable what is that which will actually enable me to say that this is the bare minimum I need to launch my successful project cost of payment has my cost of payment increased decreased has been stable again as a PM perspective you would always like to minimize the cost of payment right and not just have an overhead cost and the in the attempt of doing and getting the monetization from one area you should not compromise on the cost of payment so that's also one of the key area to actually look upon what is the charge back rates what is the user experience are you so happy with the launch what is the prototype or the beta type feedback looks like what are the fraud rates is it is it actually enablement of a given product is it like attracting more fraud rates and more fraud tagging or risk tagging on a checkout attempt what is a purchase success rate what are the KYC failure if you're actually launching a product for a new set of user like at the time of onboarding are there any lot of KYC failure on a given sub user domain so these are the key areas which you actually need to think through and say what is that you actually envision to say this is what makes my product success so again the mantras always always always define the success metrics or the exit strategy if you will for your product one key call I would like to make is again from the enterprise perspective to lose a customer to the checkout page due to the payment issue is not a desired goal for any organization so payment is of course one of the highest interest factor for an enterprise specifically when you're working on the payments platform the next we'll be talking about some key jargon syn payments again not just related or limited to but then these as a payment PM you are expected to use certain key repetitive key terminologies like TPV which is the total payment volume GMV which is the gross mean volume KYC know your customer FINRA which is your regulatory role rule code for the payments payment companies FX for an exchange ACS automated trailing house processor interchange so just not just limited to but these are the key ones YTD year to date PSP may have been service provider CBT cross-border trade KPI key performance indicator acquirer gateways these are the backend parties which are responsible to complete the payment end to end completed right so you just need to like know your jargons when your payment PM again if you're not too much in depth about a particular domain at least you should be able to win these terminologies are being used just it should just kind of ring a bell and you should be able to relate in what context are these words or these terminologies being used upon the next one is stakeholder management which is one of the key when you are actually working on the payment model or a payment industry it is very important to have I think agnostic of the type of industry stakeholder management is one of the key area which actually smoothens your engagement and your day-to-day alignment with your stakeholder so stakeholder can be categorized into an internal or an external stakeholder now depending on if your stakeholder are external or internal there are I've kind of like slaughtered into four different areas where it actually helps to make an impact which is the satisfaction actively engaging with the stakeholder keep them informed monitor so this four blocks matrix is what I have tried to illustrate on the right hand side the first important point is aligned for a common goal you cannot work with a stakeholder or any partner of yours with having a tangential opinion on given topic like your stakeholder cannot be expecting you to build something A and then you are proposing to build something B as a part of the requirement assessment it has to be with a common goal and your common feedback and your common strategy of what you actually want to define there define the scope of improvement so this is again one of the key area as to not every product is 100 percent accurate right so you have to have actually some sort of room for improvement where it says these are the areas which is what is required to actually improvise it going in the future setting realistic expectation it's always important to share the reality of what it is build your trust trust has to be built from both the sides and that is one of again the key areas where actually you should be working towards as a goal transfer and communication you should not be waiting to share any roadblock at the 11th hour of the day at the very last moment during the UAT or user testing phase and say hey we have run into an issue so that's again one of the very important point to actually be mindful about then the last slide I would just like to share from my perspective and my observation what are the key areas which actually if you incorporate in your work mechanism is something which really helps know your product you're the face of the product I think I read somewhere like you know a product manager is deemed as a CEO mini CEO of your product so you should be the face of product of your product and you should know at least the minimum you are expected to know is the starting and the end point of your product if you don't know too much about the in-depth what is the code what is the backend logic of any mechanism at least you should know what are the do's and don'ts of your project what what are the things which your product can do what are the things your product cannot support so at least you should know functionally you should know everything or the most part of your about your project or the product if not in depth excel in the width of the product if you don't know again the underlying code at least you should know that what what are the key components which are supporting your product what the code area what language has been supported with those kind of things stay realistic in approach you know it's always good to be very it's very tempting as a PM to just envision something very high standard but you should also be realistic of the timelines of the challenges and then you know of the MVP and what are the core area you want to focus against what are the a b c d e different areas you want to overload your product launch with data and statistics always always always help always base your hypothesis based on the numbers and charts and everything built us with the customer prioritize the goal you might have to do 20 items in your pipeline for the next six months or a quarter but then you have to prioritize into what are the p0 p1 p2 what are the must have what are good to have those kind of buckets so that it's easier for prioritization and work with your stakeholders and engineering to actually facilitate and accommodate that and to impact payment ecosystem not just end users so as at this point just don't be focused upon your particular domain or area but you have to think again from end to end perspective that is really helpful a regulatory and legal company when you actually work on people's money and when you're responsible for moving the funds you are heavily and deeply expected to be you know compliant with regulators and legally you are expected to be compliant so make sure any decision you take is actually wetted with your counterparts in the legal team and the regulatory team so these are the key areas which I have found very helpful when I when I have been incorporating in my day-to-day work mechanism and I thought this would be good to share because that is really helpful and I have really seen a difference by incorporating that so with that this is pretty much about my time today and that's pretty much what I intended to cover in today's session I hope you benefited a bit from this demonstration and I hope you liked it if you have any comment question just feel free to reach out to me on my LinkedIn profile I can search with my name and this is my LinkedIn so thank you so much stay safe and hope to talk to you later thank you bye