Not a straight line — a deliberate climb.
Most product managers come from engineering or MBA programmes. I didn't start in product — I started on the edge of it, where things break first. Handling escalations, debugging broken workflows at midnight, sitting inside customer frustration long enough to understand it deeply.
That path turned out to be a superpower. Every product decision I make is grounded in something I have personally felt: confusing UX that looks fine on paper, features that technically work but fail in real workflows, customers blocked at the worst possible moment. I learned early that not every problem needs a new feature — many just need a better default, clearer messaging, or a simpler mental model.
"I don't ask 'is this correct by spec?' I ask — what happens when this breaks at 2am for a paying customer?"
What each shift unlocked.
Support → Analyst. Shifted from solving individual tickets to identifying systemic issues. Learned that "rare edge cases" are never actually rare — and that bad defaults cause more damage than missing features.
Analyst → Engineer. Gained technical depth. Started reading code, understanding APIs, and speaking the language of engineering. Specificity matters — a sharp bug report is itself a product contribution.
Engineer → PM. Moved from influencing to owning. The instinct wasn't to ship faster — it was to ask: who bears the cost if we get this wrong? Can support explain this without a 20-message thread?
PM → Builder. Stopped waiting for the translation layer between vision and execution. With AI as a co-builder, I could take a requirement and ship it exactly as imagined — every feature, every interaction, every design detail.
When I stopped spec'ing and started shipping.
The traditional PM loop has a quiet problem. An idea travels from your head through a spec, through engineering, through design, and back — and by then, it is no longer your idea. The back and forth erodes intent. What ships is often a negotiated version of what you imagined, stripped of the details that made it feel right.
Pair coding and vibe coding changed that entirely. When a co-founder brought a requirement, I could build it exactly as I envisioned — every feature, every interaction, every design detail. No translation layer. No context lost between stakeholders each holding only part of the picture. The product in my head became the product in production.
The biggest unlock was the customer feedback loop. Before: receive feedback, file it, wait for a sprint slot, review a diff, test, deploy. After: receive feedback, fix it, ship it — sometimes the same day. That compression changes how you build.
"I hadn't written code in five years. I asked engineers relentless questions — how to do this, how to navigate that. But once the foundations clicked, something accelerated. The context I used to lose in hand-offs was now embedded in code I owned."
The old loop vs the new one
- Before: requirement → research → ideas → spec → engineers → designer → back and forth → outcome ≠ vision
- After: requirement → build exactly as imagined → ship → customer feedback → same-day fix
- Relearned coding fundamentals after 5 years away — with a lot of help from patient engineers
- Context that was always lost in hand-offs now lived in the code itself
- Pushed directly to GitHub, owned the full build-to-ship cycle end-to-end
What the journey built in me.
Years in support means I have felt the frustration firsthand. I do not need a persona document to tell me why a user might abandon a flow — I have been that user.
Having operated across support, engineering, and product, I can move fast between context layers. I speak the language of every stakeholder in the room.
Every product I have shipped has a success metric attached. Not because someone asked for one — because I know from experience how easy it is to ship and never know if it worked.
Fluency in AI is not about using every model feature. It is knowing when automation creates leverage and when it creates noise — and having the data to tell the difference.