Six steps to effectively tell your career story

Transform a forgettable narrative into an impactful story that sticks

This article accompanies the Skip Podcast episode on storytelling (link).  

Over the past year, I’ve hammered home this idea of shaping your career story: Leave a role when it is weakening your story, take roles that will add interesting chapters both now and in the future. In today’s environment, the story of what you’ve built, the opinions you’ve held, and the impact of your efforts matter more than ever.

What many people don’t realize is that even a successful project can be diluted by a poor telling of that story. Do you wonder why you keep getting overlooked? Are you frustrated that less qualified, yet more politically savvy people seem to be moving forward? It could be bad storytelling that’s holding you back. In fact, since releasing the podcast episode on storytelling, I’ve workshopped several people’s career stories and concluded that it’s definitely a skill to concisely explain a project, a job, or a career in a compelling fashion. 

In the past, the tech industry’s growth was able to mask a lot of problems at the granular level. It gave the impression that everyone was growing. All the boats were rising with the tide, even for the incompetent. Now as the market has shifted, there’s far more scrutiny on what you did and how well you did it. You’ll need to clearly craft your story to ensure that your skills and contributions are recognized regardless of how well or poorly the business itself is doing.

I’m aware that narrating your story feels unnatural and may seem artificial, awkward, and even self-serving. You’d rather talk about the team or the merits of the project. But learning how to share in this way is critical to your success. So I want to ensure that you leave this edition of The Skip with tips on how to communicate your story effectively. I want you to get really good at precisely describing – in a really compelling way – your past and present roles and what they entailed, and what you achieved. It will ensure that a hiring team, a boss, a colleague, an acquaintance will not only remember your achievements but also understand and appreciate them. This is also how you equip other people to advocate for you, which is only going to help you get that promising next (and next) job.

To best describe what needs to happen, I’ve fabricated a case study that portrays a basic telling of a career story. I then introduce a framework for how to structure a far stronger version of the same story, with step-by-step guidance. The goal of this exercise is to show the value of spending less time focused on the details of a project, for example, and more on why that project matters. This requires moving away from abstract jargon and using key facts backed by data; changing the tone to be conversational; and landing key points in such a way that they can easily be repeated by the listener.

So let’s have at it.

The case study: Before

This “person” I’ve created has been asked: “Hey, tell me about your role at Gmail, and what did you do?”

Here is the response: As a product manager for Gmail at Google, I started by improving the Inbox on mobile, and worked extensively with eng 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 toward 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/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.

Bad storytelling vs. good storytelling

Though this is a fictitious example, I want to point out a few things I want you to avoid in your own story:

• Long, dense stories with too much detail and too little structure: I want a clear framework that is easy to follow and has stop points to allow someone to dig deeper and engage you in conversation.

• Too much jargon and abstraction: If your story is to be memorable, you want information that “travels well,” meaning that it can be re-told by your listener. So you’ll want to start with those facts and then build your narrative around them.

• Not enough detail on the facts that matter: In this story, it’s hard to pick out the specific contributions and opinions the person had. And though the product grew and was compelling, it’s not clear how that connected with the person’s efforts.

• Solutions without clear understanding of the problems and hardships. Most of this story (and most others I review) consists of a sequential list of what was built. That’s a good starting point, but I like to understand why these were chosen (the opinions) and why it was challenging. A controversial opinion that led to success is compelling, as is a difficult internal or external environment that the person was forced to successfully (or even unsuccessfully) navigate.

Ultimately, you should prepare a clear story for each of your projects, as well as a single, comprehensive version that can speak to your full career. Doing so will require you to master both going deeper into a project when asked and quickly touching on the highlights if you're providing a full summary. If this doesn't come naturally, take the time to practice. A comfortable and clear delivery at every level—of tiny details and big-picture analyses—lends credibility to your work and communication skill.

Okay, let’s start with a simple framework for telling a compelling job story. The six areas are: project context, role context, challenge, what you built and why, what worked (or didn’t) and what you learned, and a conclusion. 

The rebuild

Step 1: Provide project context

What you could say:

Sure, happy to talk through my role on Gmail. I wanted to work on consumer apps and moved there from my PM role in Ads. I was there for 2.5 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 that disruption would come from a mobile-first email company.

