From Tax Analyst to Product Lead: What Non-Traditional PMs Bring to the Table
My LinkedIn profile has a trajectory that makes recruiters do a double-take: tax compliance at a telecom company, then Director of Tax Transformation, then product lead at JPMorgan Chase. It's not the typical PM origin story.
But that non-traditional path is the reason I'm effective at building enterprise products. And I think the industry undervalues what non-traditional PMs bring to the table.
The Operator Advantage
Before I was a product manager, I was a user. Not a casual user. I was deep in the operational trenches of tax compliance, spending hours on repetitive manual workflows, dealing with spreadsheet-based processes that hadn't been updated in years.
When I started learning analytics tooling and building automations to solve my own problems, I wasn't thinking about product management. I was thinking about making my job less painful. But that experience gave me something that's hard to develop from outside: an intuitive understanding of how operational teams actually work.
When I design enterprise platforms now, I don't have to imagine what it's like to be the user. I was the user. I know what it feels like to have a system that creates more work than it saves. I know why people cling to their spreadsheets even when "better" tools exist. I know the difference between a demo that impresses stakeholders and a workflow that actually gets used on Monday morning.
Building from Zero
At Lumen Technologies, I didn't join an existing product team. I created one. I identified the automation opportunity, made the business case, secured headcount, and hired a team of 3. I was promoted twice in four years, from Tax Manager to Director, on the strength of identifying and executing on this white space.
We shipped 20+ self-service applications and eliminated 4 FTEs of manual work ($500K+ annual savings). But more importantly, I learned the fundamentals of 0-to-1 product development in the most hands-on way possible: by doing it with no playbook, no PM framework, and no one telling me what "good product management" looked like.
That turned out to be a feature, not a bug. I built products based on whether they solved real problems for real people, not based on whether they fit a framework.
The Prototyping PM
One thing my non-traditional background taught me is the value of building to prove a concept. At work, I prototype with Figma Make and GitHub Copilot to validate ideas before committing engineering resources. At home, I build full products with Claude Code, n8n, and other AI tools.
This isn't about being a "technical PM" for the sake of it. It's about reducing risk. When I can show a working prototype instead of a PRD, the conversation with engineering shifts from "should we build this?" to "how should we build this at scale?" That's a fundamentally better starting point.
What Operators See That PMs Miss
Traditional PMs are trained to think in user stories, jobs-to-be-done, and product-market fit. These are valuable frameworks. But operators bring additional lenses:
Process debt. Just like technical debt, organizations accumulate process debt: manual workarounds, tribal knowledge dependencies, and legacy workflows that persist because "that's how we've always done it." Operators recognize process debt instinctively because they've lived with it.
The compliance constraint. In regulated industries, compliance isn't a feature request. It's the operating environment. Operators in these environments understand that the best solution is often the one that makes compliance invisible, not the one that adds a compliance step.
Adoption reality. The gap between "this tool is available" and "this tool is used" is where most enterprise products fail. Operators understand that adoption is a change management problem, not a feature problem. Scaling adoption by enabling non-technical users to build their own solutions creates a multiplier effect.
The Bridge Between Business and Engineering
The most valuable thing my non-traditional background gives me is the ability to translate between business stakeholders who think in terms of processes and outcomes, and engineering teams who think in terms of systems and architectures.
When I design a product, I'm simultaneously thinking about the operational workflow (what does the user actually do?), the business impact (what metric moves?), and the technical architecture (what's the simplest system that supports this?). That triangulation comes from having lived in all three worlds.
The Point
If you're a PM with a non-traditional background, your operational experience isn't a gap in your resume. It's a competitive advantage. The best product managers I know aren't the ones with the most PM experience. They're the ones with the deepest understanding of the problems they're solving.
And if you're a hiring manager: consider the candidate who built and shipped products before they knew the job title for what they were doing. That instinct for solving real problems is harder to teach than any PM framework.