How to prevent product failure — Anu Jagga Narang (AT&T)

Sometimes failures are predictable before we launch a product or a feature and it is socially very hard to say those out loud. What if this is like a resounding success? Do we need to think about that as well? If anything, AI increases the need for premortons instead of reducing it. A paper tiger is a risk that others may be thinking it is a risk, but the owner of the risk believes that they have it under control and they just want to reassure the team. I'm a product leader at AT&T. I recently moved into the role. I'm focused on helping the team strengthen their product strategy and how PMs are coached to lead outcomes instead of feature-based delivery. We're very AI focused. product team building a lot of features where the customers can get the appropriate answers how do you get people attuned to the right level we don't have to be apocalyptic about it we can frame it as it was an utter disaster annie thank you so much for joining us this week how are you doing today i'm very good thank you randy how are you doing all right we haven't recorded actually in a week or two so it's it's nice to get back into the groove and uh we met at an event that I ran in New York with a few other lovely former guests and wonderful people. And you came up and had some really great questions afterwards. And then you said you wanted to come on the podcast because you had some really good topics. And now here you are. This is fantastic. Yeah, I'm excited about it. So we're going to talk today about about pre-mortems, but, you know. Like I said, I've met you. I know who you are. Not everyone does. So can you give us a quick introduction? What are you doing these days? And how did you first get into product? Yeah, absolutely. I'm a product leader at AT&T. For those not in the U.S., AT&T is a telecommunication company. I recently moved into the role where I'm focused on helping the team strengthen their product strategy, how products are built, how problems are defined, and how decisions are made, and how PMs are coached to lead outcomes instead of feature-based delivery. Right before this role, I was leading a team that is building AT&T's search and virtual assistant experience so think of it as a chatbot experience i've done that role for five years and we were very ai focused product team building a lot of features where the customers can get the appropriate answers for questions that they're looking for and get the support for AT&T products and services and how do you get into the whole world of product management in the first place I went to school to be a software engineer and very quickly realized that I was not a good one. But I was always on the creative side, so gravitated towards doing user experience design and visual design, brand management, logo to creation, things like that. from there i gravitated towards doing information architecture and to business analysts and that was my road to product management i believe it's not a very traditional path but it is not a very unique one either um but i i just love product management and when i was doing information architecture i was an avid reader of consumer psychology and really wanted to understand how people behaved and thought and which informed a lot of my product decisions today and i kind of love the thought of being like a product evangelist like and and coaching all of the product people in the product teams but do you how long have you been doing it do you miss doing the hands-on work as well or are you just like really enjoying doing the coaching side of things i am six weeks into my new role okay i am still what they call finding my sea legs and i i still get to work with a lot of the teams to help them think through problem statements and build experiments and and work on their strategy so uh it's a lot less hands-on at least from what i can tell at the moment but i think time will tell but i also do a lot of ai product development on the side of my own to try out different tools and um and build products on the side so i don't think i'm going to lose the muscle of building products now specifically now when it's making it so easy with ai so uh a software engineer a not so good software engineer like myself can now develop better with ai tools that we have okay but what we're going to focus on today or at least what we're going to start with is something that predates uh the the common use of ai by quite a bit it's a technique that i think we all really love but you've written about it and you've thought more deeply about it certainly than i have and i'm curious so well let's do the background on it first So we're going to talk about premortems. So just give us the background. What are they? Where do they come from? Why are they so important? Why are you so interested in them? Absolutely. And I said that I was very deeply interested into consumer psychology, and this kind of have a little bit of a background into it, and I'll talk about that. But let me define it first. A premortem is a hypothetical disaster prevention exercise, kind of like a risk assessment, where you can assume that the launch has happened and it failed and then work backwards from there to say why why did it fail and what decisions we could have made differently so if you can think of it as a decision quality tool The method was created by cognitive psychologist Gary Klein about 30 years ago to proactively identify potential risks and issues and failures that his project may cause. So the core psychological trick it uses is called prospective hindsight that combats overconfidence and optimism bias. Why they matter? Sometimes failures are predictable before we launch a product or a feature, and it is socially very hard to say those out loud. Premortems create a psychological safety and a permission for the teams to surface any weak assumptions, any risks, or any hidden dependencies that they may not have encountered before. And this shifts the mindset from more like execution confidence we built a project plan we know what we are doing to uh thinking rigor of are we on the right path or not and you've mentioned there that this is kind of mostly focused on identifying where things could go wrong and assuming like failure or or thinking about failure you know do you ever kind of expand that into thinking about well what if this is like a resounding success like Do we need to plan for that or do we need to think about that as well? Yeah, absolutely. So we can do a success-based exercise to determine whether it could be a resounding success. What that can surface is, do we have any scaling risks? And I suppose in a way, actually, you're still thinking about failure because if the product feature or whatever is successful, but you're not prepared for that success then it's still some kind of failure so actually it's you know it's kind of thinking about failure but from a like well the future was really successful but we weren't prepared for it so therefore it was a failure so i guess in a way it's it's still kind of thinking about where it might fail if you're not prepared yeah i wouldn't replace premortems for an optimism exercise um i do think that it can uh to your point surface um scaling risks or organizational readiness for example because then you can say uh well it was a success and we were surprised that this was a success but did it it wasn't because we identified like we did we plan it right did we identify all the risks right but we didn't think about how we're going to scale it that perhaps the initial launch was success but the long-term scaling or adoption of a particular feature might still remains to be seen and that might surface up more signals of whether it is a success or not But thinking about framing it as a failure is almost as if like, it's like a cognitive unblock because we are attuned to thinking about it more to be more successful than to be a failure. How do you frame it when you're talking about failure? There's, oh God, oh God, we're all going to die. And then there's, people will just won't be happy. This will achieve, you know, 60% of what we wanted to do. How do you get people attuned to the right level? So we don't have to be apocalyptic about it. We can frame it as, hey, we launched this feature, we launched this product, and it was an utter disaster. We did not, it's six months down the line. So it's not like it's right after the launch. It's six months after the line. We've been measuring how the progress has been going. and it is not what we expected it to be so if you are defining the objectives of the product or the feature clearly and then you are tracking them over time and then you're determining that it's not going the way we had hoped people are not using it the right way or the same way that we expected or it is not being adopted as well as we thought it would or it's not driving the revenue that we wanted if any of those objectives are not being met as they were originally hoped hopefully they were well defined and they are not being met then the team has to then think about but what what did we do wrong so instead of doing it as a postmortem you think of you frame it in originally as imagine that this launch and now we're six months into it and all of our objectives haven't been met what did we do wrong what i love about that is it assumes that or it forces the team to ensure that they have an agreement on what the objectives are and i think lots of times we skip that part i've never thought of that as one of the forcing functions of a pre-mortem yeah yeah and if you can go into and talk about how it is conducted uh usually it starts with a kickoff where the team um and it can happen you can create do a pre-mortem before the project or the product has development has already started you have finished the discovery you have understood the problem statement you're you're working towards and have defined the objectives and then you kick off a pre-mortem to set yourself up for success you can also do it midway uh you are already under view of your development and um and then it is not going as you hope there are some signals from the team there may be an organizational dysfunction that you are addressing so timing aside it starts with the kickoff where you would reiterate and clarify here are the problems we were solving for here's what we're solving for here's our strategy here are our objectives and then when everybody who's who's a core part of the team are on the same page is when we go into creating a psychological safety and asking the teams to imagine that the this product as we have defined it as the objective we have defined it have failed and Now we're wanting to understand why. Yeah. So, and just talking about that sort of like the actual practicalities of running a pre-mortem, you mentioned like, you know, having a kickoff and gathering the team together and going through that process. I think you have a bit of a sort of like structure, don't you, with like what the steps are to follow in order to have a successful pre-mortem. You don't need a premortem for your premortem. So take us through, you know, you mentioned kickoff, but what are the other kind of factors of running a successful premortem and getting a good outcome from that actual process? Absolutely. Let's talk about tools first. How do you do them? You can do them in person or remotely. If in person, you can use sticky notes and a whiteboard and start putting them up there. um but if you're doing it remotely you could use tools like coda or product board or ideas boards any or any of these tools i have used idea boards extensively it's a very little known tool i like that it is anonymous and i think that helps the teams create a psychological safety to be able to openly speak about the issues and the risks that they are observing Coda is not as anonymous. There are usually people giving the feedback, has their name attached to it. And I imagine same as for product board as well. So after the kickoff and setting the stage for assuming failure and making sure the teams understand that we're trying to understand why a product launch has failed, the teams are then asked to essentially write the story of why they believe it happened. So usually I give the guidance of don't use like keywords or bullet points, like be very prescriptive because a lot of the times teams might give, and especially if you have a multicultural team and there might be a little bit of a language difference, that their way of expressing the issue at hand might be different. So I ask. for it to be very descriptive about what is the issue, perhaps give an example of a situation where that might have happened. And then once the team puts up all of theirs, everybody will review it together and then the teams provide upvotes. I have learned in the past that if I did not rein in the number of votes, people would upvote either their own issue or others' issues a lot more. So I have restricted it to one vote per idea and two votes for paper tigers and one for elephant. I know we haven't talked about that yet. Yeah, I was going to say, tell me about the voting. How does that happen? What are you voting on, whether you think... something is more likely to happen? I also believe that this is an issue. So if everyone is entering there or providing on their sticky notes their issues of why they think a product launch might fail, then you may see that someone else might be feeling it that way. So one of the reasons pre-mortems are done more openly and transparently so everybody on the team can see, someone's issue so let me give you an example we ran a pre-mortem last year where we were working on a fairly large launch and one of the things that a lot of the team members were facing but were not communicating were that the performance of the application was not meeting the mark it was really extremely slow so someone entered that feedback and it became one of the things that became the most upvoted because a lot of the people had experienced that had thought about it but but we haven't talked about that as a risk so once someone puts out their risk out there then other people can upvote that if they believe that that's something that we should focus on but if we don't restrict or have guidelines around voting then It can get aborted a lot and we may then be focusing on the wrong risk. So the guidance is then only the issue only gets voted by one person only once and they can vote on two tigers, two paper tigers and two elephants. OK, that's a menagerie. What is the difference between a tiger, a paper tiger and an elephant? Yeah, so huge shout out to Shreyas Doshi. I adopted Tiger's Paper Tigers and Elephant Framework from him. I think it is a very powerful way to classify risks. A tiger is a very clear threat. If we don't address it, it is going to kill us. So it is a concern that is going to just cause us to fail. A paper tiger is a risk that others may be thinking it is a risk, but the owner of the risk believes that they have it under control and they just want to reassure the team. So it's not that it's not a risk, but it is under control. So it's just more about communication. And an elephant is really just a proverbial elephant in the room. We should talk about it. We haven't talked about it. um and this is something that is uh needs to be addressed so if a lot of the individuals on the team are feeling it but are not talking about it it's this is a good place to communicate that as well so when we talk about tigers paper tigers and elephants usually i would create three different categories and have the team my team or my former team now knows the difference between paper tigers tigers and elephants But it would be good to describe if you're doing it for the first time, what these are and have the team categorize their issues in each of them before you start sharing it and aborting it. Hey, Lily, quick question. Do you ever get that moment when you're looking at your professional development budget and think, okay, what should I actually spend this on? Yes, definitely. It is tricky, especially when you want something inspiring, practical. And actually useful for your career, not just another checkbox course. Exactly. Which is why I always point product folks to MTPCon London, happening on 16th of June. A full day of world-class product talks, real case studies, and thousands of product people all in one place. It's basically a year's worth of learning packed into one day. And it's the perfect thing to put your team or personal training budget towards. Whether you're using up what's left... or planning how to invest your new budget for the year. Honestly, it's one of the smartest ways to grow as a PM or product leader. And it's fun, which is a bonus. If you want to grab your ticket or get help getting it approved, just head to mindtheproduct.com and search convince your boss. Get it covered, get it booked, and future you will be very pleased. So I'm guessing the paper tigers are ones that, you know, someone has said that they're assuming the risk. It's under control. So it's not one that you need to spend a lot of time on, assuming that everyone, there's nothing unexpected that comes up out of it. But what's the difference in how you deal with tigers and elephants? So tigers are really the risks that need to be addressed first and prioritized. Elephants are typically the type of risks that need to be put out there so the teams can visualize them that it's there. And sometimes it's also the cognitive load that we're thinking about. No one's talking about this thing and it's out there. But now once it's there and we can track it, we can then also prioritize based on upvoting on whether an action needs to be taken now or whether an action needs to be taken on it later. Okay, so once you have... your votes and you have a kind of a map of presumably at the end of this you have a map of like all of the different things that people have imagined can go wrong and you've had the team kind of vote on things and categorize the different risks what's the next step after that so the next step after that is assigning owners and actions so then you have to look at the ones that are the most upvoted or the most critical issues for launch and then say okay if this is the most important or most critical issue to fix whose ownership is it what would be the next step it's almost big turns into a a next step action where you say when is this going going to be fixed uh or what do we have a solution for it if we don't uh and before we talk about when is it going to be fixed so it really looks at helps us create a plan for when an issue needs to be addressed and fixed and how it will be fixed. When do you know how you're going to run a premortem? Is it a feature level and a product level, but maybe if you're just changing the functionality of a feature, does that need a premortem? What's your sort of... the characteristic of a piece of work that means that it needs a premortem? Yeah, that's a good question. I would run them before any major launch or before any irreversible decisions. Right. if uh there and there is no fixed cadence for when you will do them and and they're also not one and done i have done pre-mortems at the kickoff of a particular product that we were starting to build a new strategy we were executing on it was completely greenfield and then i have come back and done it also when we were midway and we were like we're we seem a little off track this general sense is that there's either a little bit of a dysfunction between teams though the time dynamics aren't matching we're speaking through different sheet of music so so that's a good time to come back and say okay are we aligning and it's different than a sprint retrospective because sometimes a lot of these issues come up there as well and just tactically then the scope has shifted either when it's a you know brand new greenfield launch as i said before or when scope has shifted when assumptions have changed when new information is showing up in our engines then it's good to look at a pre-mortem to avoid going further into being a little bit more risk-taking into our assumptions It's also generally a good practice to come back and do it again if you're being like completely risk averse. The another way if you're doing a second session of pre-mortem you can think about it is you can frame the questions as if we did nothing and we failed what would happen and why would we have failed then? You said we a few times in there, and I just want to clarify who's we in this case. Is it a single product development team? Do you get stakeholders in? Do you get related teams in and about how long does a session take? The session should not take more than 30 minutes itself. The action planning can take a little bit longer. We, in this case, is essentially the product leader who's leading the discussion, creating the psychological safety for the teams to openly talk about the issues. The team itself is a combination of product managers, engineers, everybody who's core to the team as part of the development of the product or the feature. I have included stakeholders in the past in one of my premortems. I felt that it was a little bit more strategic focus than tactical focus. So the focus can shift if you bring stakeholders into the conversation. It's not necessarily a bad idea. And depending on the trust and the relationship you may have with your stakeholders, it may be a good idea to bring them into view from their standpoint on where it is going. But for the team to have that psychological safety, sometimes they may feel that bringing in stakeholders will breach that. So I think it really depends on the relationship the team has with the stakeholders and with their leader and how much psychologically safe they feel to be able to openly talk about the risks. So it would vary with different stakeholders and leaders to bring everybody together. So how many... premortems have you run and is there anything that sort of really surprised you or um you know or come up in a premortem where you were like well i really wasn't expecting that um i have run about five premortems uh over the last two and a half years i am surprised by things that at the surface didn't show as risks it appeared that i'll take the same example that was before why it was so salient in my mind was because i did not expect performance to be at the top of so many people's minds on my team for an application we were about to launch and that really helped us steer in the right direction it was such a meaningful feedback from the team and and change that we were able to turn things around very quickly to bring performance up when we put the right focus on it so that was one of the things that everyone was working through their features the development was going we were testing and performance was lacking and sometimes test environments are a little bit strange for us so so it wasn't quite clear until we actually started to talk about it and people felt comfortable to speak about it out loud and were worried about it that we then found that that was something we needed to focus on when you were kind of introducing the premortem for this project at this stage is the premortem just kind of part of your product managers toolkit or do you get sort of signals from the team or the project that you're like Something feels a bit off here. Maybe I'm going to pull out my premortem now and run it and see what comes out of that process. Yes, that's a really good question. I do look at signals and I encourage a lot of product leaders to have that ear to look for signals from the team. So my more recent premortem was back in October and it was a follow-up premortem from something we had done earlier in the year when we had kicked off an initiative. the feedback in the first premortem was a lot around requirements being a little bit unclear the team wasn't focused on the right problems and there was some scope creep so because we were early in the initiative we were like oh if we were not clear in defining the problem statements we're not going to be successful which is a good indicator of where the product team needs to pay attention to and then we did a second round and learned that we had fixed a lot of the systemic issues however we still had the scope creep problem and not only we had a scope creep problem some of the accountability of the actions that we had taken back in earlier in the year were not completed which was kind of a lingering problem. So that was an indicator of, do we need to coach people differently and upskill them differently? So sometimes it can surface up issues that are not part of the project or a product you're building, but also the different personalities on the team and the team cohesion. Yeah. Yeah, that makes a lot of sense. So that's all really interesting. I'm curious. identified the ways to go well. You've talked about a couple of issues that might come up. What are some of the other common mistakes or anti-patterns that you see when people use premortems? Yes. And this comes from some of the experience that one time we ran a premortem that was more for a platform development we were doing. So it was not really a very specific, comprehensively defined. problem statement and we just had a really big backlog of things to do and we felt that we weren't making a lot of progress and i was the one who suggested we should do a pre-mortem to figure out what's going on here and that was just really not the right strategy there not tying it to a real launch is not the best approach because then you get a lot of noise around good sometimes good noise but noise around team dynamics and you know what's not working um and those are all good signals for a leader to go focus on fixing some of these other problems but the pre-votem is not the right tool for it unrestricted voting i talked about that a little bit when When I didn't have guidance around voting, how many issues to upvote, how many issues to, how many votes each person gets, then just people went to town with it. And then using them to provoke reactions or venting frustrations. There are so many times I have seen that people would provide a feedback, which was really to just generate a lot of reactions, but was not. meaningful people weaponizing an agile ceremony imagine that exactly the other issue that may surface is if you treat every risk as equal if you are comparing between tigers paper tigers and elephants but are not and are treating them all at the same level playing field without doing an assessment of how big or how critical or priority of that issue is then then it's really just noise for the team to not know what the focus is so providing that focus of what what are the important issues that we're going to work on and um as i was stating from my example before if you run them once and forget about them or if you run them and don't take actions on them then the premortems are not useful at all. So run them and revisit them periodically as a product development or project evolves is helpful because it's such a crucial area for the teams to understand how it is created. And I think the last thing I will say is, especially for the leaders, if psychological safety is not created for the teams, you are going to get surface level issues. The teams are not going to feel comfortable and safe in speaking about the deeper issues that they see at the working level. And then the project is not going to be successful. I think that's really helpful and a lot of really great tips there to make sure that it all goes well and is impactful. Just one final question I think we have time for. What impact does having all the kind of new AI tooling that we have at our fingertips these days have on how you're running premortems? Absolutely. And AI is just such a buzzword at the moment. And if anything, AI increases the need for premortems instead of reducing it. With AI, we now have the ability to ship features and ship products for the wrong problems just faster so ai introduces this like false confidence of faster output but it may not be better judgment and one of the things that we need to think about as we are shifting to AI-based development and also using AI for more efficiency gains is thinking about risks from shifting and asking the question of can we build it to should we build this, right? Should we ship this feature? AI can be very useful in summarizing the themes from the premortem. It can root out the duplicate risks that have been identified because there might be risks that are identified, just phrased differently, but really the root of it is the same. And it can help track the mitigation plan. What it cannot do is create psychological safety. It cannot create courage between teams to speak about things out loud. It can also not surface elephants, things that were left unsaid. And it also cannot make trade-off decisions or own any consequences of having a failed product launch. So premortems at the end of the day really still remain a human judgment-based exercise. AI can definitely help reduce this administrative and clerical overhead. And that was fantastic. I think it was really interesting. It's something I haven't dived into or run a premortem in a long time. Thank you so much for taking us through it today. Thank you for having me. Thank you, Annie. The product experience hosts are me, Lily Smith, host by night and chief product officer by day. And me, Randy Silver, also host by night. And I spend my days working with product and leadership teams, helping their teams to do amazing work. Lou Ron Pratt is our producer and Luke Smith is our editor.

