You’re about to launch your product—congratulations! Introducing your product to the world is the culmination of months (maybe even years) of work and is a shining moment in its history. But this is only the beginning. You’ve got grandiose plans for where to take your product next with even bigger and better features. That is, until you actually launch. Suddenly your error tracking service is blowing up with bugs for edge cases you hadn’t considered. Your socials are flooded with user feedback and requests for features you never imagined. Instead of jumping into your planned features, you’re now asking yourself: “Where do I start?”
Prioritization is already a tough nut to crack. Prioritization when your product is live becomes exponentially more difficult. Finding the right balance between bug fixes, user feedback, tech debt, and the new features you had planned is going to take some time and practice. Every product company handles it differently, and the process will change as your company continues to grow and develops the ability to tackle more tasks within a sprint.
At my start-up Marathon, a social TV tracking app, we’d love to be pushing new weekly features on top of handling bugs, feedback, and tech debt, but we’re limited by our team size (it’s just me!). When we first launched, we didn’t account for bug fixes or user feedback in our sprints, so when new issues came up we would just add them to the task list. This led to bloated sprints and a schedule that saw releases happening only once a month. This wasn’t a great arrangement for me, who felt consistently overwhelmed by the growing task list, or for our users, who felt forgotten between releases.
After six months of trial and error, we settled into a groove that now works quite well for us. Instead of cramming everything into one sprint, we prioritize all our work within a three-sprint timeline:
- Sprint 1: For our first sprint, we focus entirely on addressing user feedback we have received. We have nicknamed these sprints Feedback Weeks, and they were inspired by similar processes from Linear and Arc. Prioritizing user feedback is important—it demonstrates to your users that you listen and care about their feedback. And by leveraging new AI tools, we’re able to identify the most critical feedback to address first. Recently we’ve tackled solutions for adding usernames, new episode notifications, and series statuses.
- Sprint 2: Our second sprint is focused on addressing papercuts. Papercuts are either user-facing UI/UX issues we’ve accumulated by adding new features, or internal “technical debt” that we want to prioritize before building our next features. We work on improvements like streamlining action sheets to look the same across the app, strengthening our unit tests, and cleaning up inefficient data queries in our API.
- Sprint 3: Our third sprint is focused on delivering entirely new features. Typically, we’ll cycle through our different product focus areas to find a meaty feature we can tackle. So far during these sprints we’ve released a feature for generating share images for social media, a new upcoming calendar screen, and a settings overhaul.
With each sprint, we also make sure to tackle bug fixes as they pop up. After all, we don’t want to make users wait until the next update for their app to work again!
The name of the game, though, is flexibility. When the second sprint week rolls around, we may not have any major papercuts to address at the time, so we replace that sprint with another new feature sprint. Or we may have a lot of bug fixes coming in and need to insert a whole sprint to address them. And, of course, what works for us now may not when our team size grows.
As your product goes live, you’ll face seemingly endless tasks and ideas. It can be really helpful to follow a framework. Structuring sprints in this way has drastically improved our ability to grow and maintain a quality product. It’s made for happier users (and a much happier product team).
