They say that a product manager is like a mini-CEO. They're responsible for the product's success and steer the entire team's efforts in the right direction. Yet, product managers don't directly manage developers, designers, or testers. That's done by other people: hiring, firing, conducting reviews, handing out bonuses. In other words, they wield the main levers. So what's left for product managers? They have to engage colleagues using soft skills and leadership qualities.
People won't give 100% if they're not engaged with the task at hand, and that's true even of direct reports. To engage an employee, you need to understand their motivators—what drives them. Maybe one of your developers has always wanted to come up with a complex solution by themselves or handle a large workload. If they can try this while working on a new feature, let them know.
It's important to consistently engage with your team and learn about their goals, not just when you need something. So, make sure to talk to them about things other than work too. I often share what interests me, both inside and outside the company. This promotes a safe work environment where people are more willing to express themselves and show their talents.
Not all wishes can be fulfilled, so it's important to pay attention to motivation during recruitment and find people with similar values. In every company I've worked for, we've invited people who are broadly interested in our product and improving the user experience. This helps everyone work towards common goals. Even though a product manager doesn't hire developers, they can still chat with someone before they join their team.
A product manager is a communicator. Their job isn't just to assign tasks, but also to explain where these tasks come from. Share all the top management information with your team and set up a process for regularly passing on this context. This gives your team enough information to make decisions at their level.
Imagine you ask developers to handle a trivial task like creating a new button on the site. Explain that it's needed to test a hypothesis and conduct an experiment that could yield important business insights and potential future profits. It's essential to revisit context even after a task is completed—like explaining how their work affected the outcome.
"In the past 5-6 years, developers have become much more product-focused. Not long ago, there were many techies who didn't understand why we were running another experiment instead of implementing a new technology. Today, product managers can speak the same language as development."
Much depends on the overall tone of communication. It's crucial to remember that a product manager is as much an individual contributor as a developer or designer until they step into a leadership role with direct reports.
Involve the team in discussions about product decisions, providing opportunities for them to speak up and contribute. While not every idea will be accepted, this approach positively impacts motivation. Of course, as a product manager, the final decision rests with you, but it's always better to explain why a decision was made in a particular way.
We conduct monthly strategy meetings. It's nothing new—all product managers do them, preparing polished presentations. The issue is that others attend just to listen. For them, it's another call where they can multitask or scroll through social media.
To engage my team, I introduce surveys during the meetings. For instance, if we're addressing customer complaints, I give everyone a list of these grievances and ask them to rank them in order of importance—what we need to tackle first and what can wait. This exercise gets the team involved, helping them empathize and think from the user's perspective. Discussions become more engaging.
This productivity hack addresses developer apathy effectively. Imagine you've designed a crucial feature: created a prototype, tested it, and fixed any flaws. You're confident it's superb and eager to roll it out to clients. You hand it to the developers, wait a few sprints, and finally receive the long-awaited build. You open it and realize—one of the key functions isn't working as intended. Nobody fixed it. To make a developer ponder how a specific piece of code solves a user problem, they must see the problem. So, we swapped the task backlog for a problem backlog and altered the phrasing:
Past: please, do it this way.
Present: help solve this problem.
Now, if developers spot ux-issues in features, they send them back for rework. For instance, noticing that calculating transfer fees is time-consuming with no clear design. The problem backlog works better when connected to long-term vision. We use FigJam for this, aligning tasks across quarters, years, and five-year plans. The board enables tracking the journey from a minor issue to overarching goals.
One-on-one random meetings foster communication that is often lacking in remote work setups. During Random Coffee, the conversation need not revolve around work. You can chat about football matches or share breakfast recipes. The benefit lies in employees interacting, building emotional connections. Consequently, they feel more confident during group calls.
In tech, professionals are accustomed to seeking the right answer (solving equations or tasks). The product leader's mission is to unite such individuals. They will carry on with their work from there.
To make these meetings intriguing, involve high-level executives in the mix. This motivates employees, piquing their curiosity and prompting them to ask questions. Simultaneously, leaders are eager to learn about their employees' lives, concerns, and inspirations. Such insights aren't always gleaned from middle managers. If individuals feel lost, help them with conversation topics. Compile random questions to kick off discussions. At our banking project, teams running Random Coffee observed a 7-10% increase in speed.
Most conflicts arise because people don't understand the reasons behind certain decisions. This often happens when you involve employees after you've already devised and planned everything yourself. In a strong team, developers, analysts, and testers are the product manager's partners. When they are immersed in the business, they contribute solutions that you may not have considered.
It is important to stay engaged with your teammates consistently. We regularly conduct meetings with team leaders, quarterly and annual kick-offs with the entire team, as well as business lectures—we explain why the company chose a specific strategy and metrics to assess the results.
To better engage employees, we send them to work "in the field," closer to users. For instance, a developer working on something for tech support might spend a few hours with the support team. This firsthand experience enables them to see what needs fixing.
All team leads and testers in our teams must do this practice, while it's optional for others. Few decline the opportunity, as it's essential for them to understand whose lives they are enhancing with their work—or impacting negatively in case of a failed release.
At times during horizontal planning, we may not see eye to eye, and that's okay—this is how we exchange viewpoints. It's concerning when colleagues don't ask questions or offer counter proposals. This indicates they aren't thinking independently. Encourage discussions and let staff challenge your decisions constructively. If they can support an alternative growth point with data, the whole team benefits.
