This obviously isn’t a perfect model. I’d lump anthropologists more towards the design bucket. I’d lump data scientists more towards PMM or Engineer. It depends. You can fill in the circles for yourself based on which skills you have. Here’s a piece that outlines some example skills in each area. As you grow, each circle will become fuller.²

That’s where most people stop when they think about how to set their baseline as a PM. There’s two other components.

The one nobody talks about is how others currently perceive you.

When I first started working, I had a piece of paper that said “engineer.” This meant my engineering skills were always vastly overestimated, and my design skills were typically underestimated.

The perception matters because it can impact what work people give you, how they will judge your performance, and how much they will trust the results. It may not be worth your time to prove someone “wrong” if they’ve decided you’re bad something (even if you aren’t!) — or it might be absolutely critical.

Then, to use a phrase I hate, “soft skills.”

There are a ton of so-called hard skills that go into Product — using SQL, running a great user interview, figuring out pricing. Yet, more so than in other disciplines there are interpersonal things to keep in mind.

Is your team motivated? Are you good at keeping the team motivated?

How much do people “like” you — management, peers, subordinates? Can you manage up/down/out?

How strong are your written communication skills?

I cannot emphasize how much these things matter for how you’re perceived as a Product Manager.

So before you decide what you want to learn, think through these three things to figure out what you’re good at, and what you aren’t good at.

Business/Design/Technical Skills Others’ Perception of your skill set Interpersonal skills

You aren’t going to be good at everything, but that doesn’t mean you aren’t good at Product. There are plenty of things some people would say are “crucial” that I still can’t do.

Decide what to learn next.

Once you know where you’re at, you need to decide what to learn next. Here’s four angles to try:

(1) Where do you struggle now?

The easiest way to know this is “my boss asked me to learn to X” or “my boss says I have to get better at X,” but things usually aren’t that straightforward in Product.

Instead, I try to look at it for myself. I’ve been a long time fan of Josh Elman’s work on a Product Manager’s job:

The weird line breaks are mine, it’ll make sense in a second.

I think this is the single best way to assess if you’re doing your job as a PM. If you aren’t already sold on that, go read that piece and come back (and if you haven’t read it before, go read it!)

If one of those pieces feels weakest, chances are there’s something you can do to do your job better. I bucket them into Product areas:

So then you can dive into it to try to figure out a smaller aspect to learn first:

If your Product team doesn’t feel connected to the company, are you missing an aspect of business strategy? How do your metrics align to the overall metrics? Do you talk to the sales team enough? Have you done a sales call to see how it goes and build empathy?

It’s okay the thing you want to learn is broad — even as broad as “I have no idea what finance is.”

(2) Where is the company is going next?

Sometimes there isn’t a big issue at work! Sometimes it feels like the team is going smoothly.

That’s a great time to try to intentionally learn something. If you want to it to help the company, it’s also a great time to break out the Wayne Gretzky sentiment — “Skate to where the puck is going, not to where it is.”

If you’ve got one, you can skip to deciding how to learn it.

(3) Play to your strengths.

Sometimes you aren’t in a job, or aren’t particularly interested in learning something to make that job better. It’s good to have ways to decide what to learn that aren’t just related to your job.

I think the most fun way to learn (and probably the one I do most) is based on what I’m curious about.

This is a pretty popular technique. It’s more likely you’ll stay motivated to work on it. It’s also been shown that people are hired for their strengths, not for their lack of weaknesses.

(4) Address weaknesses.

That said, addressing your weaknesses can still be a valid path. Especially if they’re interfering with other growth.

For a long time, I felt really anxious about getting development environments set up. Actually writing some code, fine. Getting ready to write code, thinking about writing code, not so fine. I made it my new year’s resolution so I’d be forced to be more comfortable.

Recap

There are at least four good ways to figure out what to learn next:

Where you struggle now. Where your company (or just you) is going next. Reinforcing your strengths. Reducing your weaknesses.

