Technical product manager / Voltera, previously Deep Trekker
Mechatronics engineer turned product manager.
I ran Deep Trekker's portable pipe inspection line, about a quarter of company revenue.
When a handful of units came back with a failure we could not reproduce, I removed the feature sales had
led with for years. Now I'm at Voltera, doing 0‑to‑1 discovery on rapid
electronics prototyping.
I spent a week stuck on the last 2% of a PID loop for an aquatic drone. Then I heard shouting from the
production floor. A controller had shipped uncalibrated, and the complaint had amplified as it went:
from the customer to support, from support to sales, from sales to the line manager. I took half an hour and wrote a popup: an uncalibrated
controller now fills its own screen with a warning and instructions. QA would see it. If QA missed it,
the customer would see the same thing and could sort it out. The problem never came back.
Half an hour was worth more than the week I spent on that 2%.
Difficulty and value, it turns out, have little to do with one another. That's what moved me toward product.
Grant secured
$400K
The IRAP grant I won and managed. One funding line inside a much larger project budget.
Share of company revenue carried by the portable pipe inspection line, which I owned.
Discovery rate
83 / 2 mo
Voice of Customer interviews for a 0-to-1 product.
Casework01 to 03
01Deep Trekker Product Manager, 2021‑25 Pipe inspection line
I killed our main differentiator over a failure rate too small to act on.
The moat
For years our moat was a drivetrain that designed out the most common failure point on a machine of this
type. Competitors took the conventional route, which works until it doesn't, and when it doesn't you have
an immobile robot in a live sewer and an operator wondering whether he did the maintenance right.
The previous generation proved it out: effectively maintenance-free, no failures on that path in the
field. It's what sales led with and it's what customers paid for.
What went wrong
Then we launched a successor. Same architecture, tighter package. An assumption that had held comfortably
in the older, roomier design stopped holding once everything moved closer together. Units started coming
back with the drivetrain seized, sometimes taking more with it.
The tricky part was it was impossible to reproduce in house. We ran accelerated cycles under the
conditions we thought were responsible and never saw the failure. We spent about two months trying to
save the architecture: shields, geometry changes, reorienting components. Every iteration helped some
units. None of them closed the failure mode.
The fork
Then I looked at the rate. It was in the low single digits, on a small production batch. Not normally a
number you act on, especially when acting means destroying your own moat.
And here's the thing: the money wasn't the issue. Repairs were cheap and the total sat in the low
thousands. Nothing on the P&L was forcing my hand.
But the pipe inspection community is well connected. Everyone knows everyone and everyone talks. A
handful of unhappy contractors cost you more than a handful of sales.
And mind you, these guys are direct. They are either five-star or one-star reviewers. Soon enough we were
hearing about it from customers who hadn't bought yet.
The call
I moved the platform onto the conventional design. Which meant telling a sales team that had spent years
selling the thing we were about to remove that our newest product would ship without it.
It wasn't well received. But we aligned that reliability is what ultimately mattered, as long as we were
upfront about the trade-offs either way. The drivetrain was modular, so customers could still pick and
choose.
A maintenance routine published immediately, so customers already working could keep working.
Free swaps for affected customers.
A service notice to every owner of the platform, including the ones who hadn't failed, so they could inspect their own units.
Of course we don't want to advertise our own oversights. But customers actually appreciated the
transparency, especially the ones who hadn't had issues yet.
What I took from it
Process
I inherited a proven architecture and treated the new model as a repackaging exercise. I called it low
risk and didn't test it thoroughly enough across different environments.
Strategic
At the end of the day customers care about a robot that doesn't die in a pipe. They don't care how the
torque gets to the wheels. We had confused the mechanism with the value. Once I separated those two,
the decision stopped being painful.
PrototypesSide builds
Small builds I use to see how an interaction behaves before writing a spec around it. Both are
camera-based and both run locally.
PostureCorrector
Posture feedback that runs in the browser.
MediaPipe Pose, running client-side. You calibrate once, it corrects you as you go, it ties stretch
prompts to a Pomodoro timer, and it keeps a history you can look back at. The video never leaves your
machine.
Deep Trekker products I worked on that are public and still for sale. Some of it was roadmap, some was
launch, some was firmware. A lot of it was field feedback.
Pipe Trekker
A-200 crawler
Launched 2022, the first genuinely portable pipe inspection system on the market. Competitors followed with portable equivalents of their own.
I ran training for a public-sector customer in Korea. Their machines kept failing, and the reason wasn't
the machines. Operators rotated out constantly, so nobody stayed long enough to learn them and the
knowledge left with whoever left. We worked with a local channel partner to build training material the
next rotation could actually use.
I did the same thing in Chile, that time through a Deep Trekker subsidiary, and I've run field work in
the United States and Canada as well. I'm Korean, was born in Mexico and grew up there until high school,
have lived in Canada since university, and have basic Japanese. In practice it means I'm used to working
through translators and local partners.
Before productArchive
I led firmware at Deep Trekker for two years before moving into product: STM32 F-series, motion control,
PID and sliding mode and Kalman filters on wheeled robots. Before that, mechatronics at Waterloo: FEA and
fatigue analysis, CATIA and SOLIDWORKS assemblies, design for manufacture, an automated cutting rig, drone
controls fixtures, and a MasterCAM tutorial book I wrote for high school students.
Senior or technical product management, on hardware-software products.
AI, robotics, hardware-software systems, and developer tools. I'm best on products where the hardware,
the firmware, and the field conditions all constrain each other.