I joined Subterranean as product and commercial lead knowing almost nothing about robotics.
To get up to speed, I spent time with the engineers and leadership understanding the problems they were trying to solve, until I knew enough to sit inside the technical conversations and ask a different set of questions. That’s not a one-off thing I did at Subterranean. It’s the way I work on any technically ambitious product.
Subterranean flies drones into live sewers to capture LiDAR and video, instead of sending down a person or a crawler robot. No GPS, no light, radio signal that dies when the pipe turns a corner. The team has now run more than 400 of these surveys. The engineering is genuinely hard, but I didn’t need to become an engineer to meaningfully contribute.
Once I understood the problems well enough, two things became possible.
First, I could see where the story we told customers didn’t match what they actually valued. The team talked about drones and flight paths. Customers were buying access to information about their own infrastructure they’d never had before. They were buying data. We changed the story, and conversations moved away from how the survey happened and toward what customers could now know that they couldn’t before.
Second, I could ask a different kind of question about what to build next. The team had built mesh radio tech to extend flight range, and a prototype camera, both technically impressive. Neither was a bad idea on its own terms. My question was whether either was solving a problem customers were actually going to pay to have solved, or whether it was solving a problem the team found interesting.
That question had practical consequences. Rather than let a backlog of “would be useful” work keep growing, I stopped the team building things we weren’t confident anyone wanted, so the engineering time that was left went toward work with a customer already waiting on the other end of it.
That’s the role I’ve found myself playing on technical products: getting fluent enough to hold my own in the technical conversation while still asking the commercial question underneath it. If we can build this, what does it actually make possible, and does anyone care?
I’ve watched the same gap open up on other technical teams. Strong product, difficult engineering, plenty of ideas about what could be built next. Features accumulate, the backlog grows, and eventually the product can outpace not only the customer’s understanding of the offering, but the team’s understanding of why they’re building it.
What’s often missing isn’t more technical expertise. It’s someone who understands the technology well enough to challenge where it’s going without becoming so absorbed in it that they stop asking who it’s for.