Technical PM · 0 → 1 XR · Mobile · Consumer Scoped · Shipped · Measured

Flowmersion:
Technical Product Lead,
Zero to Live Users

Technical product lead on a pre-launch XR snowsports startup. Owned the product lifecycle: scoping the onboarding system, coordinating engineering, shipping the conversion funnel, and measuring the results. It went from a broken signup flow to a live, instrumented funnel.

SmartRide Dashboard
Onboarding
Analytics
Flowmersion
XR SNOWSPORTS · MOTION INTELLIGENCE PLATFORM
PRODUCT STATUS
LIVE · WAITLIST OPEN
SMARTRIDE V1 DEPLOYED
−30%
signup friction
+40%
flow completion
+35%
demo conversions
−30%
Signup friction reduced
+40%
Onboarding flow completion
+35%
Demo and waitlist conversions
Role
Technical PM & Dev Lead
Timeline
2024
Organization
Flowmersion · Remote
Type
0→1 · Consumer · Mobile-first · XR
Product System · What I scoped and owned
Roadmapping Sprint Execution Funnel Design
PRODUCT FUNNEL · OWNED END TO END Landing Page single primary CTA → join waitlist only Signup Flow 2-field form only email + riding level SmartRide Demo in onboarding path not behind nav Confirmation → community invite not a dead end ROADMAPPING ENGINEERING DIRECTION PRODUCT DECISION CONVERSION DESIGN Scope → Prioritize → Coordinate engineering → Ship → Measure → Iterate Before 5-field form · competing CTAs demo buried · mobile not optimized After 2-field form · single CTA demo in funnel · mobile-first
Context

Vision in place, no product execution.

Flowmersion builds motion-capture technology for snowsports: real-time feedback on your riding technique, delivered through an XR experience. When I joined, the technology was in development, a website existed, and there was a vision. What was missing was product execution: a roadmap, an onboarding system that didn't lose people halfway through, and a funnel that converted interest into waitlist entries.

I joined as technical product lead. In a pre-launch startup, that means owning every product decision from roadmap to sprint to ship. There was no other PM; engineering decisions waited on me.

Execution Phases

How I ran the program.

Phase 1
Discovery & Scoping
Mapped the existing product, identified the broken funnel, and defined scope for sprint 1. Set success metrics before writing a line of spec.
Phase 2
Roadmap & Sprint Structure
Built a prioritized roadmap with clear acceptance criteria. Ran sprint planning with engineering: scope, estimate, commit. No vague "improve X."
Phase 3
Build & Coordination
Directed engineering execution. Unblocked decisions in real time. Reviewed implementations against spec. Kept scope tight when new ideas surfaced.
Phase 4
Launch & Measurement
Shipped to live users. Instrumented the funnel. Measured against the metrics set in Phase 1. Iterated based on what the data showed.
The Product Problem

The original funnel was losing people.

Before: What I Inherited
  • Competing CTAs on the landing page, no clear primary action
  • 5-field signup form with required fields that users were abandoning
  • Demo buried behind navigation, not in the onboarding path
  • Confirmation page that ended in a dead end: no community hook, no next step
  • Not optimized for mobile, the primary use case for this product
After: What I Shipped
  • Single primary CTA, join waitlist. Everything else secondary or removed
  • 2-field form: email and riding level. Get them in the door first
  • SmartRide motion demo built into the onboarding path
  • Confirmation triggers a community invitation. Waitlist becomes membership
  • Mobile-first layout: designed for the phone, then adapted up
Product Decisions

The decisions behind the numbers.

Mobile-first, not mobile-adapted
Designing for a 390px viewport forces you to decide what must be there and what can be cut. That produced a tighter product than designing desktop-down would have.
Demo as part of the funnel, not a separate feature
Moving the SmartRide demo into the onboarding path turned it from a feature people might find into a moment that reinforced why they just signed up. Demo → confirmation went from a dead end to a conversion hook.
2-field form over "collect everything upfront"
Collect the minimum required to get someone in the door, then ask more once they've committed.
Confirmation as community membership
Converts a passive waitlist spot into an active community membership with a next step. One copy update, but a qualitatively different relationship between the user and the product.
What I Learned

What I took from it.

01
At pre-launch, the funnel is the product
How someone experiences signing up is the product for most early users. They never get further. Treating conversion optimization as separate from product engineering was the original mistake. Fixing it meant owning both at once, which is what a technical PM does.
02
Prioritization is the hardest engineering decision
With a small team at pre-launch, the most important decisions weren't technical. They were about what to build and what to cut. Getting that right required an explicit model of what success looked like before the sprint started, not after it ended.
03
Accountability without authority is the PM condition
I owned the outcomes: conversion, completion, signups. But I had no direct authority over engineering execution. Getting things done in that structure required clear specs, fast decisions, and a relationship with engineers built on clarity rather than command. That's the actual skill.
Back to the beginning
Production AWS Intelligence Pipeline