Fragmented systems
Different bike controls, BLE behaviors, and firmware versions made consistency difficult.
HYENA RIDER ASSISTANT · PRODUCT DESIGN & MANAGEMENT
Stabilizing core experiences.
Building rider trust.
I grew from Product Designer to Product Manager, bringing app, firmware, and hardware teams together to improve pairing, firmware updates, and app reliability for 50,000+ riders.
Live on iOS & Android · Ongoing maintenanceExplore the results ↓
01 / OVERVIEW
A connected product.
A complex foundation.
HRA helps riders pair an e-bike, record routes, review ride data, update component firmware, and manage maintenance across North America, Europe, and Asia.
50,000+riders
50+e-bike models
15brands
I joined during the late MVP stage, when usability gaps and technical debt affected core journeys. Every improvement had to work across different bike controls, firmware versions, and mobile platforms.
One rider experience. Several connected systems.
- AppInstructions & permissions
- BLE connectionCommunication with the bike
- HMI & firmwarePhysical controls & component behavior
- Timeline
- July 2020 – Present
- Platform
- iOS & Android
- Focus
- Core experience & reliability
- Current stage
- Stable operation & maintenance
02 / MY ROLE
From product design
to product ownership.
- JULY 2020 – MARCH 2022
Product Designer
Redesigned HRA from version 1.0 to 2.0, connecting rider needs with e-bike hardware behavior and app logic.
- APRIL 2022 – PRESENT
Product Manager
Led improvement priorities, specifications, and cross-functional delivery. After stabilization, my focus shifted to maintaining product reliability.
Turn rider signals into shared priorities.
- UnderstandInterviews, usage & support
- AlignApp, firmware, hardware & QA
- Deliver & follow upSpecifications, releases & results
03 / CHALLENGE & STRATEGY
Protect the moments
that determine trust.
Unreliable core journeys
Pairing failures, interrupted updates, and crashes prevented riders from experiencing the app’s value.
Competing priorities
Teams needed a shared view of rider impact to agree where to invest development effort.
The bike works without the app. Every interaction has to give riders a reason to trust it.
I used behavioral data, interviews, and support feedback to make the case for fixing critical journeys. Three focus areas connected the work:
- 01 / CONNECT
Pair successfully
Reach the first usable experience.
- 02 / MAINTAIN
Update reliably
Understand progress and recovery.
- 03 / RIDE
Keep the app stable
Protect the everyday experience.
Focus areas across the rider journey; not a release timeline.
04 / IMPACT OVERVIEW
More successful journeys.
A more dependable product.
PAIRING SUCCESS21% → 90%Android · Post-release follow-upView detailsFIRMWARE UPDATE SUCCESS65% → 99%AndroidView detailsCRASH-FREE USERS78% → 98%Android · Within 4 monthsView details
Historical improvement results, with platform breakdowns below.
05 / PAIRING
Make the first
connection work.
Interviews and usage data showed onboarding drop-offs. Generic instructions did not account for different startup procedures and BLE indicator lights across bike models.
I mapped pairing friction with engineering, documented each HMI’s behavior with hardware and firmware teams, and translated those rules into a shared implementation specification.
The same instruction does not fit every bike.
Less than 0.5 seconds to power on.
White status light when disconnected
More than 2 seconds to power on.
◉ Bluetooth symbol indicates connection
Hardware behavior → Model-specific instructions → A clearer next action
From generic instructions to guidance riders can recognize.
BEFORE · ONE GENERIC INSTRUCTION
Riders had to translate a generic button instruction to their own bike.
Recognize the control
Choose the HMI that matches the bike.
Follow the physical action
See the control and the required button action together.
Understand the feedback
Explain persistent flashing in context, with help available during pairing.
| Platform | Before | After |
|---|---|---|
| Android | ||
| iOS |
| Platform | Before | After |
|---|---|---|
| Android | 2m 35s | 2m |
| iOS | 1m 33s | 1m |
Onboarding retention improved by 17%.
06 / FIRMWARE UPDATES
Improve the logic behind
a reliable update.
I raised the severity of firmware update failures using observed data, then brought app, middleware, and firmware teams together to examine the update logic. A failed controller update could affect the bike’s assistance, making recovery a product priority.
01
Map failures across the system
I reviewed update data and brought stakeholders together around the severity of the problem, mapping failures across devices, app versions, and firmware types.
02
Work through failure and recovery
I coordinated discussions on update steps, failure handling, and retry behavior with middleware and firmware teams. The visible UI changes focused on clearer troubleshooting after an update failed.
03
Coordinate the delivery
I documented the agreed behavior, coordinated delivery, and shared follow-up results several months after the improvements were released.
Make each failure point discussable.
- PrepareEnter bootloader · read component info · erase flash
- Transfer & writeWrite data to cache · program flash
- Verify & returnVerify flash · return to application
Failure → Recovery path
Retry from the update page. If the app is restarted, surface the update retry prompt and guide the rider back to the update flow.
From observed failures to a measured release.
- Surface the problemUse observed update data to establish severity.
- Resolve across teamsDiscuss failure points, retry behavior, and test findings.
- Release & reportTrack outcomes and share post-release results.
v1.7.0 Success / failure tracking addedv1.7.5 Controller retry & flow improvements
View the original failure / retry sequence
| Platform | Before | After |
|---|---|---|
| Android | ||
| iOS |
Over 90% fewer support tickets
Update-related tickets fell within one month after launch.
60% less troubleshooting
After-sales field testing reported fewer troubleshooting needs following the update.
07 / APP RELIABILITY
Stabilize the foundation
riders depend on.
Android’s crash-free users rate was 78%. Crash complaints were a recurring theme in negative reviews, making stability a priority for the product.
01
Make failure patterns visible
I worked with the team to integrate Firebase Crashlytics and build a dashboard, prioritizing hotfixes by crash frequency and rider impact.
02
Test the difficult cases
I partnered with QA to expand edge-case testing, especially around BLE interactions, and set up staged releases to validate improvements progressively.
A repeatable path from crash signal to release.
- Identify & prioritizeCrash frequency × rider impact
- Fix & validateEngineering fixes · QA edge cases
- Roll out & monitorStaged releases · follow-up checks
| Platform | Before | After |
|---|---|---|
| Android | ||
| iOS |
Top 3 crash causes resolved
Crashlytics logs confirmed those causes remained resolved across two app versions.
App Store rating: 3.5 → 4.2
The rating improved during the stabilization period.
08 / CONTINUING OWNERSHIP
Keep the trust
we worked to build.
I connected rider feedback with system-level issues, aligned teams around shared priorities, and turned those decisions into measurable improvements.
DELIVERED
A stronger core experience
More successful pairing and updates, fewer crashes, and less support friction.
ONGOING
← Back to selected workStable operation & maintenance
I remain the Product Manager. Since the product stabilized, the focus has been on maintaining that stability, with no dedicated new-feature development.