A friend of mine, who’s is a product manager at a large company shared her frustration recently that there were some reorganization and changes in her company that caused her to manage a different product than she was hired to do.
I immediately resonated with her situation. I had personally experienced similar situations multiple times where I had to give up the ownership of products I had started to other colleagues and take the ownership of new things. But most vividly, I remember a conversation with a teammate of mine, who had also gone through a similar experience.
We had hired him as a Product Manager for our Mobile initiatives, but due to some business reasons, management decided to move the entire product (Engineering, Design, Product Management) to a different geolocation center. And he wasn’t happy with this decision at all. He kept mentioning that he was hired as a “Mobile Product Manager” and that’s what he had done in the past and is great at.
I acknowledged everything he was saying, and tried to give him another product in the Web domain which had similar “consumer psychology” problems, but he wasn’t happy. Then I explained him the framework that I use for any decision making for my product or personal career decisions –
- First and foremost, is this in the company’s best interest?
- Second, is this in my team’s best interest?
- Third, is this in my best interest?
I would always put the company first and my interest last. Every single conversation and decisions I’ve made were based on this framework.
With this context, I explained to him that he was thinking about this change in the exact opposite order. He should understand why this is a good decision from the company’s perspective and support it.
Instead of getting too attached to “Mobile” domain and getting obsessed about the app ecosystem or particular features, he should think that — he was attached to solving customers’ problems and Mobile just happened to be a medium to solve those problems.
I convinced him that he should give a chance to other domain, understand those customers, learn their problems and give it a shot. The Web is just a medium through which we solve those problems today.
Eventually, he agreed and took up the new role. At some later point, he appreciated me for changing his perspective — and that’s why I remember this story vividly.
Everyone loves to be a problem solver. It’s a common believe that if you’re exceptionally good at solving problems then you have a distinct advantage to become very successful in your career.
But I cringe to give this advice to Product Managers.
Product Management isn’t a well-defined function. Its role is changing rapidly over the past few years. A common understanding is product managers identify problems in the market, come up with a bunch of ideas to solve it, define how the idea should look and work, and then give it to designers and engineers to build it.
I’ve also done this mistake in the past too. When I was new in my Product Management career, I received the feedback from a VP of Engineering — “Aditya, can you please mind your problem boundary?”. That feedback was harsh, but it completely opened my eyes. I realized what I was doing wrong. But I took that feedback positively and quickly stopped my day to day involvement in coming up with different ideas and solutions.
Since then I strongly believe —
Product Managers shouldn’t be problem solvers. Their focus should be to —
- identify the right problems that their company and a team should solve
- prioritize which problems to solve first and which can wait later
- communicate the rationale behind these decisions to their team and other stakeholders
Essentially Product Managers should identify “what” problems they should solve, “why” their company and a team should solve it, “when” those problems need to be solved and then communicate all these things really well to their Design and Engineering teams and to other stakeholders.
And then let Design team come up with “how” it should work and look, let Engineering team come up with “how” it should be built, and let Sales and Marketing teams decide “how” to give it in customers’ hands.
The most important reason for letting other specialized teams to solve specific problems is — they feel valued and empowered.
If you, as a product manager tell a designer what to design and how it should look like, then they don’t appreciate it. Similarly, if you tell an engineer how to architect a solution or use specific technology stack, then they don’t like it. They don’t feel empowered enough to take key decisions. If you take decisions on behalf of them, they don’t feel as motivated and involved and then hesitate to take responsibility for those decisions.
In fact, I believe that we should change the title of a “Product Manager” role to “Problem Manager”. Because of the “Product Manager” title, there is this notion that they are the owners of the product and get credited for the success or blamed for the failure.
In reality, they’re just team members playing a particular role in identifying and prioritizing problems. The rest of the team is responsible for solving those problems in elegant, scalable and profitable ways. While product managers are the face of their respective products, they rarely make or break the product. It’s a collective team who is responsible for the success or failure of the product.
By calling Product Managers as Problem Managers, it will keep them away from solving problems and will remind them to focus only on identifying and managing problems.
Having said all of this, if you’re a very early stage company and can’t afford to hire specialized Designers, Engineers, Marketers, and Salespeople, then yes, as a Product Manager you might need to play different roles and get into “problem-solving” mode too. But as the company starts scaling, you should let go your other responsibilities to specialized teams and focus only on identifying the right problems and prioritizing them.
☞ If you enjoyed reading this article, then please tap or click “♥︎” below to share these thoughts with others.
Aditya Kothadiya 