Do’s, Don’ts, and Personal Pet Peeves of Product Manager Resumes

Image from Craiyon.com, an AI image generator, of an abstract resume
Image from Craiyon.com, an AI image generator 

Looking back on my time as head of product management at Patriot Software, I reviewed more than 1,000 resumes while hiring over half a dozen product managers at Patriot Software.

Some resumes stood out with clear, compelling storytelling and measurable impact. Others had vague descriptions, fluff, or outright mistakes.

A great product manager resume isn’t just a list of responsibilities or numbers; it’s a story. Getting it right can mean the difference between landing an interview or getting overlooked.

After seeing the best and worst of PM applications, I’m sharing my do’s, don’ts, and personal pet peeves to help your resume stand out.

DO’s & DON’Ts for Product Manager Resumes & Applications

✅ DO: Provide a short, 1-3 sentence summary about yourself, either your history and/or what you’re looking for

  • ❌ DON’T: Make this long and complex

✅ DO: Use spellcheck and grammar check

  • There’s just not an excuse for misspellings these days

✅ DO: Use numbers to emphasize the impact you’ve had

  • ❌ DON’T: Fail to tell your story because you’re focused only on the numbers

❌ DON’T: Use industry-specific jargon or acronyms, or at least explain / spell those out

✅ DO: Tell me what industry your company was in

  • You’d be surprised how many companies I googled for context

Re: AI: It’s fine to use AI; however:

  • ❌ DON’T: Let the end result sound like AI; your resume and answers to questions on the application need to be in your voice, even if you use AI to help brainstorm ideas or as an editor
  • ❌ DON’T: Lie
    • Example: AI said they worked at a place they didn’t 😖. This was especially prevalent in answers to the application questions, which then clearly didn’t match the resume or LinkedIn profiles. Liars get tossed out
    • Or they used AI to answer the application questions, and the AI’s answer was “I’m sorry, I don’t have an answer to this question.” 😆 Dead giveaway! Out those went

Personal Pet Peeves for Product Manager Resumes & Applications

As the header says, these are my personal pet peeves; take these with a grain of salt, as other hiring managers may have different views.

❌ DON’T: Profile pictures 

  • This is under personal pet peeves because maybe this is just a ‘me’ thing, but – why? Just why? What info am I getting from your picture that’s useful to me as someone evaluating your resume? 

✅DO: Make sure your links, such as LinkedIn links (or any other links), actually work

  • In product management, we need to be thinking about our customers (/users), and the hiring manager is the user of this resume; any extra work is a frustration
  • There are ways to add links after the fact, no matter what program you start with; it’s just a little extra effort (Adobe Acrobat, Preview, an online tool, etc.)

❌ DON’T: Have different titles between your resume and LinkedIn

  • This struck me as people lying on one or the other, and I threw out some resumes for this. You can tailor your resume for a job, yes, but changing your job title or level seems dishonest
  • I saw people doing this especially for levels between the two, but sometimes roles as well
    • Example: From “Manager of Operations” on recently updated LinkedIn profile to “Director of Product & Operations” on the resume they sent in
    • Note: I actually didn’t see this where I would have expected it. For example, some people listed themselves as “product owners”, but based on what they did, I would have considered them a product manager – and that kind of title change is understandable, because maybe your company calls it “product owner” and you know every other company considers it a “product manager”. But that was very rare to see. I’m talking about a true change in role/level

❌ DON’T: Brag

  • I’m not a fan of PMs saying “I” throughout the entire resume
    • “I increased customer count at my company 5,000% in two years” – all by yourself? I’m sure sales and marketing had nothing to do with it, never mind your Product team
    • I prefer ones that state “Aided in increasing the customer count to” or “Helped increase” or “Product manager on the team that reduced x by y%” – rather than just saying “I did it.” 
    • Even bigger pet peeve: “Managed the product team that…” – you were a product manager, not a people manager
    • That said, these weren’t disqualifiers; it just gave me a heads up to double check for humility going into an interview
Software Skills example with Jira, Confluence, Figma set at 100% and Miro set at 80%. From ChatGPT
Created by ChatGPT

