This is a really quick intro on product management it's a fairly it's designed for people who are early in the role or who are trying to get into the role i'm gonna touch briefly on what the role is and what the actual work looks like one of my pet peeves when i was first starting in was everything i found about the role seemed to just be a laundry list of things like here's a laundry list of things pms do. And it's part of that is by the nature of the role pm's tend to bring structure to otherwise an unstructured office or unstructured project plan but part of that i think is just there is a way of looking at all of the work in a structured manner. So i'm gonna try to go through it on how at least how i picture the role i'm also touch very briefly on the difference between smaller companies and larger companies i have worked at startup before this i was at a company that then got acquired by microsoft before that so i've been through a few different places so i'l touch on the differences i've seen and across the different places and then at the end i'l touch very briefly on sort of the interview process. So i there is a similarity across the interview process at least in the b2c role so the b2b roles tend to be a little bit different but the beat of scene roles there you'l find some commonality across it. So i've interviewed at a ton of places myself and so through the process i've definitely noticed a pattern so i'l touch on that. Okay. So. Yeah. So that.

Was that so the background i'l touch on my background i'l touch on what a p.m. does here i'l touch on three different things sort of setting up a roadmap for your project how the execution process works and then how do you want to do the analytics and iterate through your project and then i'l touch on getting a pm so are the skills companies look for what does what is google's grading rubric some of the other places i've worked at in the past and then sort of what questions at least google tends to ask and other places i've seen ask for each of those roles so that's me on the.

Left this is a little bit about me i went to duke and i don't know if any anybody here is from the east coast but went to school in the east coast that's in the 2010 finals when we won then cwa championships was in indianapolis that's pretty awesome right after duke i worked on powerpoint an office. I was one the early days of office 365 and so this was powerpoint online or online web editor you guys if you use powerpoint either on the client or the web you might have seen those alignment guides that come up when you're moving shapes around i put that there in fact me and my team have a patent on some of the stuff that on the logic behind how that works because when you have 200 shapes on a slide you need to figure out which ones matter and which ones don't went to business school at harvard after that's where i met my wife she's actually where she's sitting back there working not listening hello we have a cat cats name is mochi after that i worked at yammer for those who have you for those of you who aren't familiar it's basically an online work collaboration tools think slack or facebook for work now part got acquired by microsoft not part of office work that earnest which was a student loan refinance personal loan startup in the fintech space probably the biggest after so phi they just got acquired by a servicer called navient that had split off from sallie mae if you guys are aware of that space been at google since last year that's sort of the hat you get the first day you join and then called nooglers they use new googlers and then i've been on the payments team on android pay specifically in consumer payments if you guys saw the rebrand monday that we announced will be rebranding to google pay and merging a bunch of things across the company and so that's kind of what i've been working on for the past year.

Get started so what is a p.m. actually do this is a common thing i'm sure many of you have seen i kind of hate this diagram because it's kind of like saying where is it if somebody asked where the statue of liberty was he wouldn't say it's between manhattan the city and governors island mike that's a very not helpful explanation and so. But you've probably seen this a lot so i wanted to put this out there the way i think about it is that a pm owns the what and the why the specifically what problems are worth solving and what features are products should we be building to solve those problems engineering and design often ends up owning the how the boundaries are soft so you'l often you'l work across the two but generally that's at a high level at a principal level what the pm role does in a software company but.

That's upgrade at a high level but which pm owns what and so depending on where you are in the high in the level of the company your scope changes and the breadth of the problems are tackling changes and so this is true at large companies this is true at small companies it doesn't matter at large companies it might be the vp but at small companies it might be the founder i'l just talk through an example of how this works out for example at my last company ernest before i moved over to google so the founder there comes up with sort of thinks about what problem do we want to solve at a broader level what market are we trying to attack and so there the thought was student loan process is broken let's reflect me hire a team let me get some funds raise money to go solve it and a company like google it might be the head of google photos saying the vp saying all right photo sharing and storage is broken let me get a hundred engineers to go fix it. Right. So at that person they're basically putting a pillar in the sand and sort of nailing the broad market we're tackling then the level before that the head of product is going to store going to say to themselves all right i've been told we are gonna tackle student loan student loan application there's a student loan process how should we do it all right well build an online application or a phone app or something else to go address and tackle this problem then below that you might you'l have the individual pm senior pm junior p.m. They'l think through. All right. I'm working on this online application let's build a feature to make sure people can refer their friends to this online application because we think our acquisition cost can go down that way and then a junior pm might say i'm working on this referral feature let's make sure inviting friends is easy so you can upload contacts you can do things like that and so that's how at every stage you're owning the house. It's the scope that sort of changes as the level changes i'm gonna focus on this one obviously that's sort of the target of this presentation the earlier roles so we'l talk through some of the how day-to-day work ends up working in that level by the way if you have questions where something's not clear just stop me in the middle i'm happy to answer them.

