First 90 Days as a New Product Manager by former Flipkart PM

[Applause] really happy to be here thanks for the introduction Sam like he mentioned I've been here before I love the energy in the room so here's to another good session my topic today is first ninety days as a new product manager I think this is a very pertinent sort of topic to speak about as more and more of us are passionate about product management and we want to enter that industry and into that field as a product manager I always like to start with the why and so I want to give you not one but three good reasons why it matters to have a plan of attack going into a new job first one you're either trying to be break into product management it's your first stint you're trying to move up the ladder you were historically an individual contributor and now you've suddenly become manager moving into a role which is more managerial whatever the case may be a plan of action a plan of attack always helps and having a plan for your first 90 days sort of cements your role and your place in the new job second the earlier on you establish yourself the earlier on you define your role and the impact that comes with that show the better you will set yourself up for success later on and so it's really important to build credibility early on to build those relationships early on the third as a product manager and this is just by virtue of the role we play it is so cross functional and so multi-dimensional that there's just a lot of stuff that needs to get done before you actually jump into product management and so a plan of action will help you focus it will bring discipline when you start that your job so to summarize plan of action will help bring discipline it will help you focus and it will help set yourself up for success okay I'm obviously here to impart some of the insights I've gathered through several of of my product rolls so just to talk a little bit about me I've worked with small startups I've worked with unicorns I've worked with startups that have exited I worked with startups that have failed b2b b2c I work with teams across the globe Berlin China India the valley so different cultures different types of personalities and I've you know being had had the fortune of being the first product hire for some of these roles and then continued on to be one of the 60 or the 70 product managers so I've seen sort of that mix mixed bag of roles and so I've sort of synthesized all that I've learnt in in the past several years and try to present a plan of attack for for you okay again trying to bring my PM mindset I've tried to limit the scope so given the audience that are anticipated would be here I've tried to cover topics that will help aspiring PMS and mid-level PM's also try to sort of have the agenda be the lowest common multiple things that will help everybody across the board whether you're internal tools p.m. or a consumer facing PM like me so these are the five things I want to I want to talk to you about what should your first 90 days be about especially if this is your first old where do you begin how do you start what is your first step how do you build relationships with teams and people this is very very cold to product management at the end of the day as a product manager you are managing people you are managing their ideas their expectations their time and their personalities so it's very important to build good relationships should you introduce process especially if you have the first hire should you introduce process if you're the second third fifth hire and if yes when when is a good time to say I bring this to the table let's implement this when should you start thinking about the product vision the product roadmap again I'm not looking to talk about how you should build the roadmap specifically but when should you start thinking about it on in your new job or your new role and then I'm going to briefly touch upon while you are doing all of this it's always good to check and see whether you're going in the right direction and it's always good to measure you know have a checkpoint measure and see how things are going for you so let's get started again we love frameworks so what I've tried to do here is I've tried to take something that I use specially in data mining and just generally initiatives at work and I've tried to apply it here to distill everything I wanted to communicate to you so it's an it's a look called the OODA loop I don't know if it has anybody heard of it okay it's the I'll talk about it it was conceptualized in the 1960s by somebody in the US military I think I believe a journal a general or a colonel I forget but this is really really key to looking at data and distilling of breaking down problem statements I usually use it and that's what I've done here the first is orient yourself this is a new surrounding for you a new ecosystem a new environment new people and new tasks orient yourself do not rush to implement stuff do not rush to start you know I want to build my roadmap wait and try to get your bearings around orient yourself set yourself up for success step one step two observe listen and learn how is your company operating what are the gaps what are the strengths how is this sprint process is it two week is it six week why is it like that how does the engineering team work with the design team is that a contractor designer or is it a full-time learn and observe and then learn some more so basically learn the lay of the land third step you have a lot of information as you're collecting that information assimilated and use it to start guiding and building your product strategy so you're obviously there to own a product owner feature owner charter start funneling these learnings into that and the last one is execution this is the part that's meaty that's exciting that's you know what we we are in it for so it's the act so orient observe decide and act and that's how I'm going to proceed through the presentation it will be one or the other of these steps the first one when you're setting yourself up adapt to the tools and the software's that your company uses you know is it amplitude is it on nature is it SQL is it for example you need a mind data what other software does the company use to visualize data to visualize roadmaps to communicate with engineering team set yourself up for that the other thing you should also do is try and get as much as you need to succeed so for example when I went to one of my roles I realized there was no EB testing framework and I felt that it would some of my product initiatives had I not had an a/b testing tool at my disposal so I asked for that and I got it so if you think there's something that's called to your role something that will sort of hinder your contribution to that role please feel the need to ask for it and obviously justify it but set yourself up with all the tools and software's and be ready step to whatever platform your product is on Apple watch desktop mobile side native apps whatever the case may be you should start aspiring to know the ins and the outs of that product what are the design inconsistencies what are the bugs what are the bugs that you know will never get fixed what are the critical bugs that need to get fixed where are the experience gaps what are the flows that work well what are the design elements that do well you should start familiarizing yourself with all of this and like somebody said as a product manager your forte is that nobody knows your product better than you do that is what at the end of the day you bring to the table right you should know your product like nobody else so start that process early data I am a big big believer in data you must know the top metrics the trends that your company needs to know whether it's competitive landscaping or just internal trends this business is seasonal we always get our maximum orders on Sundays there are hours of the day when we send push notifications and they are clicked very higher than if we would send them at night you should start familiarizing yourself with all of these things not just that what are the metrics that matter to your business for example when I was at Flipkart we were at a scale where we had penetrated the entire Indian online market so our metric was not user acquisition it was user retention what is that metric that matters to your company you should speak that language third who are your users what do they look like where do they live how do they shop when do they come to the platform why do they come to the platform how many times do they come to the platform what are they looking for how else can you serve them it's all stuff you should start thinking about poking here and there start you know looking at documents looking at data this is a tip that I usually generally share with all my p.m. friends and especially aspiring themes let data tell you its story I've seen and I'm guilty of doing this early on in my career as well torturing data to tell you something you want to hear don't do that let it tell you its own story and use it to your advantage okay step two so we have oriented ourself we are into the ecosystem try to observe what is the protocol so how does your product team or your core team whatever is your core team how does it build features how does it think about product how do how do the internal product team members work together to build stuff how do they ID it how do they brainstorm how do they prioritize how do they give each other feedback how do they collect feedback from stakeholders who do they consider as their stakeholders how do how do they decide that for example stakeholders could be user stakeholders could be internal stakeholders like the business function or the marketing team or the engineering team or the logistics or the operations team how does your team think about all this how does the team interact start learning the ropes start seeing yourself in that role in that team and as you observe obviously try to look at the strengths and the weaknesses but at this point be an observer people like I'd mentioned earlier I strongly believe product management is a lot to do with people management observe who are the different stakeholders in the company like I'd mentioned earlier when you start diving deep into that you will realize you will have a multitude of stakeholders with multitude of personalities and needs and demands and they will all work with different working styles and different timelines you must also answer I understand when these stakeholders come together as a group under under the company's umbrella how do they interact with each other so who's who who are the key decision-makers who are the influencers what are the dynamics and also I'd like to point out build empathy for each of your stakeholders much like you build empathy for your customers who are also of course a key stakeholder empathy for the design team build empathy for the engineering team with empathy for the business and the marketing teams and the operations and logics logistics teams it'll help you be a better product manager this is the tip more than an action item like I said observe and this is something I've sorted I try to do more and more I try to be a fly on the wall so for example when the design team is doing a mood board I try to be a fly on the wall I don't want to give them any comments I don't want to give them any feedback but I want to understand how they do this creative process what are the metrics that they think of what are the user experience gaps that they want to plug how is it that they are prioritizing one thing over the other it's really important for you to be in the shoes of the people not only you serve but the people you work with because you are the hub to many many spokes that is how you will make impact as a product manager so try to be a fly on the wall even not just for your first 90 days but time you know once in a while try to observe what's happening in your teams the teams that you work with and specially and specifically for the first 90 days do not judge why our team works in a particular way or by its at six week sprint versus a two week sprint ask questions and try to answer those questions around around some concerns you may have but don't judge at this point it'll distract you from your plan of attack step 3 so we are gearing up towards the meteor stuff you've learned a lot so at this point I'd imagine you know you're starting to think of the product that you've been recruited for the vision for that product you know you're building the strategy while you're assimilating all this these nuggets of information so you know you're reading API documentation you're getting familiar with the stair the tech stacks you're you know reading past a be tests and how they were conducted for example you know you're really looking at your customer personas and saying this this is a mind map for the for our main customer you are sort of and this is something I've done before and I find we really useful you you go on site so you know you spend a day with your customer experience team you spend your day the operations team you see them live in action feel their pain you're assimilating all of that information it's a lot of information also on the right as you will see you do a lot of asking why have we made these decisions today and why did we make these decisions in the past what was the rationale why did you pick this variant over the other even though it did poorly what are some of the design decisions etc so you're asking a lot of these pertinent questions also you for example are you know participating in retros so you're trying to really understand what are the gaps in the deployment cycle today how as the product manager of this feature can I up the game how can I make this process more seamless how can I get introduced better prioritization techniques what can I add to the table so a lot of assimilating of information as a passive observer a lot of information you're assimilating by asking proactively while you're thinking of the product strategy so you're doing a lot so keep before you actually spring in an action don't lose out on all these nuggets of information synthesize them and keep documenting them ok the fun part begins so you're doing all this homework you're preparing yourself it's very important especially in larger teams or when you are not the first or the second product hired to really understand what is your role more often than not you'll find that there is a p.m. who's doing something that sky of what your charter may be and again this is a problem of bigger companies but if you happen to have that just as you know a principal always define your role especially if you are reporting in to somebody I understand what are the expectations from you what have they hired you fault what is what is the needle that they want you to move start with that define your charter let that be step one step two make sure all your key stakeholders all the people that you're going to touch whose lives you are going to impact are aligned on that as you're building and thinking of the roadmap and then this is a part of the research that we spoke about earlier which is you've identified your customers you have identified your stakeholders for your product this is your product now you're in your product email domain and you've built empathy for a lot of these stakeholders so you've understood your role you've understood your charter you know who your stakeholders are they're aligned with what you're doing where your vision is going and your base obviously understood your customers are in the process of understanding them and building empathy so now you're focusing on your product domain another part of step 3 or decide is setting the stage now you're getting closer to defining the tangibles setting goals for your product what are the KPIs that you own what are the KPIs that you are accountable for what is the cadence so who are your immediate stakeholders what is the cadence of meeting them how do you funnel and feedback from these people how do you funnel out feedback to these people or your roadmap to these people what does that feedback loop that works is that a weekly meeting is it a monthly sync up and then get ready for step four which is act this is like I said the really really fun part this is what we all love to do it's getting our hands dirty and what I mean by that is executing so you've picked I'm sorry I forgot to mention that so once you've identified your product domain you know what your Charter does specifically you've defined goals for it and you know for example say at Flipkart I was responsible for user engagement I knew what my goal was so I had set goals for myself I want users on the flip card platform to come back four times in a month this is a hypothetical arbitrary KPI say for example I've said a measurable goal for my product I know who are my immediate stakeholders for the first thing that I want to ship in the 90 days and we must aspire to ship something or at least get something rolling in in motion within your first 90 days so once you've done all the first three steps prep yourself to start shipping something or get something in motion and this is that part so getting your hands dirty with actually shipping something with the team this could be big or small doesn't have to be a six month one year feature it could be just optimizing for the login experience and adding email verification to it because so many accounts are lost and people have a bad experience because they forget to put a dot before the call and then they have to keep creating multiple accounts maybe you're solving for this so get your hands dirty execute on something and then don't forget to measure it I want to emphasize on this because I feel like we forget to do this for ourselves we do it a lot for our products where you know we have a KPI and we say we met B you know we anticipate a 20% increase in login conversion but it didn't happen or it happened and we define success by that but as PMS and when you're implementing this plan of action do measure success for this as well so when you execute this particular feature or this initiative however big or small it may be go back and understand what you did right in what you did wrong and this is really important so that if you don't do this if you don't listen to feedback if you don't measure your success if you don't measure what went wrong and what went right and you don't learn from it you will never push yourself to I trait and why that is really important is in our business it's really really really important to build credibility so I'll give you an example I'm a non-technical product manager and it's very very important for me to build credibility with my engineering team and you do that by listening by learning by improving every single time so whatever company you work with how whatever your role is whatever your Charter is whatever your product domain or KPI is make sure that you're constantly trying to take information assimilate it understand it and use it to better yourself as a p.m. whether it's building better relationships or it's you know building empathy for your customers or it's looking at data in an unbiased way make sure that when you launch something you go back and say I didn't set the EB test right or I didn't work with the engineering world and push yourself to do better and I'd say that the goal of this entire exercise is to really build credibility people have to trust you to hand you over a product and its fate so you have to do a good job of that so I've said a lot I'm sure it's a lot of information what I've done is I've actually tried to really everything that I've said in a summary format with a timeline so 90 days is about 12 weeks I say and again this is notional it could be plus/minus but start with setting up because you are not going to get time to do this again I remember at ship when I join my second day I got something that I had to ship in the next three days and if I look back in hindsight had I had more time to sort of set up I would have really you know gained from it not that I didn't enjoy jumping into execution soon but use this time if you have the time and the bandwidth set yourself up with all the tools all the software's all the data dashboards that you want familiarize yourself top to bottom be a fly on the wall see people notice their personalities how do they work how can you motivate them in the future what are their styles what motivates them you know how do they work with the product team how does the product team work what are the processes they use what's the protocol do all of that start learning the ropes so from being a fly on the wall try to be a more active participant start building your vision so once you know what your role is what product you've been hired for what is your exact Charter start building the vision start building your roadmap start looking at what has been accomplished so far why that was done set the stage for you to ship something or at least get the ball rolling in terms of splitting the time I'd say this would be the rough sort of let I'd imagine if I look back at all my rows again this differs from person to person circumstance to circumstance and like size of the company and who you're working for how many PM's they are but I'd say spend you know the first half or slightly less really trying to orient and observe you will not get this chance and this time to do to do these two things later on it will get very more difficult and then spend the the latter half of your 90 days trying to focus on why am I here what metrics do I need to move how can I do that what's more important how do i prioritize who are my stakeholders how can I build empathy how can I keep that loop going and when should I stop and measure myself and then actually act try to ship something and build that early sort of trust with your team members and then learn very very quickly from it so that the next time you do it or the third time you do it you're really the better for for having done it early on I hope this helps everybody who's starting a new stint put their best foot forward and I'm happy to answer any questions that you may have notionally yes so at the same time you you know if you aren't right how are you adapting because you're right right right and this has happened to me before so if I understand your question correctly it is that you've come in to step into another PM's role so there is a backlog already this is you're not starting a product from scratch it's something that's already in motion I'd say at that point you'll have to juggle these two things and maybe it's not a week of orientation like I said I got like two days or three days of orientation the orientation that I've find here which is usually get time to set yourself up but software is and tools and stuff like that at that point you basically juggle but what I'd recommend is to not lose sight of this plan of attack to not in that process of jumping into you know executing on the backlog of the previous product manager that you lose sight of the fact that you are a new entrant into the team that you still need to build relationships that you still need to understand the protocol that you still need to get into the groove of you know this is how I work with the developers and this is how I motivate the designers because that is a large part of what we do and I think somebody I forget the name but somebody's articulated this really well product managers are the only people who don't have a direct work force under them but they still have to lead or influence a large group of people and it is not easy so that starts with building the wrapper early on so I'd say to the situation that you described I'd still juggle being a fly on the wall and executing whatever is in motion did that answer your question sure sure sure yes sure J right right right that's a great question and I think that just happens to happen throughout you know senior or mid-level or early product manager conflict management is something we just have to keep getting better at and what I'd say to that is dring let it not be a me-too discussion and what i what i mean by that is everybody in the room is saying I think it should be this and I think it should be that I think as a product manager what you can really do differently is bring funnel insights from data and funnel insights from customers and funnel insights from metrics so for example if somebody you know is saying we shouldn't focus on the home page viewed should focus on I don't know login one way to think about this is how many people use how many new users do we get every day versus how many users use the home page step one look at the data if we were to improve this versus this what is the impact and what metrics are we you know trying to hit so when you get all these sort of data points and insights and perspectives into that conversation it's less about what you want versus what the other person wants its what are we trying to solve for and what will solve it better and it's I think another thing that I've learned over the years is fall in love anything somebody said this in another talk that I'd heard is be in love with what you're solving for don't make the solution your baby so don't be in love with what you think is the right solution be in love with the problem and sometimes that helps to resolve some of these conflicts as well so bringing these unbiased perspectives bring in these insights bring in the numbers to talk and build the story and sometimes that really helps manage these conflicts yes sure again I think it really depends on how much process there is when you join so for example in one of my roles when I joined there was literally no process and so for you for you in order for for you to be successful in that first feature that your ship or the first initiative that you that your ship you need some of that process you need may be a sprint there is no sprint or concept of sprint you need a proper queue a time for QA you need things to be designed for you know in a particular manner and so it really depends the stage at which you enter and what it is that you're shipping so for example if it's an internal tools your internal tools p.m. and you're changing something to the admin dashboard for example maybe you don't need to process a Phi as much as you would if it was consumer-facing and you know again depending on the scale of the company if it's a million users versus like 10,000 users so process definitely helps but depending on the scale of the company and the stage of the startup process affine too much also doesn't necessarily help so you have to really listen and learn and see you know what what will work and again this is a trial and error process also sometimes when there is lack of process you really have to try what's going to work so it depends on sort of just the situation but process really helps so I'll sort of guarantee that process helps so if there is no process whatsoever getting it into the picture will help streamline things yes right right right again a great question and you might have to do this time and time again as new people join the team and prioritize a priority is shift and you know there are new executives on the board and stuff like that I think one thing that that really helps is showing documented impact so you know look at what you've done in the last six months really again with an unbiased lens look at what you've accomplished so for example you know I'll give you an example of something we did at shift where we introduced a pop up which asks you to rate the AppStore given up App Store rating while you're inside the app and only if you give it X rating does it follow it follows up with a question or it accepts the rating and there is some logic to when we ask you that App Store rating question now this took our app ratings from whatever it was to four point nine right and this is a tangible impact because this is the storefront so when your window shopping in the App Store and you're looking at all the on-demand grocery services you will look at the reviews and say this is a four point nine and that's a three and so we are really creating a better first impression that is a tangible impact and so when you have these conversations or when you are trying to really highlight or bring to the forefront the impact that your team makes you should look back and say these are the big initiatives these are the things that we we are accountable for and this is what we've done for those things it could be better user experience it could be better funnel optimizations it could be the money that you've saved for example when you optimize for a login and you better that conversion you are actually saving marketing dollars that's tangible impact so bring that to the table bring that into the conversations and bringing having that mindset also helps when you are aligning stakeholders so when you when you build a business case for a product initiative and you say I think we should add this to the product because it's going to impact 70% of our repeat users and it's going to save them X seconds every time the search for something and this is it's going to lead to bigger baskets you will have more interest and you'll be curious 'ti versus saying I think we should build this so try to bring some of those things to the conversations and and sometimes this may not work but you should keep at it and at some point this will start becoming the language that that the stakeholders will sort of respond to so we use clubhouse I've used JIRA we used Clubhouse currently and my current role and the definition of done you bring up a very good point this is again something with years of experience you will realize that it's really important to define what done is and so we have a QA team who writes they write their own you know test coverage and own unit tests and they have their own mechanism of queuing so our team the product team doesn't do that but the way we communicate is there is a product brief document which basically says what's in scope and what's out of scope so for example it will say we are trying to do a but we will not do B and we will not do C so it very clearly says that the other thing that really helps with that definition of done is when you have a testing plan so you say for example I'm going to launch this in these cities or this member base say you are testing something I'm going to roll it out for two weeks or till it hits a hundred game users I'm looking for this metric to move by X percent roundabout and I don't want this metric to drop and if this product once launched for that amount of period and exposed to those many members hits those two metrics that I've defined it's a success and we'll roll it system-wide so it's you have to be very very clear crisp and communicate that to the team when you're launching these products what it also helps you avoid is traps so this is where if you don't have a good testing plan articulated or the definition of what is done two things will happen first there will be scope creep what that means is you wanted to build a but you will be let's do B also while we're doing B let's do C also and then it'll become a never-ending thing don't fall into that build trap and the second thing if you don't have your metrics and how you anticipate the impact on them with a particular product feature you will post facto torture data see it's doing this to the login rate when the product initiative is on checkout and you'll try to like storyboard these random things and you'll try to say it's a success because we all want successful products don't fall into that trap so define what is done and define what is success I hope that answered your question sure okay right very good question so credibility at least in my experience so far doesn't come from all being a good PM of course it if you keep building bad features it's not going to look good to anyone but failing on something oh taking a bet on something in it not working is absolutely normal I'd say and again I could this is anecdotal 7 out of 10 things don't work the way you plan them or you will you will think that this is going to do X but it'll end up doing Y because as much as you know about your users you really don't know how they're going to use that product and that is why you see products pivoting why do products pivot it is because you thought people are going to use it in this way but users are using it for something else and that is why products pivot so what you should in that case do and the mindset you should have is why did it feel did I was I looking at the wrong problem did nobody care for this solution did I do my user research wrong did my designs not live up to the expectations are they not intuitive did people not want this was I too late in the market and there are better solutions for this there could be so many reasons for it so look at focus on the Y and use it to inform your next initiative and that's why I'm had that slide on once you ship something check in on it like listen to what's happened measure what what's moved why did it not move and what you can learn from that to do better in the future so do not feel disheartened or discouraged or question your product management abilities at all if any bet that you have taken like doesn't live up to the expectations that happens to the best of us and in it has to happen we we can't predict the future but what you should do is learn from it and understand as a product management what you you did wrong and what you can do better next time sure right right you got all these demands right how do you recommend managing up and managing down so that you can integrate but then also deal with these personalities right uh I think it's very similar to the question he asked and I've again I've had to deal with that many times over you just have to it's something that needs to get done so maybe you can be a fly on the wall for two meetings and not five or maybe just one meeting the other thing is if you know doesn't you don't have time you're just pulled into like five directions use that as an opportunity while on the go on the field while you're on site use that opportunity to really learn people maybe don't be the let me do this you know know-it-all personality don't come across as that and sort of start delegating to people maybe take time to do that and let people drive a fair portion of the project really understand you know again how the engineering team works what are their sprints maybe they do a six-week sprint you come in you observe them for the first project and then you start you know hinting at them that maybe we should try it two weeks or maybe we should do this with that would be my salute Lee still getting that to stakeholders and sure so I'll answer that in two parts the first part absolutely just to speak to what you're not Henry Ford articulated that happens all the time your customers will be you know they'll they'll say why don't you build this and thousands and thousands of them will say why don't you build this X thing what you need to understand as a product manager is why are they asking for that what are they trying to solve with that so for example somebody will say you know give me the option to have delivery slots ten days into the future that's that's a solution but what is the problem so what Henry Ford really did was what do users want in terms of the need versus what is the solution that they think that they need did that make sense to you okay and then the second part that I wanted to answer to your question was sorry it's not coming to me changing the vision and changing the product strategy yes again that happens to a lot of us and I'll tell you why because the way road maps are is they're usually build six months to twelve months I know that that period is now shortening but you know legacy was six months to twelve months most of the startups that we work with are so fast-paced and they're scaling so fast that the persona that you were solving for six months ago is no longer the persona which is driving 80 percent of your revenue today and so what that means is that your roadmap needs to evolve and you need to be on top of that which is why being in constant touch with your stakeholders including your customers is very very important and so this happens all the time and what you need to do is again be the hub to those folks and you need to communicate you know at a cadence I'd mentioned that keep communicating your roadmap to your stakeholders they should speak the same language as you and that's what makes for a really harmonious team so again roadmaps change and they should change for a good reason sometimes what you had thought would be a good solution no longer makes sense you're changing your stack you're changing your infrastructure you've bought in you've actually hired a new team lots of stuff can change over six months and so road maps can change and evolve you just need a solid business case for it which is what we need for every single product initiative that we have so just speaks to that sure yes this is the approach that I've taken so far is I really like to understand not only how the technique works like I've said but what are their limitations and when you start thinking about and I'd mentioned this building empathy you'll realize why the development team says I can't build this in five days I need five weeks and for you to be able to understand that decision and where that's coming from you should not be clueless on why and a lot of that understanding will come from you know how does the API work and this needs to be block diagrams you don't need to know you know who wrote the code when was it written what are words our tech debt of course it's good to know all of that but like to begin with it's important for you to know what are the services we have is it like one monolith service is it one API was it broken into you know smaller services how do they talk to each other what are the roles of these services just simple block diagrams for you to understand this service is the search service and this service is the recomendation service and this is when they talk and this is when they don't talk stuff like that when you know and you bring those to the conversations helps you build credibility because now you're building empathy with your development team not only in terms of their timelines and there are you know deliverables but also in their constraints and their advantages so for example just the other day I realized I found you know this way of looking what is the API response to a front-end screen I just chanced upon it when I was talking to I felt so empowered because now I know that on that screen I have this matter like this information or metadata as it's called and I started thinking about this is available information do I need any of it to surface and all of this does not require you to code or understand how code is written it is logic and it is structure so you must acclimatize yourself with that it really helps sure yes yes yes yes I think um you know good news or bad news again you you said it yourself a DS depending on the face of the startup the personalities involved and what are the priorities for the company but I'd say at a high level I even before I make the case for something like a product I need to convince myself that this is something that merits itself to be on the roadmap that's one approach that has always worked for me and why I like to do it is I like to anticipate all the questions my stakeholders would have for me and I try to answer them so for example this will require us to build you know a new service and that service is only going to be used for this so it will be kind of you know a very big tech effort for a small pool of users so when I'm thinking of products or I'm thinking of my roadmap I do two things the first are all try to align to what's important for the company because anything outside is noise right so if Flipkart is for example using focusing on retention and I'm trying to drive products that drive new users I'm not in alignment with what the company wants so that's one and again when you you will be empowered when you have alignment with what the business wants that's one in the second is when you have a solid case for whatever it is that you are proposing so who is it going to impact what is the impact going to be why is that metric important there is no real pattern like there's no strategy that you know works that that I've used throughout my roles and it is you always tweak and and learn but I think the one thing that has stayed true is how can I build credibility how can people trust me with a product or with executing on something or you know making sure that we are focusing on the right thing we are doing what's best for the users and I think that all ties into can people trust you and how can you build that credibility so I think when you read yourself to the to the product and and solving for the users of that product you will just make the right decisions and I think that's the pattern that is seemingly worked again I think I quoted this before but be in love with what what problem that product is solving and not with solutions when you distance yourself from solutions and be razor focused on this is the problem I'm trying to solve I'm trying to solve for this is when people will start rallying rallying up you'll be able to rally up your stakeholders yeah a more measurable sustainable development process of more value than sporadic big wins or personal production and how do you calculate value or alternatively do you think there are companies where that's just never the case I can't say for sure if it's never the case but what I can say is that there is a point in time in in a startups journey usually this is more valid for startups where there is you know lack of a structured process and then you want to bring in a process is for you to try it once so much like you a be test and we did this again and one of the roles I've been at where you know there was considerable resistance to we don't want to be process if I'd into this process that you have we are doing just fine doing things the way we do them at that point you you need your colleagues to sort of you need to motivate them to say let's give it a try and let's see and then you also have to be unbiased about it if your colleagues feel that there's going to be unbiased sort of measure of success on both ends I think you'll be able to get them to do it and we've done that it might take fewer or more conversations depending on you know the potency of the of the team members you're up against but trying this so we tried this it worked really well you know the development team was really happy designing was really happy we were really happy and then we tried to you know import that into other teams and other projects and other initiatives so sometimes it's just about convincing them to say let's give it a shot and if it doesn't work it doesn't work and you go into that with that mindset and sometimes and eBooks yes I'm so sorry I'll get it okay sure so the one thing I do very very diligently and I'm really disciplined about um in fact unknowing about is I read every single NPS survey of the experience that I need I read every single feedback that comes in via email or chat I read every idea suggestion complaint crud I hear calls every Friday I listen in to calls I look at what the customer support team they have this excel where they categorize themes for that particular week or that particular time interval I look at data day in and day out those are some of the things I've come to discipline myself on because they really come handy for example knowing the pulse of your your users knowing who they are like I said what do they look like why are they using your product how often do they come stuff like that is something that you should just be able to talk about in your sleep like what are the pain points of your users and what are they loved about your product these are two things you should know again it helps drive the right problems to solve and so that is one thing I I'm sort of I make it a point to do very regularly data is another thing I look at data every week if not on a more frequent cadence data again will tell its own story it'll guide you it'll give you a sudden peak or a sudden drop and then you understand why for example NPS scores dropped in a particular month for us why did that happen when I double clicked and I double click and it only happened because you are close to data you look at it every day and you see this is not normal this is not seasonal this is outside of the deviation that you usually see so you're able to really pounce on opportunities and problems so that's one thing I do another thing is I try to have this process of starting an initiative like from concept to executing it I try to follow that am documentation I'm a firm believer of documentation I always have this one source of truth for all stakeholders and so that's really helpful sometimes you know when somebody wants to check this is what we discussed in the last meeting you know there will be the meeting notes so you are kind of getting your funneling everything into this one document and it specifies everything about that product and everything to do with that product and same for roadmap and vision the other thing is I think communicating communicating is really important when you're launching something who should be aware about this when you are analyzing something who should you share that knowledge with who can benefit from that analysis for example I do some analysis and I realized operations team can use this insight to guide some of their offering system algorithm stuff like that and that is again how you start building these relationships and these rapo because people realize that you're there you're passionate about your product and you're there to solve the right problems so those are some of the things that helped I'm sure there are others but these were top of mind right now sure from a day-to-day perspective yes I see sure sure interesting congratulations I think what you have going for you is you've got you you already have these relationships in place you don't have to adapt to the ecosystem you've been a part of the ecosystem you know you've interacted with these people I think now what will help you is to change the lens maybe you've been in a you know a different role which was not as product heavy your product focus but now you know you have this product in your hands and you are really the champion of that product and so your day sort of begins with what's working well what's not what is the vision for this where do I want to take this in in three months six months what are my projects in flight who is working on what how can I Drive this deliverable on time who do I need to communicate with with for that project there'll be a lot of multitasking there will be a lot of communication there will be a lot of analysis there will be a lot of decision-making and hard decisions that you need to make now you'll have to justify a lot of these decisions to say data set this or user set this you'll have to rally a lot of folks towards a common goal and these people will not be your reports so that is another challenge that will come your way and again you will be some companies have different product management roles but usually you will be like at the center of all these teams and you will be keeping all of them in alignment keeping them on the same page you will be the source of truth on where the products headed and why and so those are the things that will change for you but the good thing is that you won't have that initial orientation observation kind of things as much as somebody who's new on the job so you can really focus on building your vision building your strategy you can take time to really look at data and say why haven't be solved for this or why haven't we done this or these are the new users we can acquire an is why or you know whatever is possible but yeah sure sure yes I see right sure sure so again great question this is something that will happen new or existing to all PM's right and it will keep happening this is what is one of the skills we have to learn which is prioritization and what that means is that top-down somebody will come up with an idea and say let's build this or your head of product will say I think this is a good idea or you know thousand of your best customers will say we leave your app if you don't build this for us or XYZ right you as the PM you have to really justify not just those ideas but your own ideas as well and you you know you sort of go back to the basics if you like I'm repeating myself unfortunately but you really go back to the question of what is this solved for and what does that idea solve for do we need to solve for that problem is it going to impact 2% of the user base or 98% of the user base is it going to impact revenue generating users or just random people on the platform these are hard questions that you really have to evaluate a lot of these ideas on and a lot of the a lot of the times I have realized and this happened to be very recently also I was really really passionate about this one idea and I've been passionate about it for a while but when I really got into building the business case for it and saying should we invest time and effort into this or should be invest time and effort into that I had to be unbiased and you know my heart was broken but I had to say no this is what's more important for our users and so you have to do that on a recurring basis so you could be you could be really close and passionate about something and you could that could be close to your heart but go back and say is this important for my users or not because at the end of the day that is what you are accountable for not the number of features you ship not how well you shipped and of course this contributes to how well you do but the end of the day if you're managing an app and the app is you know doing well and better and better that is what you are accountable for so you just have to prioritize and you will get those ideas from all directions so welcome to our world where that happens all the time sure there are a lot of techniques on triode ization out there I can share links with you and share other insights that I have with you I'm not sure there is one more question great thank you so much for listening [Applause]

Channel: Product School

Views: 41,905

Rating: 4.9142551 out of 5

Keywords: Product, Product Manager, Product Management, Tech Startups, product manager salary, product manager resume, product manager jobs, what is product management, what is a product manager, product management training, how to become a product manager, cracking the product manager interview, product management jobs, google, machine learning, Machine Learning Products, Technology, Career, product school, flipkart, new product manager, first 90 days, first 90 days as a new product manager

Id: GVNJc87nAfs

Length: 68min 20sec (4100 seconds)

Published: Mon Apr 30 2018