How I Got Here
I’ve always been good with computers. Not in a “built my first app at 12” kind of way — more like the kid who taught herself video editing software for fun and explained internet settings to grown-ups. I grew up on a family computer and the early internet: browser games, pixel art, and long-forgotten websites. Later came video games, design tools, and a hobbyist-level comfort with software that made me the go-to tech person in every group I was part of.
That curiosity — plus a tendency to ask endless questions — eventually led me to study Computer Information Technology in college. I explored a bunch of different technical focus areas, made solid grades in programming, and fully fell in love with SQL. Not everyone lights up when they finally understand inner joins, but I did. I liked when things made sense. I still do.
After graduation, I worked in Tier 1 and 2 IT support, where I found something surprising: I loved help desk work. I loved helping people, talking through their frustrations, figuring out the real issue under the surface.
Give me a desk, a headset, and a line of people with computer problems, and I’m happy.
Then I landed at my current company as a project manager. The product was 20 years old, and the development style felt about the same age. There wasn’t a roadmap, or planning, or product strategy — just customer requests and a dev team trying to stay afloat. It didn’t take long for me to start asking questions: Why are we building this? How did this feature happen? What’s the actual problem we’re solving?
When I couldn’t find answers, I started making better ones.
Over the next few years, I helped shift us away from reactive custom development and into a real planning model. I introduced cross-departmental review, created a client suggestions pipeline, and launched a biannual prioritization cycle. I started writing specs, planning releases, and translating big, messy ideas into features that actually made sense to users.
I also did a lot of the parts no one assigned me — documenting changes, drafting marketing content, running product demos, training internal teams, and making sure people understood not just what we were building, but why. That’s the part I care about the most: making things clear. Making them human. Making them work.
Eventually, my title caught up to the work and I became a Product Manager. But I’d already been doing the job — and in many ways, defining what the job looked like in a company that hadn’t had one before.
Now I manage both web and mobile product, lead cross-functional planning, and support a complex legacy platform that I’ve come to understand like a second language. I still bring the same mindset to every new feature: What’s the real problem here? What will make this clear to users? What will make this easier for the team maintaining it two years from now?
I didn’t get here by following a linear path. I got here by showing up, asking better questions, listening closely, and learning quickly. I still do.