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
RoadmappingSprint ExecutionFunnel Design
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.