Once you’ve figured out what to learn, you have to figure out how to learn it.

Decide how to learn it.

Once you’ve figured out what you want to learn, you decide how to learn it. Unfortunately most PMs skip straight to this step.

Instead, ask yourself these five questions, based on what you’ve decided you want to learn:

Each of these is a spectrum. If you have your idea in mind, I’d draw out five spectrums so you can put an “X” on them as you go through this.

Informal vs. Formal Learning

One end of the spectrum is “I’m an autodidact, I can teach myself anything.” The other is “I like to sit in a formal classroom with an expert.”

Personally, I lean far more towards the right. I wish I was great at teaching myself things, but I do better when I’m accountable and have resources available.

Tactical vs. Strategic Knowledge

If you wrote down before that you don’t know what finance is (I said it was fine!) that’s more a strategic problem. You probably want to understand the underpinnings of how to think through your business model, or how to make money. If you wrote down something like “I need to do payroll this month” that would be tactical.

Strategic is a way to add another perspective or another way of thinking to wha you’e doing. Tactical is more likely to solve a problem in the short term.

Adjacent vs. Not

It is easier to learn things that are close to what you know. Let’s say you wrote down before that you’re very strong in running A/B tests. You also just heard a talk about multi-arm bandit tests. That’s directly adjacent to what you were doing.

Now say you said before you were good at A/B tests, but you wrote down you wanted to learn how to do a good user interview. Not adjacent.

How much do I need this?

I think of this as a spectrum between “nice to know” and “mission critical.”

If you decided to learn something for pure interest sake (doubling down on strengths) and it doesn’t seem like it’ll impact you in the short term, that’s towards nice to know.

If you don’t think your product will succeed unless you figure this out, that’s mission critical.

Do I need credibility?

Last one is if you need credibility or not. In some working environments, being able to “do the work” is enough. In others, you need a formal degree to get the title or promotion you want.

Putting it together.

Once you’ve drawn this out five times, you end up with a picture like this for your skill. Let’s say I’d written down “Building a Financial Model” back in 2014, pre-MBA.

I personally like to learn formally. Understanding how to make a product make money (vs. be something people liked) was more strategic. It had nothing to do with what I’d done before — engineering and design. It was pretty important to me to become a better product leader. To some extent no one wants a spreadsheet that you just made up. Having some credibility when you make a financial model is nice.

Only once you’ve gotten here should you start trying to figure out the right place to learn. This is the last possible step in deciding how to learn.

I bucket the ways to learn into five major areas:

It’s not just about reading the list and deciding what sounds best. Each will be better depending on the type of thing you are trying to learn.

An MBA was a good way for me to learn how to make a financial model, but only because I like learning that way, it was a big new area for me (not like anything I’d done!) and I thought it was important. That’s not going to be the case for everyone.

An MBA would not have been a good way for me to learn to manage. That was done much more effectively by a combination of actually managing a team (new job) and self directed education.

“Should I get an MBA?” isn’t a question.

It’s an answer to “How can I learn to make products that people love, AND generate sustainable enterprise value?”

Repeat.

As soon as you feel confident in your new knowledge and skills, you can start this process over again. I’ve taken new jobs. I’ve gone to school for all of the “core” product disciplines — engineering, design, and business. I’ve taken other, unrelated classes. I’ve asked for advice from friends and mentors. I’ve read books. I’ve used everything I learned so far and tried to teach it to others to see how applicable it was. All of it has helped make me the PM that I am today.

If you take one thing from this, as a Product Manager, please never ask yourself “do I need an MBA?” or “do I need to go to a code bootcamp?”

Instead, ask yourself,

“What’s the best thing I can learn next? How can I learn that most effectively?”

This framework is the culmination of my entire career trying to learn about Product.³ Found it helpful? I’d appreciate your support (one week only!) for my next set of writing.