P.m. your job is shipped great feature shipped great products shipped great features and so the way i look at it this is broadly every feature just goes through the structure like there's some pre building phase there's some execution phase and then there's some phase where you launch and iterate any one feature is pretty neat along this sign the reason why if you look at a pms calendar it's all over the map and i'l show you what mine looks like it's all over the map it's just because you'l have a multitude of projects at every stage at any point in time but basically you have these three stages and there are key deliverables on these stages so the stuff in white you're basically have a road map initially the goal is to figure out what you're building and how you're prioritizing then in the execution phase you're gonna have a prd and then you're gonna work with engineers and designers to design it the exact term that your company will be different some companies have it faq dot some companies have a pr d some commune have something else generally conceptually the same thing then you're gonna launch i'l talk through some of what goes into actually launching and then you're gonna analyze the results of the launch and sort of iterate based on that all right so pre building let's.

Talk about what the output of this phase is the output of this phase is a road map that's the most important thing that you as a pm should control your job as a pm you're getting paid to prioritize what features to build so your job should always be to have a clear list of here's the prioritized list of things i want to do small companies and big companies do this slightly differently big companies will prioritize individual teams or prioritize things and this will all roll up to an okay. Are i'l show you what that looks like at google. It's just a way of saying measurable results that are tracked across the companies startups will have a backlog that they use in backlog grooming and agile if they're doing agile so that's the output the question is how do you get there so there's a lot of inputs that go in. But you're basically trying to figure out what features to build and how do you prioritize them so there's some vision and strategy coming in from the top from the people above you that i just mentioned and then within that you'l think through what does the market look like what are my competitors doing the cost you'l do some customer and user research i call this the soft stuff. But you're looking for qualitative data that will help guide you and bring out new feature ideas depending on what stage you are of the company this can be easier or harder i actually find this a lot easier to do if the companies earlier you get locked in into a machine when the company's harder doing it yourself. So. But it's important to get out there and do this in fact if you're in a product that is pre product market fit. It's actually one of the best times in your product you can just sit down with every single user and understand what are their pinpoints where they're doing because once you are at thousands of users then everybody is just a number on this on a dashboard and so it's actually a pretty nice place to be so. But there's a customer user research aspect there's the analytics hard data as you start to scale this becomes easier and easier to gather you'l head get cross-functional ass especially if you work in a larger place and they'l be bd marketing sales they'l all have ideas so you want to pull them all in and then your understanding so part of the reason you get hired is for a little bit for your gut sense. And so you want to make sure that once you're in the industry you'l have a sense of pain points and things that work and things that don't work the important thing there is to validate it with the data and the research. So you know you don't want you want to use that as a guide. But then you always want to validate it so all of that will go in so here's a roadmap this is what my roadmap.

Would look like at earnest i put it in a google tricks it format really doesn't matter these are real projects we did the ideas basically came from all of the sources that i just mentioned so if you look at this list there was the idea of launching a new student loan project so we did refinance the idea was we would launch a product for new student loans at this point i was doing copy experiments on an application page to improve conversion i was starting with a basic referral program and then there was a request to build a new blogging platform for our content team so that they could improve our seo so this was an actual road map i had at some point one thing you'l notice is like i try to keep big bets and small quick wins at any point in time and i try to categorize things in those ways just found that it's nice to make sure you always have a mix of those on your road map at any point if you only go for shooting the moon you miss out on a lot of little things that you should be improving and quick wins but if you only go for quick wins you'l get into a local maxima and it's really hard to shoot for the big projects you also don't want to go for two quarters without any wins and so the quick wins sort of help balance out if you're taking big risks and nothing ends up panning out you're see you still made a lot of headway by accumulating a bunch of quick win the potential impact this is backed by user research and analytics so you would run data you run user research and you'l try to figure out all right like i think and used to a long project that can open us up to entirely new market so huge impact copy experiments medium actually copy tends to have be pretty strong in terms of one of the quick wins you can have and so medium impact potentially across all of them referrals similar thing here's you want to measure your cost here's where a basic understanding of the technical infrastructure of higher product works helps a lot like for it to fit you should be able to fill out this column at a high level without having to run to engineering for every single row ideally you always want to validate it with engineering and if you're not sure then you want to have a conversation with them but this allows you to when you have when this lift gets really wrong long it allows you to scrape out a bunch of things really quickly because you know instantly. Oh yeah. The system can't support this today this will be a lot of work you combine the impact in the cost with two your roi and come up with a priority and then you basically just draw the line somewhere.

Roadmap how does this really differ between small community and become these small companies you basically just pop the next thing off your roadmap once you have engineers that's. And then you work agile typically every company differs but that's essentially how it works. And so where does the urgency come from the urgency comes from because well at small companies everything's always urgent like you have aggressive growth targets your china meet you have launch date for dates for big projects that investors want to see your board wants to see so you know they'l be plenty of urgency.

