BY The Product Experience ON DECEMBER 29, 2021

If you’re the kind of person that listens to the Product Experience and reads articles on MTP, then you’re already familiar with any number of frameworks, methodologies and principles to make you a better product manager.  But knowing them isn’t enough to do the job — or, at least, not to do it well.  Figuring out what works for you is way more important.  That’s something we discussed with Esha Shukla, Product Manager at WhatsApp, for this week’s podcast – she’s spent the last few years refining her approach to 5 solid principles that really work.

Listen to more episodes…

---

Featured Links: Follow Esha on LinkedIn and Twitter | Meta | WhatsApp

Episode transcript

Randy Silver: 0:00

Hey, Lily, Are you the kind of person that makes New Year’s resolutions?

Lily Smith: 0:04

Well, funny, you should ask that, Randy. Because last year, my New Year’s resolution was to eliminate plastic waste from my bathroom. And then I ended up joining Bauer collective, which its very mission is to eliminate plastic waste for the world. So that became a really easy New Year’s resolution. But I don’t generally make them I mean, I think just kind of like, you know, general self improvement is good. Read a few more books, that kind of thing. What about you, Randy?

Randy Silver: 0:36

Not really, I never saw the point of promising to be better at something right when the weather was so miserable. I do like the idea of finding something that you want to get better at making a plan and sticking with it.

Lily Smith: 0:49

Ah, I see what you did there. And that’s kind of exactly what today’s guest did.

Randy Silver: 0:53

Yes subtle. I am not.

Lily Smith: 0:57

Aisha Shukla is joining us to talk about her five product principles, things she’s learned along the way that make her a better product manager.

Randy Silver: 1:05

And we could tell you all about Asia, but she does an awfully good introduction herself. So hit the music

Lily Smith: 1:18

the product experience is brought to you by mind the product.

Randy Silver: 1:21

Every week, we talk to the best product people from around the globe about how we can improve our practice and build products that people love.

Lily Smith: 1:29

Is it mind the product.com to catch up on past episodes and to discover an extensive library of great content and videos,

Randy Silver: 1:37

browse for free, or become a mind the product member to unlock premium articles, unseen videos, amas roundtables, discounts to our conferences around the world training opportunities.

Lily Smith: 1:50

Mind product also offers free product tank meetups in more than 200 cities and less property. Hi, Isha. It’s so lovely to have you on the podcast today. How you doing?

Esha Shukla: 2:05

I’m doing great. How about you?

Lily Smith: 2:07

Yeah, very good. Thank you. And before we get stuck into our topic for today, it would be really great if you could give us a super quick introduction to who you are and how you got into product.

Esha Shukla: 2:19

Yeah, of course. Firstly, thanks so much for having me on your podcast. I’m really honoured to be here. My name is Aisha Shukla. I’m currently a product manager at WhatsApp for their group messaging team. I’ve been at meta for the last two years. Before WhatsApp I was working on a team that focuses on helping women particularly those in emerging markets feel safe and in control of the experience on the Facebook app by building features that could help address some of their safety concerns like photo misuse and stranger contact. Prior to matter, I was a product manager at meetup, which is a startup that focuses on bringing people together in real life through interest based communities and events. I worked on their organiser subscriptions groups and events team for about two years. Meetup is really where I got into consumer facing products and learn how to solve problems. By building features for millions of users. Before meetup, I worked as a mobile product manager at Citibank for about three years for their corporate mobile and tablet applications. Citibank is really where I kick started my product management career, I had done an internship there on one of their product development teams, while I was pursuing my master’s in engineering management degree at Duke. And I just really enjoyed how I got to collaborate across several functions like product design, engineering data, work on solving problems and building things for users. And so when I finished my degree, I went back and joined full time. And that’s how I landed into the world of Product Management.

Randy Silver: 3:56

I can’t believe you called meetup a startup, I guess after coming from Citibank, it totally makes sense.

Esha Shukla: 4:02

