Product manager portfolios are a mix of words (narrative of what you did + any written components of your portfolio) and images (wireframes and/or screengrabs)
Keep that in mind when choosing how to build your portfolio. Some good tools: @NotionHQ, @Medium, @carrd are easy/fast
Add an "about me" section! This is a great way to introduce yourself on your terms and make you more "real" - not just a resume in a pile.
Many portfolios present work well, but person to person connections get the interviews ✨
Show as much as you can from start to finish for your portfolio products/projects. If you started with research, describe where and what you learned. Similarly, if you helped marketing or sales, include that too!
Most portfolios just focus on delivery, but we do so much more!
If you only have one product/project to talk about, that's fine! But make it as robust as possible. If you have multiple products/projects to show, you can choose which things to emphasize.
Failures are fine to add too - include what you learned and what you'd do differently
Social proof matters! Be brave and ask people around you to give you pull quotes that you can feature on your portfolio.
Doesn't have to be your manager - other PMs, devs or UX teammates can all be compelling to hiring managers.
Always close with "next steps" in mind! It should be easy to find your contact info and other supporting links, such as to your LinkedIn profile.
Remember, hiring managers are looking to reduce their risk of hiring a PM who will make things worse - if you can assure them that you onboard quickly and can work well across the team, you have an advantage on the job market!
Last thing - where to "advertise" your portfolio now that you created it? Add it as a link to your LinkedIn profile, add it to your Twitter bio, add it as a link in any job applications.
Hiring managers will spend the time to look at a portfolio, it's faster than a phone screen.
Happy to answer other qs if you have them! Good luck!
• • •
Missing some Tweet in this thread? You can try to
force a refresh
This Friday's #prodmgmt story is about the extremely fraught process of "doing a rebuild" 💀 and then moving customers over to your new app.
If you work in tech long enough, you'll find a CTO or VP of Eng who really would like to rebuild the app. New backend, new UI, whatever...
This is usually because the existing app is full of issues and hardcoded logic and built on an outdated stack. For this story, we had all of those things. The app wasn't resilient and it needed a facelift asap.
The engineering team carved out 18 months to rewrite the app.
Carving out 18 months to rewrite it was by itself a problem - customer success teams and other stakeholders were told to "just wait" many times with no real idea of when "later" would be 😓
(as an aside, this itself caused the CTO to get fired about 12 months into the project)
A few times in my career, I have found myself working with a dev team that is totally off-track.
They don't really know what they're building, have 200 top priorities, and are getting inundated with asks.
I usually find them stressed as hell. Here's what I do as a PM - 🧵
1. First, announce your intentions - "I'm here to help get you organized so you can get your work done easier."
Most people will appreciate this. If they are defensive, they are probably too stressed to process stuff - keep repeating intentions and provide a safe space to vent.
2. Document ALL THE THINGS.
These teams usually have at least 5 big efforts going all at once, which means nothing is being finished. I usually start by grouping tickets/requests into larger "buckets" of work (like "tech debt" or "strategic initiative x"). Write it all down.
I graduated college 15 years ago (😱) and I've worked at 10 companies. Recently, a few people asked me about this "job hopping" and first off, obv, non-white dudes generally have a ROUGH time in tech, so it happens. But let's talk about why job hopping is actually helpful 🧵
1. Quickly pattern match
Job hopping exposes you to a lot of different environments and you can start to rapidly pattern match when dysfunctions arise. A bully in tech? An indecisive CEO? A frustrated sales manager? Yep, seen it, handled it, learned from it.
2. Fast to onboard
Job hopping also means that you become very good at onboarding and jumping into the work. I don't need a lot of guidance - I can look at the Jira board, have a few 1x1s, talk to a few customers, read the research and get started. I need ~2 weeks max.