Company like google a lot of becoming students differently this how google does it we have okay ours who cares are basically measurable results they stand for objective key results i think the important thing is they're measurable and so this scale goes top to bottom so this is last year genuinely how payments okrs would roll up into the company so at the top level if you looked at our company. Okay. Our obviously got rid of the numbers but. If you looked at our company okay. Our i would say something like alright the payments team should do yr and google and payments wants to do y dot million dollars or billion dollars of gross volume of transactions we want to launch in-store payments in x number of markets the product area which would be the payments actual payments team so this is owned by the ceo of google the product area owned by the individual team would then own all right. So we're actually gonna go and launch this product in x y z markets we're gonna launch online in what in y websites we're gonna ensure that maybe some percentage of people aren't ready to paste it which is what we called it would just you have a card in file you're ready to go the idea is all of this should help this metric and then individually as a p.m. you would own features that roll-up into that. And so you would go through your backlog figure out what you wanted to do and what would contribute the most and then you put it in your okay our list and make sure it just matched up tied to an okay are above you so it might be things like improving conversion of card adding are launching campaigns with stores and merchants so things like that with the goal of improving increasing transactions or gross value or whatever the top lines metric list i think all of that should hopefully i've been straightforward yes. All right. So execution you have your roadmap you know what features you want to build now you're writing your requirements toc this is basically where you write down what is the feature trying to achieve and really the details of it should be a collaborative process honestly between with you and engineering and design like you what you don't want to do is write it prd and throw it over the fence that rarely ends up working out so you work with your engineers to understand what are the questions they really need answered you want to make sure you lay those out these are the sections of the purities i write these days it changes depending on the company different teams matter here you'l see seconds for risks and legal we're in security we're in a we're in payments those things matter so we'l have things like that high level use cases and detailed design. This right here that's a meet of it that's where all of the key sections go again this should feel like a team the important thing to remember is you your designer and your engineer you're on the same team if it feels like you're not if it feels like you're pulling teeth and you guys want to go different ways you need to step back and figure out how to align the team there are two obviously two reasons teams can not be aligned you may not be aligned on the goal or you may not be aligned on how to get there and if you need to figure out which one of those two thinks it is because if you're not aligned on the goal then trying to align on how you to get there is a is a bad idea it just it won't work so.

D done often gets broken down into tasks if you are in some place that's agile they'l go in some sort of backlog and my current team at google is pretty is not so great about this we just go with quarterly okay arts. But i've worked i know the teams at google that are. And i start up we used to follow agile pretty closely typically you'l have if you have a tpm or an ng they'l they might help aggressively with this in that case i just recommend get it staying involved in the stand up so you know how well how much progress you're making as things go on and you can sense when there's going to be issues earlier on. But yeah we just track what's defined what's in progress what's done we've actually use jira. But i didn't have access to joy right now. So i just made up a screen giant.

You built broken down everything to tasks you worked with your ux you put it all together and that's getting close time to launch. So how do you do that so first thing obviously you're gonna run across is bugs like what are what are the bugs were a lot talking this is my day right now because we're working through this big rebranding project we're pulling everything together under google pay so what i'm working together through to figure out all right like every day what are the bugs triage make sure you figure out what's launch blocking that's the most important thing at this point you're looking to classify bugs as launch blocking or not aside from it you'l prioritize a bunch of things but ultimately that's the decision that matters and then are all the cross-functional teams ready so for us this is legal risk customer service that sort of thing might be marketing beauty other things in your in your company and we'l do something like this so we'l have we actually use a tracker called ariane or launch cal goes by a couple of names within the company. But basically you can pad which teams you think are involved in that project it should be involved and they'l have to check it and then other teams just get marquez fyi and so and the feature doesn't launch until everyone's check it the last person to check it used tends to be the vp so the vp our vp won't look at it until every other box is checked and then he'l put in a final check and we'l start rolling out the feature all.

Right so you launch it. And then now it's time to measure the results so if you watch it as an x you either launch it as an experiment or you launch it as a feature sometimes not everything can be an experiment but let's say you launch it as an experiment so your step is to your next job is to analyze the results of an experiment. And there you can do a whole course on this but i'l just give like a quick two minute on tariffs like as if from a philosophy level or philosophical level what do you look at the high level so generally some stuffs gonna go down other stuffs gonna go up and you're gonna have to figure out what to do it's ai not a ton of experiments where everything is positive there's all usually trade-offs in a product make something bigger something else gets de-emphasized so you need to figure out what to do so here's an example of an actual feature we launched at yammer so for those of you are that who are not familiar with yammer think of it as a slack or a facebook for a worker and this was my job two jobs ago basically an enterprise communication tool. So we had groups in yammer kind of like kind of like slot channels or facebook groups i guess. And we launched a feature that let users search for a message within the group and this is effectively what happened i changed up the numbers a little bit. But generally this is what happens so these are the metrics we looked at that were on my dashboard we had one day retention which is users coming. But how many users come back the following day that seemed to go up the number in brackets is p-value the lower the better it's a measure of how statistically strong your results are what's a chance it's actually by chance you generally want.

