what milestone or markers would you look for in a product that might not be performing well to determine if you should sunset it or not [Music] hey everyone welcome back to another exponent product management mock interview my name is kevin way and on today's show we have matt we're going to be doing a craft and execution question and before we get started matt do you want to just tell the audience a few words about who you are what you do sure hi i'm matt i'm a long time pm coach here at exponent uh i've throughout my career i've been at google and a number of smaller startups and i'm excited to be here today great so the craft and execution question i'd like to ask you is this what milestone or markers would you look for in a product that might not be performing well to determine if you should sunset it or not got it okay so just to repeat that back so uh what milestones or markers would i look at if my product isn't performing well to determine if we should sunset it or not right okay great uh just give me a minute to uh think this through a little bit and then i'll come back and answer cool okay so um you know great question and you know as i think about this a couple of things that just stick out to me to start with um you know i'm gonna have to balance a couple different things here bring in a lot of different considerations you know what's on our roadmap and you know what's the effort required to continue to support this product or how does it split our focus uh you know what's the user sentiment around it what's the strategic important importance how do our stakeholders feel about it um you know all these sorts of things are going to come into that decision making process but uh to start out let me talk about that you know when am i looking what are those milestones um and uh you know i think these milestones probably come in a couple different flavors right there's the ones that are you know sort of uh like a a flag going up of some sort because it's become necessary or relevant for us to consider uh sunsetting this product and then the other side is you know just like as part of our regular planning process uh and you know kind of evaluating where we are uh as far as those ones that make it necessarily irrelevant that could be cases where you know maybe we're refactoring the product and continue to support this would be really difficult um and you know we have to figure out if that's worth it um it could be that we've decided to move the product in a different direction and so we don't want to support this anymore like we don't want users doing the thing that this product does um it could be becoming obsolete or redundant with something that we're doing i could be causing a problem of some sort whether that's like a security issue or you know some kind of like user experience issue uh you know so there might be something that in some sense is a little more urgent that causes us to really look at this and say hey you know should we be sunsetting this now or you know what do we do about this product um on the planning side you know in general it's just good to take stock of your product surface so you know as i go into planning mode a lot of times i'll be looking at the various products that we support and figuring out you know like what their you know if they're continuing to provide value if they're performing well um you know there doesn't have to be an explicit problem but sometimes you can get a sense of like hey you know this might be dragging us a little bit or this might be causing some problems for our users or causing some confusion so you know good to keep track of that as well um you know in general i'm usually a fan of keeping at least as a smaller product surface uh if you can just because it creates less work for everyone um and you know creates less opportunities for conflicts within your product or confusions or you know documentation getting out of date and things like that um not to say that you should be sub-setting everything but you know uh there should be some sense of like okay does everything need to actually stay in the product we might be able to remove some things well so what what kind of determinant like like once you determine that you want to sunset it because of the considerations that you mentioned is there a process that you'd lay out to do this yeah um you know the process the first part of it is you know i have those considerations that kind of point me towards whether or not i want to sunset it obviously i'd have to also look at like the metrics uh and all those considerations i mentioned before the strategic importance and all these things and those are going to determine uh a bit of that process as well right if there's still high usership um but we need to sunset it for some strategic or you know compliance reason or something like that right that's going to be a different process than if it's got very low usership and you know it's just not worth supporting anymore um and so uh you know as i go through that process of you know actually going on to sunset this um you know some of the things i'm thinking about are you know as we're sunsetting it is there any other value we can gain from this right is there something we can learn from what we've done here is there you know some way to you know continue to serve these users or move them to another product that we have um is there uh you know is there some last hurrah for this product depending on exactly what it is you know uh sometimes games will have you know before they're shutting down servers we'll have some kind of you know big fun experience um and then you know as we're actually shutting it down how do we do that gracefully right how are we transitioning those customers uh or you know they have to move somewhere else you know how can we make that easier for them so that they don't have a bad experience because obviously users you know if they've been using this product and they care about it you know they don't want to see it go they don't want to have to learn a new product they don't want to have to lose their data or things like that so you know usually i aim to be pro user even if they're not coming back to a product of ours i want them to feel good at least as good as possible about that process of of this process of this product being sunsetted um so i'm considering all those things on the internal side you know there are lots of stakeholders who are going to have opinions about this and some who might not want to do this i might feel strongly about it so you know obviously the engineering team you know they probably put in a lot of work in building this product and some of them might feel you know connection to you know this uh the thing that they created uh the sales team may you know uh have used it as a selling point of the product and we're gonna have to you know make sure that they're you know that they understand why we're doing this or that they understand what the alternatives are um leadership you know obviously have to get them uh you know aware of the situation and make sure that you know they're on board with the direction that we're going or why we're sunsetting this there could be you know uh larger marketing implications you know sometimes if we're shutting it down for legal reasons obviously they're going to be a stakeholder um but you know uh this is the a situation to communicate early and often uh at least with close stakeholders right you you know especially from my experience at google when something gets announced that's being sunset uh people from all over the company would have opinions about it um so you you know you want to make sure that you're managing that communication uh to the right people at the right time but definitely within the people who are going to be directly affected uh by your shutdown of this product you know you want to be bringing them in to help you figure out okay how are we messaging this to users okay what are we building to help them uh get off of this you know smoothly um and so you know shutting down a product it's uh it's not as easy as just pulling the plug right there is extra work actually that goes into sunsetting it uh if you want to do that well uh so you know it that's the kind of plan that i'm thinking about i'm happy to go deeper into you know some of the actual conversations or decisions that might be made along the way as well uh if you want to know more there cool um i think we're good so far um i think what i heard from you was that you talked you think about should we even sense it in the first place like what are the considerations there and then you talked about the process you talked about how you would manage this externally with the customers maybe you'd have some blast to rob maybe some cool banner um help you know help them move their data just to help them continue to do their tasks and then you talked about the internal processes with engineering and managing stakeholders i think this is um very helpful um yeah like maybe we can dive deeper into like some of those conversations so like uh what is maybe like pick one key conversation and tell me how you'd handle it yeah let let's talk about the relationship with engineering uh you know it's a particularly important one for a lot of pms um and i think that there's sort of a in some ways there might be a more personal connection and so it becomes kind of uh i think more of a relationship uh challenge to make sure that this goes well and you really do need their support in order to shut these things down gracefully um so obviously as i mentioned you know you want to communicate this uh early on make sure that they're involved so you know as throughout this process of exploring okay should we be shutting this down you know is it performing or not obviously one thing i didn't mention earlier is like whether or not we can actually save this if there's some changes that we could make to the product um but assuming that you know we've already explored this and decided that we're going down the sun setting path um you know the techlee would have been involved in those discussions earlier on right so they this shouldn't be a surprise to them right they uh probably understand why this is being made they might have you know not wanted it to happen but ideally there's enough trust in the team already that you know even if there's disagreement or even if you know uh there's like a desire to hold on to this product we all you know move in unison towards what we think is best for the team or for the towards the decision that we've all made overall um so hopefully that should help there obviously a lot of the engineers on the team themselves will also you know probably have feelings about this and so you know would want to make sure that it's being communicated to them uh that they understand why we're doing this what it allows us to do in the future what we're doing instead a lot of engineers do care about the user experience and you know won't want us to upset users so we'd also want to explain that plan to them about what we're doing uh both because you know it'll help you know allay any of their it might help relate concerns but they're also going to help build uh some of those solutions and hopefully they can be you know proud uh to you know to help with that um and so you know that's kind of the relationship side of it obviously from the prioritization or from the the building side you know we're going to have to have a clear sense of what we're doing to help our users if we have to build some kind of data export uh if we have to bring users over to another product you know how do we make that graceful um you know obviously all the actual infrastructural work that goes into shutting down a product and managing you know like winding it down and shutting down whatever services or figuring out if like other you know figuring out what we can cut out of the code base in the future maybe don't want to be too bold about a refactor at this point but you know uh yeah right there there is a lot of playing that goes into now this hole of sorts that we're uh putting into the product um so uh you know we'll probably have to put this on the roadmap right it's not a thing that we can just do tomorrow we're going to figure out okay these are the several steps and phases that we're going to have uh you know we're going to give users time to find out about this we're going to launch you know this data export tool at this point so that they can start to move over and then you know it's probably not going to be six months a year two years later depending on what the product is and you know uh our users but uh you know it's going to be that long process of getting to the point where we are technically ready uh to shut it down and you know customers feel ready for it to uh to be shut down yeah i think uh that makes sense for the relationship with engineering and i think like for two points like first tactically you want to avoid any thrash you want to make sure that the team understands the priorities and how we're going to get there and the second is probably just morale like making sure that these engineers who have some connection to the products um you know they they they know that you're hearing any of their thoughts and um you're you're able to keep morale up even if the decision has been made to shut things down yeah and that thrash point is actually a really important one this is especially meaningful if this is a relatively new product right to have just built something and then you know on a short timeline be shutting it down because you know probably it means that it failed miserably unfortunately or had some like huge problems like that can be really demoralizing um and that's a really important place to have like a post-mortem on like why didn't this work right and like really bring in lots of opinions make sure that everybody gets heard uh so we can one you know make sure that everybody understands what's going on gets a chance to to be a part of this but also so that we don't have this kind of situation again or avoid it as much as possible obviously if this is something that's you know built 15 years ago and it's just time to sunset it like it's the thrash is you know not as uh not as meaningful it's like okay it's lived its purpose and now it's time for us to move on to new things and that probably will fit very well with our you know you know the strategic priorities we've already discussed with them cool thanks matt um and before we wrap things up was there one tip that you'd give the audience if they were facing a craft and execution question yeah um a lot of this uh you know whenever i think about it kind of depends on your theory of pming right how is it that you approach problems at the pm what do you think is important um you know and so as i go through i try to explain you know how i'm thinking about the problem itself and then you know how that contributes to what i'm doing about it um and you know that includes everything from what's the decision we're making about the product and how do we understand the product to how am i thinking about my team um how am i thinking about managing the actual process of execution right uh these questions are not just about the the one decision it's about the entire process there makes sense cool thanks matt and for the audience watching at home good luck with your upcoming pm interview thanks so much for watching don't forget to hit the like and subscribe buttons below to let us know that this video is valuable for you and of course check out hundreds more videos just like this at tryexponent.com thanks for watching and good luck on your upcoming interview [Music] you