Every time I begin a project in a new field, there is a period when I must learn its language.
In one project, the important terms are bristle geometry, DNA yield, and transport medium. In another, they are residuals, sensor drift, and ammonia. Then suddenly I am thinking about torque inside an industrial mixer or what rescue equipment needs to withstand after a building collapses.
Learning the terminology is usually the easy part. The harder part is understanding what counts as evidence, what counts as failure, and what “working” means within each system.
A clinician, an engineer, and an operator may describe the same problem differently because each experiences a different part of it. Building products across several technical fields has taught me that product development often depends on translating between those perspectives.
Projects rarely begin as perfectly defined engineering questions. They begin with observations.
The printed parts are brittle. The procedure is too invasive. The sensor reading looks wrong. Something is not working, but that first observation rarely tells you exactly what needs to be built.
The first translation is turning the observation into a problem you can investigate.
While developing re:store, the visible failure was happening inside the printer. That made the printer the obvious place to look. Instead, we found that the filament was absorbing moisture while sitting in storage. It was already compromised before it reached the machine.
Once we expanded the boundary around the problem, the project changed. Instead of asking how to correct the printing process, we began asking how to preserve the material before printing started.
The next translation is turning a complex system into something measurable.
With HydroTwin, an unusual ammonia reading could mean that an aquaponic system was entering a dangerous state. It could also mean that the sensor was drifting. Both explanations appeared as the same number on a screen.
The challenge was not simply collecting more data. It was finding an independent way to decide which explanation to trust. HydroTwin uses relationships within the water chemistry to estimate what the ammonia level should be, then compares that expectation with what the sensor reports.
The result has to do more than produce a prediction. It must support a decision: trust the reading, suspect the sensor, or investigate the biology.
Then comes the translation from technical performance into a real workflow.
With ORCADE, collecting enough DNA was only one definition of success. The device also needed to remain non-invasive, make sense in the hands of a provider, preserve the sample during transportation, and reduce the opportunities for loss or contamination.
A prototype can perform perfectly on a workbench and become impractical as soon as another person has to use it. The product does not end with the central technology. It includes the environment, the workflow, and the decisions surrounding it.
The same principle appears differently in every field. Disaster-response equipment cannot depend on careful setup or ideal conditions. A waste-management system cannot assume that people will change their behavior to accommodate it. A carbon measurement may be technically accurate while the policies surrounding it prevent the communities protecting that carbon from benefiting.
The technology changes, but the product still should fit into the world around it.
For a long time, I thought moving between fields meant repeatedly starting over. In some ways, it does. Every new area comes with knowledge I do not have yet, assumptions I may not recognize, and people who understand parts of the system far better than I do.
But starting over is not the same as starting from nothing.
The technical answers rarely transfer. The process does.
Understand how different people experience the problem. Expand the system until its real constraints become visible. Turn uncertainty into something measurable. Build a prototype that can challenge an assumption. Then translate what you learned into something another person can actually use.
That is why I no longer see working across fields as moving away from a single path. The connection between these projects is not a shared technology or industry. It is the kind of problem-solving they demand and the process of turning unfamiliar systems into products that can work beyond a controlled test.
You do not need every problem to resemble the one before it. What matters is knowing how to enter an unfamiliar system, understand what its different parts are saying, and translate between them until something useful can be built!