Portfolios for Product Managers

Interviewing people is hard. If you’ve been a hiring manager for more than a few years, you’ve almost certainly run into somebody who seems great in the interview but can’t do the work. And you’ve probably missed out on some amazing talent who, for whatever reason, weren’t impressive in their interviews.

It’s tough on the other side, too. When you’re looking for a job as a product manager, you need to find a way to show people not just that you’re great in conversation but that you’re great at making things. Designers and engineers have a bit of an advantage here over PMs. They have portfolios and GitHub where they can showcase actual things that they’ve made.

But as a PM, what you make most often is decisions. How do you show that you made the right ones?

I know it’s not common, but I think that interviewing would be an awful lot easier on both sides if everybody created portfolios of their work, even PMs. Now, before you run out and grab a Dribbble account, let me give you a few guidelines for what a good portfolio could look like.

Don’t worry! You don’t have to be an artist (or even a designer) to make one. I’m not suggesting you create a beautiful showpiece, just something that will help people understand what sort of projects you’ve worked on and what your contribution was to the team.

A good portfolio should consist of one or more case studies of projects that you’ve personally worked on. The point of each case study is to show your particular contribution to achieving a necessary business goal.

State the Goal

When I’m working with designers on portfolios, I always ask them to make sure to state the goal of the project up front. While it can be tempting to jump right into a long description of the thing you made, that can pretty quickly turn into a boring list of features.

There’s a good chance that those features won’t be at all interesting or relevant to potential hiring managers. What IS interesting is how you made decisions about those features, because it shows the way you approach problems. To do that, make sure you share the problem you were trying to solve or the goal your team was trying to reach.

The type of goal you want to share might be a specific metric, like “increase revenue among a specific subset of users” or “decrease the amount of time users spend on tasks that could be automated.” It could also be something more exploratory like “find an adjacent market that could be an opportunity for an existing product expansion.” Or it could be an experiment to validate an existing idea.

Whatever the goal, make sure it’s not something proscriptive like “build a comments system.” Describing your goal that way makes it clear that you’re not thinking strategically about customer needs; you’re just taking orders from somebody else and executing on an existing plan. If you did build a comments section, tell your reader why on earth you’d want to do such a thing!

Show Your Work (and give credit to others)

I did say that you don’t need to be an artist, and that’s true. You do need to show your work deliverables though.

Products don’t jump fully formed from the heads of their creators. If you’re going directly from vague feature to fully implemented product, then you’re either skipping a bunch of steps or you’re completely removed from how your product is actually getting built.

Show the process that your team used to research, synthesize, ideate, communicate, and develop. If you did in depth user research, describe how you did it and what you learned. If you made sketches or mockups, show them. If you ran a design sprint, explain how and why and show the results. If you built a Powerpoint deck to sell the idea to execs, include a few slides. And if you actually built a functional prototype, by all means link to it (if you can).

This is your chance to show what you’re capable of. It’s also the chance to give credit to the rest of your team. If the designer made the mockups, credit them. If an engineer helped on the prototype, give them a shout out. Explain which parts you built yourself and where you collaborated with others, since very few of us are expected to build software on our own.

Explain Your Thinking

Here’s the most important part. You need to explain why you made the decisions you did. Try, if at all possible, to pick a project where the explanation isn’t just “because the senior execs told me to,” although I know that most PMs I know have lived some version of that project.

You already said what the goal was, and you showed what sorts of ideas you came up with and how you explored them. Now explain why you picked the direction you did.

What does the product do now do that it didn’t do before, and how did you expect it to help your company reach its goal? What made you sure that it would work? How did you prioritize the changes you made over others?

Share the Result (if possible!)

I know, it’s not always possible, but if you can share the results of the change, even at a high level, it can be incredibly helpful. Even if the feature didn’t perform in the way you’d hoped, sharing that and explaining what you did to fix it later can be a great example of how you’d recover from a similar setback at your new job.

If you don’t have (or aren’t allowed to disclose) numbers, consider describing user reaction to the feature or the general reception by the intended audience. Sharing results helps show that you care about the outcome of what you’re building and that you are focused on creating value for both your users and your company.

Get Started Now

So, how can you do this? There are a few options. One is to go with something fairly simple like this write up done by an ex-student of mine in UX. Alternatively, here are a couple examples made by students of Alex Cowan, with whom I’m teaching class in May 2019:

“But wait,” you say. Those are all student projects, not real life examples. That’s right. For those of you who don’t have projects that you can share publicly, presenting a student project or some sort of side hustle can still help show what you can do.