Learning in Product
Too much Product content still relates to “what is “Product” (ugh), “how to get into Product” (ok cool, but then what), and “do we really need Product anyway?” (double ugh).
We lack content on “how to get better” and I think it’s because everyone does it differently. Companies define it differently, it reports to different departments, and Product Managers have widely divergent backgrounds. Career ladders don’t all look the same. You’d need more than a lifetime to learn every skill that might be useful.
I’ve been experimenting. Here’s how to get better at Product in four easy steps.
- Set an honest baseline.
- Decide what you need (or want) to learn next.
- Figure out the best way for you to learn it.
- Repeat.
Since those are basically how you learn anything, I’ve broken them down in a way to think about it for Product in particular. This guide is hopefully a way to go from Product 101 (which we’ve got covered) to Product 401.¹
Set an honest baseline.
First, you need to figure out where you are as a Product Manager.
It’s really tempting to say you sit at the middle of Technology, Design and Business. This is what most people assume Product Managers are.
That’s a fine elevator pitch of your job, but it isn’t a fine way to approach your own learning. Almost no one is equally strong in all areas — most people fall into a flavor.
Chances are it’s more like your skills are consolidated into one of the three buckets, based on what you studied and/or did before PM:
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:
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.
(1) When I first realized this gap, I called it the “Leland” gap. Leland was a senior Product Manager that I worked with at Kickstarter. He was able to take on a set of broad, diverse projects and make them go very smoothly. I couldn’t see a smooth path to get from where I was to being as good as Leland. It helps to have someone to look up to.
(2) As an aside, I’m also a fan of Sachin Rekhi’s model of builders, tuners, and innovators as types of PMs, but it hasn’t helped me as much for figuring out what to learn next. I do think it’s helpful when trying to decide what type of job you want next and what you find fulfilling in Product.
(3) The personal backstory behind why I came up with this, and why I shared it is over here.
