I had been talking with some associate product mentees at a TPM meetup about what is expected of them in the role. Unless you have a manager that is good about setting goals and mentoring this can be confusing.

New product managers come out of schools or bootcamps with a lot of theory about how to run projects, but that is rarely what is needed to actually build great products. Book learnin’ doesn’t help you that much when comparing the performance with more experienced product people. At Microsoft we would joke that product people (we called them ‘program managers’) weren’t worth anything for their first two years in the role.

A way to allow for new product managers to grow is to create a space where they are safe to fail. If they can’t get that experience through doing things and failing they will be stunted in their growth.

I must have had Karate Kid (or the Kung Fu movie) on my mind, because I thought about Mr. Miyagi giving Daniel-san seemingly boring jobs during training. In the end, those boring jobs were used to teach and master basic techniques. I wondered how we could use the boring or difficult aspects (aka hazing) as a way for new product managers to learn the basics, important mindsets and other techniques on the job.

Here is a possible ‘lesson’ schedule for a new product manager based on my personal product management school of thought…

Note: we don’t haze our new product managers at Philosophie (yet) and this article is meant as a thought exersize. We are very nice to our new product managers…

Lesson 1: constant backlog grooming

This is influenced by the fact that I’m no fan of backlogs. I think they are a poor use of time to constantly groom and are, frankly, anti-agile.

When the product manager first starts they are given a huge list of everything ever asked for by management, customers, etc. The budding product manager would need to go through this list and stack rank them using some type of prioritization technique. Pick one randomly for them to use.

When they are done be appreciative and ask about what they learned while doing it. It is key to bring up points about why a particular priority order may not make sense for particular cases.

Afterwards ask them to reorder them again with a different technique and repeat until they start to show frustration.

The lesson: there are lots of great prioritization techniques, but they are just a starting point for a conversation. Anytime that we are taking a process over conversations we are going to lose the nuance of the situation.

Lesson 2: the never good enough status update

I’m also not a fan of status updates, especially over email. They aren’t all bad, but they need to be incredibly directed otherwise they get out of control and become worthless.

The assignment is to gather status for a particular project with no other feedback given. They can get this from the planning/review meetings and from repositories of product state (e.g. Github or Trello).

When they send the draft status ask for more detail. Give vague answers on what else needs to be included. Make them go through a few different iterations.

The ideal outcome is that they start asking what status needs to be conveyed and why.

The lesson: status is only as good as what it is used for. I would hope that they start to realize that most status is more of a signaling mechanism than one that changes the way an org works.

Lesson 3: disseminate all the metrics

When I was at KAYAK, one of my jobs was to pull together all of the appropriate metrics regarding mobile into one report. This included data from Google Analytics, AppAnnie, Tableu, Cognos, and various internal tools. It was a big spreadsheet that I generated once a month.

I don’t think they were hazing me, but it was definitely a thankless job. There were always inaccuracies if you dug enough (as with any analytics) and this was exploited when people disagreed with what the data was saying.

Give the task of collecting all of the available metrics into one spreadsheet. When they present the spreadsheet dig into how the different metrics are collected. Ask why there are inconsistencies (there always are).

Point out information that is missing and should be added.

Have them add some way to collect information on who is reading it. They will most likely be disappointed by the number of opens their email gets.

The lesson: metrics aren’t impactful unless they help make decisions.

The added side benefit is that they start to learn the edges of what is known about the product and the mechanisms by which they get that information.

Lesson 4: flip a coin or roll a dice for every decision

You give the product manager a coin and say anytime that there is a decision (even simple ones) they need to flip a coin to decide which one to do. They need to do this for all decisions.

Half way through you should have them look back on how often that coin flip sent the team down the wrong path or made a bad decision. What would have happened if they didn’t make that decision?

Next, you take away the coin and tell them to roll a dice whenever they are making a decision and go with the option rolled. What is different is that they need to consider at least six different possibilities for each face of the dice. In particular, they need to be pushed to creative in distinctive possibilities rather than multiple with slight variations.

This not only reinforced the fact that decisions can have little impact, but that there are rarely only two options.

The lesson: first, the decisions you make are less meaningful than you think. In fact, there are plenty of times that making any decision at all is what is important.

Second, throwing dice shows there are more than two options when making a decision. If you get caught into the trap of only seeing two then you aren’t seeing the whole picture.

Lesson 5: find out what customers want

We constantly work to remove our customer’s biases from decision making. Talking with customers is a double-edged sword when they have a lot of requests.

Ask the the product person to go out and find out ‘what customers want’ by talking to them without any other direction. When they come back with a list of features ‘5 Why’ them. If they don’t have a handle on why that solves something then they need to go back.

Ask them to guess how many people will pay for the features they just discovered. Have them call up the people and try to collect credit cards to be charged for the app or service when they are implemented. They will probably not be impressed with the results.

The lesson: it isn’t about what people say they will do or what they say they want. It is about what they actually need based on what they have done before.

“No such thing as bad student, only bad teacher.”

While this may seem cruel in some ways, I believe that all experienced product people have come to these similar conclusions based on years of trying (and failing).

Why not give the next generation of product people a leg up on us by learning the hard way, fast?