Understanding User Interactions on Mobile
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.
How Our Product Team Works
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.
Find Hidden Issues and Improvements for Your Product
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.
Better Retrospectives for Distributed Teams
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.
Useful and Inspiring Product Management Blogs
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.
What I Learned From My First Beta
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.
Scotty Doesn’t Know (What the Product Team is Building)
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.
Goin’ Remote: A Product Team Experiment
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.