I call my previous work "product engineering" because, in my mind, there's product work and infrastructure engineering. That breakdown helps you separate whether you're working on customer-facing parts of the application, or whether you're helping support all of the product engineers.
This work was critical for me to become a successful developer advocate, in my opinion, because I can emphasize with developers. I've seen that massive codebase with spaghetti code that no one wants to touch. I've been in those difficult conversations where you're deciding where to cut scope, where to make sacrifices, and how you compromise and iterate forward.
This experience helps me dig deeper when folks ask questions and give more pragmatic recommendations. For example my latest video, "Should you learn JavaScript before React?".