That number low three person 0.03 just means that three percent chance that this result this positive result is chance you run this experiment a hundred times they're gonna get it one point five percent lift by chance even if the two things were equal so that's why you want this number to be lower but and that sort of the lift the delta between the test and the control groups the two groups you launched it. So anyway so one day retention went up 1.5 percent is actually a fairly strong boost for mature product and retention so the one day retention went up a lot days engaged which was another metric we measured sort of tied to that it was how many days did you engage in a week so that went up slightly the number of likes that we got for posts went down actually substantially messages that people wrote went up. But it went but the p-value was slightly large so not hard to read that into that too much and then posting binary number of users who posted and then thread stars the difference between messages and thirst starters as thread starters is just the initial post messages includes replies that was also flat when the hot p-value is flat we just attribute it to chance. And so we say it's or the p-value is large we just attributed the chance that we say this number doesn't matter it's just it's flat. So question so how would does anybody want to venture on how they would interpret this like would you ship this would you not ship this any ideas. Yeah. Why yeah. It's a good answer. Oh so the n here is a number of people in the experiment. So that's a sample size so the equation to power calculate p-value is its complex uub it's a statistical curve. So. But it's basically the number is the percent that result is purely by chance so for example this means that if i run this experiment a hundred times with making no difference between the test and control group twelve out of the hundred times i will i will see a lift of point four percent right just out of pure statistical chance so you want that to be lower we've looked at we typically consider p-values of 0.05 and less so 5% or less good p-values of 10% or less okay. 15 or less all. Right fine you're stretching it though lower than that we would just said all right it's purely chance if you higher sample size you can get even closer. So facebook i'm a su i'm guessing they're gonna have go shoot for really low p values retention is good. Yeah. So that's alright answer so the comment was the retention is good so let me talk about how to look at this generally so the wrong answers more things are green than red. So we should chip it you can always add more metrics to your dashboard and you'l end up with more green or red or more red or green that's not helpful at all the correct answer is trying to figure out what the global metric is so there are global metrics and there are local metrics global metrics are the metrics that most closely represents the top-level goal of the company and so well i'l give i'l tucker cheat sheet really. But like what happened to a global to your global metric and then local metrics is basically do they support what happened to the global metric if not then you need to think through what is your hypothesis for why that might have changed so a quick cheat sheet on what the global metric is companies tend to fall in two buckets they're either or typically i'm sure there are exceptions but there is typically transactional or engagement driven. So if your transactional you're trying to get people through a funnel that basically means so for example at earnest we gave out loans so loan applications or the number of loans we gave out that was transactional amazon. It's gonna be transactional it's how many people make it through a funnel sure searching on amazon is great. And so you might measure some engagement metrics as local metrics but if you're not moving orders that's a problem like something that gets searches up but moves orders down that's probably not a good thing or you could be engagement driven where you want to make sure people come back to the product or spending time on it facebook's engagement driven yammer in this example was engagement driven. And so if you're an engagement driven company in this case you're gonna measure engagement. And so the top thing you're gonna look at these things like time spent on site or number of days are coming back or things like and so given that retention and engagement went up that's your symbol for why you're gonna ship this likes went down you should think to why that could be coincidence there's always a little bit of chance i pay p-values still not zero. But it could also happen our hypothesis here was well we let you search so you're doing less scrolling they're doing less scrolling you might come across less random post that you might like so. Likes went down so we then said all right let's validate that what happened to actual searches and so then we ran a custom query because searches wasn't in our dashboard and we said. All right. Yeah it looks like searches did go down it sorry it looks like scrolling did go down a little bit sorry scrolling what's it in our dashboard. So we said yeah scrolling went down a little bit. Yeah that validates why likes may have gone down. And so that was our hypothesis. But we said hey seems like people are getting to what they want quicker. And they're posting more engaging more good thing if i were right now i'm a i'm on android pay we're gonna be google pay. And so a lot of fun metrics have been changed but like last year one of our key metrics was taps how many times do you tap at a store to make a purchase for in-store purchases so that's a transactional product.

Yeah this is i started my presentation with this a single project my fall just nice schedule. But your schedule doesn't right like this is what my schedule looks like ends up starting at like 8 a.m. 9 a.m. Sometimes goes down to the meeting with my manager at. 9 p.m. It's a thursday night meetings with singapore so a little bit all over the map at the time at least when i looked at this was a week in november i try to figure out how i spend my time roughly a day all overall was spent on figuring out the product strategy and planning a day on partner and user research and then meeting with partners time with engineering time of design metrics and analysis and then serve general coordination general coordination saab viously hired in a bigger company you're sort of the glue.

