Operations Dashboard / COROS
A performance hardware brand does not suffer from a lack of data. It usually suffers from too many disconnected versions of it.
Product teams look at specifications. Marketing teams look at conversion. Support teams look at tickets. E-commerce teams look at inventory, returns, and regional sales. App teams look at activation, training plans, device pairing, and retention. Each dataset is useful on its own, but none of them explains the full journey from product interest to long-term athletic use.
For this project, the dashboard was not designed as a reporting surface. It was designed as a decision system.
The first step was to separate the business into three layers of data.Product Data covers device models, pricing, weight, battery life, GPS modes, sensors, sport profiles, firmware versions, and comparison points between products.
User Data covers runners, cyclists, climbers, triathletes, first-time users, advanced endurance athletes, and the different motivations that bring them into the product ecosystem.
Business Data covers sales, returns, inventory, regional demand, content conversion, support issues, app activation, repeat purchase, and upgrade behavior.
The problem was not that these signals did not exist. The problem was that they lived in different places: the e-commerce backend, the app analytics stack, the support inbox, product planning documents, marketing reports, and scattered spreadsheets. So the work became clear: COROS did not need a generic sales dashboard. It needed a product-operation dashboard — a system that could connect what the product is, who it serves, how people understand it, and what happens after the device is purchased.
What We Diagnosed
We broke the operating questions into five parts.
Which product is for which athlete?
Not every watch serves the same kind of user. A road runner, a trail runner, a climber, a cyclist, and a first-time endurance athlete all evaluate products through different criteria.
Which feature actually drives purchase?
Battery life, GPS accuracy, mapping, weight, price, training plans, and athlete endorsements all matter, but not with the same weight for every segment.
Where do users get confused?
Some users leave because they are not convinced. Others leave because they cannot tell which model is right for them. Confusion around comparison tables, technical terms, and feature overlap becomes a conversion problem.
What happens after activation?
A purchase is not the end of the relationship. We needed to understand whether users paired the device, downloaded a training plan, customized sport modes, used navigation, reviewed recovery metrics, and returned to the app after the first week.
Which product story converts best?
Technical specifications, athlete stories, training scenarios, comparison charts, and educational content all perform differently. The dashboard needed to show not only what users bought, but which explanation helped them make the decision.
What We Built
The dashboard was structured around four working views.
The first view was Product Line Intelligence. It gave the product and marketing teams a shared view of model performance, feature hierarchy, price positioning, firmware status, review sentiment, and support issue frequency. Instead of asking whether a product was “selling well,” the team could ask why a product was performing in a specific segment, region, or use case.
The second view was Athlete Segmentation. Users were grouped by athletic context: road running, trail running, cycling, climbing, triathlon, general fitness, and high-volume endurance training. Each segment showed product interest, conversion rate, most viewed features, app activation, training plan usage, and common support questions.
The third view was Product Education Funnel. This view tracked how users moved from first contact to purchase: landing page, product page, comparison table, feature explanation, athlete story, cart, purchase, app activation. For a technical product, conversion is rarely caused by one page. It is usually caused by a sequence of understanding.
The fourth view was Post-Activation Behavior. Once a user had purchased a device, the dashboard looked at pairing, setup completion, training plan adoption, sport mode usage, navigation usage, firmware updates, and early retention. This helped the team see where the product experience continued smoothly and where it broke after purchase.
Automation Layer
Automation was built into the data flow rather than added as a separate feature.
E-commerce orders were synced into the product model database. App activation data was connected to athlete segments. Support tickets were automatically grouped by product and issue type. Content performance was fed back into the product education funnel. Firmware updates were tracked against changes in support volume. Each week, the system generated a concise operating snapshot for product, growth, and leadership teams.
The value of the dashboard was not the number of charts. The value was the reduction of ambiguity. A team could see whether a product story was working, whether users understood the difference between models, whether a feature deserved more explanation, and whether the customer relationship continued after the first workout.
Visual Direction
The interface needed to feel closer to training equipment than enterprise software: clear, durable, low-noise, and built for repeat use. The visual system used dense but calm layouts, restrained contrast, sport-specific segmentation, route-like flow diagrams, and comparison modules that could be scanned quickly. The dashboard avoided decorative data visualization. Every module had to answer a decision question.
The result was an operating layer that connected product, athlete, content, and commerce into one readable system.
