 Thank you everyone, thanks for coming in tonight and learning more about product management. Let's see. So I'm going to talk about problem solving from a product perspective and I'll tell you why I call it a product perspective. So a little bit about me, I come from an engineering background. I have a master's in computer science, I was an application developer, full stack. I did some front end back end and those is Java swing developer and moved into product management probably about five, six years ago now. So my journey was like from one of the important things that I worked on was at CBC, I was a lead Java developer for something called Hockey Night in Canada, which is an first iPhone app for the hockey game, the NHL and brand new to CBC and it's like here, take this game and deliver it on all devices on iPhone, on Android, on the mobile web. I don't know anything about the game, like figure it out. So that's where I started my journey of talking to all the developers. We are sitting remotely, not everybody is in Toronto, started talking to the vendors because they were providing us with the data, started talking to the subject matter expert to gather all the requirements of the game and how should it work with the design team. So that gave me a little bit of a flavor that this is more than development, I think I can do this and I'm enjoying it. That was more important, I'm not sitting behind the desk all day writing code and not talking to anybody, I'm interacting with real people and making a bigger impact. So after I moved, so the app did well, it was like number one on the app store for like three weeks and we had like 300,000 downloads. So that was very encouraging team effort, we did a good job and everything went well. Then I moved to the Bay Area and where I was at Apple, I was working with the point of sale solution team. It was interesting, it was again some server configuration and stuff like that, but I had already felt that I wanted to do more. So then I quit my job at Apple and I'm like, okay, what next? I didn't know, I didn't know what next. I wanted to, so do I do, do I get into data science, do I become an enterprise architect, do I do usability and design or do I do project management, do I do business analysis? The options were all open, I could have tried anything. So at that point, I was not aware of product management. So I decided I wanted to do business analysis because that has got some business, some technical, a little bit of project management, so I started there. Then I also had a startup of my own with four other partners, it was into health, health software. We worked for about a year, the proof of concept was pretty good, but the device itself was not ready for like end user testing. Like I couldn't just give it to you and you will know what to do. It was not very like user friendly. So we decided to shelve it because the technology was not ready yet. But that project gave me the background to kind of package my experience and present it to a product management position. And that is where I got my first break at Visa. I was the technical product manager for Mobile Banking Platform. And from there, I went to Toyota, where I worked on the connected cars. And right now I'm at First Tech as a senior product manager for online and Mobile Banking. So that's a little bit about how it all went because some of us are coming from engineering backgrounds and when I was five years back, I was like, how do you break into product management? There was no product school. Nobody was giving us that input, but nice to have now. It's great that somebody is guiding you through it like, you know. So today's agenda, let's see what we are going to talk about. I'm going to dwell a little bit on the role. I'm sure you guys have seen this on the web and other presentations, but like what I think about the role. And then I'm going to talk about the PM versus the developer toolkit, like how does the PM approach a problem versus how a developer approaches a problem. And then this is my, I've coined this term called the communication chain, where you decide, you never forget the chain and you just decide when to activate the chain, it's like Spider-Man, the spider web is activated, it's something like that. And then there is the type of challenges, right? Like what kind of challenges are the product manager you are going to face? And then there are those C type of challenges we are going to dig into further like the current product, the problems with the existing features. New development, you are developing something new, it's about to be released. How are you going to address the problems that come with it? And long term, like, so the CTO will come and say, okay, you've done all this great work, now tell me what we should do next. Well, I don't know, okay, then figure it out, so how do you figure it out? The strategy and roadmap is one of the things we are going to touch upon. And then the final is, what did you learn today? The key takeaways. So the role, so the product manager, I'm sure you have seen this before. We lie right in the middle of design, of technology, and for business. So I think of it as an interdisciplinary role. It is like a bridge between various business units or various departments in your organization, and what is your key function? So you represent the voice of the customer, and you define the what. What is this feature going to do? What is the user interaction with this feature? What are you expecting out of this? Like, say Uber, when it was brand new, right? What was Uber's selling point? When is they want to make the ride sharing easier? And the second one was they want to add an extra source of income to somebody. So they were the two main goals that Uber was trying to solve. So now you want to do ride sharing, and now you want to do add income. So what are you going to do now? So who are the players? The guy who wants a ride, and the guy who wants to offer the ride, right? Now you develop the ecosystem for these guys. And then you define what that ecosystem means, what it means today, what it means after one year, what it means after two years. So that is what you are thinking about. You are always thinking about from the customer perspective. But you are also thinking about the business. How is this going to be? How will this work for us? I mean, finally, you have to survive, right? You can't just do a good job and not make money out of it. So the key factors from my experience, the key factors to product management success have been building relationships within the organization, especially when you move from a startup to like an enterprise. There are a lot of people that you need to be involved with. So building relationships is very important because you can just expect them to react to you the day you need them. You need to know them a little bit in advance to kind of form that working relationship with them. So sometimes you need to do things for them that it's not really a job, but you do that to build a relationship. Also, the product manager always needs to think of the data. How many members are going to be impacted? What does this mean for the organization? Is it going to bring in new customers? Is it going to bring in revenue? Is it going to build market share? What is it bringing to the organization? And we need to also communicate very clearly and very consciously. So if I have a problem, I will have to customize my information for my development team, for my design team, for my marketing team, for my customer sales team, different teams. Same problem, but different set of information. So it's very important to customize your communication. And now, yeah, we are going to talk about the product manager versus the developer toolkit. So as a developer, what was I doing? I was thinking about algorithms, which is like how the system is working. How is it thinking? As a product manager, I am thinking about how the people are behaving. What are they thinking? It's a system of humans. Well, the algorithm is like a system of machines. And databases, how is the data stored? How is it correlated? How is it moving? What is the relationship? In data insights, it's on top of the databases. You are understanding your view of the product through data. Like the data is telling you a story. You need to figure out what story it's trying to tell you. And configurations are like relationship between systems or servers and everything else. So as a PM, your relationship is within the organization and to a certain extent with your customer also. You should know what your customer needs. So code is a language for the developer. So communication is what is needed for a product manager. Communication is very, very important. That is where many things fail. And there are many roadblocks because you have not either communicated accurately or you have not communicated early enough. And then deployments, like you are deciding when to release things out, when to what is the timeline looking like, what are the dependencies you have. And on the product management side of things, the strategy is the last in the list. But strategy envelopes everything else above it. So the strategy will consist of your customer empathy, your data insights, your relationship, your communication. Everything will come into your strategy. So this is my communication chain. So product manager is right in the middle. And now, I mean, this is like a snapshot of where I come from from the financial industry. But you can have different kind of actors in this chain. You can have, if you are a product company, you will have business development, sales team. So just remember that you need to always remember all the key players in your organization. And you need to decide whom you need to communicate at which point. So there is, you have the customer right in the middle. The font is a little bigger. And it's generally in the center of your mind. So even if you have to take care of all these other folks, you still need to remember the customer is your primary focus. You should never forget that. Then you have the executives and the sponsors in your organization, the design team. The enterprise architect, the developer and the QA, the vendors, the marketing, product support, technical support, legal. So now you need to figure out every given problem. How are you going to communicate when and to which group? Any questions so far? So there are three types of challenges that a product manager faces. You have an immediate need. You have a current product. Then something is broken in the product. So what are you going to do about it? How are you going to address that problem? Short term is you have a new feature getting developed. And you have a laundry list. Like say you have like 12 feet new features to be developed in six months. Somebody has given you that charter. How are you going to do it? Or how are you going to solve for it? And then the long term is what is your growth strategy and what does your long term roadmap look like? We are going to go for the first one. So the current product, right? I'll give you an example. So suppose I have like around 50,000 credit card customers and I get a report from my technical support team or my contact center saying in the last two days my credit card members are not able to pay the credit card bills at all. So the question is first, like the first few emails will come to you saying this is escalation. We can't get this. This is such a big risk. Everything will, it will come flowing down to you. So now how do you do? Like first you'll be like shocked. Okay, this is rock bottom. What do you do now? Like, you know, so then you take a step back, you breathe, you go for a walk, figure out how what your strategy is to relax. First, calm down. And then you think, okay. So is it all 50,000 members or customers who are impacted or is it a smaller subset? What are the different types of credit cards? Which ones are affected? Is it like payment, what kind of payments? You can pay like automatic payments. You can make manual payments. You can schedule a payment. So which kind of payments are impacted, right? So you figure the problem out. So you first say, okay, what's the severity? If you say 50,000 all are affected, it's P zero. Nobody goes home. Nobody sleeps. Nobody eats. Everybody sits down to figure it out. So the support team will come to you to figure out what is the priority of this issue. Because say I have this product manager who's working on this brand spanking new feature who has the same resources. And I come to him with this severity zero issue. And I say, I need the same resources that you are using for this problem. So then I have to tell him why. Because he's like, I'm not giving you my resources. But then you have to tell him, no. Everybody's impacted. What is organizational impact? Is it, are we at risk from legal or compliance? Are we, you know, are the customers going to leave us? Or are they getting hit by something like bad credit score or something like that because of this issue? So I have to give all this analysis to this, to the team to make sure that it gets the importance that it needs and get the right teams assigned. And then for the right teams, so for the teams, right, you need to define the problem statement because the customer will say something. My engineering support will say one thing. And then I need to define the problem for everybody so they understand what the exact nature of the problem is. So listen, listen clearly, listen a lot, then absorb it, process it, sleep over it. I know it's urgent, but you need to come up with the right problem statement. If you do not define the problem clearly, you're probably going to go down the rabbit hole and you will be wasting everybody's time. So it's important you come up with the right problem statement and keep it with you. Do not go out to the town to the communication chain yet because just talking about the problem, it's great, but then everybody will ask, so what? When is it going to get fixed? So just having the problem, keep it with you, figure out which team is going to fix it, assemble the team, give them the problem statement, and then they will start investigating the solutions. Now you, because you come from a development background, you need, you can be involved in the solution definition, the discussion on how to solve it, but stay out of it, be a part of it, but don't be the main person driving it because let the ideas flow because you are not in the system anymore. There are other people who are within the system and who probably know more than you do because you are not the developer at this point. If they are stuck though, if they are stuck, if your engineering team is not able to come up with something, then you put your system thinking cap on and then you say, how about this? How about that? And sometimes it happens to all of us. You are in the thick of the problem and you have blind folders on, right? You can't just see anything else. You are like totally stuck in it. So then you come from the outside in perspective and you try to push the problem along. And all this needs to happen in parallel. It's not a sequential thing. You need to understand the impact, start getting the team ready and also figure out who needs to be involved and who needs to start having the communication. So for the communication, right? What I do is I treat my stakeholders as customers. So I put myself in their shoes and I try to think like, what do they need? What is the most important piece of information for them from this whole thing? So even for the solution options, right? You can have immediate solution is like put a banner up in your website or send out emails to your customers saying this is happening. So your marketing team wants to know about that on what is the immediate information that they need to know to help you figure, to help you solve the problem. A short-term is going to be like, is it okay? How many, like the short-term solution is like, 70% of the customers, the issue is going to go away. 30% are still going to be impacted. They added any workarounds for the 30%. And if not, how long until the long-term solution is actually applied, the right solution, right? So all this needs to not be packaged and communicated to the whole wide world. So that is where our communication chain kicks in now. I'm going to break it down into phases. So phase one, since we are talking about a customer issue, we are going to, first inform the executive and the sponsors, then we are going to involve any vendors and marketing and support. So the ideal condition is the problem is solved between the group in blue and then you communicate to the customer about how much of it is necessary. You might not need to tell them everything that you know. Sometimes the short-term and the long-term solution will involve design and your actual development team because you are building a new feature to address the problem. So that's why I put it in gray because not every time a customer issue needs to be, like every time you don't need design and development involved. So for legal, not every issue becomes a legal issue. There's sometimes issues are simple, members are not able to do something that they always are doing, maybe not able to view something. So not every time it's like a legal issue. So that's why we need to figure out who are the right people that needs this information and what information do they need. So this is the exciting part about product development where the strategy has come to you and now you need to execute. So you have, say like as I said, there are a list of 12 features that came to you now you are to figure out, so what are these things that I need to do? What are the features? How are the different competitors, how are they doing it and which ones are the important ones among this? So we have a five-step process here where the product discovery, product vision, you prioritize the backlog, present it to the scrum team and then come up with the final roadmap. So for the product discovery, you gather requirements from within your organization, from the member pain points, from various business units who are sponsoring your project, figure out what is it that they want to achieve with this new feature. Then you need to write stories. That's the important product tool that you are responsible for the stories. And then try to do a POC and the user testing on whatever you've come up with so far to kind of validate. Is this what the user needs? Is this what it really is or is there something else we need to do? For the vision, you need to come up. So you have a list of 12 features. So come up with a set of like five, which are the most important among the 12. So you come up with an MVP and then you come up with a whole roadmap of 12, like where do they lie, which which release over how many months are we going to produce this complete set of features? And then what are your product goals? Do you want to increase the number of customers? Or do you want to increase your revenue? Or do you want to just increase your presence in various places? So the competition is a little less. And then how do you kind of track this goals, right? You need to define the KPIs, like what are the metrics that you are going to track to make sure your goals are being reached. So that's the product vision. And then after all this, you are going to prioritize your backlog. Now you have like a set of like 100 stories, which one comes first, which one comes next. So now you have to give it a priority that comes from, you need to figure out, is it valuable to the customer? And if it is how valuable it is, how important it is. And does it align to the business objectives? So it needs to align both for customer and for your internal organization, not one or the other. And then we take all this and we present it to our Scrum team, where they will estimate this whole backlog. And depending on that, like your feature number one, like say, I want to present credit card statements. I have three things. I want to present credit card statements, mortgage statements and debit statements. So my team will tell me, if you do credit card statements, it's going to take me three months. But if you do debit and mortgage, I can give you both in three months. So which one do you want? Which one is more important? So then you go back to this, your prioritization list and figure out why credit card statement is more important than the other two, or is it okay to switch? So that is where you kind of reprioritize. And then you come up with the final roadmap now, which you need to socialize it to everybody in your organization and get their sign off and commitment, saying this is what we have all agreed to, this is when it is going to be delivered and this is the timeline. So now the communication chain is a little different because we are in new product development. So the phase one is going to be the executive and the sponsors. The design and development will help you with the POC and then with the estimation and everything. And the legal needs to be aware of any new feature because of all the regulatory risk that we run generally in the financial world. It might be something else in different industries. So this is what the communication would look like. Then when you are ready with the features and now you want to take it to market, that is when you're ready with the roadmap actually, you engage the vendor. If there are vendors involved, not just an internal development, but there are vendors involved, you engage them for the delivery of this new feature. Then in the end, you engage the marketing support who will then be the last mile kind of communication with the customer. Hey, we are coming up with this new feature present of how to video, send them some brochures, whatever you want to kind of get more engagement from the customers. So this is what the new product development cycle looks like. For the last one. Yeah. Yeah, yeah, yeah. What do you do after you give that to them? They're working for three, six months, whatever. Knocking through every single task you've given them. What are you doing that time? Are you taking on new projects? Yeah. You are taking up, no. So you are taking up new projects and the scrum team will come to you for small use cases that you have not thought of. Or they'll be like, like in our case, there are a lot of dependency on offer. In our case, there are a lot of dependency on outside vendors. Like they'll say, we thought the API does this, but it's not doing it. That is going to impact the design. That's going to impact the feature itself. Then the conversation starts again. Okay, we thought it's going to do this, but it's not doing it anymore. So how do you want to approach it? Nixit, ask the vendors to actually build it, build whatever's missing, or wait for later. So those conversations begin again. And while you are, so what happens is you define the stories for the MVP and the engineering teams are working on that. But the rest of your roadmap, you need to start preparing for those stories in bulk. Like, you know, because I have a story writing framework and it's exhaustive. Like if you write like those many stories for every Epic or every feature that you want to release, it's going to take up all your time. So the requirement gathering phase is the busiest for a product manager and the scrum team, when it kicks off, you have forgotten about those stories most of the time. You just know it's proceeding properly and it's working as planned. But you are focusing on the next set, you know, the phase two release, the phase three release. You are working on gathering information for the next chunk of work. Projects, but how many... So, see, at Visa, it's like a technology company, right? The groups are huge over there. Like, you know, there are like many groups working at the same time. But for something like a credit union where we are in the business of banking, but not really in technology, the teams are much smaller. So the delivery pipeline is much narrower in these cases. So we are like four or five product managers in our group and we have like three teams amongst us. Like, if it's not more than that, like, you know, so then we need to prioritize the work amongst ourselves because not everything is going to get done as we want them, you know, there's continuous negotiation and that keeps happening on our side. You mentioned that the requirement, again, is the manager also attend the day is from... Yeah, yeah, yeah, we do. So what happens is, in my experience, initially when the project kicks off, while, so the most important thing if you are doing agile for a product manager is grooming where you actually groom the stories where the story refers time being seen by the, by the scrum team. So that is where it will be like, okay, this can work, this cannot work. Did you think about this assumption, this corner case? All that will come up there in the grooming. Then the product manager goes back, does the homework and comes back depending on what questions came up there. Then after like, in one week, we have like a planning session when the stories are called play ready, when they are all cleaned up, aligned. At that point, if the scrum team says, no, this just cannot happen, then you throw the story out of that sprint because it needs whatever, there's a dependency, it needs more information, whatever. And the last part of that sprint process is the commit on the day which the scrum team actually commit to that amount of story points. So those are the most important steps for product manager and the daily scrums, I attend sometimes, sometimes I don't, depends on if it's a small team, its interaction is like ongoing. So then the project manager or the scrum master will actually have your back. If there's a question and you are busy with some other meeting, they will come to you and they'll tell you, these are the questions, come to the next meeting, you know? Yeah, those are important. Yeah, yeah, yeah. Those are the most important meetings. The scrum sessions, the daily scrums, stand-ups are important, but more for the team rather than the product manager. Unless like you know there is an issue going on and you are aware of what's going on, then you can, and there's continuous JIRA updates happening. So if you keep track of it, you know what's happening in the team. The chair burned down chat, yeah. Yeah, yeah, we look at that, yeah, yeah. Because if you don't keep track of it, your delivery will be at stake. So I am always having an eye on it because you have committed, right? That you said, I'm taking your money, I'm going to deliver it in three months or six months. At the end of three months, I can't say, sorry, we didn't make it, you know? But we're off. Yeah, yeah, we track all of it, yeah. But the scrum master does all that because this is a enterprise. Like if you are in a startup, the product manager is expected to do all of it. So the product management function, right, in every organization is different. So it depends on the size of the organization, your responsibilities will change. But product management and project are, it can be called in one box in certain places. Like, you know, if it's a small enough team, you can do it. You have 50 people, you can't do both functions. Anything else? Sure. Yeah, go ahead. Yeah, because in our, where I come from in the financial industry, we don't have direct connection with the sales. It's a different channel that they go through. So right now we only focus on the digital customers. So the sales is, for banking is different, right? We have branches and we have digital channels like mobile online, you know, the web, mobile web. So that's why we, our customers are generally the existing customers. Or if we have like some new integrations happening and we know that the new customers are going to come in, then we can communicate to them also. But since bank is very regulatory, you can't really just go and get customers. You need to know them before you even interact with them. So it's kind of very, you know, like kind of restricted on what you can and cannot do. So that's why this is a little different when it comes to the financial industry. Sure. So like you brought a development, I can talk about this here. So like in my case, right? What I'm building some new features right now has going to be released in a couple of months from now. So what is happening is I have, I have the timeline and the budget already. It's been approved by the executives. So now I built that list of features like the, I've done this product discovery, product vision, backlog prioritization and all this has been done. So now the development team and the design team are working on, so for the design, right? The stories have to be a little different because they are looking at it from a holistic perspective. Like, you know, my MVP is like this, narrow. I want to get it done. But like from my design perspective, let's see. Like, you know, like we want to offer like free, if you lose your car, right? We want to offer free shipping to certain segment of our customer base. So, you know, for, I'm saying, we'll just do free shipping. No, I'm saying we'll do free shipping, but for seven to 10 days is our normal shipping cycle. But we can offer expert at shipping, but it will cost you. So the another use case that came to us is like, design team brought to me is like, what about our high network customers, right? Like we should offer it as a free service because they are our cherished customers. I'm like, fair enough. So they built one workflow for this platinum customers, if you call it. And for them, we are not going to charge them the expert at shipping free. But it's not a part of my MVP, but I have to let them design it because they need to come up with a complete design on, you know, like it's a worldwide open for them. It's not something, I'm stopping them from thinking. Like, you know, because we need that thinking, right? We need to think of what are our other options. So that's where design thinking comes in and that's where the designers or design stories. I don't give them too much restrictions because I want them to come up with more information, more use cases. But on the other hand, the development stories are very tight because if I tell them take left and then right, they'll say it will take 10 hours. If I say take left, right, left, that is 20 hours. Okay, no, we are not doing that. We are just doing left and then we are doing right. And that's it, like, you know. So that's where the communication is in the stories between design and there. So what happens is now I'm designing this feature, right? Now there's going to be some disclosures around it. So my legal team and my compliance team needs to know what that feature looks like. What kind of error messaging are you going to do it? In the error messages, what text are you using it? And then my sponsor will say, I need to be on it for the review. So I went, this gets designed and even before it's get developed, we are already working on the content. So I am not going to write that content. My marketing, my design, my sponsors are going to write the content, you know. So they need to know what I have asked to do and what's happening and what are we going to show to the user when action actually happens. So different information to different groups. And then like, so this feature, right? So there is one of the workflows where we cannot expedite the card. Even if I want to pay for it, I cannot expedite it. So now I get my marketing and my support. Like somebody will call, hey, I want to expedite this shipping. I'm not able to do it online. So I need to already, it's called a known issue. I'm already putting it in my FAQ area or some info area in my app that there are limitations to this feature and we are working on it, making it better or something like that. So we already published that information, the handicap that we already know. So that is that communication for those groups, you know. So it's same. So interestingly, we think that the whole organization is a friendly place and we all are brothers and sisters. It's not like that. Every project has to be funded. Every new idea, we call something called a business case. Why it is important? What is it going to bring to you? Why is it important to the organization? And why is it important versus all these four other projects? Why should this come first and why should this come next? So the sponsor or the business unit sometimes works directly on their own and their own silo presents this option to the CEO, to the CTO, depends on the executive team, gets it vetted through and then it comes down to us. Sometimes in this green field area, like the strategy that I'm going to talk about, that is like a joint effort between the digital and the rest of the organization where you will kind of work together to find out why it is important and especially the digital-only initiatives, you need some backing from the rest of the organization. So if you present a digital opportunity and if it's not going to benefit anybody in the organization, it's not going to go anywhere, right? So you need to start evangelizing it and then get the project approved. And then there is some organizational, you know? Yeah, yeah. Oh yeah, so it depends. So sometimes we do certain projects because we have SLAs, right? On when a complaint comes in, how soon should that complaint be resolved or how quickly should that information be shared back with the customer. So some projects are like, if we don't do this, we are going to be out of regulation and we need to, it's like process improvement. Some projects are process improvement, some projects are like being even with the market. Like Bank of America is doing this, we are two years behind Bank of America, like let's get it done kind of thing. And then what is it going to bring to us? Like why is it better? Because sometimes it is, the contact center will get less number of calls. We will need less staff to manually process all this information. So that's why we are digitizing all this. It's not like the process does not exist today, but it's not efficient. So some of the projects that come from sponsors are generally like this. So now the digital team in this space is the one who's forward looking on what should be like, you know, we start a new idea rather than it coming from somewhere else. So that is where our strong point comes in when we do the strategy and the growth prospects for the organization. Yeah. So I will tell you from at least the way I do it, I get the hard data from, unless you are doing something groundbreaking which has not done before, then there is no data. Then you is what you think, what your intuition tells you. So what we do is, yeah, so we have different channels. We have a social media channel. We have surveys, we have contact center, which all this information, all the complaints come to us through all these various channels. We distill these complaints, we make a list in terms of which area, what complaints are coming, and we take the top five and figure out how to address these problems. So that gives us one set of data. The other set of data for this newer inventions or innovations are, I do industry research on what the industry is saying. You have this paid reports from a few places where you can actually get more industry insights on how small places are actually achieving a lot more. So that gives you more motivation that if a small 20 million bank can do this, then we are much bigger and we should be able to do it, and we might have better results because we have a, I'm at a credit union, we have a mission. We are a not-for-profit, right? So we are for helping people achieve their financial dreams. So it's like a small for-profit organization can do this. We even have a better concept going here for us. So we can do this and actually take our organization higher. So you take the industry research, figure out what your customer problems are, and how like, you say AI or VR or like, does it even apply to you? Great if other banks are doing it, but does it apply to you? Does your customer base want it? And if it's like a maybe situation, I don't know, like loosey-goosey soft thing, then try to get a POC going and see if it even matters, you know? It might not be even hard-core PAC. It might be some using one of those, make your small little app and publish it on a few mobile apps, you know, like just click, click, click and create your apps. It might be even that. Get it tested and see if it's even there's an appetite for this. If it's not, then you are wrong, move on, you know? Don't invest everybody's time and money on this. So when there's no data, you might have to do some testing. But most of the times, there is some sort of a data available. If you need to look hard enough, anything. We kind of covered a little bit of this already. So for the strategy and roadmap, that's what I was saying. Like we do the industry research, figure out what your predictions are. Like there will be like a report saying, 2017 forward-looking predictions for finance industry or 2018, first half, second half, there's a lot of information out there. Also, conferences are relevant. If you pick the right conferences, you will get a lot of interesting data and knowledge on what other people are doing and how they are thinking about things. I like depends which ones you go to, but I generally like to listen to them. And slowly, and also YouTube, I was doing some research on my own, one new strategy I'm coming up with. I just shut myself off from everything. Tell your manager I cannot think of anything as I need to think of only this for one day. Put the YouTube on, find the right videos and live in that world for a little while. You know, like let it percolate in your mind. Like you should start living and breathing it for a while. Sleep over it and then think about, okay, I know my problems very well. So that is, this is where the first challenge about customer issue helps. Because when you talk about that customer issue, right, it's like, production support is like, I'm a product manager, why am I doing production support? Well, you are in a new domain, you are in a new industry, you don't know anything about it. The production support is like your closest, your closest to your customer at that point. And the production issues will come from different areas of your product. It's not going to like, oh, I'm an expert at this and no, it'll come from everywhere. So that will help you learn the product. So if you're getting that kind of like technical product manager or some whatever flavor of it, and that is your segue into product management, take it. You got nothing to lose, you know. And you will learn about the product and when you are actually thinking of the strategy that all those problems that you have handled are going to come now into play. Because now you know your customers, you know what they want and you know what they would like to see, you know. Okay, it's gone again. So yeah, so you come up with some assumption saying, I want to apply this new technology to my customer base. So great. Then you are like, how does it, what happens to my organizational goal? Is it going to help it? My business plan for 2018 says, I need to increase selling these kinds of loans, more loans, I need to sell more loans. So is this strategy going to help me do that? You know, is it true? So you need to evaluate it. And the bigger impact amongst your business units, the better buy-in you will have for your strategy because the more people can use this technology advancement, the more people are going to be interested in it and you will get a faster buy-in. Then you perform the financial analysis. All this is great, great thinking, but what is it going to cost me? Should I buy? Should I build? Should I partner? What is my initial investment going to be like? What kind of people do I need for this? Do I already have them in the organization? Do I need to hire more people? And if I put the investment today, how soon am I going to be profitable? How soon am I going to see money back from this investment? What is ROI? So you need to be coming up with some numbers there. You don't need to do it yourself. You will have somebody in your organization help you with the financial, but you need to give them what you are thinking and they'll come up with the numbers for you. Then you are going to define what the success of this idea looks like. Then how are you going to assess it yourself? That is where the POC comes in, right? So you build a quick and dirty POC, see if it even is worth it, and then you also put in what kind of KPIs are you going to track? Because you will say, if I don't bring in 10 new customers in three months, means this project has failed, it's out of the box. So you lay it down for yourself, keep it real for everybody, right? Don't keep trying. So the KPIs, if you design it as a specific to each major feature, what will be the product or a whole product? No, it will be per feature. It will be per feature. Because see, like if you have 10 features, right? And then you think that two of the 10 are going to be high performers. You'll set some KPIs for that. But it turns out that the number three and four are actually doing better than the one and two. So you start focusing on three and four and deep prioritize the one and two. If there is some new work coming in that area, you will say, no, the three and four, I should give it more importance because that's what the customer wants. And the one and two is say, nobody's using it after like some six months of maintaining it. You have to decide to kill it, you know? Yeah, yeah. You just say, okay, nobody's using it. Forget it. Let's get rid of it and maintaining it will also cost you, right? Yeah, yeah. And then you have this wonderful idea. You have the financial analysis done. You know it's going to work. Then you share your dream. You create a vision, mission strategy and then you start getting buy-in from, so that business relationship that you have built in the first two sections is going to come to use now. Like you start talking to them, hey, look, you already have a good relation because see, I helped you with this project. I helped you with that project. Now I have something for you. What do you think about this? Can you help me, you know, make it, promote it so I can actually get people interested in it? So that is when, so this is where the chain gets activated again. The famous chain is here. So now here you are going to, there are going to be three phases. First you need the executive sponsor sign off and then of course the help of the engineering teams to make even your POC happen and give you some estimates on the financials and everything. Then when it's agreed upon, you get the design and the legal involved. And of course, engineering also will be involved at that time. Enterprise architecture, yeah. And then the vendors will also, like sometimes you have vendor dependencies so you want to involve them and give them a heads up, hey, this is coming down the pipeline, not today, but it's coming up like, you know. And then in the end you take care of your customers through the information to marketing and support. So the three phase approach to this chain here. It's a generally, it's generally an architecture function. Generally they are the main players in it, but there are different people involved, especially when the technical buying a platform or something, then there are information securities involved, you know, then there are, the development team is also involved because after you buy the product. I'm also involved. We did one recently and I'm also involved because I am setting the vision of the product. So I need to make sure that the product, yeah. Yeah, we what, how we did it is we created like an RFC. We created like a list of 100 questions for 10 different teams. And then those RFCs were submitted to like around eight or nine vendors. They gave the responses. We took everybody's inputs, weighed the inputs and pick four finalists. Out of four, we picked one and that's how we went about it. But yeah, sometimes the product manager is not involved. This is a perfect, this is a good scenario. But sometimes the product manager is not involved in the vendor selection and that's a very different story. Then you will see problems which would have been addressed if the product manager was involved in time. It's not all, doesn't happen all this, especially for industries who are not used to the digital product managers yet. They have these issues. No, no, that's a, there is some sort of a code review. We do run some sort of some tool to check on the code for certain things. But it doesn't go as far, yeah, with between engineering and architect that gets resolved, all those issues. What about like releases, packets? I don't know, patents, oh. I haven't seen patents coming from our place, no. Not, I'm not, not aware of it yet, no. Okay, so key takeaways. What did you learn after all this talk? Know your customer, keep an eye on the data, collaborate, build relationships. Focus on clear and custom communication. And in the end, if you don't know what to do, where to go, think about your vision strategy and roadmap and follow that as a guide for whenever you are making a decision and you are not able to make it, think of why you are doing this, whom you are doing this for and what do you want out of it. So that is like the, because product management has to make like decisions every day, many decisions every day. So how, sometimes you will be like, I'm not sure how this goes. So that's when you think of why you are doing this, whom you are doing this for and what do you want out of it. And that will be your guiding principle. Yeah. So that's what I was saying. When there are these brand new products, you rely on a lot of like testing. Like I was listening or reading about Uber and they are like, you know, they went, they did not have the digital technology build when they started. They went like, they went driver to driver asking them what, if they would buy this and what would they need to buy this? Like, you know, and then they Uber wanted the driver to have this phone on them, right? The smartphones were not that popular a few years ago. So driver says, I don't have a phone. So Uber actually gave them the phone, like, you know, so you need to actually do this, the old fashioned way when it comes to new products. Like I've been suggesting to a friend also, like do it on paper, whatever you are trying to do with technology, first do it on paper. See if it works. See if it, it's a little bit more effort, but you know, like take the form submitted, go here, go there. But see, even if you get one transaction on it, value when you do this, that's a like a motivating, inspiring thing. Like, you know, then you will say, okay, there is a market. Now I will develop the technology and now then you run some tests on. So that's why MVP is very important because you don't want to build, build, build for two years. And then, oh my God, this doesn't work. So build, build fast, fail fast, you know. First run it on paper, then do a little bit of MVP, test it out, and then kind of decide at that end of MVP, okay, is this worth it? Should I go for funding? You know, what is my market? Because I worked at the Citrix, start the Pixelated 2 for a little while. The first question the venture capitalists ask is, what is the market size? What are you, you know, how much, how many people are going to buy this? So that was a good lesson. Like there were 10 startups there and I was, and everybody was like, oh, this is a great idea, but we don't know what the market is. So they were helping them figure that market out by doing all this testing and all that. It's a blow hot, blow cold relationship. So they are partners for sure. I worked in different places because I have come from engineering background. I'm able to establish the rapport easily with the engineering teams because I understand them and it's much easier. But generally what happens is, if it's a good engineering manager, they can also do things that you are doing, just that they should have the cycles because they have like 10 projects running, while you have like three projects running, you know. So most of the times, there should be a well understood code of partnership that the product gives the vision and the engineering takes care of the delivery. And you are welcome to challenge everything the product says. There is no harm in that. Everybody should challenge the product because that gives you the good end result, you know, a good product in the end. But sometimes it is very good. Sometimes it is like a little rough. It depends on the personality also of the engineering manager. Because end of the day, as you see in that communication chain, it's a lot about people. Product management is a lot about people. In engineering, it's at least less focused on people, you know. Yeah, the goal is different, right? The product manager goal is to build the best product and the engineering team goal is to deliver the product, right? So whatever it has. Oh yeah, there is always a handoff that that that will happen. Like, you know, oh, this feature has been requested, but you don't think it's the best option. And you kind of find out a way to do it or at least like, because I did it, like I had this list of 12 features to be delivered in six months. I'm like, this is not going to happen. Take the whole estimate of the story points and tell them what can happen and tell them what cannot happen and why it should not happen. If you have a very data kind of... Yeah, yeah, yeah. It's real life. Yeah. So vision is like, like, you know, you want to be offering the best loan products amongst all the credit unions. That can be your vision. So loan products amongst the credit unions, right? You can say that I want to be the best loan provider amongst the credit unions. That is your vision. So strategy is like, okay, so what is needed to do that? So do you need any new technology? Do you need, how are you going to do this? You need to build partnerships from outside. You know, how are you going to become the best loan provider? Because in the FinTech space, there are so many people doing so many different kinds of micro loans and all that. So how are you going to make this happen, right? So do we need a technology? Do we need new partnerships? What kind of support do you need within the organization? So that will be your strategy. And the roadmap is to dilute the strategy into like a real execution plan. Like, you know, I need this new technology by three months. Then in the next three months, I need to build partnerships. And the next three months, I need to actually start seeing people coming in through this partnership. So that's the roadmap. Oh, no, no. Visa is a very big organization. So they, yeah, their stuff is very different. But yeah, the business model canvas, that is used a lot by startups. And sometimes even I refer to it when I want to come up with a strategy and all that. It helps you think clearly, like, you know.