Yes. So when I joined them, I think they were they were smaller. I mean, they had just been acquired by we work, but I think yes, in relative scale of Citibank and meta in my head, it’s.

Lily Smith: 4:17

And so with all of that experience, and tonnes of experience there, we spoke the other day about how you’ve developed some principles for product management. So give us a quick overview of what these are, and also how you’re currently using them.

Esha Shukla: 4:34

Yeah, of course, over the last, I think about seven years of being a PM, I’ve learned some product principles, either through product leaders I’ve worked with or just situations that I’ve been in. These principles have helped me make effective decisions as a pm and today my goal of sharing them in this forum is just to help new PMS or aspiring PMS or encourage other people leaders to share principles they may have learned over their careers. I typically keep these in mind, in my day to day job as I’m making decisions. That’s how I find them most helpful and effective just to refer back to them. These five principles that we’ll go through today include, number one, lead with goals, not constraints. Number two, invest time and understanding how your product is built. That is the basic technical details. Number three, start with the problem, not the solution you or someone else wants. Number four, being opinionated and voicing it is a good thing. Number five, team morale is an important criteria to consider when weighing trade offs.

Randy Silver: 5:42

I love those principles. Let’s just start with that first one, and start with there. So it’s lead with goals, not constraints. So can you tell us about a time when you’ve used that or where that’s made a massive difference?

Esha Shukla: 5:55

Yeah, I think this is by far the most important principle I’ve learned from my prior manager at meta. This principle has helped me focus on the desired outcome and anchor my recommendations on that versus trying to alter the recommended path based on constraints we might face. today. I’ll give an example to help explain this. While working on the women in emerging markets team at Facebook, I had to present a recommendation for a marketing campaign that our team wanted to run for our feature, we were told that we had a limited budget available to run this campaign. And so we framed our entire recommendation around what we could do with the budget that we had available, hoping that this would expedite next steps and bring clarity into what’s possible. When we entered the review with leadership, the feedback that we got really surprised me, we spent about 80% of the review talking about what we really wanted to accomplish. And whether we thought our recommendation would get us there. That really opened my eyes and was a big learning lesson to think about leading with the goal in mind while listening the constraints but not having them define your recommendation. So the question that we got was, this is a budget that you have today. But if you had an infinite amount of budget, or what what budget, would you like to do what you really want to accomplish? And let’s focus the conversation on that versus being limited by the constraint that we have today.

Randy Silver: 7:15

Can you tell me about a time then where you’ve since you’ve learned this, where you’ve gone in with a different attitude or where you’ve helped somebody else? So change your attitude? What was the difference in the conversation?

Esha Shukla: 7:28

Yeah, I think constraints can be things like, you know, budget, people project timelines. And if you sometimes focus on constraints, you limit your path to what’s feasible today versus focusing on a need from your team or leadership to be really successful. And product and other function leaders are really there to help unblock you. So I think leveraging reviews to really position your asks by making sure you’re highlighting the constraints, but not limiting your recommendation. And I tend to follow this, even in the simplest forms of roadmap planning, right? You go into a roadmap, you typically try to highlight resources, which could be your team size today. And then you say, based on this team size, here’s what our strategy or here’s what our plan is for the upcoming half. I think ever since that example, or experience that I’ve had, what I will do is try to position it as what do we need to do to win? And then what is our current team size. And then if we have an ask you position that is there to say, this is what we would like to do. But with our given constraints, which is the current team size, here’s what we can do. So we’re asking you for additional headcount. So I think it’s just kind of reframing the conversation and making sure that you’re not starting by listening to constraints, but just bringing awareness and then asking leadership to really help you unblock yourself with them.

Lily Smith: 8:45

I think this is a really fantastic one. And certainly something that I’ve learned in my product career as well. I had a conversation just the other day talking about, well, this is probably what we can do with the resources that we have. And then my CEO was like, but, you know, go just ask me and or like, tell me what resources you need to just go that extra bit more. And I think it feels like there’s a lot more of these conversations happening where the product manager is, you know, thinking within the constraints, like you say, of, of what they have, and the leadership are like, no demandable for me, like, tell

