Strava Conquer
A PM portfolio project I built as a longtime Strava user and fan. The idea: the same activity data, product-managed two ways, can serve two athletes, the competitor chasing PRs and the rider just trying to stay healthy, with a “Conquer” feature that estimates whether a goal is realistic, grounded only in published exercise science.
Where I'd take the analytics next
I've used Strava for a decade and love it, so this started as a fan's question: if I were on the team, where would I take the analytics next? Strava is excellent at the competitive, social side of the sport. The opportunity I kept seeing was to add a layer that helps an athlete decide what's next, not just review what already happened, and to bring along the returning or more casual athlete who wants to get healthier at their own pace. Same great data, a complementary audience to grow into.
One dataset, two experiences. Rather than build one more dashboard, I treated the same underlying metrics as raw material for two distinct experiences, each with its own AI interpretation. The serious athlete gets the training-load and fitness metrics this audience already expects, presented with extra rigor and transparency. The wellness athlete gets overtraining detection and gentle, mental-health-aware guardrails for returning or casual riders and runners, an audience there's room to welcome in.
Heart-rate only, no power meter. I scoped to heart rate on purpose: power-based metrics would exclude the runner, hiker, and casual athlete the wellness view is for. Sticking to heart rate keeps that second experience open to everyone rather than narrowing it back to dedicated cyclists.
The AI never generates a number. A metrics engine computes everything in Python from established exercise-science formulas; the Claude layer only interprets the resulting numbers in plain language. That makes “no hallucinated metrics” a structural guarantee rather than a prompt-engineering hope, and I label any simplification so a user can never mistake it for a fabricated figure.
With “Conquer” you enter a free-text goal, “a 60-mile ride in 14 weeks”, and get back a transparent go / caution / no-go verdict built from your fitness, your recent training capacity, and the weather and elevation the goal implies. It's decision support: the point is to help you commit or adjust, then get out and ride.
Training load is built from heart-rate training stress (hrTSS and TRIMP, Banister and Edwards methods), aggregated into Chronic and Acute Training Load and their balance (fitness, fatigue, and form). Injury risk uses the Acute:Chronic Workload Ratio as both a rolling average and an EWMA; other models cover aerobic decoupling and race prediction (Riegel, VDOT). I validated every formula against published literature with a DOI citation on a “Show Your Math” page, and 112 regression tests encode worked examples straight from the papers. Raw activity streams are stored so metrics recompute when a user corrects their Max HR, Resting HR, or LTHR.
This is a PM portfolio project, with a full PRD and competitive analysis behind it. It began as interview prep, but more than that it's how I express product enthusiasm as a longtime user: by building the thing rather than just pitching it.