This is not going to be a skill vs. luck essay. That topic warrants its own post. For now, let’s say product management is one of those fields where both skill and luck play a role in determining how successful you are. Luck may even play a dominant role. But you can’t really control luck, so let’s talk about skill. My hypothesis is that a methodical approach to skill development is main thing keeping most PMs from being great.

Why is skill development hard for PMs? In my view, the job itself isn’t set up for systematic skill development. The nature of the role lends itself to a somewhat random learn-as-you go. PMs are constantly jumping between different and disparate activities (e.g., backlog priorization, management presentations, working sessions, data analysis, etc.) and this makes it hard to hone in on certain skills for systematic development. Compare this to salespeople who can practice their pitch multiple times on different customers, designers who are constantly revising and improving their designs, and engineers who often budget time to refactor their code. As a Product Manager, most things happen just once. Once you prioritize a backlog, you’re not going to go back and prioritize it again. It wouldn’t make sense to do a “practice prioritization” the way a salesperson can practice a pitch. So how does a PM actually become a better PM? I think the principles of deliberate practice can help.

Deliberate Practice

By now, most people are familiar with the 10,000 hour rule. Simply put, it’s the notion that across a wide range of fields (e.g., sports, music, chess, medicine, etc.), it takes 10,000 hours of deliberate practice to reach expert levels of performance. This rule, however, is widely misunderstood. Most people focus on the “10,000 hours” part, and miss another important phrase — “deliberate practice.” Not just practice, deliberate practice.

The current research on development of expertise suggests the top experts in many fields practice their craft differently than the rest. Hard work is required, but in competitive fields, everyone works hard. In addition to putting in the hours, it’s also how the hours are used that separates the true experts from those who are just very good.

What exactly is deliberate practice? There are many examples scattered across the web and in the literature, but one of my favorite examples is Chris Rock and how he prepares his comedy routine. The Chris Rock most of us see is the brash yet polished comedian performing in front of thousands. What we don’t see is the months of painstaking work that goes into producing the 90 minutes of material he uses in his performances. To prepare this amount of material, Rock will frequent a small local comedy club in New Jersey 40 to 50 times. Each time, he tries some new material and takes copious notes on the audience’s reaction. He uses the reactions to rework his material over and over again until the content and delivery are what we expect from the best in the world. My guess is that many professional comedians put in the hours, but few are as methodical as Chris Rock.

So let’s break it down — what makes Chris Rock’s method of preparation a form of deliberate practice instead of just practice? Deliberate practice is a complex subject (see this, this, this, and this), but here are the slightly-adapted components that I think are relevant to product management:

1. Design: the practice activity must stretch the individual just beyond his current skill level. Stretching too far may actually slow down skill development while stretching too little doesn’t do much. If done right, the activity should cause strain or discomfort. The design of the activity is often done with the help of a coach.
2. Feedback: there must be immediate feedback as to whether the individual accomplished the stated goal of the activity.
3. Repetition: the individual must repeat the activity again until it’s done right.

In Chris Rock’s case, his New Jersey club sessions are designed to test new material, constantly stretching his creative boundaries (apparently, trying a new joke in front of even a small group of people is extremely uncomfortable, even for professional comedians). He gets the feedback immediately from the audience reaction. And he repeats this over and over again until he has his 90 minutes of material.

Deliberate practice isn’t fun. That comes later (for Chris Rock, it’s the actual performance). This type of practice is hard, grueling work. The good news, though, is that many of us have done this type of work at some point in our lives, even if it’s for a short amount of time (e.g., playing sports, learning a musical instrument, even learning how to drive has elements of deliberate practice). But few people have figured out how to apply this type of practice to the workplace.

The Problem: Applying Deliberate Practice to Product Management

The use of deliberate practice as a way to increase performance has emerged more quickly in some fields than others. Sports is one where deliberate practice has taken hold among the top performers: Kobe Bryant, Michael Jordan, and Tiger Woods are all examples of elite athletes whose practice habits mirror the core tenants of deliberate practice. The benefits of deliberate practice have been shown in chess, music, teaching and medicine.

