A Humbly Arrogant Blog

Posts about software development

Is Your It Harmful?: Product Team

Here I try to explain in nontechnical ways things that happen in IT departments which in my opinion are generally harmful to the company. The aim of this series is to help company founders who aren’t experienced in IT be able to judge the health of their IT department.

The Product Team is there to decide which features are to built first and how the features are to work. They are one of the most crucial parts of the development processes since they choose the path for the project and help make sure that the project brings the most business value as possible. However, problems can occur when the technical part of the development process never says no.

The Product Rush

In this example, there was a company whose core business was e-commerce they operated in several countries around the world. They, however, had severe technical issues, to the point where the CTO managed to convince the COO and CEO that they needed to stop all feature development and only focus on the technical problems they had. A freeze on feature development is for the most part unheard of since for the most part; new features increase revenue. However, since the technical problems they were encountering resulted in frequent downtime it was clear, uptime is the main priority. So there was a feature freeze until it was clear we had solved the downtime issue and increased engineering quality. The feature freeze lasted two months or so.

On the day of the unfreeze when we were to start work on feature work. One of the Product Managers was instantly pressuring one of the developers to rush out a feature that day. That feature was rushed out, with the developer who did it telling them it was not a good idea.

That feature was rushed out cost the company an estimated 750,000 euros in hosting fees. Coincidentally, when the feature freeze was over the downtime issue reappeared.

Non-Responsive Product Teams

Another kind of Product Team that can cause issues is what I would call the “Non-Responsive Product” teams. This is where the product team gets requests but nothing ever happens to them, they move at an extremely slow pace, or worse they are not even treated as requests and instantly dismissed.

This becomes a major issue because when the Product team is deemed to be not responsive to requests people stop requesting things, stop submitting bugs, and stop communicating with the IT department. With communication being one of the biggest factors to how good your IT team can be. In some cases, departments will bypass Product altogether, which will result in a product that doesn’t have a consistent roadmap which it can build on.

With Product Team’s job to tirage other departments requests and help bring value from features not having requests clearly means they can’t do their job fully since no requests mean nothing to tirage. This clearly means the Product Team is no longer able to fully do its job.

How to Spot Issues with your Product Team

One of the major things that is generally quite common with poor performing product teams is missing deadlines. Missing deadlines either means something massively went wrong and it’s a one-off or if it’s happening constantly there is something wrong with the planning.

Another thing to look at is how long it takes for a ticket to go from being created to being done. In a large company, you can expect lots of tickets to take a month or so before hitting the development queue. If you’re a small business, for the most part, it should take a week or so for the ticket to hit the development queue. A massive sign that there is something wrong with the prioritization is if quick-win tickets, those that are extremely easy to do - will take 1-4 hours or not being done extremely quickly. These are called quick-wins because for very little effort you have a ticket request done. If the ticket can deliver massive business value such as doubling or tripling your lead generation and it’s not done extremely quickly you have a serious problem with your Product department.

Conclusion

This is a few of the things I’ve noticed throughout the years that I’ve seen within companies that have failed and had what many would consider a failing IT department. Hopefully, some people will find this helpful and be able to use it to guide their company to success.