The speaker emphasizes that in today's tech environment, where growth no longer automatically validates individual contributions, telling a compelling career story is critical. Many people struggle to articulate their own story, often because they dislike self-promotion or provide overly detailed, impersonal accounts that fail to highlight their specific role and impact. The speaker left Meta to dedicate himself to helping others with their careers through content, coaching, and future services. He plans to refresh past content, share live coaching calls, and introduce new frameworks. A key framework for storytelling involves six elements: project context, role context, challenge, what was built and why, what worked and learned, and a conclusion. Using a fabricated Gmail example, he contrasts a typical, feature-heavy story with a more effective version that quickly sets the scene, clarifies the person's role and team size, and invites conversation. The goal is to create a story that is concise, dynamic, and memorable, allowing the listener to engage and ask questions rather than passively receive information. This approach helps ensure that the individual's actual contributions are recognized and valued.
Stories matter more of late than ever before. In the past, growth hit a lot of problems. You know, the company was growing, the industry was growing, so you were rising, the tide was raising all boats. Now, people are worried that maybe a person that was successful was just watching the movie. They weren't participating in it. And as a result, there's a lot more scrutiny on what did you do and what did you learn and what opinion did you have and it's less about what level did you acquire? How many people were in your team? What was the success of the product? I see this all the time. Oh, you know, I was on a hundred million dollar product and when I left it was a 500 million dollar product, we're supposed to describe value to that. But in reality, they may have had nothing to do with that growth. In fact, no, probably single individual had anything to do with the growth. The story is about what was your role in that growth if at all? And increasingly, there's a lot of skepticism for companies that are successful. And I think the flip also applies. Companies have struggled with growth. Doesn't mean that the people that work there were problematic or weak in skill. And so if your story is strong, but the company didn't work out, that might be more compelling than someone who happened to be enjoying a ride, the music stopped, and they don't really have the skills to be able to get the next job. So this is the reason why storytelling, especially of late is critical. (upbeat music) - Hi everyone, welcome to The Skip. My name is Nikkel Singhal, I'm your host, and I'm delighted to be back after almost a three month hiatus. The big news is in April, I made a decision to leave meta. Many of you know that I am a product management leader within Facebook. But over the last six months, I've realized that there's a choice that I have to make between where I wanna go long-term and how I wanna help meta kind of grow as an organization. And you know, it was a tough decision to transition out of a great operating role. I think that the company is a terrific company. It's continuing to surge. But my heart has increasingly been around helping people with their careers through the community, through the content, through some of the one-on-one coaching I do. And I could tell that even within meta, that's the area that I had the most passion, most opinion on. And so it became a very clear decision that the time was now to focus on where my heart goes and to really help as many of you in your career as possible. You might be wondering, well, what changes can we expect on skip now that you're focusing on it full time? Well, I'll probably say two things. One is that I think I've been working for almost 28 years in different operating roles. And what I wanna do is get a little distance from that before I go and create my next. I think that distance will give me a perspective, will give me the opportunity to reinvent how I wanna invest my own time between friends and family and health, as well as my professional pursuits. And I'm also very long-term oriented. I'd like to continue to work on something for 20, 30 years from now. And so my goal is to build something in service of people's career, not just content and coaching and community, but really set of product and services that transform the offerings in that space. I'm a little premature to signal exactly what I have in mind. Frankly, it's not even clear in my head. And so you'll hear from me more and more on the subject. But for the short term, my hope is to commit to the community, the product management, individuals that I help coach, frequent content, and then also hear more and respond more to you. I've asked a number of you to kind of reach out to me, ask for help, ask for guidance, give me questions that I could use in future, we've had some real luck with getting some folks on the show to take calls with me through coaching and then record them and share them out. But I haven't had a chance to really build enough consistency on that. And so my hope is to invest there in the short term. And then ultimately we'll work together on figuring out how does this turn into something that I think it could really transform our industry when it comes to folks tech careers. Now, in terms of the specific content of the podcast, and you can expect kind of three different things. I think one is I would like to continue our coaching calls and analyze them and share them out. I think they're the best example of real life situations meeting the frameworks that I've been speaking to. I think the second is that I want to go back in time and look at some of the content that I've shared over the last decade and really update that, perhaps make it more concise, but also recognize that the world's changed quite a bit, both in terms of technology and product management, but also just the tech sector in terms of growth and opportunity. And I want to make sure that those continue to exist. So if you're just tuning in for the first time or you've been a recent viewer caller, then I'm hoping that you can kind of catch up with some of this content in this extra time will give me a chance to modernize those sort of greatest hits. And the third is over the last two years, I've been building a number of new frameworks on how we should think about very specific areas that can help your career. And today's episode is one of those examples where I really want to get into the importance of telling your career story. So if you're in following long, you hear me use this word story quite a bit. And yeah, product managers tend to talk about the importance of storytelling. This specific topic is more around telling your own story, your career story. For example, I'll say, you should leave your current company if you feel your story is rather shallow, not particularly compelling. And if you're trying to decide between two jobs, before you look at compensation and manager and perhaps how the company will grow, think a little bit about the story that you will tell after you transition out of the role that you're considering. And if you compare those two side by side, the one with has the more compelling story is going to be the more effective chapter in your book of career. Part of that is the contents of the story, but part of it is the quality of your ability to communicate the story. And what I find is oftentimes people that struggle with communicating their story are conflated with people who have a weak story to begin with. So the art of storytelling your own career story is just as important as having a compelling story to begin with. By the way, this comes up in lots of places. It comes up when you're writing your six months review on yourself. It comes up when you're in an interview. It comes up on LinkedIn when you summarize. And a lot of people have anxiety. I would say the majority of people have anxiety or almost sheer terror in putting pen to paper. Because if you're a high quality person, often you don't like talking about yourself. If you like talking about the team, you don't like talking about your accomplishments. And frankly, it's sometimes hard to get that visibility into your own work and that distance. But unfortunately, you can't really ask your manager how to tell your own story easily, because often they're the customer in the performance case, where if you're leaving the company, obviously kind of awkward. And one of the things that I wanted get better at is for those that work with Skip, they are able to tell their story more effectively. And I think stories matter more of late than ever before. You know, the company was growing, the industry was growing. So you were rising, the tide was raising all boats. Now people are worried that maybe a person that was successful was just watching the movie. And as a result, there's a lot more scrutiny on what did you do and what did you learn and what opinion did you have? And it's less about what level did you acquire? Oh, you know, I was on a hundred million dollar product. And when I left, it was a 500 million dollar product. We're supposed to describe value to that. Wow, five times, that's a lot. If the person had done six times, that'd be more if they had done three times, that'd be less. And increasingly, there's a lot of skepticism for companies that are successful that maybe they're individual that they're speaking to wasn't really that involved. So this is the reason why storytelling, especially of late, is critical. But lastly, if you're not convinced by the importance of stories and telling that story effectively, recognize that as a product manager, if you're listening, then you can't explain what you did concisely. How are you going to be able to explain a product or how are you going to be able to be effective at your job? How is anyone going to advocate for you in a promotion process or in an interview process? If they don't quite follow the work you've done. So the art of storytelling your career is one of the key things that I want to ensure that everyone leaves this episode with. And so let's get started. I think the best way to illustrate this is through a case study. In a perfect world, I would have actually had a live call where someone walked me through their story. I would have hit pause, and I would have said, listen, I don't find this story to be--
be articulated well, but I think there's some substance here. Let's go back to the caller. Let's get engaged with that caller and figure out how to find those diamonds in the rough. Unfortunately, I didn't have one of those callers, but I will suggest that if any of you want to go through this case study approach in a live setting, I'm going to do one or two, just 'cause I think illustrating this is so important for career development. But today I'm still going to use a case study. I'm just fabricating it. I'm going to use an example from someone who worked on Gmail during the growth phase. And I'm going to read you a story, and then we're going to dissect it. And we're going to come back with something a lot more compelling now. If you're in the car walking around or exercising your listening to me right now, you don't have a piece of paper or whatever, that's fine. Because if it's a good story, you'll remember it. After this episode, my suspicion is you won't remember the original version and we'll be able to kind of workshop this in narrative. But the first one is fabricated. It's not terrible. I will just start by saying that it's not a horrible story. I didn't come up with some facetious example of someone who went into sort of microscopic detail and got distracted. I think most of you that are listening are actually reasonably good at telling this story. They just struggle with making it compelling. It's a very producty, not very marketing. And this is a marketing effort. And this particular story is also fairly concise, which is rare. Most of the time, my biggest pet peeve on listening to people's story is it takes eight minutes. They go through this entire set of information. They're almost like running out the clock in an interview setting. And then you're sort of sitting there like, OK, where do I start? How do I engage? And the person didn't really leave me much. This is a more concise version, but it doesn't have the content that I would have expected. OK, here's an example of a story in response to the question of, how tell me about your role at Gmail? And what did you do? As a product manager for Gmail at Google, I was responsible for managing the full product lifecycle for several major feature areas. I owned strategy and execution on improving the inbox on mobile and worked extensively with engineering and design. During my time, Gmail was mostly on the web with a pretty basic look and functionality. One of the first major updates was the introduction of threaded conversation views, which drastically improved how users could read through chains of back and forth emails. We also rolled out robust search capabilities that made it much easier to find emails based on sender, subject, dates, and more. As mobile adoption skyrocketed, we had to overhaul Gmail to create optimized mobile web and native app experiences across Android and iOS. Features like push notifications became critical. The trend towards inbox overload led us to develop new organizational tools like tabs to automatically categorize emails as primary, social, or promotions based on content. We used machine learning for smarter bundling and surfacing of important messages. Gmail became much more than just email, integrating Google Calendar, Tasks, Keep Notes, and even chat or messaging over time. We enabled third-party add-ons to enhance productivity with services like DocuSign, Trello, and more. Security and privacy were also major focus areas with increased safeguards around phishing, malware, and authentication. We added granular permissions for users to control what data could be accessed by external apps and services. We had over 100 million installs on Android alone. iOS adoption ramped up quickly as well. That, to me, is a pretty typical story. Maybe a little bit more written and mechanical than what you do normally here. But you can tell it was sort of a little kitchen sink. It was a bit of, this is kind of what was happening on Gmail. And it's designed for you to be impressed. It's designed to say, wow, there's a lot of stuff that took place. But I'm a little bit challenged to figure out what specifically did this individual do. And so that's where the nature of my questions are then come. Frankly, to be honest, I'm not trying to gain much. I don't know if you've gained much from this. You just heard what Gmail went through. And that's pretty typical. Either I'll hear a story that's like, here's all the stuff that was happening on the product. And then a little bit on what the person might have been involved in or reverse. Here's the stuff that I was involved in. I don't have the overall. The key thing that I wanted in any story is I wanted to be concise and at the right level. I wanted being a conversation with the person. So I don't want to overload the information such that the person doesn't have the ability to engage. I want to set seeds and almost tease things that I know the person will ask me about, because that creates a dialogue as opposed to a monologue. That's what a great story does. I want it to be clear around the impact and the data around the person's role. And I absolutely wanted to feel dynamic and interesting. But I think that most people's stories, just to be honest with you, aren't that memorable. And so what I'm going to construct is a way to quickly hit on six areas that I think create the template or the framework to be able to quickly walk through your clear story. And in a perfect world, you'd have a 30-second version, the two-minute version, and perhaps a follow-on, which has answers to questions that'll lead to about a four or five minute version. So the six topics that I like to hit on, and they don't have to be in the sequence, but it helps, is number one, I want the context of the project. Number two, I want a context of your role. Then I want to hear what the challenge was. Step four, what did you build and why? And then step five and six is what worked, what you learned, and then ultimately the conclusion. So you can get from this heavy amount of context, clarity around role, a clear understanding of what the opinion, what was built, and what the learning was, and ultimately a wrap-up. Now, can we do this in two minutes? Let's try to do this and see if it comes across more compelling. So I want, in the first step here, to explain the context of the project. I want this person to understand exactly what is the product that I was working on so that they can quickly know what the weather's like, what the environment is like, and obviously in the Gmail case, I picked because everyone on the call knows what Gmail is, but for many of you, you work at companies that are very important, but perhaps the individual on the other side of the table or the reader on LinkedIn has no idea what the company does and certainly doesn't know your project. And so this sort of first, 15-second teaser is important. So in this example, I would say, sure, I'm happy to talk to my role on Gmail. I wanted to work on consumer apps and move there for my PM role in ads. I was there for two and a half years at the time that Gmail was the established leader in email. But we were a web player, mobile was increasingly where email mattered, and we were worried disruption would come from a mobile first email company. OK, I just made that up. I don't know if that actually happened. But the point is, look how quickly I've connected this story around my career where I was in terms of prior chapters, why I came to this role, and then ultimately what the environment was like. We did that in like 20 seconds. Happy to talk to my role in Gmail, wanting to work on consumer, move from PM and ads was there for two and a half years. Gmail was the established leader but was worried about mobile disruption. That was information that maybe you could guess, but it's pretty valuable. Because the point that I'm trying to suggest is who the hell cares what Gmail did while you were there. They want to hear your story. So that's the reason why we're leaning forward on this. And perhaps that you can tell by the way I told it, it's a bit more conversational. It allows the reader or the listener to be a little bit more relaxed. When you explain it like you're having a conversation, people feel like they have an opportunity to converse. If you're explaining it as though it's a Wikipedia page, it's going to be filled with information, but it also sends this subtle hint that maybe you're worried about them poking holes or asking questions. So again, even though this is Gmail, we're having to place Gmail in an era. There's a lot of things that happen in Gmail over what probably is 20 years of existence. Placing it allows us to then say, oh, yeah, I remember that period of time. OK, let's keep going. So number two is we want to set up the role. Up until now, we sort of connected them to a bit of where I was in my career. And a bit of what in this case, Gmail, the product was going through, I didn't have to explain the product in great detail because I assumed it was Gmail, but I did explain a little bit of the market challenge. Perhaps that needs to be tweaked a bit, depending on your specific scenario. Now we say, I was hired into the team responsible for the iOS app for Gmail. Yet it only existed for a year. And most of our focus at the time was on Android. So I was the only PM for 18 months until we hired a second PM. OK, this one's important. This is the most common mistake I see, which is people will say either what they did or what was happening in the product, but they don't explain it in context to the rest of the team. For example, if I read your accomplishment, and I see that the product has done fabulously and you are one of 1100 product people on this project, I will feel differently than if you're one of three, or if you were the first product manager on the project, or perhaps you had never done product management and you had seen something for the first time and showed a lot of success, what does the environment look like from just the people side helps frame all of the accomplishments and challenges going forward. So you could say, look, I came in this product and I did two or three projects across this product line, project one, project two and project three, all have this sort of commonality. That is very compelling. And the next point is, hey, this product existed for only a year, this in case the iOS app and most of our focus was on Android, so you can tell that maybe this was not where leadership attention was. Well, I'm setting up this story of, well, eventually, that changes. And then I know,
note, I was the only product manager for 18 months. Well, that's pretty big deal. So you're making a note that, hey, leadership is focused elsewhere. I was the only product management and then eventually the team group. So these are all important seeds that the person now has opportunity to ask about. They can say, oh, well, you know, interesting. You were the only product manager. So what were the kind of responsibilities in that era and then how did it shift as the team group? Or you can make a note that, hey, you know, sounds like there's a lot of leadership tension at Android, where did creativity come from for the iOS app? It shows more weight, but it also openly acknowledges there was less innovation work and a lot more fast follow work. All of these points have been signaled without saying it. But what you've done is you've set up a really compelling story. Now, keep in mind, we're about 30, maybe 40 seconds into our story and we have already seeded without even getting into detail as to what the person built. We've seated where this fits in career. What were the overall environmental challenges? We've signaled what the team was like and we've given people a flavor of what kind of product development was being asked during this period of tenure that the person's had all with very, very rapid information and being very light, being very understood, being very conversational. That's the type of story I'm looking for. Okay, so now we're on step three. And before I spend time talking about what I specifically built and why I want to frame the challenge, often I find that people will go from, here's what the company and product did to hear what I've built. And naturally as you're going through it, you're asking yourself, why, you know, I kind of get a sense of what the weather's like. I kind of get the sense of what your role and why you took it. But I'm not terribly clear on what was hard. You know, why did you end up choosing X versus why what did the company choose that, et cetera? So the challenge is where I go next. So in this example, we say at first Android mostly copied features from the web and we copied features into iOS. Then we realized that mobile patterns are just different than websites. People couldn't read or type long emails as easily, but they opened their email 10 times more than the web, just in shorter sessions. So we had to redefine everything on the app from inbox to composition to how we organize the content. And as the only PM, I had adapted this to iOS patterns and to prioritize what was essential since our engine was about 20% of Android. Okay. Now people are really getting clearer on what was hard, what the weather was like, what the challenge was, and then where the person fit in. This is really compelling now because people are starting to feel what the product was going through and then put your story in context. In this example, there's not only it clear understanding of the challenge, but it became clear what the team was asked to accomplish. And then how quickly the person was able to grab on in the challenge. But also I'm careful not to take too much credit. What I've been clear on is what I did when I didn't do again, another big gotcha because a lot of times people will say, Oh, here's what I did. And it sounds almost incredulous that one person could do so much. Oh, you know, we launched this product and we had a billion users. And it really foundationally changed the industry. And yeah, I was in my second year and I was the only person on the team and half the time, you know, we didn't even have the engineers. But yep, that was me. And they don't say that last part. But then you're looking at that like, well, there's no chance this person's story is real. And now the credibility of your entire story is shot. Instead, in this example, I was pretty clear. Look, a lot of the interesting work was happening on Android. The hard part wasn't me coming up with my own feature set. It was me really understanding that that team was much larger. And I had to be a lot more efficient and judicious. So we couldn't do everything. So this became the product challenge. We also recognized that what worked in one setting wasn't going to work in the other. So clearly the person had to work with his counterparts or her counterparts in order to make this fly. So we're about a minute in and we've effectively laid out the project. Now we're in a position to pivot and to get into much more real detail about me. I haven't used I that much so far. But I've laid out bread crumbs. Bread comes for future questions. You know, I've essentially made a point that organizational challenges were everywhere. We had a web team. We had an Android team. We had a bunch of teams focusing that one direction. I had to figure out a way to focus in another direction. So that must have been complicated, working with different PMs, different organizations, etc. Then you've got this innovation at scale, which I haven't demonstrated. Well, I have not set up being creative, which is a natural question for someone to ask, well, it sounds like you were doing mostly copying. Where did you create? So in my second minute, I'm definitely going to get there. But because I know I'm going to get there, I make it clear I haven't gotten there so far by creating that moment. Maybe they interrupted this point. Maybe they say, well, it sounds like you've mostly been copying. Can you give me an example or you know, and you're like, well, I'm glad you're asked. I'm going to get there next. You can see that because I've sort of laid things out for things coming that I've achieved, you've effectively given a lot of footholds for the person reading, person listening, person interviewing to engage. Okay, naturally now in minute two, we need to get quickly into what I build and why. I break down our strategy in the three phases. In phase one, we're focusing on the basics. We had to ensure people could see all the emails and compose new messages in this near medium. Honestly, it wasn't too different than just opening the website on the phone, making that work natively was new for the team and we didn't have that many iOS engineers. But in phase two, we moved into growth. Things were stable. We found that most people on iOS weren't using our native apps. They were just using apples. So we didn't extensive research study both Qual and Quon. And we found four key areas of investment. My role was to prioritize these features with our leadership team and I'm happy to walk through the specifics of that helpful. Then ultimately our growth stabilized and we entered phase three. We started to worry that chat was growing exponentially where emails were growing linearly. So we needed to innovate. So I suggested three features which simplified emails, all three of which remain today. Okay, this is a pretty compelling PM to be honest. You know, I'm excited about this story because I see a richness in lots of capabilities that I look for in product managers. I see being able to fast follow managing organizations, the creativity on talking to users and looking qualitative understanding of products, innovation, looking at data, also recognizing there are a lot of opinions coming. There is prioritization. There was clearly an opportunity to work with leadership. I love the fact that this was structured in three phases because what it allowed me to do is not get so focused on some feature. Now, in this example, I mentioned four features that we had to prioritize. Three features and other time, naturally what most storytellers do is they just start pounding through those stories. Hey, let me tell you about this thing that we build and it got into this smart folder. You know, the person's like, you look, you're not building for concern folders for my company. Why the hell do I need to learn all about it? What I want to know is how do these seven things get prioritized? And what was your process that you went through it? And maybe there was, is it seven or is it seven hundred or is it six or is it two or did you even not come up with any or did someone else come up with them? You know, there's a million questions that people are going to want to know. The recruiters are going to want to learn about in order to figure out if you're the person they want to place or even reach out to. So the reason why I did it this way is I created a bit of a framework for the work I did over this two year period. And so I essentially said, okay, if this is me, I want to have these three phases, the basic, the growth and the innovation. But then I created this sort of next layer of the onion. I'm like, okay, within that one was a fast follow. One was an innovation project. One was an area that required partization. Okay, God hit. And what I didn't do is I didn't cover it. I bred grumbed it. So I'm giving you now the opportunity as the listener, the reader to come back and say, you know, there's a thing you mentioned about prioritizing. I really want to go into depth there because in their mind, they're like, that's the challenge I face here. That's what I want to understand. But it could be that you're talking to a company that's very early in product market fit. And so prioritizing may not be as important because they don't have customer feedback. They may want to know about well, how did you start from the scratch? And maybe that's the area that you covered in phase three. So what I'm trying to do is again, get me down to greater detail by sharing my product structure, by sharing the challenges by noting that I've been on this project for this amount of time, seen different movies. But by the way, there's some durability to the work I did. I didn't sit down and I said Gmail grew from this to this because of this feature because that's silly. But I did make it pretty clear that there were seven things, some of which still remain in the product and there were challenges along the way so that as I set up the depth of what I'm doing, I've effectively grounded people in why this stuff actually matter and why it was good. And keep in mind that one element in this story was that challenge was around us and things weren't always working. Again, that creates a lot of empathy. Nobody has a product where everything's working. And if they do, they probably don't care about hiring you or they don't care about entertaining you. Ultimately, what I'm looking for from a career story is a little bit of authenticity around yeah, the stuff is really hard. This thing didn't work out the way we wanted. The market shifted on us as a competitor. They came along. Those are the things that are existing in the person's mind that are reading your story and that need you for the next. So you want
of again create those footholds for that individual. Okay, so we're two minutes in roughly maybe a minute 45. I think most people get about that much time. If it's compelling and if you're moving and we've moved quite a bit from why we chose the job to what was happening in Gmail to the challenges that you know the industry was facing to the role to the phases of investment to the type of things that I have now available to you to ask about when it comes to features we moved one minute 45 seconds in. So we're set to now hit a pause and to say hey is this the level of depth you're looking for? What I'm doing next is I'd want to walk you through a little bit of how things worked, what didn't work, and what I've learned, but I also want to go where you need me to go. Now if this is a dialogue and not an obviously you can't do this on a written format like LinkedIn, but you can definitely do that if you're in a conversation with someone and you could even do it if you're at a cocktail party and you're just talking to someone about what you worked on. I mean you wouldn't ask answered in the same way that would be kind of awkward, but you could say things like hey you know that's kind of what I did. I'm happy to keep going, but curious around again you can reciprocate tell me your story or you can say curious is there's any of these areas that you know interesting for you. I'm happy to go into more depth because what you don't want to do is go so far without checking in with the user is kind of obvious conversation dynamic, but you also want to give someone the opportunity to say the magic words which is just keep going because at this rate I'm going to get all my questions that can answered my first round now I'm going to go my second round and that's good because it implies that I'm going to be able to repeat back to the next person what your story was and that's our goal. It's does our story travel. Our goal is to make sure that the conversation we're having sticks enough that the person afterwards and say hey you know I talked to Jane, Jane's story is really compelling. Look at all the things that she did. These types of challenges are like much greater than the ones that we have loved and bold Jane in our project. That's the kind of conversation. That's the goal of what we're trying to achieve and that's in many ways what we've achieved so far with them in 45. In fact, you could probably repeat exactly what I just said, but you have no chance of repeating when I started the podcast with in terms of that original story because it's generic. And now we have point of view. So now just as I alluded to, I like making sure that the person has a clear sense of what I learned and what opinion we had and maybe where things didn't work out. You get 10 times the number points or opinions and learning then you do on facts on the ground. And again, if we look at our original story, it's very light on opinion, very light on clarity of role, very heavy on information, density, that you could probably guess by looking at other persons been on Gmail for two and a half years during this period kind of guess what's going to be the challenge and what they were working on. That's the distinction between the generic story and the personalized story. So in this case, whether you get it in a Q and A, whether you present it more productively, I want to make sure I'm leaving this person with this information because it's so valuable to hear. And this is the part that requires a bit of practice. So you can come back and say, okay, well, now I think back, I think we did a lot of things right. It was smart to stabilize the app before we experimented with new features, but I think in retrospect, we shouldn't have copied the web. Instead, we should have just focused on fewer features really well integrated in NIOUS. There wasn't about it growing our install base, who was about convincing people to use the native app instead of a message is that built into the platform. And that required a few key features that people couldn't live without that just wasn't available anywhere else. What we eventually realized was that was smart folders along with tight integration with other Google products like Chad and me, or things that are just hard to find elsewhere. And so that's why we invested in those products. Moreover, I'm really glad we spent last time trying to reinvent messaging. You know, email had really become a commodity and had effectively solved the user problem. So instead of trying to reinvent email, we started to integrate our product into their apps on their phone and recognize that things like security and phishing had become way more important than spam and organizing information. This may not be the perfect opinion because now, you know, again, I'm totally made up the product manager. I have literally no idea if this person really exists, but I've laid out opinions. This style gives people a sense of it was smart to do this. It was not smart to do that. We decided to go here for very thoughtful reason. It turns out it was a non-obvious decision. Those are the types of moments where you're hearing judgment from the person. And that judgment, by the way, could have been done by leadership and the person just by retelling it, but explaining it clearly gives gravitas. Let me point this out one more time because it's important. Many of you are saying, look, I am not the one in charge making the decision to build feature A versus feature B. So how am I going to drive opinion? Well, do you understand that opinion is actually happening in the product that you are building? If you don't think there's an opinion anywhere in the ecosystem, you should probably leave because your story is quite uncombelly. But if opinion exists, seek to understand why, not because some high paid individual is actually out there telling you what to do, but there must be some rationale. Hey, they're weighing A versus B. This becomes the more important thing now that I understand where they're heading. I can explain. This was the rationale, whether it worked out or wasn't. When you explain it the way I just did, people are like, wow, this person understands the opinion and perhaps would have made the same decision or perhaps wouldn't have made the same decision. But that's very valuable because you need an opinion to be an effective leader, product manager, everyone to call it. So I'm seeding lots of opinions that were in the ether suggesting I agreed with some of this. I didn't agree with some of this. Some of this was maybe what conventional wisdom suggests, but we went the other way. Those are always the best because if you said, look, we went and talked with venture customers and they said that they would pay us $10 million if we went left and 5 million if we went right. So after a long debate, we decided 10 million is bigger than 5 million. I mean, what is that? That's not genuine. That's just basically looking at a number. What you really want to know is, look, we looked at A and we realized that there was many core customers that would actually service that and we looked at door B and there were far fewer. But by the way, the technology underneath us would have had to change radically and we had an 11 person platform team and those people all hated us. They had pictures of us in their cubicle and they used to put darts in us because we would come to them and we asked them to deliver more and more and they just didn't like us. And so frankly, my opinion was though there was more money and more customers and left, we went right because I didn't want to get shot and the reason why didn't want to get shot is because our platform is rickety. Now that sounds like an opinion. That sounds like a real challenge and you might be sitting there like, oh my god, I can't explain that. We look weak. I'm like, you don't look weak. You look real. And that's a point I'm trying to make is stories are compelling because they're real. They're authentic. They're clear. They're concise. They're not generic and abstract and high-falutenant. They sound enormous because those don't exist. No one person can do big things in that way, but you can make opinions. You can understand what direction and you can articulate it effectively. Lastly, we're just going to conclude. Increasingly, I realized that I'd seen what it takes to scale and mature a product. After a couple of years, there were options to grow a team, but I felt there were less opportunities to build new things in the project. Just given how constrained the work and the product was, I wanted to pm a different phase of company so I ended up running a search and getting pulled into my current employer notion, which is far less established. Okay. I'm returning to your career as a set of chapters. Each chapter motivates the next. If you're talking about Gmail, you talked about what you did before and you conclude with where you're heading after. Again, by bookending it a little bit, puts things in context. It allows you to quickly move to next. If that's important to the individual, it allows you to suggest what motivated you. In this case, it's very clear that the person was seeking something, signaling like, "Hey, it's a constrained or the product was constrained. Maybe not the best time for you to be there." You don't have to say that, "Oh, my boss changed hands and I ended up getting reorg 17 times." That was just the total cluster. I've explained it that way, but I signaled that that's the answer. If they said, "Well, did you have an opportunity to stay there?" It's like, "Now really, we ended up reorging ourselves out as I mentioned and as a result, it just made sense that that was the right time." You can signal enough, but don't feel defensive, but be honest that not everything's rosy in this example in terms of work and product. That's the conclusion I'm reaching, not repeating back what I said, but setting us out in context to what might be next. In our conclusion of this episode, things that I want you to remember, six steps. We're going to start with project context. Then we're going to go into role context. Then we're going to talk about challenge and then what you built. Then we're going to talk about what worked and what didn't and ultimately drives them in conclusion. This is a structure less important to get it in this order. Very important to make sure that within a couple of minutes, you have these pieces. We're going to seed breadcrumbs, so you're not trying to jam as much as you can in two minutes. I'm not trying to get you to go on three X speed and just speak faster to get it all in two minutes. I'm trying to figure out what is the smallest amount of information that allows a conversation to take place, but does give people grounding of what you did, what the challenge was. I'm also very careful not to over or undersell. Again, avoid trying to take credit for all of the things happening at the company industry project. Be a little bit humble and be clear on what didn't work, what did work, what did you learn. You put all those things together. You have a very tight authentic story that leads to a compelling conversation. Now, for those of you that are like, look, I think if I worked a Gmail during this period of time on a product that was super clear to everyone, I could tell the story.
where he really easily just like Nikkele did. I have a very challenging esoteric example. I think the story is compelling, but I'm really struggling with the words. I'm kinda interested. I, you know, I think that maybe one or two of these examples using real live ammunition will be great. If you are interested in participating in an anonymous podcast episode where we case study this, I think this is so important telling your story effectively that I bet you will boost the industry as a whole if everyone told their story as compelling as the work that they're actually doing. So I would love to be able to audition a few of you and then maybe take a couple all the way through and share it as a future podcast episode. In the meantime, I look forward to hearing from all of you on things that you want me to cover. I'm excited to be focusing more on Skip and it was a pleasure to be back in the saddle. Thanks for listening to the Skip. If today's episode resonated with you, please consider leaving a review or sharing it with the people you know who want more out of their career. You can also subscribe with this podcast on Apple, Spotify, YouTube or wherever you currently listen. You can also follow my newsletter on Substack. And if you have questions or feedback, leave a comment or send a note on LinkedIn, threads or Twitter. I try to answer each one correctly. As always, I'm Nikelle and this is Dennis Skip. (upbeat music)
Podcast Summary
Key Points:
Storytelling about one's career is increasingly important because company and industry growth no longer automatically validate individual contributions; there is more scrutiny on what each person actually did and learned.
Many people struggle to tell their own story effectively, often conflating weak communication with weak performance, and they may avoid self-promotion due to discomfort.
A compelling career story should be concise, conversational, and structured around six elements: project context, role context, challenge, what was built and why, what worked and learned, and conclusion.
The speaker left Meta to focus full-time on helping people with their careers through community, content, coaching, and future products, with plans to refresh past content, share coaching calls, and introduce new frameworks.
In an example about Gmail, a typical story listing features fails to highlight individual impact, whereas a well-crafted story quickly sets context, clarifies the person's role and team size, and invites dialogue.
Summary:
The speaker emphasizes that in today's tech environment, where growth no longer automatically validates individual contributions, telling a compelling career story is critical. Many people struggle to articulate their own story, often because they dislike self-promotion or provide overly detailed, impersonal accounts that fail to highlight their specific role and impact. The speaker left Meta to dedicate himself to helping others with their careers through content, coaching, and future services.
He plans to refresh past content, share live coaching calls, and introduce new frameworks. A key framework for storytelling involves six elements: project context, role context, challenge, what was built and why, what worked and learned, and a conclusion. Using a fabricated Gmail example, he contrasts a typical, feature-heavy story with a more effective version that quickly sets the scene, clarifies the person's role and team size, and invites conversation.
The goal is to create a story that is concise, dynamic, and memorable, allowing the listener to engage and ask questions rather than passively receive information. This approach helps ensure that the individual's actual contributions are recognized and valued.
FAQs
Stories matter more now because growth is no longer guaranteed, and companies scrutinize what you actually did. A strong story shows your role and impact, especially when the company's success isn't clearly tied to your efforts.
Think about the story you'll tell after leaving each role. Choose the one with a more compelling narrative for your career book, as it can be more valuable than compensation or company growth.
Use a framework covering six areas: project context, your role context, the challenge, what you built and why, what worked and what you learned, and a conclusion. Keep it concise and conversational, not like a Wikipedia page.
People often list what the product did without clearly explaining their specific role or the team size, making it hard for others to gauge their individual contribution.
Begin with a 15-second teaser that sets the project context, your prior experience, and why you joined the role, such as mentioning the product's market position and challenges.
It frames your accomplishments and challenges. For example, being one of few PMs on a project shows more individual impact than being one of many.
Chat with AI
Loading...
Pro features
Go deeper with this episode
Unlock creator-grade tools that turn any transcript into show notes and subtitle files.