Where I Learned Systems From the Bottom Up

I started at Ericsson on 24/7 support for prepaid charging. That means: when a system breaks at three in the morning, you are the one who wakes up, and you have until sunrise to answer the question "why did it break". Nobody hands you an architecture diagram; you walk through the logs and work out how the system actually behaves.

After a while I wrote alarm-monitoring scripts so we could catch failures before they happened instead of waiting for them. What those years really left me was not technical knowledge but a reflex: if something behaves strangely, there is always an understandable reason underneath.

If I can understand what a developer means today when they say "this one is hard", those night shifts are the reason.

Then It Was My Turn to Ask the Questions

In 2015 I moved to business analysis and project work — test processes, verification and package design on Turkcell projects. I learned something else there: knowing how a system works is not the same as knowing what it should do.

Misreading a requirement always ended up in the same place: a requirement error found after delivery costs far more than the single question that could have been asked at the start. Asking the right question at the right time has been at the centre of my work ever since.

Since 2017 I have been a Product Owner & Expert Analyst at Turkcell. From public tenders to legal workflows, I take apart processes that have run on "this is how it is done" for years and rebuild them — with RPA yesterday, with AI modules today. The full timeline is in my CV.

Why I Stand on Both Sides

There is a distance between describing a product and building it. For years I stood on one side of that distance: writing the scope, listening to estimates, waiting for the result. At some point I became curious — what would happen if I did the whole thing myself?

I started trying it in my time outside work. I make the scope decisions, build the data model, and write the code alongside AI. What came out of it: a web platform running live for an Umrah agency, a health coach that speaks Turkish, a five-brand advice platform and several more apps. They are all under Projects.

What this gave me was not a new profession but calibration: I now know from my own experience why a piece of work takes as long as it does. Product ownership is still my main job — but when someone asks "can this be done", I answer as someone who has tried, not as someone guessing.

Why This Site Looks Like This

I love single-panel cartoons — short, sharp, the whole thing landing in one hit. The design of this site comes from there: every section in its own frame, with a short note underneath. The same reflex works on the product side: throw out everything unnecessary, leave the meaning.

The 3D side of the site comes from the same curiosity. It started as "what if a portfolio were walkable" and turned into an island built from scratch with Three.js. You can walk around it if you like — I hid a few jokes in there as well.

Me Outside Work

I travel whenever I get the chance; with a backpack, and as close to street level as possible. I have seen eleven countries and a good number of provinces in Turkey — but the answer to "the most beautiful place you have been" is, without question, Mecca and Medina. Not because of the view; it is that your hurry stays outside the door there.

The rest is cartoons, long-running series, the occasional game, and Fenerbahçe on match day. It is all on the hobbies page — where I leave the work side out entirely.

// I rewrote this page three times. Narrowing the scope helped here too.

Let's continue the story

Senior Product Owner roles, product consulting, or the question "could we build this with AI" — all three go to the same address.