In this episode, Lily Smith and Randy Silver host Anu Jagga‑Narang, a product evangelist at AT&T, to explore premortems — a powerful technique for anticipating product failure before launch. Anu explains how premortems use prospective hindsight to uncover risks early, surface assumptions teams are reluctant to voice, and improve decision quality. 

The conversation covers practical steps for running premortems, risk classification using tigers, paper tigers and elephants, common pitfalls, and when to revisit the exercise as products evolve. They also examine how emerging AI capabilities influence product risk management — increasing the need for thoughtful planning rather than replacing human insight. This discussion offers product leaders a framework to strengthen strategic thinking, foster psychological safety and equip teams to build with confidence and clarity.

Chapters 
02:14 Career Journey into Product
05:03 What Is a Premortem?
07:04 Framing Failure and Success in Premortems
11:02 How to Conduct a Premortem
15:04 Voting and Risk Classification
17:00 Tigers, Paper Tigers, and Elephants
20:22 Assigning Ownership and Actions
21:28 When to Run a Premortem
23:40 Who Should Participate and Duration
25:14 Examples and Surprising Insights
28:43 Common Mistakes and Anti‑patterns
31:51 AI’s Impact on Premortems
34:13 Closing Remarks and Credits

Key Takeaways
— Premortems shift focus from execution certainty to better decision quality.
Anu defines premortems as structured exercises in “prospective hindsight”, helping teams assume failure and work backwards to reveal hidden risks and weak assumptions.
— Premortems create psychological safety.
By imagining failure in advance, teams surface issues they might otherwise avoid discussing, tackling overconfidence and optimism bias.
— Classifying risk sharpens prioritisation.
The tigers, paper tigers and elephants framework helps teams distinguish between clear threats, perceived but controlled risks, and overlooked issues that need attention.
— Premortems are not one‑off rituals.
Run them before major launches, when assumptions shift, midway through delivery, or when signals show misalignment. Revisiting them ensures continued learning and alignment.
— Practical structure matters.
Effective sessions include a kickoff with clear objectives, anonymous contribution where appropriate, descriptive inputs rather than bullet points, and disciplined voting to highlight real risks.
— Ownership and action plans are essential.
Identifying risk is only the first step — assigning owners and defining tangible next steps turns insights into mitigation.
— Avoid common anti‑patterns.
Unrestricted voting, treating all risks equally, using premortems as a venting ground, and failing to act on insights undermine the value of the exercise.
— AI enhances tooling but not the core human work.
AI can help consolidate themes, reduce clerical overhead, and track mitigation plans, but it cannot create psychological safety or replace human judgement.