Randy Silver: 9:27

me what I’m here for. Right? That’s what they say. Yeah. Something I keep telling teams that I work with is, you know, they complain that they’re not going to be able to hit the ambitious goals. We said, so that’s fine. Tell me what you know, tell me what you can do. And tell me what you would need to get there because I don’t know the gap. I can help you set that set an ambitious goal with leadership. I don’t know what is realistic. You need to tell me and I may tell you no, but we’ll adjust the goal if that’s the case, but I’d rather we started ambitious and then figure it out. Yeah.

Lily Smith: 10:00

Great. Well, that’s a very good first one. I love that. So number two was around understanding how the product works. What are your kind of top tips for enabling this?

Esha Shukla: 10:15

Yeah, before we jump into top tips, one thing I do want to clarify or call out is when I say you should invest time in understanding how your product is built, like the basic technical details, I do not mean, to be a successful product manager, you must have a computer science background, what I mean is investing time and working with your engineering manager or lead to understand how your product is built, what the tech stack is, what are some common constraints that you will need to keep in mind will go a really long way, particularly when you have to discuss trade offs, like technical debt or change in product behaviour for a feature because of some technical constraints that you might face. So just wanted to call that out. Before we jump into, you know, top tips. Regarding top tips, I think just spending time with your engineering team, it could be the engineering manager, or the tech lead that you work most closely with, to learn about some of these concepts for your product is the best start. Another tip could be to find technical papers, if applicable to your product area to gain some knowledge, jot down questions after you read them. And then you can use those to have one on one and talk to your peers about them. Both of these things will make you a stronger product manager. And I’ve learned this from my recent experience at WhatsApp, I just joined WhatsApp about a month and a half ago. So I’m still ramping up on this team. And what I found is WhatsApp has a very client heavy architecture. And what this means is, in order to launch new features to users, you have to they have to update their client, which is the app version. And we don’t force users to update your app version. So this brings in some very important considerations and challenges to think about when you’re making product decisions. For example, you have to be very deliberate about features and the quality of them when you roll them out. Because rolling back is not as easy thing is compatibility and user experience, you have to think about these because you could launch your latest app version, but not every user has updated to that. So what does the user experience look like for those that may be on an older version. And then number three kind of falling along those lines, keeping in mind and designing for some of the error states. So you have that in mind, for those that may not be on the latest app version? These are some really basic examples. But I think in specific scenarios, I’ve also been reading up on the technical paper for end to end encryption, because WhatsApp uses end to end encryption, what that is, how do you set up an encrypted session? What’s a ratchet function? All these things, I think, as basic concepts are really important for me as a product manager to understand, because when it comes time to building features and thinking about trade offs, these are things that I will need to keep in mind and will just facilitate better collaboration between me and the engineering team. So we

Randy Silver: 13:03

talked about the fact that it’s the engineering team job to figure out the how it’s our job to do the what. So how does this? How do you use this in a way that doesn’t get you into starting to tell people how to do it or potentially going, you know, going a little too far over that line?

Esha Shukla: 13:21

Yeah, I’m glad you asked that this, this, this definitely not intending to say that you should learn some of these concepts so that you can be involved or engaged in you know how the feature is going to be built. I think it’s just really helpful when you make trade off decisions. Because those are really times when your engineering lead or your engineer will come to you and say, because of XYZ or how the app is built, like the way that you’ve we’ve defined the requirements right now is not going to work, we need to think of some other alternatives. And at that point, if you don’t even understand what the issue is, I think it becomes really difficult for you to react. And so I think it’s just proactively understanding what issues you might face so that when you have to make decisions that require you to change your original requirements, or react, when there’s an issue or specific bug, it’s really helpful and you don’t have to spend all that time in the moment where you’re expected to make progress and just execute.

Lily Smith: 14:19