But deliberate practice doesn’t seem to have taken hold among product managers. In fact, it’s hard to find much material on its use in business and technology. It’s easy to see how deliberate practice can apply to areas like sports and chess where you do the same (or at least very similar) thing over and over again. But how do you apply deliberate practice to product management, where, as I mentioned before, every day is different from the last? Product management simply doesn’t have the repeatable tasks that you find in chess, music, sports, or writing.

Also, a good PM needs to be competent at a wide range of skills. So even if you could find time to practice, it would be nearly impossible to do so across that many skills. And what about the feedback? Sometimes, there’s quick feedback (e.g. running an A/B test). But other times, like when we’re trying to influence user behavior, we won’t know whether a product is successful until months later. These confounds aren’t unique to product. I actually think that they’re more the rule than the exception in today’s working environment.

Possible Solutions

I haven’t tried these in the field yet, but I wanted to get these ideas out there so people can start experimenting. The key in each case is to isolate a specific component of the skill, find ways to incorporate deliberate practice elements while at the same time integrating the activity into the mainline work of a PM as much possible.

Strategy

In my experience, Strategy and Narrative are deeply intertwined, so a good place to look for ideas regarding how to develop strategy skills is writing. In a way, professional writing is built around deliberate practice: write → get feedback on draft → repeat.

So here’s an idea. Commit to writing six strategy documents, one per month. Each strategy doc should be 2–3 pages. They should be in long-form text. Diagrams and charts are okay, but No Powerpoint. Ask at least 3 people you respect to read these documents and give you feedback. Ask them to focus on 1) whether the strategy is sound and why, and 2) whether the writing is logical, coherent, supported, cogent, etc. (let the grammar and spelling slide). Document their feedback. These strategy pieces don’t need to be company-level Big Kahuna strategies. It might be easier to start with something narrower like “Product Strategy for User Segment X”. But be clear about the objective, write the piece, get the feedback, and incorporate it into your next piece.

Prioritization

If there’s one thing a product manager should be able to do, it’s prioritize a list of options with sound rationale. PMs get plenty of practice doing this — if you’re doing your job right, you should be prioritizing things all day, every day. But how do you turn this into deliberate practice?

One way is to take a page out of science labs and document [pun intended]. Since all PMs love spreadsheets, I’ve created this spreadsheet as a starting point for how PMs might document their everyday prioritization decisions. For every decision you make as a PM, this ledger allows you to to track the decision, the measure of success, and whether you were right. This gives an ongoing tally of # of rights vs. # of wrongs so you can do fun things like track your moving percentage of “rights” over time.

But more importantly, this approach does two specific things:

1. You should start to uncover your own biases when it comes to decision-making — where you tend to be right, where you tend to be wrong, and why. Maybe you tend to overestimate users’s willingness to try new things. Or maybe you tend to underestimate the impact of some design heuristic.
2. Much like the lab notebook, you can use this ledger as a tool to uncover deeper insights into your users and your market. These insights could lead to new product ideas new product ideas or even an idea for a new business. Many PMs I’ve worked with already have some way of doing this, but often without the diligence that could lead to sustained improvement and insight.

Also find someone to do this with, such as your manager or someone on your development team. Having a partner can help keep you honest. Even the best of us explain away situations when we’re wrong. And if you fight the right partner, it can be fun — thinking of it as hacking decision-making.

Communication (verbal)

I’ll borrow one of the methods that Doug Lemov uses with training teachers at Uncommon Schools, a charter school that puts heavy emphasis on developing the best teachers. In his book Practice Perfect, Lemov describes how he uses role-play as a way to have teacher practice how they handle different classroom scenarios such as unexpected comments from students. Lemov will get a group of teachers together and have one play the role of “teacher” while the others play the “students.” The “teacher” will go through the lesson verbatim and the “students” will throw out unexpected questions, answers, etc. The teacher is expected to respond exactly as he would in class. If the teacher stumbles, Lemov (the coach) stops, identifies the mistake, offers suggestions for improvement, and rewinds immediately for the teacher to try again.

Before your next important presentation, ask a few people to get together to role play. Budget 2–3x the expected length of the actual presentation for practice.