You interview let's talk about that so this is what this is what google will grade you on and ernest - we actually had our lead p.m. was from google. So google and ernest we're basically them we had just taken google's grading rubric. And i put sort of the list on what we looked at well we were at yammer google doesn't really break it into hard skills and soft skills that's just how i look at it. So i sort of put in my lens on there but on the hard side skill side we look at analytical we look at technical abilities we look at product and strategic insight and then communication creativity and culture fit for soft skills culture fit is so you can probably figure out what communication and creativity our culture fit is basically does the interviewer get along with you effectively and do you comment for google it's also a heavy dose of does this person feel like a team player i remember when i started one of the folks i worked with at google told me you're not gonna get ahead at google by working really hard because there are plenty of people who work here really hard and you're gonna burn yourself out you're not gonna get ahead at google by being really smart because we hire really smart people and i'm sure there are plenty of people smarter than you're gonna get ahead here by trying to be a team player. And. So i that is i think one of the key things i took away from my first few days and it's one of the things that they look for or we look for in on the culture side duh. And then i've sort of mapped those to what yammer looks at you phrased in a lot of different ways but a lot of the same elements are there so i guess my point is there's a level of consistency that you'l notice across the different companies at least the consumer facing ones b2c companies. All right. So yeah i'l come to that i have examples so here are with some questions that i would put in the hard bucket for each of these so for a product to come very common set of questions and the nature of the company actually affects which one you're more likely to be asked so if you know people at the company i would i would try to figure that out this actually does this laser pointer work. Okay. So the two types of sort of design x4y which is like design an alarm clock for a blind person or some things i call it a blue sky question or how would you improve product x and that's i sort of call that the improvement question there you're given an existing product or you're told pick your favorite app on your phone how would you improve it like how do you improve an existing product i'l sort of come through what we what how to answer those and what we're looking at i think there's a structured approach that generally makes sense everybody has their own style i'l give you mine some analytically focused ones metrics focused talking about some of the things i just talked about around metrics we ran an experiment this happened what do you do math focused we still ask i forget whether google still ask some of those i forget whether i was asked this. But we certainly ask to use a lot of earnest how many people fly out of sfo a day how many bottles of shampoo are sold every year basic estimation questions. Oh yeah. I was at. Yeah. I think they're still there at google technical questions two types typically high level technical insights so for example what factors would you consider when deciding which videos to show and how to rank them on the youtube column in the related videos tab or in section and then sequel basics like given the following tables how would you produce this other output depending on the company there may be more or less of this i think it's good to brush up on some basic sequel queries you can do that offline you can do that. I know stanford has a great online class that's where i first picked it up before i started getting into interviews where this was a thing. And then it was useful in all my jobs about the soft skills all right you're not gonna get asked a question about this i mean they'l be general behavioral questions where they'l judge some of this. But there won't be a specific question for this they'l try to get at this as you answer these other things so i'l just talk through these for really quickly the two product ones and the two analytical once and that's enough so it'd be the end of the presentation just because those tend to be the most common and structured from an approach standpoint.

Serve question like you're given some thing to decide the best piece of advice i can give you and this is surf advice i got when i was interviewing for my first pm job if you're asked regardless of what you're asked to design think about what is the first where are the first five questions you'l ask the interviewer when you're told to design something so for example if i tell you to design a toothbrush i haven't really told you anything like who is the person who's using this toothbrush or they're using it traveling are they using it at home are they is it is a person disabled is a person not disabled like how much are they willing to spend like i haven't really told you anything about the factors that are like are you designing our time crunch like what's going on here so you need to figure out like what are the think about what are five genetic questions that you can ask right away and that's useful because when you're getting a question there might be a moment where you're where you have a i guess a deer in the headlights moments where you're not sure what to do it's interview. It's high-stress if you're prepared you'l get the ball rolling quickly the most important thing generally though is to fix to start with the user as a p.m. you're the voice of the user you probably heard that so start with the user figure out who is the user what are their needs and if you're not given a user you should list some options and then prioritize and quickly pick one. I'm so i now give you an example of that in a second i think through ideas and features try to have at least four or five on things you could do and try to have at least a couple that are out there this is where you get your creativity points so you want to go for some things that seem obvious and things you could improve but some things that are creative and get out there and then generally i think this is really smart like this is where your communication skills comes in you should always be structuring. So anytime you give an answer no laundry list always structure whenever you can that's super important. So if you're prioritizing you should say i'm prioritizing based on these two factors i think this will drive usage and this would and this will be easier to implement or something you should have some logic or structure to answering each of these sections.

Is a question i got when i was interning at microsoft back in 2009 design a music system for a car so start with clarifying questions who is a user where do they live what type of car do they have so for example you may have and let's say you're not told you answer you get those answers and then you're not really told who the user is so some options there could be a student in college it could be a working dad in the house you could be somebody driving an suv pick-list some options pick one tell them how you're picking one you think the markets bigger for this or you think their current car these are the people tend to own cars or drive them more or whatever have some logic pick one then feature ideas. So what features should this music system for a car have where did where does it get its music from so is it from your phone is it local storage is sync with home wi-fi. How do you control it things like that and then for each of those questions you should prioritize and then pick your aunt's option. Right so for example if you want to decide where does it get music from you may say all right they could get its music from your phone your local storage or sync with your house where the pros and cons of each and then based on that it'l pick some options and go forward right.