I really love this one too. I love all of them actually fit with this principle as well. I think that there’s a real opportunity here for you to get to know your engineering team better and also kind of build up a rapport with them by you know, being genuinely interested in what they’re doing and how that you know how the product is working. And, and wanting to kind of understand and learn and like you say it’s not you don’t have to go so far as to be an engineer yourself but just understanding the sort of basic principles of how the product comes together. And and I’m gonna, I’m gonna add to top tips I would love to do. So two of the things that I always ask my engineering team is like to draw me the technical architecture diagram. And so that I can see all of the different component pieces of the of the product and how they all relate to each other. And then the other one is understanding the data and the the kind of the flow of data and the way that the data is connected. So kind of the data model, but not quite as technical as the data model. But just to kind of sketch it out on a on a page with an engineer or two, just so that you get an understanding. And I find that these two things also really help.

Esha Shukla: 15:45

Great one. Thank you.

Lily Smith: 15:48

Inspired by by. Awesome, so number three. So start with the problem was the third principle that you mentioned. And as product managers, we hear this quite a lot. But I guess, with other kind of people within the business, it’s probably not as familiar a concept. So how do you how do you kind of bring that starting with the problem into your work? And what kind of inspired you I guess, to use a to define this as one of the principles that you follow?

Esha Shukla: 16:29

Yeah, I think like you mentioned as PMS, this principle is fairly common. And we’ve all probably heard it a lot. But I think there’s something about internalising it and being conscious of asking the questions to ensure that every single person is on the same page about the problem that you’re really trying to solve. Before you jump into focusing on the solution and get into execution mode. I learned this through an experience that I had when I was working at meetup. I was on their groups and events team, we were working on a company top priority project that was called supergroups. At the time, this project was aimed at highlighting some of the most successful groups on the platform by awarding them with badges and showing positive member reviews, sort of promoting these high quality groups, so members could find them easily. Throughout this project, I was new, first of all to the company new as a consumer facing pm as well. And the team were that we were working on kind of inherited this project. And so we were already in execution mode. And when we kind of transitioned and I realised reflecting back that we didn’t really stop to think about the problem or even question why this was the solution that everybody wanted. So I think the best indication that you spent enough time on the problem is to just ask your cross functional partners, like the team that’s working on it, ask them and ask each person to relay the problem statement as they think it is. And that can really help very quickly highlight any miscommunication if there is at all so that before you even start thinking about solutions, brainstorming execution, you are all aligned on is this the actual problem that we’re solving? And do we all agree that this is the most important problem that we need to solve? So

Randy Silver: 18:13

you did some interesting things you talked about, you came into something that was already in motion. And a lot of times when we talk about product stuff, we talk about coming to something fresh and and being the person who is you know, leading the the approach to it. Yeah. But when you coming into something in motion, that it’s a really good point, you can have a project plan, you can be working towards things. Curious, in this case, did you have a defined metric of success? To start with that that indicated what the problem was? Or was it the problem? Say it wasn’t? The problem itself? It wasn’t stated anywhere in in any of the sprints and ceremonies? He never came back to it? Or what did you find when you came in?

Esha Shukla: 18:57

Yeah, I think when I came in, the problem was stated until we did have success metrics around the number of supergroups number of events that members would attend of groups that were supergroups. But I think it went a little bit deeper in terms of internalising the problem statement, because the problem statement was you know, we want to provide recognition to some of these organisers that are really doing a lot of hard work to organise some of these events, right. And so this was a solution that we charted out. But when I sat down with the data scientists and the user researcher, we try to double click a little bit more on this problem statement to figure out is it impacting all cohorts of users across organisers that we’re focusing just on these kind of repeat loyal organisers? Or is this a universal problem that all organises irrespective of whether you’ve been organising events frequently, or not as frequently does everybody feel this lack of recognition? And so we did user research interviews, we also broke down the data trends to see And we found that it was not actually just to a specific cohort of organisers, but across the board. And so if that’s the case, the solution that we were working on would only really benefit some of the top organisers, not everyone. And so that helps us really reflect on maybe the solution that we need to build need to be more generic across all organisers not just for those that are, you know, loyal to us and repeat organisers because we want to benefit and reward organisers in the form of monetary recognition or sponsorships. And that should be something that all organisers should benefit from, not just the ones that have been with us the longest.

