I didn’t plan to become a Product Manager. If you’d asked me six years ago, I’m not even sure I could’ve described what the job was.

I was starting a role as a PR and Communications Associate at an eCommerce watch company. It was meant to be press releases, media relationships, and the usual PR work. But the job grew quickly, and not in a neat way. I ended up taking on social media strategy, working closely with photographers, and doing customer service through the messages we got every day.

I’m mentioning the messy scope creep because that was the point. That was the first time I was close enough to the customer to actually hear what they were thinking.

Where I First Noticed the Product

A lot of the feedback didn’t sound like “product feedback” at the time. It came through casual conversations with reviewers. It came through customers asking the same questions again and again. It came through complaints that were half about the watch and half about the experience of trying to buy it.

And I started reacting differently than I used to.

Instead of only thinking about how to respond well, I found myself thinking about what we could change so the message wouldn’t need to be sent in the first place. What’s confusing here? Why is this happening at this step? Is this really a customer problem, or is it our problem?

That was the first time I properly understood that communication roles can sit right on top of product, even if they’re not labelled that way. When you’re the person reading the feedback, you become the person who sees the patterns.

The thing about being close to users is that it changes the way you prioritise. You stop guessing. You stop debating hypotheticals. You start recognising repeat pain points, and you start thinking in terms of journeys.

Customer service taught me this in a very practical way. People don’t always ask for what they actually need. They ask for the thing they can see. They describe the symptom. Your job is to work out what would genuinely solve it, and do it in a way that keeps trust intact.

It’s a small skill until you realise it’s basically the foundation of product work.

Then I Moved Into Crypto

When I moved into a PM role at a crypto company, the speed was a shock.

Back in 2022, things moved so fast that being late by a couple of days could make you feel behind. Features were being shipped constantly. Competitors were launching things overnight. There was always pressure to keep up, and it did sometimes feel like chasing shiny objects because the space rewards momentum. The investment, the hype, the constant “what’s next” — it’s hard not to get pulled into that current.

But I also loved it. I liked learning in real-time. I liked waking up and having to get good at something quickly, because I didn’t have another option.

The Learning Curve Was Not Gentle

I learned how to write PRDs, but not in a textbook way. I learned how to write them for the team in front of me: what detail they needed, what assumptions had to be spelled out, who needed to sign off, and what “good enough” actually looked like when the goal was to ship.

I learned epics, user stories, standups, all the standard things. And then I learned everything around the standard things, the parts you don’t really notice in a corporate environment because the structure holds you up.

We had language barriers with the engineering team, who all spoke Mandarin, and we realised quickly that tickets weren’t enough. We had to do more walkthroughs. More design reviews. More “here’s exactly what this needs to do” conversations, because otherwise the gaps showed up in the build.

Shipping quickly came with tech debt. There were features that should’ve used another sprint. There were decisions that were made because time forced them, not because they were the best long-term call. That was the reality of the pace.

And it shaped how I work now.

Why I Think That Path Matters

Now that I’m the product person for my own co-founded business, I can see the through line more clearly than I could at the time.

That early job taught me what it feels like to be close to customers and have direct exposure to what they’re struggling with. Crypto taught me how to ship, how to make decisions with incomplete information, and how to keep moving even when the product isn’t perfect.

Co-founding has been its own kind of correction. Iterations are faster. Feedback loops are tighter. If something is creating friction, you feel it immediately. And if you’re willing to fix it, you can fix it quickly.

Sometimes it’s as simple as changing a CTA or rebuilding a flow in the same afternoon, which still feels slightly unreal when you’ve spent years in environments where changes take weeks.

The Point, If There Is One

I don’t think my path into product is a “normal” one, but I also don’t think there is a normal one anymore.

What it gave me is range. Being able to wear different hats without losing the thread. Being able to talk to different people and translate between them. Being able to take messy feedback and turn it into something buildable.

I didn’t start with the title. I started with the habit: listening closely, seeing patterns, wanting to fix what wasn’t working.

And honestly, that part is still the most useful part.