Support Taught Me Product Engineering Before I Knew the Word

The product engineer checklist opens with an instruction that made me laugh: engineers should talk to users before writing code. Demand it, even. Support the team in finding out who the user is and what hurts.

I talked to users for four years. We just called it support.

From the end of 2020 into 2025 I worked support at WPManageNinja, the last year leading it. Fluent Forms, WP Social Ninja, Ninja Tables, FluentCommunity, plugins running on more than a million active websites. When the checklist asks “Who’s the user?”, my answer comes from the queue: the user is the person who writes to you at midnight because their form broke and a client is waiting. You learn what delights them and what pains them because they tell you, every day, sometimes in capitals.

What a Thousand Tickets Teaches You

The checklist makes a distinction most engineers skip: the user is not always the customer. The person who uses your product and the person who pays for it are often different people with different problems. In the WordPress plugin world you feel that split in every second ticket. The site builder wants it flexible. The license holder wants it to just work.

Support also teaches you the third question before you know to ask it. “Why is this important?” Every angry ticket is a product decision that failed somewhere upstream. A confusing setting, a missing error message, an update that broke a workflow people actually relied on. You start reading the queue not as a list of problems to close but as a running commentary on the product’s judgment.

There’s a line in the checklist about testing the product yourself instead of relying on others to find issues. Support is that, at industrial scale. Everything we shipped, users tested for us. The feedback loop just had a real cost attached, measured in tickets and reviews.

The Part Support Didn’t Teach Me

I don’t want to romanticize it. Support teaches you what’s broken and why, but it doesn’t teach you to build. I kept writing code on my own time, JavaScript mostly, and stayed up to date with the modern stack. But knowing what’s wrong and being the one who ships the fix are different muscles, and the second one needed deliberate work. That’s a different story for a different post.

And the checklist is honest about the limits too. Knowing the user isn’t a free pass into product decisions. You earn that seat by shipping things, showing up with proposals instead of complaints. Support gives you the raw material. It doesn’t build the track record. Only building does.

Why the Title Change Made Sense

When I moved into product engineering at Themefic, people asked what actually changed. The stack, partly. But the bigger change was permission. Everything I’d learned in the queue about what users struggle with, the questions the checklist wants engineers to ask, why this feature, why now, for whom, finally had somewhere to go.

The three questions the checklist ends with, “What’s the problem? For who? Why is this important?”, read to me less like a new framework and more like a job description for the thing support engineers already do, pointed finally at the code instead of the inbox.

If you’re in support now and quietly learning how products fail: that’s not a detour from product work. It’s the part most product people have to simulate with surveys. You got it live.

The checklist is here. Twenty minutes, worth it, and the chapter on earning trust is the most honest part.