Lily Smith: 20:33

So if you find yourself in a situation where you are Kind of partway through something, what kind of conversations did you need to have to bring people back out of the solution space and back into the problem space? And how difficult was that? Yeah,

Esha Shukla: 20:53

great question. I think the kinds of questions you need to ask just start with sitting down, especially in this case, because it’s understanding the problem a little bit more, it’s sitting down with your data analyst or user researcher to really understand what does the current state look like. And it could be in this case, we were trying to make organisers happier. So what is the organiser satisfaction today, across different types of organisers? What are their problem statements? Do we have any quotes or feedback from focus groups? So really trying to use qualitative and quantitative data pieces that you may have to help understand the problem statements? It’s really sitting down with those two stakeholders? And then once you have had that conversation, I think it is difficult because the entire team is in execution mode, right? So this is where it can also be you coming in as a new PM, you don’t want to be that person who’s like, how are we doing the right thing, and then just shake up everything. So you have to be a little bit more mindful about how you bring your team along. And so that’s why you do this kind of homework with the data analysts and user researcher to make sure that you feel comfortable with the problem statement. And then it’s about just sitting down with the team in whatever team meeting you may have, when you’re talking about this project and say, Hey, we want to just make sure everybody’s on the same page. And you can do that same exercise that I mentioned earlier off, just go around the room and ask each person to talk about the problem. And then if there’s lack of clarity, it will just become really apparent. And then you can use that as kind of a trigger to say, here’s we’ve been digging a little bit more into the data or user research sessions. Here’s what we found. And so wonder if we should maybe just pause a little bit on execution and, and make sure that we’re solving the right problem. And the solution that we are working on, is really going to help us get there.

Randy Silver: 22:38

So I’m curious, when new people come into the team, you may have been on it for a long time, you may think it’s really well understood. Is this something you consciously use restaged in ceremonies or you use when you you’re onboarding new people?

Esha Shukla: 22:54

Yeah, I think that’s a good question. And and that can definitely be done. And the other I think, lesson that I learned to this experience was take advantage of that new person card, right? Like when you’re new, you can ask questions, and you should really take advantage of that. Because even if the question that you asked me sound as like, are we sure we’re doing the right thing, no one’s gonna, no one’s gonna be offended by that because you are the new person. And then they’re going to try to sit down and help explain the problem to you. And that itself can be a good way to make sure you are taking advantage of that fresh perspective and ensuring that everyone’s on the same page.

Lily Smith: 23:29

Awesome. Thanks, Isha. So let’s move on to the next one. This one is also great. I actually used this advice today. So I was very happy that I had this conversation, or you know, we were having this conversation today, because this advice came in very handy earlier on. And being opinionated is a good thing. And so tell us a little bit more about how you learned about this principle. Yeah. And how you use it now?

Esha Shukla: 24:02

