First User Research: What a Real Cyclist Taught Me About My Own Product

The First Real Test

Thirteen episodes of building, and I'd never watched someone else use SportsSync. Not a demo I controlled. Not a walkthrough I narrated. An actual person, sitting at their computer, trying to figure out what the app does and whether it matters to them.

Santi is 27, lost 20kg through cycling (94 to 74), and trains with power meters and heart rate monitors. He pays for Strava, pays for Whoop (€30/month), and tracks every metric religiously. If SportsSync has a target user, it's him.

Landing Page: First Impressions

Santi's first reaction to the landing page was positive — he immediately understood the concept from the hero video. A cycling video with telemetry overlaid. "This is something many of us are missing," he said without prompting.

The layout resonated: minimal, direct, not overloaded. He clicked through the sections naturally, understood the "How It Works" flow, and noticed the community feed placeholder. His comment on the feed: "For seeing a full training session, maybe not. But for specific zones — where I push hard, where I climb — absolutely."

Unprompted insight: Santi mentioned wanting to compare his performance on specific segments with friends. "It would be cool to see if my friend goes faster here or if I push harder there." The social comparison angle wasn't something I'd prioritized, but for his demographic, it's a natural extension.

The Strava-to-YouTube Gap

The first friction point appeared immediately: SportsSync requires a YouTube video AND a GPX file. Santi had cycling videos on his phone (shot in portrait for Instagram Stories) and activities in Strava. He didn't have cycling videos on YouTube.

We spent 10 minutes uploading a 23-second video to YouTube before we could even start. This is a massive friction point for the target audience — cyclists record for Instagram, not YouTube. The video-to-YouTube pipeline needs to be eliminated or dramatically simplified.

Critical discovery: portrait video format. Santi's video was 9:16 (vertical), shot for Instagram Stories. The overlay is designed for 16:9 (landscape). When we loaded his vertical video, YouTube embedded it in landscape mode with black bars on the sides, and the telemetry gauges were positioned for a wide frame that didn't exist.

I had never tested with vertical video. Every test I'd done used my own GoPro footage, which is always landscape. But Santi's generation records vertically by default — it's the native format for their primary sharing platform. This is a fundamental product gap.

The Synchronization Flow

Once we had both files loaded, the synchronization process worked. Santi found a recognizable point in his video (a curve on a road he knows well), located the same point on the GPS map, and created the sync. The fine-tuning controls (plus/minus buttons for single-step navigation) helped him get precision.

What worked: The concept was immediately clear. Video point + GPS point = synchronization. The map helped him orient spatially.

What didn't: The flow requires too many steps and isn't self-explanatory. I had to guide Santi through the "create sync point" and "activate synchronization" buttons. A first-time user without guidance would likely get lost.

The Insight I Didn't Expect

The conversation took an unexpected turn when Santi started analyzing his own telemetry in real time. He paused the video at a flat section showing 27 km/h and pointed to the heart rate: 174 BPM.

"This is wise," he said. "Because right before this, there are these little hills. They're not big, but they spike your heart rate. So here you think you're cruising, but you're actually at 174 because of what came before."

Then he asked for something I hadn't built: gradient visualization on the video. He wanted to see the slope overlay so he could understand why his metrics looked a certain way at any given moment. The video shows the road, the telemetry shows the effort, but the slope connects the two.

The deeper insight: Santi wasn't thinking about sharing. He was thinking about analysis. He wanted to replay his rides with full context — visual, physiological, and topographical — to understand his performance. The "share cool shorts" use case I'd been optimizing for was secondary to him. The primary value was self-analysis with visual context.

This reframes Phase 1 entirely. It's not just a viewer — it's an analysis tool that happens to produce shareable content.

Power Data Missing

Santi's GPX file had power data (he rides with a power meter on his crankset), but the overlay didn't show watts. Investigation revealed the issue: his Garmin device formats power data with a different XML tag than my Favero pedal-based power meter. The GPX parser was optimized for one format and missed the other.

This is exactly the kind of bug that only surfaces with real users. My testing used exclusively my own GPX files from my own device. One different hardware brand, and the parser breaks.

Would He Pay?

I asked directly: is this something you'd pay a monthly subscription for?

His answer was nuanced and more valuable than a simple yes/no. He framed it around value perception in the cycling world: cyclists already pay for Strava, for Whoop, for smart trainers, for premium gear. The cycling market is full of people who don't mind paying for tools that improve their experience. The question isn't whether they'll pay — it's what value justifies payment.

For Santi, the value of Phase 1 (view telemetry on video) is real but limited. He already has Strava for data analysis. The unique value is the visual context — seeing the road, feeling the moment, understanding why the numbers look the way they do at that specific point.

For Phase 2 (automatic short generation), the value is clearer. He mentioned wanting to compare "a day when I feel slow" versus "a day when I'm flying" on the same road segment, with metrics visible. The ability to produce those comparison clips automatically would be something he'd pay for.

Unexpected Use Cases

Santi suggested two use cases I hadn't considered:

Cycling tours and events. Companies like Thomson organize amateur cycling experiences on professional routes (Tour de France stages, Stelvio, etc.). Participants would love to have their ride data overlaid on video — "Look, I climbed Alpe d'Huez at THIS heart rate." Event organizers could offer SportsSync integration as a premium add-on.

Training analysis with coaches. If Santi had a coach, the coach could review specific video segments with telemetry to identify where technique breaks down. "You were at 230 watts here but should have been at 280 — let's look at your pedaling form in the video." This is coach-facing value, not just rider-facing.

The Commitment

Santi committed to a real-world test: recording the same road segment on three different days — one when fatigued, one when fresh, one normal — and synchronizing all three in SportsSync. This gives him a direct comparison of how his metrics differ based on condition, all on the same route.

This is exactly the kind of organic usage that validates a product. Not because I asked him to test it, but because he saw a personal use case and wants to explore it.

What I Learned

Five takeaways from 45 minutes of user research:

1. Vertical video support is non-negotiable. The target audience records in 9:16 for Instagram. If SportsSync can't handle portrait video, it's missing the primary content format.

2. Analysis > Sharing. I built for sharing. Users want analysis. The sharing comes after — once they understand their ride, they share the interesting parts. The product needs to serve the analysis use case first.

3. Power meter compatibility varies. Different hardware brands format GPX data differently. The parser needs to handle Garmin, Wahoo, Favero, Stages, and every other major brand's XML extensions.

4. The YouTube requirement is friction. Requiring users to upload to YouTube before they can use SportsSync adds a step that doesn't serve them. Direct video upload (even if stored temporarily) would dramatically reduce onboarding friction.

5. The slope/gradient overlay adds critical context. Without gradient data visible on the video, the telemetry numbers lack explanation. Why is heart rate at 174? Because there was a hill 30 seconds ago. The gradient connects the effort to the terrain.

Series Conclusion

Thirteen episodes. From an idea validated with Claude to a working application with real users. The journey covered brand design, landing pages, GPS data debugging, FFmpeg architecture, code migration, and finally — talking to an actual human about whether any of it matters.

The answer is yes, with caveats. The product has value, but not exactly the value I assumed. The sharing use case is real but secondary. The analysis use case is primary but under-built. And the entire vertical video format was a blind spot.

Building in public taught me something I couldn't have learned building in private: your assumptions about your own product are always wrong in ways you can't predict. The only fix is putting it in front of real people, early and often.

What's next: fix the vertical video support, expand GPX parser compatibility, build the gradient overlay, and schedule nine more user research sessions. The product isn't done. It's just starting.