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
Jord Sips, Senior Product Manager at Mews, shares his expertise on a common challenge for product managers – finding root causes and solutions.
Senior Product Manager at Mews
Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.
Senior EPM/TPM at Apple Inc.
Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.
Head of Product at ROI Hunter
Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.
Head of Software Quality Assurance at FICO
David Kormushoff, Director at Koho, recalls how he galvanized his team to tackle a time-sensitive problem, sharing his tips on how to shift chaos into calm.
Director at Koho
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.