Why Overloading Product Teams Never Work
23 November, 2021
null at Evermos
Overloaded Product Team
I was working in one of the startups in my region, and while working on various projects, the organization decided to shuffle things around. I was transferred to another division, one of the essential departments in the company 一 it has a scary reputation. In the beginning, I noticed that the division was in a mess; they had a product that was way over the due date, the team had a lack of trust, and the time to market was perceived as slow.
Imagine trying to deliver something and already lagging three months behind! Two weeks might be still acceptable, but three months is unacceptable. When I tried to make a sense out of this, I noticed that not only was the market slow but there were a couple of other problems with it:
- The team was overworked but stakeholders are feeling they were very slow.
- Even after delaying the timeline and building the product, it does not have any impact.
- There was a lack of trust among the operational functions; teams played the blame game on each other and did not execute correctly.
- Worst of all, the product team acted as a feature factory. They had no room to explore.
This is a pretty common problem, but the good thing is that I took action immediately so that in just around 6 months the things turned around from worse to better. Upon my leaving the company, the team was one of the best performing teams in the organization.
Product Managers Should Build Context
At first, I approached the stakeholders. Starting with the engineering team, the different business teams to research and development, I gathered a lot of different perspectives from everyone. While we were all talking about the same thing, the engineering team would have their opinions, whereas the business leaders would say the same things with different perspectives.
In that regard, all I did was try to build trust and empathy among everyone. In order to fix things, I knew that it was the only way to get things done with stakeholders. Simply saying, “I hear you, and I cannot fix the problem immediately, let us try to help in other ways.
Afterward, I tried to find some quick wins, perhaps not anything extraordinary, but something to hold on to. I told them that I couldn’t solve the hundreds of problems that they could throw at me to build their trust. Instead, I could start solving 1 - 2 problems a day. I kept proceeding with the more minor things to gain their confidence.
By finding some quick wins and political plays, I could praise them for all they had done. In essence, my job was to shield the team from unnecessary distractions. I wanted the team members to come up with their perspectives and improvements on the processes.
I sought help and support from an ideal coach. When I realized that the team was struggling to estimate their workload, I got some time from the head of engineering to help us in the process. I tried to coach the team, especially the product manager, in assisting them in saying ‘no,’ while improving their capabilities.
We wanted to deliver what we promised with adequate quality. Instead of saying ‘yes' to everything and then delaying the timeline, it would be a far better idea to focus on what we were doing. We built transparency and honesty, which enabled us to become one of the best teams in the company.
- Empathy is the key. Instead of refusing to understand the problem, or come up with a solution, try to say that “we understand the problem, and we are taking steps in solving it.” The problem might not be solved right away, but showing that you are working towards it is a more significant step towards doing it.
- In order to build trust, you need to have transparency. I created a working document where everyone could see what was on the plate. In that way, others would know what we prioritized and what we did not.
- Saying ‘yes” is sometimes worse than saying ‘no.’ When you cannot keep a promise or a commitment, it’s better to sway away from it. Never opt for false hopes to others, which can create confusion among others.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.
Viswa Mani Kiran Peddinti
Sr Engineering Manager at Instacart
Vineet Puranik, Senior Engineering Manager at DocuSign, discusses the impact of roadmaps, organization, and proper management for your teams to procure growth.
Senior Engineering Manager at DocuSign
Saikrishna Desaraju, Engineering Manager at Marks & Spencer, draws from his personal experience to advise new managers on thriving in their roles.
Engineering Manager at Marks and Spencer
Pavel Safarik, Head of Product at ROI Hunter, discusses the frequently overlooked role of product marketing in getting high user adoption rates for your product.
Head of Product at ROI Hunter
Muhammad Hamada, Engineering Manager at HelloFresh, addresses the uncertainties brought on by the pandemic, how these have affected our work environments, and how we can adapt.
Engineering Manager at HelloFresh