What it looks like to be genuinely user-driven inside a company that has never had to be, and why it matters more on a safety product than anywhere else.
My LinkedIn subtitle says “I Fight for the Users.” That’s not a slogan. It’s the job description I’ve given myself at a company where the job description didn’t previously exist.
Gentex spent decades building products for automotive OEMs. The customer handed you requirements. You built what they asked. There was no end user to fight for because the end user was never in the room. PLACE changed that: Gentex’s first direct-to-consumer product, a safety device that goes into people’s homes, that wakes their children when there’s smoke, that a father expects to work correctly when his family is in danger.
The stakes of getting this wrong are different on a smoke alarm than they are on a productivity app. You don’t ship a “minimum viable” fire detector. And you don’t treat a user complaint as a support ticket to be closed.
When I joined, the organization had good intentions and no muscle memory for what user-driven actually looked like in practice. I’ve spent two years trying to build that muscle, mostly by being the person in the room who keeps asking the uncomfortable question: “But what does the user actually experience?”
I monitor online communities, reviews, and forums continuously. Not through a dashboard. I read the posts.
A user named getchpdx showed up in a Reddit thread about Nest Protect alternatives. He had eight PLACE devices. Four had been faulty. He was dealing with non-stop false alarms, a support experience that kept redirecting him to Home Depot, and a feature gap that particularly bothered him: when an alarm triggers, only the detecting unit announces the problem. Every other unit in the house just blares a horn. He described running up and down the stairs at 3am trying to figure out which alarm was “mad.”
That specific complaint, stated plainly by a frustrated real user, moved up the roadmap. Voice announcements of the alarm type across all interconnected devices, and voice alerts for caution mode, got reprioritized. Not because a stakeholder pushed for it. Because getchpdx was right.
I recruited users directly through the app for open-ended interviews conducted with our UX researcher. The insights were sometimes validating, sometimes uncomfortable, always useful.
One user described the product as “half-baked.” He wasn’t wrong about that either. He said he didn’t mind being a beta user but he’d paid full price, and the product didn’t have the refinement he expected. That framing went directly into how I talked about the ratings problem internally and why I argued against scaling marketing spend before fixing it.
The interview I think about most was with a father about my age. I already knew his story: his support ticket had been forwarded to me. Multiple false alarms in the same night. I’d read it, noted it, moved on.
Hearing him tell it was different. His wife woke up. His young child woke up. His dog woke up. He described his kid’s reaction in the way that parents describe things that scared their children: carefully, with the specific details you remember because you felt helpless. Reading a support ticket tells you what happened. Talking to someone tells you what it was like.
A false alarm is a defect. Hearing one parent describe what that defect felt like at 2am, with a two-year-old in the house, is not the same as reading a ticket summary that says “multiple false alarms, customer upset.” I knew about the problem before the interview. I understood it after.
I told him I’d share his story with the team. I did. Not as a data point. As a story.
Product discussions at Gentex can drift: toward engineering preferences, internal politics, what’s feasible, what’s been done before. I try to be the person who brings it back.
Recently, in a meeting that was getting contentious, I kept making arguments grounded in what was best for the product and for the users. My boss later relayed that our director had noticed. He said he was impressed that I kept coming back to that ground when the conversation was pulling elsewhere. That mattered to me because it’s the kind of thing that only works if people notice you doing it consistently, not just once.
My VP has been heard quoting back the product vision statement I wrote unprompted: “become a smart smoke alarm everyone can truly love.” When the person above you starts using your language to make arguments, something has shifted.
Individual interviews and Reddit monitoring are necessary but not sufficient. I built the infrastructure to do this continuously: automated scraping across twelve subreddits, Home Depot review monitoring for all four PLACE models, in-app surveys for CSAT, roadmap prioritization, and how users discovered PLACE, live user interviews recruited via the app.
The goal was to make sure user feedback wasn’t dependent on me having time to look for it. The system surfaces it. I still have to read it and feel it.
Get to the live interviews faster. The automated monitoring is good for breadth. It catches patterns. But a single 30-minute conversation with a real user who has your product in their home is worth dozens of scraped Reddit posts, because the human context changes how you hear it. The father’s false alarm story hit differently than a one-star review saying the same thing, and I acted on it differently too.
I’d also invest earlier in closing the loop with users who take the time to complain publicly. getchpdx wrote multiple detailed comments about specific failures. There’s no good reason he shouldn’t have heard back from someone at PLACE. We didn’t have the infrastructure or the process for that when he posted. We’re still building it.