How I earned the nickname "Captain Unreasonable" by refusing to ship a smoke alarm that would accidentally blast its self-test at full volume during setup — and what changed because of it.
Gentex is a $2B+ publicly traded company that has spent decades building products for automotive OEMs. In that world, the customer hands you requirements, systems engineers translate them into specs, and engineering executes. There is no product management function. There is no user research. Requirements come from the customer, and you build what they ask for.
PLACE was Gentex’s first direct-to-consumer product. Suddenly there was no OEM handing over a spec sheet. The “customer” was a homeowner who would never write one. And the organization had no muscle memory for figuring out what that person actually needed.
I was hired as the Technical Product Manager for PLACE. Honestly, I didn’t fully know what a product manager did when I took the role. I came from eight years of embedded engineering where I’d developed product sense, but I’d never formally practiced the discipline. Gentex hired me because of an unusual background: a film studies degree from Michigan (creative thinking, storytelling, writing) combined with an electrical engineering degree and years of shipping firmware for medical devices (analytical thinking, technical credibility). They were betting that combination would be useful. They were right, but it took a minute.
I joined mid-development cycle. My intuition told me something was off almost immediately, but it took months of reading (The Right It, Build, Continuous Discovery Habits, The Mom Test, all three of Cagan’s books, and more) before I could put words to what I was seeing.
What I was seeing was this: decisions were being made without ever asking how they would benefit a real user. “Good ideas” were being engineered into a product that fell apart the moment you asked a simple question.
For example: one of the PLACE models is a $350 nursery unit with a built-in camera, intended to double as a baby monitor. Sounds great on paper. But the camera can’t be aimed, has a wide-angle lens, and 98% of smoke alarms are installed right inside the doorway because that’s makes for the shortest runs of Romex. So the camera is pointed at the floor inside the door, not at the crib across the room. A $350 baby monitor that can’t see the baby.
Or the mounting bracket: PLACE is a square device with rounded corners. The bracket has fixed screw holes with maybe 15 degrees of rotation. Depending on where your junction box sits, it’s often impossible to make the device look square on the wall. User testing revealed this, but hundreds of thousands of brackets had already been manufactured. There was no turning back.
These weren’t edge cases. They were obvious problems that would have been caught earlier if anyone had asked a user to try the product before committing to tooling. Nobody had, because that wasn’t how things worked here.
I won’t pretend I showed up with a PM playbook. I read voraciously and applied what I learned in real time. The Right It by Alberto Savoia taught me to validate ideas before building them. Teresa Torres gave me the framework for continuous discovery. Tony Fadell’s Build showed me what product obsession actually looks like. Marty Cagan’s books gave me the vocabulary for what was broken and what “good” looked like. I was building the plane while flying it.
The moment I graduated into being a true Product Manager came in the final month before cutting the firmware release for certification.
The device has a capacitive touch button that triggers a menu system. The HMI designed by the systems engineers worked like this: hold the button 1-3 seconds and release for a self-test, 5-7 seconds for Bluetooth pairing, or 9-11 seconds for a factory reset. The only indication of where you were in the menu was flashing LEDs. No voice prompts. No countdown. No way to cancel.
The self-test triggers a 79 dBA, 520 Hz low-frequency sounder at full volume. It is designed to wake deep sleepers and children. It goes off like a bomb in your hand.
I had accidentally triggered it countless times at my desk. Bluetooth pairing is the very first thing a new user needs to do when installing the device. Imagine a homeowner at the top of a ladder, trying to pair their brand new smoke alarm, and instead setting off an air-raid siren in their hands with no warning and no way to stop it.
I put this at the top of my “show stopper issues” list. The engineering team said it was too risky to change this late. My uplines were skeptical it was needed. The systems engineers who designed it thought I was sticking my nose where it didn’t belong.
So I built my own user study. Armed with a battery-powered device, a full printout of the user manual, and my cellphone camera, I walked the halls of our building looking for guinea pigs. I handed each person the device and the manual and asked them to put it into Bluetooth pairing mode.
Out of 9 participants, 6 accidentally set off the full-volume self-test.
I brought the data to a meeting with the VP of Engineering, VP of Product, and several directors. I presented the results. I was met with skepticism. “They’ll read the manual. It’ll be fine.”
So I handed the VP of Engineering the device and the manual and asked him to put it into pairing mode. He flipped through a few pages, got bored, hit the button, and set the alarm off in his own hands.
I think I pissed him off. But we fixed the issue.
We implemented a full voice menu system with clear instructions, warnings that the self-test is loud, and a countdown that allows the user to exit before the sounder fires. The engineers dubbed me “Captain Unreasonable” because I refused to back down. I consider it the highest compliment I’ve received in my career.
Winning the argument was one thing. Executing the fix was another.
After getting buy-in from the VPs, I enlisted UX designers to rework the HMI and pulled the firmware engineers into the review process early. The systems engineers who would rewrite the requirements joined too. Over several workshop sessions, we hammered out a workable plan with a timeline. There was tension: the systems and firmware engineers pushed to make as few changes as possible, and I refused to budge on the user experience being central. That tension is what earned me the nickname.
But the plan worked. Engineers initially estimated six sprints. After the workshops, they revised to four. They shipped it in three. When I ran a brief retro and asked why it went faster than expected, the answer was simple: having the plan upfront, with buy-in from all parties, let them execute efficiently instead of second-guessing scope along the way.
That was the seed. The real turning point came several months later, on our first post-launch feature delivered via OTA update.
On OTA1, the organization ran the only script it knew: waterfall. A one-sentence feature description went out and five disciplines each built their own interpretation of it. When the work came together, the misalignment was obvious. The firmware engineers agreed the UX approach made more sense for users but felt bound by baselined requirements — a process designed for automotive programs where stability matters, now acting as a straitjacket on a consumer IoT product.
I told them: “If the requirements are wrong, we will change them. What matters is getting the feature right.” The idea that they could push back on baselined requirements seemed like a revelation to engineers who had just called me Captain Unreasonable.
That debacle made the case for a new process better than any presentation could. I started organizing twice-weekly Discovery Workshops: all five disciplines in the room before anyone starts building, collaboratively defining features from the start. The format has since been adopted by two other product lines at Gentex. The full mechanics are in Case Study 03.
I also authored a Product Development Strategy document emphasizing continuous improvement over the ship-once cadence the automotive side was used to, and started a PM book club across the product management and design teams.
I’d bring the Discovery Workshops in from day one. The first year was a series of individual battles: fighting for this usability fix, pushing back on that requirement, making the case one issue at a time. Each battle built credibility, but it also burned goodwill and made change feel adversarial. The Double Diamond process proved that when you get everyone in the room early, alignment happens faster and engineers become advocates instead of resistors. If I’d had that framework from the start, the mounting bracket and nursery camera problems might have been caught before hundreds of thousands of units were manufactured. The lesson: don’t just fight for better outcomes. Build the process that makes better outcomes the default.
The other thing I’d push for earlier is a quarterly release cadence with explicitly defined outcomes and success KPIs for each quarter. The Double Diamond process gave us a way to define features well. What it didn’t give us was a forcing function for deciding which features matter most right now, and how we’d know if we shipped the right thing. I’m working on establishing that cadence now, and getting organizational buy-in has been slow. But the resistance itself is instructive: in a company that’s never had a PM function, even the concept of outcomes-based planning is a shift in how people think about what shipping means. That’s a harder change than any single process fix.