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:
- Uneven growth of people - only those that strive to change themselves do rather than everyone making small adjustments all the time.
- Groupthink - without lots of feedback people fall into trying to be more like those people with power to avoid bad feedback.
- 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
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:
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:
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.
- Thanks for the Feedback: The Science and Art of Receiving Feedback Well - great book on giving and (more importantly) receiving feedback.
- Farnam Street blog as a few great posts on feedback including: What Information Do You Need in Order to Change?, Mental Model: Feedback Loops, How to Provide Great Feedback When You're Not In Charge.
- Feedback is Non-Negotiable - great podcast by ProfitWell's Patrick Campbell on their feedback culture.
- Asynchronous Design Critique: Giving Feedback – A List Apart - lots of great foundational information about structuring feedback and doing so async.