In the world of product management, we don't focus on learning or feedback as much as we should. The most effective way for product people to learn is on the job and from others that do the job. The product operations team has a key role in shepherding those learning opportunities.

When I first started as head of product operations at Cognizant we had a few key goals: reduce attrition, create consistency in PM leveling, and create a baseline for PM training. My immediate response was to tackle a skills matrix to see where to start regarding competencies. I wanted to get people into training as soon as possible and have them commit to 10% of their time for self-improvement. When people heard this they thought of all of the horrible learning management systems they have been mandated to use for code of conduct training.

After the severe reaction, I considered how we might take some of our existing meetings and gear them towards being better for learning. In particular, council meetings, where PMs get to present their current engagement to leadership, had been particularly in need of revamping (someone may have quit with the prep for these meetings as one of the reasons). After a few pilot sessions with a new format and rolling it out to everyone we found that these meetings were some of the most valuable we have had as a community.

The reason this is so different is that on most teams, product people work cross-discipline without other product people on the team. The only time that all the product people come together is for near useless status meetings to get “hand downs” from leaders. Or to “go around the room to check-in.” These are the worst ways to spend your time together as a team. And you definitely aren’t learning much.

Instead, every product team should maximize the chances for a product person to learn through feedback. This includes tacit knowledge from product people working on other projects and from other disciplines giving feedback on how the product team works with them.

In this piece, we will talk about how to build a comprehensive feedback program to help all product people be the best they can be. These are methods I’ve found to be useful over the last 20 years of product management leadership across large and small companies.

The key is to make training and learning look more like regular work.

Symptoms of a team without good feedback

Without feedback there are many dysfunctions that can be observed in teams:

  1. Uneven growth of people - only those that strive to change themselves do rather than everyone making small adjustments all the time.
  2. Groupthink - without lots of feedback people fall into trying to be more like those people with power to avoid bad feedback.
  3. Lack of trust - people don’t know what others are thinking so they think the worst.

Teams are not simple machines. They are incredibly complex systems with many people creating a culture through behaviors, goals, and incentives. Inside of large complex systems you can never just make a clean change. You have to make small interventions to either amplify behaviors you want or dampen behaviors you don’t.

This means that not every intervention will work for every team. The approach for making change in the complex domain (ala Cynefin) is to probe with an experiment, sense how it works, and respond with further changes. Change inside large, complex organizations is iterative.

Communities of practice are all about transferring tacit knowledge

football team

A certain amount of a product person’s job can be trained in the traditional sense but is limited to explicit knowledge. These are things like how to log a story or assigning it to an engineer. They end up being procedural or a checklist.

Tacit knowledge can’t be taught well by sitting in a lecture. It's something that can be transferred between people through discussion and other experiences that simulate it. The world of product management requires extensive experience and intuition to do well. This is pattern-matching and other types of experience background that's required.

What stops tacit knowledge from being transferred is the fact that product people seldom share it with each other. Engineers have code reviews and designers have critiques. In most product teams I’ve been on we have rarely had the opportunity to talk product to product about how to make decisions with the goal of learning.

This is why people shadow others when they are getting started. It is why apprentice models work the way they do. We could go to the extreme and start to have all of the product people in every meeting. This would give everyone a huge amount of transfer of tacit knowledge but we would never get anything done.

A key tradeoff in every team is how to transfer as much tacit knowledge as possible with as low overhead as it is worth.

Feedback isn’t performance evaluation

There is a lot of fear around feedback because any little throwaway piece of feedback from someone you had a single interaction with could be turned into a negative reason to not get a promotion. Without separating the way that performance evaluation is done from the many different types of feedback we need we are lost.

Feedback is how you as an individual or team get information about how some work is matching against expectations (even if the expectations are not always said). It will sometimes include recommendations on how to make it match or exceed the expectations. This is key to being a gold standard product organization. Everyone should expect and seek out feedback from managers, leaders, and peers.

Evaluation is how you are judged to either be at your current stage in a career ladder (or one above it and in need of promotion). This should be highly objective and evidence-based. It shouldn’t be focused on personal styles or preferences. It doesn’t matter whether someone likes or dislikes your work if it meets the level of competency the organization expects. Evaluation is linked to incentives and monetary compensation.

This important distinction means there is safety in giving direct feedback without incentives for personal growth being impacted. Is up to us to decide whether we take the feedback on or not but if you aren’t performing at the level you are expected to you need to make a change.

Spreading tacit knowledge

Feedback can come from all different types of sources. This includes your manager, your peers, other functions, and even people you don’t work directly with. It’s key to learn from all of the different perspectives you have access to.

We should be asking some important questions when considering the setting for the feedback: How personal or public is this feedback? How many people are involved in it? How sensitive is the information?

Also, the feedback can be on things that have already happened and those that might happen. Lessons learned by comparing the decision process and the outcome are great ways to analyze the past. We can also look ahead into the future to test our possible decisions to see how they might turn out.

For the timeframe of the feedback we should ask the following questions: Is this looking at things that already happened? Or things that are yet to happen? Or things that could maybe happen?

