My Move from Technical Program Manager to Product Manager

How building compliance expertise and seizing an offhand comment landed me a new role

One month ago I moved from a Technical Program Manager role to a Product Manager role. This was an internal move within my current company.

Here’s how it happened (and more importantly, why I made the move).

How It Happened

First things first: the mechanics of how it happened:

• Open conversations about career aspirations

• Growing domain expertise

• Doing product things

Conversations About Career Aspirations

I started 2025 as a Staff Technical Program Manager, but I’m driven by growth. I had regular conversations with my manager about career aspirations—not every 1:1, but monthly or quarterly to show my hunger for advancement.

Through consistent program delivery and these career conversations, I built a trusting relationship with my TPM manager.

I had identified three potential paths forward: Senior Staff TPM, TPM Manager, or Product Manager. I didn’t expect any of these to happen in 2025, and I had no preferred path. It was a simple calculation of probability based on where my current skills could take me.

But I felt confident that each was feasible as a next step for professional growth.

Growth In Compliance Domain Expertise

I’ve been working at HashiCorp for the past 3 years. If you’re not familiar, HashiCorp makes products like Terraform and Vault. My time here has focused on the non-functional aspects of running successful SaaS products: infrastructure reliability, security engineering, and compliance.

For every program I ran, there was a consistent goal: raise the bar of these non-functional capabilities so we can attract enterprise customers around the world.

The last 18 months have been especially focused on Compliance Certifications (SOC 2, ISO, PCI, FedRamp, etc.) and implementing the controls required to achieve them.

These certifications are gatekeepers to industries, geographies, and enterprise-scale customer segments.

Running these programs (and understanding perspectives from VPs to IC engineers) I built a strong network and deep compliance expertise.

This set me up well to step into a product role where domain expertise is a core requirement.

Doing Product Things

This expertise became the foundation for my transition.

In October 2024, I had a conversation with our Director of Product who owned our cloud platform reliability, security, and compliance.

I regularly discussed with her where support was needed from Product for compliance initiatives. This healthy working relationship was the foundation for internal career mobility.

Several times throughout the past year, I helped fill product manager gaps when necessary. She was fully aware of this (as was my TPM Manager), and I regularly collaborated with her so none of my inputs into product took her by surprise.

Then one day, we had a 1:1 discussing the current state of some work and she made a side comment about needing a more dedicated Product person to handle it. My opportunity had just arrived.

Though it was offhand, I seized the moment and said that if it was an actual opportunity, I wanted to talk about it.

So we did. And one month later, I moved into her team.

Putting It All Together

Before we move to the “why,” there are some core lessons in the “how” that I want to point out:

1. Building a trusting relationship with your existing manager is necessary. You do this through open career conversations while also delivering with high performance. Get good at your craft. Be trustworthy. Be reliable.

2. Don’t just run programs; build expertise. You’re doing the TPM job wrong if you think your only job is to facilitate program meetings, keep Jira up-to-date, and point out potential missed deadlines.

3. Look for opportunities to fill a gap if there are skills you want. This is tricky because you must not let this interfere with performance of your current role. But be opportunistic and seek to add value in many ways. Don’t let your mind get pigeonholed into your current role. If you only think through the lens of your current role, you self-limit your problem-solving skills.

Why I Made The Move

Moving to a new role is not a small decision. I want to tell you about my decision from two perspectives: factors that were NOT reasons to move and factors that WERE reasons to move.

Anti-Reason 1: Negative Forecasting the TPM Role

I did not leave my Technical Program Manager role because of any negative job-demand forecasting around the role.

I’m still bullish on the TPM role. I am a huge advocate for its usefulness. I still love it. And who knows, perhaps someday I’ll return to it.

(However, I do foresee that the TPM role is rapidly changing due to AI, so the need to adapt definitely exists. This need to adapt exists just as much for my new Product Manager role.)

Anti-Reason 2: Running away from hard things

I also didn’t do it because I felt anything I’m working on is hard. You should never leave a job because it is hard.

I’m not saying it is easy. In fact, the things I want to get done in 2026 are very hard. But the difficulty is not persuading me to turn away.

A small caveat: A hard job is sometimes conflated with a bad fit job. A bad fit job is different than a hard job. A bad fit job sometimes looks like: a manager who isn’t supportive of your growth, a culture that perpetually crushes your work-life balance, zero growth in the job, etc.

Reason 1: Motivated by Learning

At my very core, I am motivated by learning. This means I enjoy throwing myself into new domains and projects because it honestly makes my mind feel alive.

I see much of my life like a video game. More specifically, like an RPG. I want to wake up most mornings on a quest to better myself!

When I was a kid, I poured so much time into an online game called RuneScape. I was absolutely addicted, no shame. (I turned out alright in life despite being obsessed with the game!)

In the game, I was fascinated by the chance to level up to be an expert fisherman, miner, swordsman, cook, farmer, etc. If you dedicated the time, you could level up in ALL of these areas and unlock awesome stuff.

In my career, I’ve had a similar approach trying out many different roles: Quality Assurance, Front End Engineer, IT Project Manager, Software Engineer, Technical Program Manager, etc.

Now I can build my Product Management skills. The opportunity came and I immediately felt motivated by the Product Craft.

This core motivation of learning helped me be deeply interested in the TPM Craft. I plan to apply much of the same rigor to the Product Craft as well.

Reason 2: Family Stability

This is a more personal reason, but a big one.

This was an internal job move. This means my family has felt no change. My kids can continue going to school with their friends and we can remain in the same community that we enjoy. (Oh yeah, and I don’t have to cough up buckets of money to move anywhere because cost of living is wild in the USA these days.)

I can preserve all those things while gaining new skills. That is a unique and rare opportunity that I had to consider.

Reason 3: Leadership, Strategy, and Impact

A lot of people want to have positive impact in their careers. I’m no different.

If I’m going to spend MOST of my life in a career, I want to make it worth it by having a positive impact on those around me and the world generally.

In a product role, I believe my leadership trajectory is different because product sits more squarely in the strategy of the business. My hope is to influence strategy for the good of whoever the customers are and execute on it in a way that lifts those around me.

This is very aspirational. Very vague. But it feels directionally correct.

What does this mean for the TPM Craft Newsletter?

Honestly, I’m not 100% sure yet.

For now, I will keep writing for a bit. I enjoy writing and (apparently) some of you enjoy receiving these TPM Craft insights.

Long-term? We’ll see. I am certainly grateful for everyone who found value in TPM Craft Newsletter.