Improve x. So this is sort of what i call the improvement question or like pick your favorite app how would you prove it very similar to the previous one with some added complexity around it's a product that's already out there so you need to know what's the current vision or goal of the product and then what is the top level metric based on that so once you know what the vision or goal is what is that thing that they should be trying to improve anyways and then who are the users where someone met needs. And then how would you structure an experiment to improve those like when you're doing improvement you can experiment you can't it's a little harder to do that when you're designing something new entirely a quick tip here before you go into the interview there are lots of interviews where you'l get asked to pick a favorite product and improve it have id have thought through at least three or four products ahead of time three or four products are phone apps three or four products that are web apps three or four products that are b2b apps and then sort of think to like and come up with three or four ideas for improve to improve them the important thing is if you've thought through apps and you have ideas at the interview you still need to go through the steps you shouldn't say. Oh yeah. I love this product here are four ideas that laundry list will not work you need to start with and say all right this is the user and this is what they need so i'l.

Give it an example let's say i'm told pick a favorite app improve it might say all right look i've recently been using uber eats. I think it's a great app it's designed to help people get food they want quickly i'm smirking because our friend back there who works on new breed's. I. So i might start with a user and say all right so this app is designed to help you get food you want quickly who are some people who might use it well there might be single working men and women so they get home for dinner they don't want to cook they just order it might be office workers during lunch might have a few of those pick one so let's say we pick single working men and women they care about time they care about convenience. All right. So what are some improvement ideas well you want to help them get their food quicker you want to make it more convenient. So maybe there's a pre-selected menu of top nearby items that you can check out with one click. Right. So it's really quick to check out quick to make and deliver because they care about time or maybe there's a one-click order option for the items that are already there then you drank and prioritize this and you pick an idea one of the things you'l notice here is again like i might come up with ideas that i've thought of at the end of the day just having done this exercise in the past. But it's important to go through this you can don't just jump into ideas the sort of metrics piece on this often a follow-up on the improve x question which is all right great you thought of a great idea a one-click order of popular items on new breed's how would you test it how would you test it that's a good idea. Well you can obviously build a full feature one thing to think of is can you do an mvp test a minimum viable product is so is there a piece you can pull out and test and see all right check your hypothesis and see if you are down the right path so for example the goal here is convenience. So maybe and speed so maybe you have a one click repeat last order button and that way you're not dealing with creating quick order menus and things like that you're just putting a single button that lets you repeat the last order that would be an example of an mvp experiment the goal is at the end of the day think about what top-line metric is ubereats is a transactional product they probably care about orders so that's probably going to be your top line metric and i think that who would you test on so would you test on users everywhere are you gonna to the extent you can you want to test on your entire population base if it's a product that's local to certain markets then you may want to test a location by location but otherwise you try to test on your full population base because you'l get to statistical significance quicker you'l have more people and tests and more people in control here's an example of.

An analytics math based question how many planes fly out of sfo every month i was asked this in earnest or when i was joining our nest the most important thing is lay out the complete formula first don't do a single calculation until you've laid out the full formula so you might say number of flights is number of days per month tens minutes per day times takeoffs plus run weight each minutes times number of runways at the sfo airport. And then you might make some guess for how many runways they are at the sfa airport but lay out the formula first then do the math then gut check and say all right does that look right or does that not look right. And then you stress test it. And i'm surprised by how many how few candidates and interviews actually do this is one of the reasons why laying out the formula first is super useful like you look at it. And you end up with a number that say all right a hundred flights fire defesa for every month well you're like well that can't be right there's clearly something wrong so go back to this. And you can say all right like which assumption did i probably screw up. And then you can stress test that. And you can come up with a range so you can say all right let's assume the runways it's not they're not two. But it's four to six what does that mean that means i have a lower bound and an upper bound at 4 at 6 so the laura got an upper bound of what i end up calculating changes and so laying out the formula helps a lot otherwise you at some point you'l get lost in the calculations. And then if your stress test it won't work ideally you stress test yourself before your interviewer stress test the answer for you some resources i've found.

Helpful going through the interview process most of these are pretty common knowledge which is really awesome because when i was interviewing for the first time none of these books were there cracking the pm interview by gail mcdowell this book i found / and by the way i have nothing i have no vested interest in any of these resources so this is things i personally found helpful this book. I found very useful early on if you want to understand just what the pm role is. And i found this good for the technical part so if you want to brush up on some basic technical algorithms and things like that you four guide it's good for that decode and conquer by lewis lin this is good for practice questions like to just go through questions and questions in question i found lewis's learn better for basic like q&a stuff than gail's book. But i found gail's book better for like the technical stuff and an overview of the pm roll and then do you definitely do a korra medium google search for prep on the specific company not just on interview questions but see if you can find out what the head of product has spoken about in interviews and other areas. You'l understand how they think through their product at a high level and what sort of metrics they look for and what their vision is and their goal is well. Yeah. That's basically it the one of the nice things about the interview process for pms is i think it's actually a very preferable role like if you if you do this and spend your time you can really prepare and out prepare and then beyond that it's a numbers game the you'l net you'l never be a perfect fit for every company there's always going to be 40% luck and then review process regardless of how well you've prepared the interviewer doesn't like you that interview was having a bad day you stumble you blank out like a lot of stuff happens so beyond that once you've prepared it's just a numbers game so.