Restructure and replace your current meetings

There are many feedback mechanisms you can set up for your team. Some will be required as doing business and others are optional when people need help. You may even do some of these meetings today but not with the goal of feedback in mind.

I’ve started to think about feedback mechanism across two dimensions: 1) how public the feedback is and 2) in what timeframe it focuses on:

feedback mechanism model

Not all of these feedback opportunities will work for your team. You should consider how much you need to be looking back or to the future. It is important to also gauge how comfortable your team is with public vs. private mechanisms.

Below are deeper descriptions of the methods and where you can find out more:

Method

Description

More information

Manager 1:1s

A classic method where managers and their direct reports will talk about problems. The transfer of tacit knowledge goes both ways. The direct report learns how the manager may have handled something similar in the past or would handle this. The manager learns how their direct report would think about handling the situation. The hazard can be these meetings turning into status meetings. 

Managing People The Ultimate Guide to Manager 1:1s 

Councils

A PM meets regularly with a (potentially cross-function) group of leaders to get their feedback on a particular project. When presenting the challenge the PM can use the what/so what/now what format for the narrative but the majority of the time should be saved for discussion. I’ve implemented these meetings as critiques across the PM group but they can also be created as critiques across function.

Product Manager Critiques: How to Raise the Bar of Your Product People 

Retros

After every set of work completed by the team everyone gets together to talk about how it worked out. This is a key activity for any agile practice. These can go wrong when they aren’t focused on the team and its needs. 

The Definitive Guide to Agile Retrospectives and Post-Mortem Meetings 

Post mortems

After a project is completed the entire team (even salespeople if they were involved) will think about how it worked out. This usually results in a document that can be stored and shared. It helps identify new processes for future projects. 

The Definitive Guide to Agile Retrospectives and Post-Mortem Meetings 

OKR grading and setting

OKRs get a bad rap in a lot of circles but the key aspect of them is to constantly check whether what you are doing is towards the strategic goals of the organization. It is important that these are not tied to performance evaluation.

How Google sets goals: OKRs / Startup Lab Workshop 

Topic mobbing

Pulling together a just-in-time group of interested people or experts in a particular topic to help someone. They can be stewards of a topic in a playbook or something less official. We have added a section to each topic in our playbook to list out everyone passionate about the topic to be part of the mob. 

There is no product person mobbing article written yet since we are in the process of testing it out but engineer mobbing can be found here: Mob programming

Recipes

Any PM can share a short recipe of a technique and how it worked in a case study. We have generally capped these presentations at 10 minutes. They can be a great way to build out your playbook. 

I haven’t found a great article about this practice. It is something that we have done as part of our whole group meetings. 

Circles

Smaller groups of people that are from different projects get together regularly. These people meet to have a safe conversation about particular topics that are important to the whole group. 

Lead a Lean In Circle

Mentorship and coaching

1:1 mentoring or coaching is where someone that is a 3rd party can help someone either learn through their experience (mentoring) or by working it through themselves (coaching). 

Agile Coaching Circles has lots of mentorship and coaching resources 

Pre-mortems

Talking with the cross-functional team about what could go wrong is a valuable exercise. 

Performing a Project Premortem (2007) 

Scenario planning

This is a tool to look at big uncertainties for the organization and to consider how these uncertainties could impact in different scenarios. Usually two different uncertainties are chosen to create a 2x2 with four different scenarios. Each of those scenarios should be discussed for plausibility, preparedness, and what we might do if it came into being. 

Scenario Planning: A Tool for Strategic Thinking By Paul J.H. Schoemaker 

Decision forcing games or cases

These are case studies that are played out with a group of people to consider different people’s thought processes. There are many of these cases developed for military strategy and tactics but relatively few for product management (for now). 

Decision-Forcing Cases by Bruce I. Gudmundsson 

Simulation and wargaming

Gathering product people around to work through a problem as if it were really happening teaches so much about the decision making processes. I’ve found this is very valuable when comparing how you might make different decisions from someone else. 

Business War Games: How Large, Small, and New Companies Can Vastly Improve Their Strategies and Outmaneuver the Competition


Simulations and Student Learning 


I’ll be writing a follow up article talking about how I’ve used wargame-like systems to help explore decision making processes for product people. 

Feedback makes the product team

These mechanisms can be implemented to help the entire team up their capabilities. Without many different circumstances to get feedback from many different people they will get stuck into doing things the same way over and over.

It is important to mention that a failure of these meetings is when they turn into status meetings. We shouldn’t be wasting our precious in-person (or synchronous remote) time just rattling off what is going on. We should be reserving that time to learn from each other.

Feedback is essential to teams that will continue to get better. As product operations people we have a duty to understand the needs of our teams and balance that against the overhead of additional meetings. Restructure the learning to look more like regular work.

Addendum: other feedback resources

Feedback is a particularly important aspect of my work and this discussion is built on the shoulders of giants. I’d like to offer these other resources in case you want to dive into them for more information.