Why is this better?

The main thing to remember is the listener doesn’t have context, so immediately jumping into what you built is going to feel like starting a book at the halfway point. Yet so many people answer the question with, “The first project I worked on…”  Instead, take a quick second to provide context on what was going on with the company, product, and/or market. Because tech changes so frequently, the problem you faced back then might have felt impossible, yet today it might be easily solvable or even seem a bit silly. Bottom line: Ensure you start with context to avoid having your work dismissed or misunderstood. 

Also note the tone of the wording. It’s all done on a personal level and in a matter of a few sentences – totaling about 20 seconds – so it doesn’t feel long-winded and rehearsed. No time is wasted going into more detail about Gmail. There’s enough here to motivate the rest of the story but allow follow-up questions if the listener is unclear. 

Step 2: Provide role context

What you could say:

I was hired into the team responsible for the iOS app for Gmail. It had 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.

Why is this better?

One very common mistake is failing to provide context about the team surrounding you on the project. Were you one of a thousand people working on some fabulous product, or one of three? Were you the first on the scene? Had you not handled product management before? Providing this kind of detail – “I was the only PM for 18 months until we hired a second PM” – without ticking through every product feature and task, can plant seeds about your work ethic, skills, and the environment you’re capable of operating in without going down a detail rabbit hole.

By now the listener has enough context to evaluate the work. Any further breadth might frustrate someone looking to understand your contribution. So in a 2-minute story, don’t spend more than 45 seconds on setup.

Step 3: Explain the challenge

What you could say:

At first, Android mostly copied features from the web, and we copied features from iOS. Then we realized that mobile patterns were just different from websites. People couldn’t read or type long emails as easily, but they opened their email 10x more than on the web. Just in shorter sessions. So we had to redefine everything in the app, from inbox to composition to how we organized the content. And as the only PM, I had to adapt this to iOS patterns and prioritize what was essential, since our eng team was 20% the size of Android.

Why is this better?

Again, I’m avoiding going into depth on what was built and instead electing to focus on the challenge first. If the listener doesn’t appreciate the challenge, you risk being dismissed as solving an easy or unimportant problem. It’s best to ensure every story describes a tough challenge that’s clearly connected to your work.

In this narrative, the tone has become more opinionated – in a good way. There is a lot more depth about the project’s environment and the team’s thought process. Most important, this tack avoids giving yourself too much credit. Leaving out details about the rest of the project, including its specific challenges, is an all-too-common mistake. “Yep, our product grew by 100x, and I’m hoping you conclude I was the main reason.” In my experience, the opposite is true. When you openly discuss what was hard and what was not (in this case, copying rather than inventing features), it builds credibility for the hard problems you did face (much smaller team with more responsibility).

At this point, we’ve established all of the context we need to evaluate your contributions in this project.

Step 4: What you built – and why

What you could say:

I’d break down our strategy into three phases.

In Phase I, we were focusing on the basics. We had to ensure people could see all of the emails and could compose new messages. Honestly, it wasn’t too different from just opening the website on the phone. But making that work natively was new for the team, as we didn’t have many iOS engineers.

In Phase II, we moved into growth. The product was stable, but we found most people with iOS phones weren’t using our native app – they were just using Mail (which comes from Apple). We did an extensive research study (both qual and quant), and we found four key areas of investment. My role was to prioritize these features with our leadership team. I’m happy to walk through specifics if that’s helpful.

Ultimately, as our growth stabilized, we started to worry that chat was growing exponentially while emails were growing linearly. So we needed to innovate. So I suggested three features that simplify email, all three of which remain today.

Why is this better?

The first thing you’ll notice is that there is a framework to encompass the features that were developed. This isn’t just a punch list of “we built this, then that, then this other thing.” Most products are really hard to follow unless you’re really familiar with them. At this point it’s about creating some basic structure that the listener can relate to in order to put the product features into context. 