That's it questions. Yeah that's a great question so it depends on so it depends on what you're trying to do so typically i found that changing industry and function both is hard so if you're already in tech it's easier to make it over to p.m. if assuming you're not a p.m. already if you're not in tech then it's often easier to move to a similar function in tech that similar to what you're doing and then move over to the role couple of options if you're if you go to a startup there's typically enough for everyone to do particularly good regardless of how young the company is so i've found a lot of lateral transfers in startups as well just because you end up doing if you show an interest in that sort of thing you can do a lot of projects and then and then move over or interview at a place and say you did all of these other things at that company at larger companies at google we also do lateral transfers so there it comes down to like one of my one of my teammates who worked on the customer facing side what we call the partnerships team helps partners implement google technical solutions just moved over and the way he did it was he was basically working me with me for a while he started doing more and more things at p.m. would typically do which was very useful for me particularly at times where i had a lot on my plate but he would work closely with partners he would write he would put up the dashboards to analyze metrics start doing things like that and then and then it was a pretty clear process from there to then interviewing for the role and then transferring and so it's there's no one of the odd things about p.m. is it's a fairly flat organization typically so if you're a company like if you are a company with 100 engineers so typically have 8 or 10 p.m. So when while there are like three levels and pm sorry on engineering site they only be one or two on the pm side. And so what that means is hierarchy doesn't matter so much the scope of ownership matters so regardless of which company you joint try to find a company where you can do some of that job. And then you can move over with whether within that company or outside that's typically the post i found at the easiest a yammer for example we had 10 pms while i was there two of them came over from marketing one of them interned in marketing but then joined full-time as a pm two of them came over from our own bd team one of the three of them were engineers and then two of them i think were full-time or wore pm's before that so don't think that adds up to 10 but roughly it was a pretty broad sex cross-section of folks.

So happiness so let's talk of it i saw i actually i liked shipping stuff like the best thing about it p.m. is shipping stuff like seeing your products in the wild and naturally shipping things is pretty awesome. It's by like being able to look at something on a phone or something at a laptop or something i'm on someone's device and say. Yeah i made that's really cool. And that's really exciting the thing that's the thing that's great not so great. Let's think so the process can get tiring something. So and this is this is genuinely true regardless of whether the company is small or big different companies have different pros and cons at a smaller company you'l have bigger scope of ownership obviously but you're typically perennially in a state of urgency and everything's on fire at a larger company that happens less but you have more layers to work through managing above and managing across so different things at different companies.

I was going trying to get out of p.m. And then i got to business school i was going to go into consulting i worked at bain for a summer and a strategy consulting. And then i decided i liked product way more. And so i basically came back business school is one of those weird things where i think the soft it gives you a couple of things i think the soft skills it gives you is way more valuable than many of the hard skills it's kind of like i mean all of you guys went probably went to undergrad how much of your undergrad do you use today maybe a little bit if you did cs and you're now in tech but otherwise probably not that much was it useful did you learn a lot generically. Yeah. Probably so business school i thought was useful in that same sort of way. I think it was good do you look at the world and products and things holistically it is somewhat of a funnel for to get into some pm jobs at large companies people do tend to evaluate you as. Okay. You're graduating from business school more than okay. What is it that you are just doing right now but depending on your motives i would say if you just to get into pm roll i think it's useful only to just learn and figure out like how things work i told you what my motivation was but probably different for different people.

So no i wasn't so undergrad was electrical engineering not computer science which means i did a bunch of stuff with wires and circuit boards so a little bit of programming then did a little bit on the side afterwards too which where i picked up a little bit more but undergrad was not see yes if that's the question i think as a p.m. you need to know and if any of you are thinking about doing coding i think more useful than like hackathons and things like that what's really useful is understanding the basics like it's more useful to understand the basics of how things work so that you can piece together an architecture in your head systematically than it is to be able to hack together something because as a p.m. you're mostly doing resource allocation and thinking at a high level what makes sense you're never actually gonna be well you may be but typically you're not going to be actually writing the code so sequel you'l do it's useful to know how to do basic sequel imr we had a very strong data science team. So i ended up not doing it so much at google there's a little data science team that works on the business side at least on my team but otherwise it's the pm's and engineers coding sorry writing the sequel scripts themselves.

