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.
Team
10 eng
Electrical, mechanical, firmware, frontend, UI design.
Line revenue
~25%
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.

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.

Small builds I use to see how an interaction behaves before writing a spec around it. Both are camera-based and both run locally.

Demo of the PostureCorrector interface showing live posture feedback

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.

  • MediaPipe Pose
  • Runs client-side
  • Pomodoro timer
Repository
Demo of the Distraction Detector interface showing attention-state tracking

Distraction Detector

Attention tracking with a session report.

OpenCV and MediaPipe Face Mesh, on the desktop. It notices when you have looked away, plays a sound, and gives you a breakdown when the session ends.

  • Face mesh
  • Audio cue
  • Session report
Repository

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.

What I found

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.

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.

See the engineering work →

Open to

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.