Next, I’m signaling a set of product challenges that the team had to overcome to successfully deliver these features: “We had to ship despite engineering, market, and growth-related challenges.” This allows you to neatly layer different skills within each phase, which fills out the portrait of who you are and how you operate. Not every recruiter or colleague is going to care about the same thing, so try tucking in a skill that might appeal to, say, a bigger company in one area and another skill elsewhere that would matter to a startup. Ultimately, the goal is for the listener or reader to focus more on you, the product manager, than the product features.

Midway through it’s smart to open the door for dialogue. In this rebuilt response, you not only conversationally note, “I’m happy to walk through specifics if helpful,” but you also present a clear set of conversation starters. You’re likely armed with plenty of examples that can demonstrate prioritization, partnership with engineering, user research, a qualitative understanding of the market, the courage to innovate, and a readiness to parse data. Any follow-ups can build on top of the foundation that’s been established. And you show the durability of your efforts by adding that three of your suggestions are still alive and kicking within Gmail. 

Now that you’re 2 minutes in, it’s a good idea to touch base and perhaps ask, “Is this the level of depth you are looking for?” Maybe add, “I’m planning on walking through what I learned and things I’d do differently, but I want to ensure I’m answering your question.”

Hopefully you’ll hear “keep going,” a sign that you’re on the right track, or they’ll ask one of the questions you’ve motivated, which is encouraging as it’s something you’re prepared to answer. Or, they might move you to another area, an indication that they are fishing to discuss something else more specific and aren’t finding it here. This is also a success, as you want to get to a discussion as quickly as possible.

Step 5: What worked, what didn’t, what you learned

What you could say:

As I look 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 we shouldn’t have copied the web, instead focusing on fewer features really integrated into iOS. It wasn’t about growing our install base, it was about convincing people to use the native app instead of the Mail app built into the platform. And that required a few key features that people couldn’t live without. What they eventually realized was that smart folders along with tight integration with other Google products like Chat and Meet made the difference.

Moreover, I am glad we spent less time trying to invent messaging. Email had really become a commodity and had effectively solved the user problem. Instead of trying to reinvent email, we started to integrate our product into other apps on their phone – and recognize that things like security and phishing attacks had become more important than spam and organizing information.

Why is this better?

Ah, the all-important opinions. Now that the listener understands the context, challenge, and what you built, they want to hear your opinions, especially with the gift of hindsight. Hiring often comes down to judgment and the opinions a PM can bring to the business. So the strongest stories must have clear, well-motivated opinions.  

Your opinions are a combination of what you thought and how they landed. You’ll get points for a thoughtful perspective, especially one that worked and drove impact. But you’ll also gain points for explaining the opinions of your leadership or even your competitors. And looking back, if you share how things could have gone differently, it shows wisdom.

All too often people are overly focused on telling a clean story where they built something and it just worked without a hitch. But that’s unlikely the problem the listener is confronting. If they hear how you dealt with a messy problem and what you learned, you immediately are drawn closer to the listener and the challenge they are navigating.

Step 6: Conclusion

What you could say:

Increasingly, I realized that I had seen what it takes to scale a mature product. After a couple of years, there were options to grow a team. But I felt that there were fewer opportunities to build new things, given how constrained the org and product were. 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.

Why is this better?

You’ve moved through some heavy material up to this point: context, clarity around your role, understanding of what was built, and opinions around the process and the product. And you’ve done it in roughly 2 minutes.

If we again think about your career as a set of chapters, the story of this role is not the whole book. There is another chapter, and you can conclude the story by indicating how you thought and navigated through transition. Every ending is challenging, but instead of detailing all of the complexity that led to your exit, just focus on how this story served you. Ideally, you’d have a few career themes in any story you are telling, such as that you’re an innovator, or you thrive growing existing products, or you manage large, complex orgs and teams. And you can conclude by tying this story into one of your enduring themes.

In conclusion

With this framework, I’m hoping you can transform your job story into something that’s conversational, memorable, and easily understood. It’s detailed enough for someone to dig deeper, but it doesn’t go so deep that you frustrate the listener. And, most important, it sounds real and authentic. You’re not showering yourself with all the credit, but your contributions and opinions come through, as well as the complexity and challenges you navigated.

Storytelling in product management is a key skill, but I think it’s even more challenging when applied to yourself. But when you tell your story effectively, it opens up far more opportunities.