Product feedback is a gift
I am lucky enough to work at a company where we often joke that every employee is a self-declared Chief Product Officer. Whether internal or external, every Strava user has an idealistic image of what they want the Strava app to do for them.
Because many of us are athletes ourselves, Strava employees are a concentrated representation of our most loyal user base. Whenever I am out on a bike ride wearing my Strava kit, I am often stopped by someone to tell me 1) how much they love Strava and 2) they would really love if Strava did X.
When your users care so much about your product, how can an engineering manager funnel these strong and differing opinions into something productive?
Internal Feedback
Well before starting to build a product, our leads group (engineering, product, design and analytics) assembles a product brief to keep us focused on solving a core athlete problem.
When launching a product internally, we include a feedback Slack channel to direct comments and concerns. Within seconds, we have tens of screenshots and paragraphs of opinions. (Are people constantly monitoring Slack for an excuse to not do their normal work?)
As an engineering manager, I deeply understand the product goal and the engineering steps required to fulfill it. I can accept a barrage of feedback and clearly define what engineering tasks are most important for our product to be as effective as possible. I use this unique position to enable our talented engineers to deliver the most impact from their work.
Managing Feedback
As builders of the product, only we engineers know what we have time to do. We must be explicit about what feedback we are looking for, but more importantly, what we are not looking for. Making expectations clear up front allows us to focus on important things like browser rendering issues while saving the color preference comments for later. At the internal release stage, we are not typically seeking design feedback, but rather, feedback on core functionality.
One of our most-loved features is the Training Log — a visual overview of your activities each day — which uses color to differentiate sport and size to represent length of an activity. When we launched Training Log for internal testing, we had already spent tens of hours analyzing data and discussing implementations. We had debated how to handle multiple activities on a day, sport bounds (is an hour of yoga the same size as a 3 hour bike ride?) and the sport color palette (we have 37 different activity types). This was not the time to rehash discussions about how multiple bubbles appear on a given day.
Stating upfront that I am choosing to send any non-critical issues to the backburner helps both our alpha testers and engineers stay focused on the right things.
Deciding Priority
In late summer 2019, we launched Fitness on mobile. This feature tracks your training load and fatigue over time. Our employees were over-the-moon excited to have their beloved fitness graph now available in the palm of their hand. However, our six mobile engineers only had so much time before the public release, and their time had to be best utilized.
To decide the priority of issues to address, we go back to the product brief and the core athlete needs. How can we help all athletes track their progress over time and at a glance? For Fitness, this was super clear. To enable this feature to all athletes, it was absolutely essential that we build a flow to help new athletes log a Perceived Exertion score to generate their fitness graph without existing heart rate data. The fatigue and form lines that were core to the Fitness and Freshness feature on the web, were removed for clarity on mobile.
When the barrage of internal feedback comes in, I pipe all the Slack messages into a Google sheet and create JIRA tickets for everything, allowing us to group similar issues. With usually one sprint before launch, we look at the whole picture and draw a distinctive line between the “must-do”s and the “nice-to-have”s. This helps engineers conceptualize exactly what needs to be done before launch and only pick up the bonus tasks if they have time.
External Feedback
At Strava, our user experience is so important to us that we built a feedback system that we drop into high-touch features such as activities, routes and fitness. Users can tell us directly what they think, inside the app. We regularly analyze this at an aggregate level, but we also read the free-form text input! We also have a community-driven ranked feature request, where athletes can vote and comment on what they want to see next. We are extremely fortunate to have enthusiastic athletes who are not afraid to tell us what they want from Strava as a whole, and will find any form to communicate with us directly. We use this data to inform what and how we build.
Sometimes feedback can be more abrasive than we would like. It is my job as an engineering leader to carefully consider user opinions but never, ever forget the careful thought and long hours the team has put into building the end product. Some engineers, especially early career ones, haven’t yet developed the thicker skin of industry experience; we must constantly remind ourselves that singular opinions do not define our work.
Celebrate
Launching a product to millions of passionate users is a special moment. In this excitement, celebrate your team. Remember to personally thank the individuals who stepped up over the course of the project. Call out the cross-functional partners who worked hard to deliver design assets, go-to-markets and strategic feedback. Now go enjoy a launch happy hour and start scheming up your next product launch.