Yeah, this was something I think I really struggled with in my early pm years. Going forward with the story of meetup while I was working there, I mentioned that I was the first like, consumer facing pm role that I had. And so you know, I was working on features that would be used by millions of users. And so on that high priority project that we were just talking about, we used to have these weekly workstream meetings, where leaders across all the different functions would be in the room, and you would talk about priorities, blockers, and progress against milestones. And so that room, obviously, because it was a top priority project, everyone felt really connected to it. And so they had strong opinions and choices when decisions had to be made. And so, being a pm on that project, when there were recommendations that had to be presented, I’d lay them out on a slide and say, here are all of our options with the pros and the cons, but I didn’t really strongly voice my opinion in that room to say off these four options, this is what I think we should do. And here’s why. This was because of two things. Partly I was the new PM. And I felt like it wasn’t my place to have the opinion, all these people in the room has so much more experience than me. And so I can just present the options. And then that way we can use them to make the decision. And the second part of that was a little bit more about just being hesitant or shy to speak up in a room full of really opinionated people. And so, because of this game, and it gave impression to a lot of people that I as the product manager didn’t really have a strong opinion or stake in the ground, which is not really the case, it was just not the right forum for me to, to express that. And so a big drawback, in addition to the feedback that I got that people felt like I wasn’t strongly opinionated was just It took so much back and forth after that meeting to just really align on the decision because you didn’t go I didn’t go into the review and saying, they’re the four options. This is my recommendation, do we agree? Or do we disagree, I think that would have really helped facilitate, and make that decision much quicker. And so through that experience, the way I use that principle, going forward now is just making sure I have an opinion from what the product should do. So not just in the short term, but what is the nonstop for that feature, a product that I’m building, and number two, every single time an option, or is presented or several options, I will document the criteria that we’re weighing them against, but I will make sure I call out my recommendation whether or not they that may be the direction we ended up taking. But that actually helps facilitate a conversation to say this is your recommendation, I actually don’t agree, let’s talk about the other options. So it just kind of, even if it may not be the recommendation that everyone agrees with, it just helps facilitate quicker decision making.

Lily Smith: 26:46

I think that’s great. And there’s that whole thing isn’t there around, you’re looking for consensus, not agreement. That’s the phrase, isn’t it? And, you know, just being able to say, you know, this is my view on things, but also being able to graciously go okay, you know, if the consensus, or if the the decision is to move forward in this particular way, that’s fine, you know, then we’ll go ahead with that. But you’re able to put forward your your view. And I imagine there are some PMS who may struggle with voicing their opinion, especially if you are more junior, or if you’re new to the business. Or if you’re just, you know, slightly more introverted, perhaps, in a room full of extroverts. Just even finding time to speak can be difficult sometimes. So do you have advice for anyone in that situation?

Esha Shukla: 27:47

Yeah, I can give advice based of what was given to me when I was in that situation struggling, I think the best thing to do is, if that forum, which is a large firm of everyone is not the right, you know, mechanism for you to voice your opinion, talk to your manager about alternative ways. And I talked about two alternative ways with my manager, which we then put into practice. And number one was to make sure that I started to develop this habit of voicing my opinion in that forum. And so my manager would point at me and say, What do you think about this issue, just kind of as a way to pause the conversation and bring it back to me and give me that space to voice what I want to. And the second, I think alternative way is to do it in a written form. Sometimes that gives you more time to process your thoughts, put them into a comment. So it could be a Google Doc or a slide that you’re working on for that project. And so if that live meeting is not the best way for you to present your recommendation and voice your opinion, do it async do it in a written form of communication that allows you to kind of spend time thinking about how you want to position you are a POV.

Randy Silver: 28:56

So I’m curious about this, when you go looking the way I do coming from the background I come from this is not something that I’ve ever really struggled with. And I’ve always felt the ability to to voice an opinion. They haven’t always been the best opinions. And I’ve gotten negative feedback on that at times and totally fairly. But I recognise that not everyone feels as comfortable speaking up. Is there any advice you’d give for for people to ensure that either they can create a better environment for themselves or you talked a little bit about how your boss helped you or about potentially doing it for other people as well?

Esha Shukla: 29:33

Yeah, great question. I think it goes both ways, right? It’s it’s the two camps of people, people who feel really comfortable and confident expressing their opinions and then the other camp that doesn’t I think the best way to do that is if you are in the camp of someone who is openly voicing your opinion, you feel comfortable and confident. Just pause and and see around the room and see if there’s somebody that’s hasn’t spoken up the entire meeting or hasn’t said something. I think that’s the best way and you can create that form a place for them to eat. paying them separately and say, hey, you know, just wanted to make sure that you felt aligned with what we talked about? Or do you have a different opinion on what we just discussed? Or in that meeting, ask the person to say, what do you think? And so really creating that space, I love that you asked that question. I think creating that space and being mindful, and just observing, maybe there might be people in the room who aren’t speaking up and just facilitating that for them is really appreciated.

