Support Taught Me Product Engineering Before I Knew the Word

The product engineer checklist has an instruction that made me laugh: engineers should understand their 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 more than 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 useful distinction: the user is not always the customer. The person who uses your product and the person who pays for it can have different priorities. In WordPress support, that might mean helping a site builder configure a form while their client cares about whether inquiries reach the business. Understanding the configuration is only part of understanding the problem.

Support also gives you reasons to ask, “Why is this important?” Recurring tickets can expose friction upstream: a confusing setting, an unclear error, or an update that broke a workflow. Other tickets come from configuration mistakes, third-party conflicts, or expectations the product doesn’t meet. The useful work is figuring out which problem you’re looking at before deciding what should change.

There’s a line in the checklist about testing the product yourself instead of relying on users to find issues. Support showed me the cost when problems reached customers: interrupted work, more troubleshooting, and sometimes a loss of trust. Those conversations made the case for testing workflows ourselves before asking people to depend on them.

What Changed Beyond Support

I’d worked as a WordPress developer before moving into support, and I continued writing code. Hotfixes, workarounds, and helper add-ons were part of solving customer problems. Support and development overlapped in my work.

Product engineering expanded that responsibility to deciding what to build and owning how it worked. Understanding a reported problem helped, but I also had to weigh possible solutions against the wider product and the effort involved.

The checklist’s section on earning trust matters here. Knowing customers gives you something useful to contribute; you still have to turn that knowledge into thoughtful proposals and follow through with the team. A repeated request is evidence to investigate, not an instruction to add a feature.

Why the Title Change Made Sense

At Themefic, my scope expanded. What I’d learned in the queue had already helped me troubleshoot issues and work with engineering on recurring problems. Now that knowledge also shaped questions earlier in the process: why this feature, why now, and for whom?

The checklist’s three central questions, “What’s the problem? For who? Why is this important?”, felt familiar from support. Product engineering gave me broader responsibility for acting on the answers.

Support gave me direct access to problems people cared enough to report. It also gave me a partial view. The queue couldn’t tell me much about satisfied users, people who left without contacting us, or those who never adopted the product. Research and usage data help fill those gaps.

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