Put it to you this way i it is true that at google it's one of the companies that looks for more of a technical background and perhaps other companies exactly how much will end up depending on the engineer who's interviewing you that day. But we it certainly looks for a little bit more of a technical background or at least a technical understanding like you need to be able to answer in a structured fashion but the whatever question comes up whether it's like how do you rank videos on youtube like how would you think through it like what or you're writing an algorithm for or solving sudoku like how would you analyze you're not you don't actually end up writing the code though you could write pseudocode. But it things like all right now go to a row by row out in lights for this and so how do you build that out does that do you have a way a structured way of answering that makes sense. So yes i would agree that from a at a high level yes we google probably looks for slightly more technical respecting more than say for example i've been through interviews that linkedin and microsoft and facebook and some of the other big companies a little bit more so program managers the role at google is much more amorphous than what product managers do i think product managers is somewhat standardized at google even though still a huge amount of variability within teams but more so than program managers program managers in some teams so we have a few and our teams they help mostly with project management so my job is to figure out what goes on the train their job is to make sure each train ships leaves the station on time and. So. And i put stuff on the train and so depending on the team that could differ i've seen folks program editors who also own actual growth metrics and things like that. And so it really depends on the team there's a little bit more ambiguity and if you go to our job section and you filter for program managers you'l actually see that the different the definitions or the descriptions will be varied.

Worked with any technical account managers on my side my understanding is that they work with the partner too so they work with a partner to help integrate the technical solution so in fact in many cases they're more technical than product managers their job is to is to basically if you have a solution you have api's you have big partners on the other end they're trying to work against it you help them interface and you understand they're actually a fairly a very strong resource. But and they tend to be even more technical to be honest. Yeah that's a good question. So btob the biggest difference is you have a big sales team or you have a sales team and the sales team is close to the user and your users come in lumps and so individual users end up mattering way more and so thing you'l often make product decisions because there's a 10 million dollar deal on the line like that's something that happens in a b2b context that doesn't happen in a b2c context so your sales team ends up being a huge impact on your roadmap and being ends up being a huge influencer of your roadmap that's probably the biggest difference your users are your voice of the users sometimes you're working through the sales team you want to get on the customer calls yourself and understand things yourself always so you can understand what's common versus what is what is being proposed just because of this one deal but the sales team i think is probably the biggest voice and then and then on the other side you're translating that to engineering and so one of the things that actually does happen is you end up being an even stronger voice of the customer or of the business to engineers because in b2b roles unless you're building a dev tool in b2b roles you'l often find that there are less opinions of what to build everybody can look at like a loan application flow and say.

So yeah that's a good question. So. Yeah. So you'd have a so like for example at earnest our business metric at the end of the day was the dollars of loans that we gave out that then translated that the novice and then and the average interest rate on the loans that we gave out it's or the delta between the our cost of financing and the loans we gave out and. So. But then effectively that would then the you end up driving that is through some change on the user side that is the metric you end up owning as a p.m. And so that's why i was focusing on the user benefit there'l be a marketing team they'l focus on cost of acquisition and things like that. And so but a lot of the business metrics will then end up coming down to you as a pm in terms of a user behavior or metric that you're trying to drive cool let's take one more.

So qualitative three ways two ways to get it you either run a survey where you're not in front of the user or you sit down with a user and you talk them through the product or mocks or whatever the if you do a survey you can typically get quicker responses but you're more limited on what you can pass and it's a little harder to get a feel for what the person is doing when you're doing an interview in person you can ask a question if they react to a screen or a product or say oh this flow doesn't make sense or i don't understand what to do here you can follow up immediately and say well how does it make you feel what's not right about it like what would you do like if you had a magic wand and you could wave it how would you have done something else instead you can have follow-up questions those are obviously more expensive not in terms of money but just in terms of your time the rule of thumb i've seen in the past is that you start getting diminishing returns after like five or six in-person interviews and then after that you want to take your learnings back iterate on the mocks or iterate on the design and then go back and put it in front of another set of people and do it again ah you'd have to give me a more concrete example typically. So. Oh so yes that's. Oh yes. So the question was like if you improve if you improve if you do if you create a feature that improves transactions but the rate of fraud goes up what do you do a good question there's that's a trade-off where you have to make a call so i'l give you an example let's say you're a pm at linkedin. You put more ads on the home feed you'l make more money but let's say engagement drops how do you ultimately make that trade-off i asked a friend who worked on the linkedin feed and he basically said the head of product said we're willing to take a 5% cut this quarter for ads how much ads can you wake so at some point that basically just becomes a trade-off you have to make a call that comes down to the business at that point and that's certainly not a startup only issue that happens just as much as at big companies in fact it big companies you have more people above you who can have the same thing happen so definitely not a start-up only thing the question was what do you do at a smaller company if your ceo or big client comes to you and says they want a specific feature how do you react to it you have to figure out where like as a p.m. you need to step back and figure out how it lands in your roadmap. And then you need to be able to communicate that up this was part of your job is managing up will the roadmap get influenced by the people of a view absolutely it's going to happen there's no question about it. But it's your job to make sure that it fits in the broader objective data helps a lot user studies a lot and that's the sort of thing where you take back you put out new roadmap. And then you try to do get some data and some user studies to validate it is it only this customer is that all the customers do all our users feel this way. Right. And then you can take that back and do a report and decide whether or not it's worth it see if you can break it down into a small feature that you can quickly build and do run it as an a/b test also helps that's not always possible if the idea is really out there.