Randy Silver: 30:24

And I have a feeling that one has a big bearing on the that last principle as well about team morale. So do you want to dig into that a bit?

Esha Shukla: 30:33

Yes. team morale is a very important criteria when weighing trade offs. And I, I think when you say this as a principle, it sounds like yeah, of course, right. But I think when, at least for me, personally, when I was going through that example, when you are weighing trade offs, there are a lot of different criteria that you may consider, like speed of execution effort impact to users. But I’ve never really seen in that traffic like method when you have different criteria, team morale being one. And I’m not necessarily saying that it needs to be weighted against some of these other criteria. All I’m saying is, when you are making an important decision, I think it’s important to stop and make sure you’re cognizant of your team’s morale, especially when you’re making trade off decisions. This happened to me last year, when my team at the time was asked to expedite launching our feature, which is called profile, lock it in a single toggle makes all your past photos and posts shared to friends only, and then all your future photos and posts will be shared with friends only. So this feature was really targeted in emerging markets, where there’s loads of literacy and just fear of retaliation and low motivation to report bad behaviour to make sure that people felt really safe about what they were sharing on the platform. And so we knew we were working on launching that feature last year, I think it was June. And then COVID happened. And with COVID, we all know that everyone’s reliance on social media really went up to communicate with your friends and your family. And so we were asked to see if we can expedite launching this feature sooner so that you know more users could benefit while they were on the platform. And so we did the whole rubric of vein trade offs, cutting the scope, bringing more people onto the team, the impact that would have for the users. But we didn’t really stop to think about team morale. And as you can imagine, with COVID, there was so much going on everyone’s personal and professional lives that we launched the feature, everything went great. And then we did a retro on the whole expedited launch process. And obviously, we I heard feedback from the team to say, they just felt really stressed at times, especially with everything else going on in the world. And they would have appreciated, you know, just thinking about whether exporting the 10 line by a month was worth all of that. And so that really helped me reflect on Oh, I shouldn’t have really done this, I should have been more productive as a PM, especially in this situation where there was so much going on to make sure that the trade off of pulling up the launch by a month was actually worth it even for the team. Because the worst thing you can do is make if your team is not happy, that’s not great. And so that has really taught me going forward, especially when it comes to things like expediting lunches, when you’re winning trade off decisions, talk to your team and get feedback from them directly on whether they agree whether they don’t agree whether they have concerns, and then you can use that as in your rubric of making decisions.

Lily Smith: 33:25

And let’s just kind of talk a little bit more about you know, you make it sound very simple in terms of like, just talk to the team and find out how they’re feeling. But I guess there can be complexities in that because, you know, certain people might prefer to go a different pace to other people on the team. And then you kind of need to weigh off how different team members, you know, respond to different environments or, but also like just asking people out rates, you know, does it give you enough information? Or is that balanced with like, just what you know about the team and what they can you know, that the situation in which they thrive?

Esha Shukla: 34:07

Yeah, great question. I think for conversations like this, I’ve personally found making sure you are building a relationship with each person on your team, just regularly through one on one so so that when situations like this arise, you sort of know the person and you can talk to them one on one. I do agree with you, I think, you know, it’s not as easy as it sounds. You can’t just ask the team in a team meeting. Like Are we all okay with this chances are a lot of people are not going to open up or say anything. And so that’s really where building those working relationships one to one with your team members comes in real handy because you can talk to them throughout what you’re working on and then in a situation like this address and make sure that how they how they feel about the situation so you have all the information that you need it maybe you know, in one on one conversations, but at the end of the day through those conversations So at least you’ll have a picture of how your team feels about it. And in this case, I think reflecting back, if I had done that, I would have realised that expediting it by one month was going to put a lot of pressure. And, you know, even in terms of what we got in return, I think, yes, we got the feature quicker, we had a lot more users using it. But that that was a trade off, right? The team morale versus getting it out, like 30 days ahead of time. And so I’m not sure going back, if I would make that same decision, like 30 days is not a significant amount of time. If it was like more than that. Sure. Maybe you have a conversation with your team and talk to them about it. But that’s, that’s my recommendation is just building those relationships one to one, so you can understand your team in situations like this. Yeah,

