Four Untapped Product Manager Dimensions
During my experience in product management — on different teams, at different companies — I was exposed to many distinct situations that required me to be constantly developing new dimensions to handle them. As a ferocious reader, I started to get unsettled, because only part of these dimensions were deeply discussed in modern digital-products literature. If you read the top recommended books or articles about product management, you’ll probably notice, in general, there aren’t many PM dimensions presented.
What really bugs me is that some very frequent situations are ignored or just not explored well enough. They’re missing clear tools for the PM to handle their work in a better way. Being a restless guy, I decided to gather some of these unexplored/unusual PM dimensions and start to write about them.
In this article, I present you with four dimensions every product manager should develop. They were cherry-picked from my own experience.
1. The punch bag
When I was leaving my first company, I received feedback from an engineer I worked with as a product manager that really touched me. He said: “We would never find a punch bag as good as you. It was awesome to have you on the team.” I was a little bit confused by his testimonial. When I asked him to explain, he told me: “You take punches from both sides every day and manage to stay calm and lead us anyway. We (devs) beat you in every meeting, the directors beat you every time, putting pressure to make things run smoothly for everyone.” That was a “Wow” moment! It was a statement too strong to be ignored, and from that moment, I trained every PM I managed in this dimension.
But how exactly? The punch-bag PM will take punches all the time. The important thing here is to know how to behave after the hit. There’s two distinct scenarios to handle, depending on the punch origin:
1. Dose the pressure from above: It’s important to distribute pressure from above in smaller fractions to your team. Do it strategically to avoid breaking morale, and make it with the right context, avoiding unhealthy distortions. Warning: It’s important to distribute the pressure to your team somehow; do not shield them.
2. Push feedback from below as fast as possible: When your team punches you, complaining about the company or directors, it’s important to pass this feedback to above layers with as many details and as fast as possible. The faster you act upon it, the faster your team will have their problems solved.
2. The downward trust spiral
Once upon a time, in a company I used to work for, one of the teams was responsible for rebuilding our users’ sign-up flow in our Android app. We expected it to be ready for tests in one month, the team estimated two, and in the end, it took almost four. We were shaken about the situation, so I joined our CTO to talk to the team’s PM and tech lead. Together, we could rapidly draw on the whiteboard a six-week MVP, much simpler than the one that had been developed. When we asked the tech lead why that wasn’t proposed in the first place, he said, “If we didn’t build it right the first time, we’ll never prioritize the debts again.” That statement shocked us. He was reactive and obviously disturbed. He had known a simpler and faster path existed, but he omitted information even to his PM. How did we get to that point? Here’s how, with a simple generic story:
- The PM proposes a simplification of a task, accumulating tech debt to be prioritized at a later time.
- That time never comes.
- These steps happen a dozen times.
- Bugs starts to arise.
- Developers lose trust in PM and start creating complexity layers in each task.
- More micromanagement, more toxic environment.
- Productivity drops (a lot); even simple tasks take an eternity.
That’s what I call the downward trust spiral. It’s a vicious cycle that draws on team energy, productivity and overall health. It’s very important for the PM to avoid these scenarios, no matter what. Prioritizing technical debts and other requests from the dev team is important — not only for their trust; if you don’t do this, bugs and problems will start popping up and consuming your energy. So what are you waiting for? Just prioritize technical debts, time for tests, fixes and so on!
3. Dealing with negative influencers
Almost every team has that guy who just doesn’t get tired of talking, making every discussion tiresome by entering into circular arguments or over-explanation. The guy who cuts everyone off in the middle and doesn’t provide opportunity for others to express themselves, or even worse, who tells everyone else they are wrong every time or their ideas are dumb.
This profile is very bad for the health of the team. It’s difficult to deal with them. It’s important for the PM to help dilute this guy’s influence/behavior as much as possible.
How? Individual processes are a great start, so whenever you can use them, do it (group brainstorming is usually not productive anyway). For instance: Try to use Scrum poker or some voting mechanisms in a planning meeting, so everyone can vote, and all are invited to defend their votes afterward.
Another good tactic for situations where group thinking is required is to separate your team into sub-groups. By doing this, you’ll directly dilute this guy’s influence (even better, put most shy people on other groups). After smaller groups have discussed enough, you can merge the results, and voila, a more healthy environment has been created for most of the team.
4. Inviting diversity and participation of the shy ones
It’s very important to be able to accept ideas from the various distinct profiles a team might have. That’s regarding distinct demographic profiles (genders, races, cultures) and distinct roles (developers, scientists, designers, analysts). The literature teaches PMs to build product discovery tracks to run in parallel to delivery tracks for research around what to build. What the literature usually doesn’t emphasize is the importance of including these diverse profiles in this discovery process.
Here, the PM can help by creating a democratic environment and constantly inviting everyone to participate in product idealization discussions during product discovery. If some people are shy, constantly invite them to talk during meetings; ask questions directly to them. Make them feel as comfortable to share as possible. It is very important to maintain a healthy team environment without reactivity, defensiveness and constant judgment of each other. The tips from the previous section might be useful, as well.
Good readings to help you develop in these four dimensions
Management 3.0 by Jurgen Appelo
Emotional Intelligence by Daniel Goleman
The Hard Thing About Hard Things by Ben Horowitz
That’s all, folks! If you liked these dimensions or have a suggestion about others, please leave a comment. I’m also open to discussing any of them directly; just send me a message on LinkedIn or via my email.