❌ DON’T: Use ‘level of expertise’ bars for software skills, if you include those at all

  • I’m indifferent to whether you include software skills; it’s nice-ish to know that you’ve used Jira or whatever, but I can assume you know the basics from a good resume
  • But if you DO include software skills, I’m really not a huge fan of the ones with skill level bars; almost everyone puts all but one of them to be ‘full’; they lack meaning
  • (Apparently, this one isn’t just my pet peeve, others recommend against it as well – though this article is in the dev world, so it’s not 100% applicable)

Example:

❌ DON’T: “I increased MAU by 30%”

  • Because:
    • Yes, MAU = Monthly Active Users to most, but there’s a chance MAU means something else at this company – spell it out
    • This breaks my ‘humble’ rule – you increased MAU all by yourself?
    • There’s no story here; how did you increase MAU? In what timeframe?

✅ DO: “Worked closely with sales and marketing to launch new feature Excelsior, which directly led to a 30% increase in monthly active users within 6 months”

  • Perhaps some hiring managers would rather just see the numbers, but I find that hard to believe. As a hiring manager, I needed to know how they made an impact, not just that they made an impact; I could also then ask about that ‘Excelsior’ and how they measured growth in interviews. 

Remember that resumes are (hopefully!) just the start of the conversation. Good luck!

Encouraging a Product Management Team to use AI

You’ve likely seen countless articles on why AI is transformative, and you’ve read about the various and sundry LLMs that are out there.

This article takes a different approach: how do you actually get your product management team to consistently use AI to help level up your team?

While I don’t claim to have cracked this nut entirely, it is something that I’ve worked on, and thought it would be helpful to share with other product people interested in bringing AI to their teams.

The process has looked something like this:

Make sure you understand your company’s policies around LLM/AI usage

  • This likely incorporates details around data security, such as not including PII even in secured paid accounts, and nothing company-specific in any free LLMs

Get access to any paid AI accounts available at your company, and start using the AI(s) yourself

  • You have to understand the possibilities yourself first

Add a few eager early adopters to the AIs and encourage their usage

  • Ensure they understand the company LLM//AI policy before they dive in

After a few weeks of this, bring the team together:

  • Have them read a relevant article before the meeting if possible. We read Lenny’s How to Use Perplexity in Your PM Work
    • While many had been interested in AI, this helped drive an understanding of practical uses
  • Review the company policy around LLM/AI policy
    • Not only is this important for the company, it’s important for your team: if they don’t feel comfortable knowing what they can and can’t put in which tools, they will be less likely to use them
  • Encourage the early adopters to share their use cases, including screensharing where possible
    • Share any useful company-specific prompts that people have created with the team
      • For example, I created a prompt to write story tickets and another to write bug tickets using our standard format
    • The early adopters shared other use cases as well, such as using LLMs to assist with:
      • SQL queries
      • Email and help article copywriting
      • Qualitative data analysis
    • We also shared where AI has not proven useful
      • I shared where I’d tried to use it for something math-related, and it totally fell on its face. Luckily, I realized this just before sharing inaccurate data with all of the leadership team!
  • Run a mini-workshop
    • We did this with a free version of Perplexity, where I gave my team a particular item to research related to decreasing churn within their respective products, and they each researched it with that tool instead of using Google. Then several of them shared what they found.
  • If there are multiple tools the team can use, make sure it’s clear which are best for which use cases

Once the team has access to the tools, ask the team on a regular basis what they are using AI for

  • For example, one team member brought up that ChatGPT enables you to install add-on modules, and she’d used one of those to create a complex flow diagram that would have otherwise taken her a lot of time
  • I shared with the team that I realized you could upload images to ChatGPT and it could ‘read’ the image, speeding up my ticket writing time when I wanted the copy from designs in the ticket

Share additional AI resources with the team, and encourage them to do the same

  • I’m a fan of the AI for Work newsletter, and encouraged my team to sign up as a source of ongoing AI news and information

I hope you find these ideas helpful in bringing AI to your own teams. Best of luck!

Product Management Career Day: An Adventure in Teaching Kids

Last Wednesday was ‘career day’ at my fifth grade daughter’s school. They’d asked any parents with “interesting” careers to volunteer; figuring that product management should count, I signed up.

