Understanding how users interact with your product is a key to lean software development. Seeing people trip over your navigation or completely turn around your expected use case may be cringe inducing, but it’s critical to understanding if what you built delivers. We’ll take a look at software we’ve used at Hudl to see exactly how a person uses an app in a non-intrusive manner. It’s not only saved us loads of time but also greatly increased our sample size.
One part of Hudl I frequently have to explain to people outside the company is the structure of our product team. Fellow developers at other companies, friends I graduated with, and plenty of people in between want to know how Hudl works—and as it turns out, there’s a lot to talk about. We’re constantly evolving and learning more about how to keep our heads on straight, and as we do, we want to get the lessons learned on the table.
Our Product team is split into several squads, each owning a different area of Hudl. At the start of a project, we focus in on that area. This allows us to move quickly and keep our goals top of mind. However, we also need to keep all areas of Hudl running smoothly. What’s the best way to prioritize fixing existing features against the new project you’re trying to deliver? At Hudl, we have a couple of processes in place to help.
In the eighteen months that I’ve been at Hudl, I’ve been on partially distributed teams. Currently, I’m the PM of a team of twelve, and six of those team members are remote. Because of that, I’ve had lots of opportunities to find out what works and what doesn’t work when you run retrospectives for distributed teams. In this post, I want to highlight the mistakes I’ve made, and then describe some of the best practices that make our retrospectives go smoothly.
One of my favorite things about working at Hudl is the culture of continual learning. I’ve never been with a company that puts such focus on constant improvement, genuinely striving to help everyone “level up”. Project Managers at Hudl are a very knowledge-hungry bunch. Between book discussions, weekly presentations on cutting-edge techniques and strategies, conference attendance, and more, there is never a lack of new information and always a chance to better our skills.
We’re working on a brand-new basketball product here at Hudl. It’s an extremely exciting opportunity for our company—we’re creating a whole new way of capturing, consuming, and analyzing basketball video. The 2013-14 basketball season was my first beta at this scale, and I’d be lying if I told you we had a flawless strategy and executed perfectly from every angle. The team and I learned some valuable lessons during the course of this season that I’d like to share with you in this post.
Until recently, product update meetings at Hudl sucked. They didn’t used to, but that’s one cost of growing a product team of 10 to a team of 40. We promised a brief, 5-minute update of what we’d been working on. Instead, we presented a 15-minute barrage of words, hand-wavings, and most shockingly, no demonstrations of actual software. Plus, if you couldn’t make the update meeting, you were SOL.
Those problems led us to try out a new video format for our weekly updates.
The tech community has cherished remote work for literally tens of years. Many companies, including Hudl, allow employees in certain roles to work remotely. For tech startups like us, a huge benefit of remote work is that it allows us to look beyond the borders of Nebraska for top talent. We currently have remote workers based in California, New York, and Texas.
However, remote work has come under attack recently. My previous employer temporarily banned remote work after one employee started watching TV at home all day instead of working. Earlier this year, Marissa Meyer declared remote work to be verboten at Yahoo, prompting waves of outrage from the tech community. That news also led me into a Twitter argument on the subject with a friend of mine (side note: never argue with a lawyer on Twitter).
In the wake of that decision, and since we want to make life better for our own remote workers, we decided to try a little process experiment. One of our small feature teams (we call them squads) decided to work remotely for an entire week last month. None of that team’s members had ever worked from home for any extended period of time.