MY ROLE
DURATION
CONTRIBUTION
SCOPE
I spent sixteen months as a product designer and design strategist at FASTER, a pre-seed startup developing a consumer wearable for large-scale emergency response. I was the only product designer on a team of twelve, working alongside the founder, CTO, hardware and firmware engineers, and an external mechanical consultant. Much of my role was holding the product between legitimate but competing demands: what the founder believed it should become, what engineering could support, what manufacturing could produce, and what the business could afford.
The founder’s orientation was expansive. New features, material preferences, form-factor questions, and changing use cases entered the project continuously. The CTO’s was compressive: reduce cost, simplify tooling, minimize secondary processes, and justify every manufacturing decision. Between them were component requirements, molding tolerances, manufacturer minimums, hardware revisions, and an investor timeline that kept the product moving faster than individual decisions wanted to move. My job was not simply to respond to those pressures, but to maintain a coherent design direction through them.
DECIDING WHAT THE PRODUCT NEEDED
One of the clearest decisions came when the original depressible-bezel interaction failed. Its geometry could not reconcile the required shore hardness, crack resistance, and waterproof integrity at the enclosure joint. What initially appeared to be a mechanical problem became a broader design question: whether the interaction itself was worth preserving under those constraints.
I recommended ending the direction and replacing the tactile mechanism with capacitive touch, using a coil positioned beneath the bezel apex. The new architecture cost less than the switch it replaced, eliminated mechanical depression and wear, required no additional manufacturing process, and preserved the waterproof joint. I presented the CTO, firmware engineer, and hardware engineer with a written rationale spanning interaction, cost, manufacturing, and implementation. The team adopted the change. Constraint did not merely simplify the design; it produced a better relationship between the enclosure and the behavior it supported.
A second decision concerned the wristband retainer. We considered developing a proprietary mechanism to increase tamper resistance and create a stronger IP position. I argued against it. The proposed mechanism added cost, complexity, and development time to solve a condition the system could already detect digitally when the wristband separated from its provisioned device. We retained the standard mechanism. The product did not need a physical solution to a condition it already understood through software.
These decisions came to represent what professional product design inside the startup demanded from me: technical reasoning, manufacturing judgment, negotiation, systems thinking, and the ability to argue for what the product needed without losing sight of what the business could bear.
WHAT THE FRAMEWORK MADE VISIBLE
The experience also clarified what the commercial product-development framework is, and is not, organized to answer. Its priorities are coherent and necessary: How do we build this? What will it cost? What will it take to ship it? Answering those questions well requires real design skill, and the consequences of answering them poorly are immediate.
What I found less structurally represented was a different order of question: not only how a product functions, but how it is experienced; not only what it does, but what it does to the person who lives with it. This was not because the people around me were indifferent to those questions. It was because the development process had established ways to produce evidence around cost, manufacturing, usability, and technical performance, while experiential questions remained easier to hold as intentions than as inputs to a decision.
Those questions were already present in my work, but often privately, occasionally surfaced with the founder, and consistently subordinate to the pressures of development. Working inside that system with full commitment showed me that bringing them forward requires more than conviction. It requires methods capable of producing evidence about lived experience that a development team can act on.
That is the practice I want to build inside industry rather than beside it: bringing questions of lived experience into the same decision making as cost, manufacturing, usability, and performance.
↑
back to top
made by me for you, 2026