When you role-play, remember the following:

1. Say the actual words. I’ve been in countless prep sessions where people (me included) walk through the slides and say something like “on this slide, I’ll talk about this, on this slide I’ll talk about that.” Use the actual words you would use on game day.
2. Designate someone a coach. This person should be charged with identifying strengths and weaknesses, and rewinding the tape.
3. Repeat.

Practicing like this is admittedly contrived. But many practice activities are. As Lemov notes, these exercises intentionally distort reality to enable us to work on specific areas. Keep the goal in mind: you’re isolating a skill (communicating the content) and practicing it so that when you actually give the presentation, you can focus more on the higher-level stuff, like connecting with and influencing people.

Analysis

The best way to develop these quant skills is to work in an area that generates lots of data with short feedback cycles (Short = daily, if not more frequently. Weekly is acceptable, but nothing longer). These are typically in optimization areas (e.g., landing page, sign up, shopping cart, “growth hacking”). These areas usually aren’t the sexiest, but it might be worth spending 3-6 months in a role where all you’re trying to do is to get the conversion on page X up by a few percentage points. Similar to the prioritization exercise above, document what you tried. Work with a strong data analyst that can help you interpret the data (e.g., discuss sample sizes, sources of bias, 1st order vs. 2nd order effects, etc.). The very nature of this type of work lends itself to deliberate practice, as long as you’re intentional in your approach (design, feedback, repeat).

If you can’t find this type of opportunity, you can still work on your analysis skills (I’m assuming that you’re already incorporating regular quantitative analysis in your job — if you don’t, you need to). If your company is anything like the ones that I’ve worked at, you’ll get plenty of feedback anytime you present data. That feedback is usually helpful, so pay attention to it. But oftentimes it is unstructured and/or hit-or-miss. What’s even more helpful is systematic feedback from someone who really understands how to work with data. Find a data scientist and ask her to get together with you every other week to critique a piece of analysis you did. Then take her suggestions, rerun the analysis, and see what you find. Keep a log of the feedback and try to incorporate the feedback into your next piece of analysis. You’re doing the analysis anyway, so this is just one more step.

If you’re doing these activities right, you shouldn’t be fun. Writing long-form text is hard, logging each prioritization decision is mind-numbing, practicing a presentation with the actual words is uncomfortable and weird, and optimization work is grinding. But that’s the nature of deliberate practice. These activities should be pushing you in ways that cause discomfort.

So if I do the above exercises for 10k hours, I’ll become an expert PM?

Not likely. Product Management as a whole isn’t a field where deliberate practice alone can bring people to expert levels. It lacks some of the important characteristics of fields where deliberate practice over a long period of time can bring people to a very high level of expertise. In product, you have to search to find repeatable tasks. The relationship between cause and effect is oftentimes unclear. And while some PM skills are closely related (e.g., analysis and prioritization/decision-making), others may be largely unrelated (e.g., analysis and communication). There’s the role of luck and other things outside a PM’s control. And it’s simply impractical to expect that any PM is going to spend 10k practicing — we have product to ship after all. So it’s unlikely that deliberate practice alone will lead anyone to levels of PM nirvana.

But the principles of deliberate practice can certainly be helpful in developing specific skills, ones that can accelerate growth as a PM. Doing so will take time and energy. While the notion of this type of practice can be a bit daunting, getting started doesn’t have to be. In fact, Cal Newport (who I mentioned in the above comment) hypothesizes that with the right deliberate practice, you should be able to see a separation from your peers at well under 10,000 hours, perhaps even starting at few hundred. I think this is likely to be true in product management since since very few product managers actually engage in deliberate practice. While it’s unlikely that you’ll notice an immediate difference, my guess is that you’ll start seeing a change sooner than you think if you keep at it.

But remember, your skills exist to serve the product

Remember that all of this should be done with the end goal of building great products. Just as Chris Rock’s small-club sessions ultimately serve to improve his big performances, your skills as a product manager should ultimately result in products that delight your users (vs. building skills for the sake of building skills). Deliberate practice has pushed the boundaries of what is possible in many fields and I’m curious to see what it can do for product.