I had thought that it would only be fifth graders that I’d be teaching; they told me that there would be 5 classes, and that I’d be in the same room the whole time. With about ~20 kids per class, for 2.5 hrs, it sounded difficult, but doable. That’s what I thought, anyway…

Surprise! Teach the WHOLE School!

whiteboard from the class where I didn't have a computer for my presentation.

When I got there, it turned out to be 6 classes, for all of the grades – that’s 3rd through 5th at my daughter’s school – with 40+ kids per class! Each class was in a different room, and the schedule they gave me was less than accurate in terms of which room I was supposed to be in. In the last room, there wasn’t even a computer, so I did the presentation with a whiteboard (that was probably my best class, actually!)

While it was an exhausting experience, it was also a rewarding one. I’m sharing more about that experience in case anyone else is doing a ‘product management career day,’ and wants to use any of what I put together for the kids.

Continue reading

Metrics Sharing at a PM Community of Practice

As part of our Product Management Community of Practice, we regularly share metrics. 

We experimented with a few ways this could work. 

At one point, it was anything goes:

  • Data to help make a decision
  • Pre-shaping opportunity estimate
  • Team dashboard
  • ROI estimate
  • Ongoing project goal metric
  • Post-launch metric

They also talked about where they were having challenges and got input from the group, such as knowing what they wanted to measure for their project, but not being sure how to measure that information.

Continue reading

Invite ‘Special Guests’ to Community of Practice Meetings

Continuing in the series of how to keep a community of practice engaging, for our PM Club, we’ve had a number of ‘special guests’ that have led to interesting conversations.

We were lucky enough to have Rich Mironov present to us one time, which led into an interesting conversation. We followed up that conversation by reading another one of his blog articles that related to that conversation, and continuing the conversation on our own.

Examples of other special guests have included:

Continue reading

Use “Vote & Discuss” for an Engaging Meeting

To encourage engagement in a book club or a community of practice meeting, have everyone vote before you start a conversation.

It’s a lot easier for people to agree with what everyone else is saying, or just stay quiet, but if they have to vote first, then you can have more conversation about where the group has variances in how they voted. 

Depending on what tools you’re using, you can vote anonymously, or you can have team members vote in such a way that you know who voted for what. The advantage of the latter is that you can call on people to ask them why they voted the way that they did. Of course, you don’t want anyone to get defensive or dislike the workshop, so this will depend on the topic and how close-knit your group is. 

Continue reading

Communities of Practice: Making it Engaging

It can be hard to keep regular meetings interesting, whether that’s a book club, or a community of practice such as the “PM Club” that I lead weekly with my team. 

Even with good questions as prompts, I found just bringing together the group to talk about an article or a chapter didn’t seem to be quite enough after a while. Particularly as the team grew, it became harder to have great discussions. And what came out of the discussions? Could I really be sure that everyone walked away with an understanding that they could apply to their work? Particularly when we did this week… after week… after week… for months. It got a little old, honestly. 

But what else is there to do? 

That’s what this series is about.

Continue reading
Example of the filled-in prioritization 'tray'

Running a Cross-Team Initiatives Prioritization Brainstorm

Late in 2022, I was looking to get alignment on cross-team initiatives we’d work on in 2023 across multiple teams. I wanted input from a certain group of engineering managers and product managers on:

  • Which initiatives we wanted to go after
  • What our order of priority was

Whenever possible, getting input from everyone involved leads to far better results from both a buy-in perspective and from a two (or more) heads-are-better-than-one perspective than just making the decision yourself in a vacuum. You can’t always make decisions by committee, but you can get input that way. In this case, I was able to both get consensus and the input ended up changing my mind so that I was aligned with the group on the priorities.

This post is about how I set up the brainstorm.

Continue reading

Creating Team-Driven Product Management Principles

Inspired by Martin Eriksson’s Product Decision Stack video, I set up a brainstorm for my team. What were our PM principles that could act as “shortcuts” in helping us make difficult decisions that would also ladder up to our strategy and vision?

The product managers watched a few key minutes of Eriksson’s video, and then we brainstormed.

The board was set up  like this, in Miro:

[sticky note] even over [sticky note]
[sticky note] even over [sticky note]
Continue reading