Randy Silver: 35:42

you should. This has been fantastic. And we’re running short on time. So I’m gonna do one more question for you, if that’s all right, yes. Okay. So my favourite thing about these principles is, it’s gonna sound like a backhanded compliment, mean it in a really genuine way. They’re not the most original of things. In some cases, they’re things that I’ve heard from other people in places, but what I love about is that you’ve made them yours. And you’ve really thought about what’s important to you, and you use them all the time. And I think that’s more important than necessarily being original all the time. You don’t get points for originality, you could point you’re doing it well. And that’s really impressive about the way you thought about it. So I’m curious if you’ve got five, and it’s a great number, but I’m always suspicious of people who have lists that are very specific number. So is there anything else that you’re potentially working on or anything else that might be one more that that ruins the symmetry? But?

Esha Shukla: 36:37

That’s a great question. Yeah, I love that you brought it up, they are very simple, really. But I think with principles, what it comes down to is really relying on them and using them so that it becomes habit. And the larger number you have, the more difficult it is. So I think for some anyone listening, the advice I would give is like start with a few like it could even be one and then make sure that you’re really relying on that when you’re making decisions before you start to add to the list. If there was one that comes to mind that I again, try to use in a lot of my product scenarios or reviews is maybe somewhat related to being opinionated. But when you’re having discussions around what recommendation or which path you might go on, and if people don’t agree, just disagree and commit, I think that’s really undervalued. But it’s so important and can help push the conversation. And if you just have that as a principle to making decisions ahead of time, there’ll be no hard feelings and you make sure that the team is getting what you need not so much as one person’s recommendation being what the what you end up working on. So I think just recognising that there is conflict and agreeing and saying we don’t agree, but we’re going to proceed with this direction. Anyways. And are we good with that? I think is another one.

Lily Smith: 37:51

Isha, thank you so much. It’s been such a pleasure talking to you today. And hopefully everyone will enjoy these principles and take them away and do lots of them. But yeah, this has been fantastic. Thank you.

Esha Shukla: 38:06

Thank you so much for having me really. And Randy, I really appreciate it.

Randy Silver: 38:19

Hey, Billy, do you have any principles that you’ve this by? I’ll take that doesn’t know.

Lily Smith: 38:31

I probably have loads, but I’m really terrible at answering things like that under pressure. How about you?

Randy Silver: 38:37

Um, I mean, I put together for things that start with P. So I called them my product principles. But yeah, I love the way that he shows thought these things really through and applies them. It’s fantastic. And I think it’s something that we could all use a little more discipline about.

Lily Smith: 38:55

So how can you only have four p’s and not five? You know, I thought everything was meant to be uneven in the world of lists.

Randy Silver: 39:04

Because I’m not done with it yet.

Lily Smith: 39:07

You shouldn’t have added the third one. I know the fourth ones until you had a fifth one. They have to come in to us anyway. start rambling let’s let people go and have a lovely evening or day whatever it is. Thanks for listening.

Randy Silver: 39:23

Be New Year.

Lily Smith: 39:34

Haste, me, Lily Smith and me Randy silver. Emily Tate is our producer. And Luke Smith is our editor. Our

Randy Silver: 39:43

theme music is from humbard baseband power that’s pa you thanks to Arnica Hitler who runs product tank and MTP engage in Hamburg and please based in the band for willingness to use their music, connect with your local product community via product tank or regular free meetups in a Over 200 cities worldwide.

Lily Smith: 40:02

If there’s not one Nagy you can consider starting one yourself. To find out more go to mind the product.com forward slash product tank.

Randy Silver: 40:11

Product Tech is a global community of meetups driven by and for product people. We offer expert talks group discussion and a safe environment for product people to come together and share greetings and tips.