Find Hidden Issues and Improvements for Your Product

Here at Hudl, we love our Support team. They know more about the whole product than the rest of us. They test new features to find problems before release and serve on the front lines to answer questions about the product while squads focus on building impactful changes for coaches. An overlooked value they bring is hearing problems that might otherwise slip under the radar.

Our Product team is split into several squads, each owning a different area of Hudl. At the start of a project, we build all tracking and metrics around that area. This allows us to move quickly and keep our goals top of mind but can also lead to a state where we don’t think about problems with other features in our given area. We have to balance letting every issue stop our progress with keeping other features running smoothly for customers and support. How should you prioritize fixing existing features and the new project you’re trying to deliver? At Hudl, we have a couple of processes in place to help.

Ways to Find and Fix Issues

We use Jira to house a production issues board that sorts ​“Prod tickets” into lanes based on varying levels of urgency. It’s up to the squad’s QA member to voice the issue’s importance and keep Support updated on the resolution.

The concept of ​“Fire Squads” is something I’ve seen only at Hudl. These squads don’t have to strike a balance between moving their project forward and fixing support issues. They set aside an entire week to work with Support toward two big goals:

• Be the front line of defense against sudden problems with production
• Implement one change to improve how the Support or Sales team does its job.

Fire squads benefit both the support and product teams. Support knows the Product team is keeping them in mind while Product members who aren’t on that week’s fire squad have fewer support issues to handle, allowing them to focus on new features.

Each squad’s product manager meets with a support lead at least once a week to keep the connection between both teams active and effective. In one of these meetings, a lead informed me of a bug that nobody on the squad knew about. We were looking through support tickets when I noticed frequent mention of, ​“Exchanging, switched browsers”. 

Exchanges are how coaches share film with one another – a highly used feature in Hudl. When I asked what that meant, I was told the Exchanges page was broken in IE9, but worked fine in other browsers, so coaches were simply told to switch. Exchanging wasn’t something we were working on at the time, and with an easy work-around Support didn’t feel the need to create a new task for the Product team, but it was a problem the squad wanted to fix once we knew about it. When a quick work-around is available, it can mask a deeper problem that could lay dormant if you don’t dig.

Collecting Internal Suggestions for Product Improvements

So far I’ve focused on how we hear from Support when something is broken, but we also want to hear how Hudl could work better in general. This could be a pain other Hudlies experience as part of their daily work, or something they know coaches go through. We collect these issues on an internal board we call ​“Priorities”. A great priority has a problem-based title, a description of the pain, and a couple of suggestions on how it could be solved.

Any Hudlie can submit one of these, and everyone has five votes to use on the ones they find most important. Ideas with the clearest stories tend to get the most votes and the attention of the squad recommended to solve it.

What Works for You?

Focusing on a single project keeps the team running smoothly, but it can cause tunnel vision. Having good checks in place to keep support issues in mind makes for a better overall product. What does your product team do to make sure support issues are bubbled up appro­pri­ate­ly? How does your team prioritize issues or defects against new features or improvements?