“Teknik Product Manager kod yazmalı mı?” sorusu karşıma sık çıkıyor. Ben kod kurcalamayı, SQL ile bir iddiayı kontrol etmeyi ve loglarda kaybolup sonra doğru satırı bulmayı seviyorum. Yine de bence soru yanlış yerden başlıyor. Her teknik PM production kodu yazmak zorunda değil. Asıl mesele, verdiği ürün kararının sistemde neye dokunduğunu anlayabilmesi.
Teknik olmak mühendis rolü yapmak veya toplantıda en çok terimi kullanmak değil. Bir API çağrısının başına ne geldiğini takip edebilmek, verinin nerede değiştiğini anlayabilmek, bir sorun çıktığında doğru loga bakmak ve “bunu hızlı yaparsak sonra neresi ağrır?” diye sorabilmek. Kod yazmak bunları öğrenmeyi kolaylaştırıyor, evet. Ama tek ölçü bu değil.
Teknik yeterlilik bir merdiven değil, haritadır
Her ürün yöneticisinin aynı teknik derinliğe ihtiyacı yok. Bir içerik ürününde önemli olan alanlarla ödeme, enerji veya multi-tenant bir platformda gereken alanlar farklıdır. Ben teknik yeterliliği beş başlıkta düşünüyorum:
- Ürün ve domain: Sistem hangi gerçek dünya sürecini temsil ediyor?
- Veri: Başarıyı hangi event ve metriklerle ölçüyoruz? SQL ile sonucu kontrol edebilir miyim?
- API ve entegrasyon: Request, response, hata, retry ve idempotency davranışlarını anlayabiliyor muyum?
- Mimari: Bir değişiklik hangi servisleri, tenant’ları ve bağımlılıkları etkiliyor?
- Operasyon: Release, log, alarm, rollback ve incident sürecinde neye bakılacağını biliyor muyum?
Bir eMSP ürününde kullanıcı sadece “şarjı başlat” butonuna basıyor. Ekranda tek hareket. Arkada ise kimlik doğrulama, roaming, cihaz durumu, tarife, transaction ve faturalama sıraya giriyor. PM’in bütün protokol mesajlarını ezberlemesi gerekmiyor; benim de ezberimde değil. Ama sorun çıktığında “backend bir baksın” demekten biraz daha ileri gidebilmek gerekiyor.
Minimum teknik seviye nedir?
Bence teknik PM en azından şu dört eylemi yapabilmeli:
- Doğru soruyu sormak: Bu davranış senkron mu, asenkron mu? Tekrar denenirse ne olur? Tenant sınırı nerede?
- Trade-off’u anlamak: Daha hızlı teslimat karşılığında hangi borcu veya operasyon riskini kabul ediyoruz?
- Kanıtı okuyabilmek: Log, SQL sonucu, API response veya dashboard gerçekten iddiayı destekliyor mu?
- Teslimatı doğrulamak: “Deploy oldu” ile “kullanıcı problemi çözüldü” arasındaki farkı görebiliyor muyuz?
Bu dört madde beni yazılımcı yapmıyor. Fakat mühendis “retry’de aynı işlem iki kere oluşabilir” dediğinde neden durup düşünmem gerektiğini anlamamı sağlıyor. Bence değer tam burada.
Az teknik olmak kadar fazla teknik olmak da riskli
Teknik bilgisi yetersiz bir ürün yöneticisi çözümü ekibe bırakırken problemi de bırakabilir. Task’lar belirsizleşir, edge case’ler geç keşfedilir ve release başarı metriği “ticket kapandı” olur.
Diğer uçta ise çözümün içine fazla girip mimariyi dikte etmek vardır. Product Manager belirli endpoint, tablo veya framework konusunda ısrar ederek ekibin çözüm alanını daraltabilir. Bu kez kullanıcı problemi yerine kendi teknik fikrini yönetmeye başlar.
Doğru denge, problemin ve sonucun ownership’ini almak; çözüm tasarımını uzmanlarla birlikte yapmak.
Kendimi nasıl ölçüyorum?
Bir alandaki teknik seviyemi “biliyor muyum?” diye değil, üç soruyla ölçmek daha yararlı geliyor:
- Bu konuda anlamlı bir karar verebilir miyim?
- Karar veremiyorsam doğru uzmana doğru soruyu sorabilir miyim?
- Sonucun doğru olduğunu bağımsız bir kanıtla kontrol edebilir miyim?
Üçüne de cevap hayırsa o alan için öğrenme ihtiyacı vardır. Üçüne de evetse üretim kodu yazmasam bile teknik ürün sorumluluğunu taşıyabilirim.
Hâlâ bilmediğim çok şey var; zaten bu işin hoşuma giden tarafı da bu. Bazen bir log satırı, bazen küçük bir SQL sorgusu, bazen de mühendisin sorduğu tek soru yeni bir şey öğretiyor. Teknik PM’in hedefi odadaki en iyi geliştirici olmak değil. Kullanıcıyı, işi ve sistemi birbirine tercüme ederken anlamı kaybetmemek. Merakını kaybetmezse teknik derinlik zamanla geliyor.