Why PMs don't improve as fast as designers
Using PM Crits to up-level your product management team.
Product Managers are a hungry bunch. The role is broad, demanding and requires a subtle blend of analytical and qualitative skills, many of which can’t be taught in college. But it’s disappointing to see how PMs tend to grow skills by themselves, in their own track, through trial and error, and not collectively as a team.
It may be that the role attracts particularly driven individuals, or how the job of leading a team leads to more competitive behavior. The cause isn’t that relevant, the opportunity is: PMs could still develop faster if learning as a team. I’ve seen it with designers before.
Introducing PM Crits
I come from a design background, where critiques (affectionately referred to as crits) are common practice. Crits are structured, no-holds-barred craft-oriented feedback sessions. I’ve always relied on them, since they provide a reliable mechanism for learning from each other within a team.
So when I took over Product Management at Gladly, I saw an opportunity to speed up learning and elevate quality in my team through crits. It was a novel experiment, bumpy early on, but in a few weeks the results started to show. We saw better writing, more thoughtful sequencing of projects, more reliable success metrics, tighter but more impactful scope.
By now I’m convinced every product management team should try this practice, and I hope you do.
Why are crits effective?
Ken Blanchard, author of The One Minute manager, puts it well: feedback is the breakfast of champions. In general, early and regular feedback, in a safe space, consistently improves your work.
Plus the math is simple: why constrain your work to your own brain, if you can use other people’s brain cycles for your own benefit? Even if I produce good work, the idea of getting others to think about my problems and suggest ways to improve it, seems like a no-brainer.
So as a manager, I encourage members of my team to learn from other members’ successes and mistakes. PM Steve doesn’t have to bang their head against the wall to crack a hard problem: I can expose them to Maria’s point of view and experience in solving an analogous problem, which accelerates his learning. Crits create an environment and formalize a process for teams to learn and grow regularly and quickly.
Since PM teams are often composed of people with different, complementary skill sets, the value of feedback is compounded.
Crits create an environment and formalize a process for teams to learn and grow regularly and quickly.
How to run one of these?
Here I outline a summary of my recommended mechanics. You can go deeper in my previous article on design crits, but the gist is the same:
1. Have a sign up sheet so team members can take their slots beforehand
It’s valuable to get the team to sign up early on, to ensure you’re prioritizing what’s more urgent/important and encouraging people to present. As a manager, you may want to nudge your reports to bring their work to crit.
My PM team runs weekly 1-hour sessions; my design team has more volume and organized itself to run two 1-hour sessions a week. Frequency and length will be a function of your team size and how much new work they produce every week.
I’ve found that crits are awkward with fewer than 4 participants and unwieldy with more than 10. Keep group size in mind. Larger PM teams may want to split crits into smaller groups — keeping groups stable most likely yields more honest feedback, but rotating attendees might lead to positive cross-pollination.
30 minutes seems like the ideal time per presenter (a 1-hour session would have two presenters). Less can sometimes be enough for smaller items, but more than that and the popcorn of feedback stops popping.
2. Before presenting, ensure everyone has sticky notes and sharpies
There’s beauty to feedback written on sticky notes: it leads to conciseness, focus (one piece of feedback per note) and a practical bonus: once done, the presenter can stack all of the sticky notes, stick them on their laptop (they fit perfectly to the sides of your trackpad) and process them later, in their own time.
For distributed teams (the case for everyone right now), there are plenty of alternatives: digital replacements like stickies.io, Figma or collecting comments on Slack threads after the meeting. In any case, I’d still encourage participants to write feedback on stickies on their end, for the benefits above.
3. When presenting, ensure presenters articulate what kind of feedback they’re looking for
Not only is it discouraging to hear feedback you’ve already anticipated, but not every part of a document or presentation may be in the same level of refinement. I encourage my team to present in crit as early as possible, which means sometimes incomplete work. By giving presenters the opportunity (and responsibility) to articulate what kind of feedback they’re looking for, you keep the conversation focused and productive. That includes mentioning the target audience of the artifact and potentially the timeframe to work with (since more rushed projects may need to compress a couple steps in the process).
For a presentation format, you may want to try doing them on the spot or ask participants to pre-read what will be presented, so you can save some time, especially if there’s long form content. I have a preference for real-time, otherwise if a participant didn’t have time to read beforehand, they’re excluded from the session (along with their feedback).
4. While presenting, accept no interruptions, except for clarifying questions
The presenter is bound to be in a vulnerable position, so let them tell their entire story arc before anyone steps in with feedback. More often than not, I see notes being written and then crumpled, a symptom that the presenter organically answered the point which was being noted.
5. Once each presentation is done, go around the room, with each person sharing their feedback, while minding time
You’ll only get honest feedback if the participants feel like they can share safely, so make sure it flows continuously and that the presenter doesn’t spend too long defending their choices, instead mostly listening to what their peers have to say.
A couple tips:
- If the team lead/manager is in the room, they should go last. It squashes any chance of people changing their feedback to align with theirs (yours?).
- To keep things moving, make each person, when they’re done sharing their feedback, nominate the person to go next.
6. Keep the mood honest, but positive
There isn’t sense in doing this if feedback isn’t detailed, pointed and actionable. But at the same time, people can take feedback personally (especially more junior folks). As a leader/facilitator, pay attention to ensure a productive balance between honesty, precision and friendliness.
What to bring to crit?
Figuring out what to bring to PM crit was actually a significant challenge at first. The artifacts of design work are easily critiqued: diagrams, flows, mocks, prototypes. PM craft is more about words –strategy documents, PRDs, metrics analysis, process definitions. That said, you can still critique those, especially if your encourage your team to keep them short. My PM team regularly brings project decks (our take on PRDs), product documentation drafts, pricing proposals, etc.
It’s important to have an artifact to present and discuss, though, because crits are as much about the big picture as the details: word choice, sequencing, etc. So I’d discourage crits about strictly verbal articulations.
What happens with crit feedback?
Crit ≠ contract. It’s up to the presenter to take the feedback, process it, and implement as they see fit. There should be no expectation that loops be closed (though that can be helpful at times).
That’s pretty much it. The team learns and grows together quite fast, and the quality of both the craft (structure, word choice, articulation) and thinking (strategy, sequencing, consideration of alternatives) grows significantly. And once everyone has gone through it a few times, it engenders trust and makes for a stronger team.
Thank you to Bruno Orsini, Ayush Khanna and Brett Goldstein who provided feedback on this piece.