“AI işleri elimizden mi alacak, yoksa yeni işler mi yaratacak?” Bu soru hepimizin aklında. Bizce cevap, aslında her ikisi de. Çünkü AI, meslek tanımlarını yeniden yazarken yepyeni roller de ortaya koyuyor. İşte bu noktada ürün yöneticileri için AI otomasyonunun anlamını tartışıyoruz. Sözü, Alive 2025’teki ilham verici konuşmasıyla tanıdığımız Ateş Yankı Öksüz’e bırakıyoruz. Ayrıca Yankı’nın “Vibe PM: Lovable ile Prototipleme” eğitimi üzerine hazırladığımız rehberi de blogumuzda okuyabilirsiniz.

‍

Product İçin AI Otomasyon: Ünvan Değil, Beceri

Geçtiğimiz günlerde Wade Foster’ın X’te yaptığı şu paylaşım dikkatimi çekti:
“If you’re an AI automation engineer, we’ll hire you. Into ANY open role… Seriously, 100% of our open jobs are up for grabs to AI automation engineers.”

(Brick Not: Biz de bu twite önceki bültenimizde yer vermiştik)

Bu aslında şunu söylüyor: AI otomasyon bir pozisyon veya iş tanımı değil, neredeyse her pozisyonun üstüne eklenen ve beklenen bir beceri. Tekrarlayan işleri görebilen, veriyi ve araçları birbirine bağlayıp LLM’leri doğru yerde çalıştırabilen ve süreçleri otomatikleştirmeye gönüllü herkes için kapı açık; gelecek burada.

Tweet’i okuduğumda bunun ürün yöneticileri için ne anlama geldiğini, hemen paniklemeli miyiz ve nasıl daha hazır hâle gelebiliriz sorularını irdelemek istedim.

‍

Önce “neden şimdi” kısmı. Zapier, Make, n8n gibi orkestrasyon araçları ve GPT/Claude/Gemini gibi modellerle bir şeyleri birbirine bağlamak artık yalnızca yazılımcılara bırakılması gereken bir maharet değil. Günlük rutinlerimizin birçoğu belki de “anlamsız” ve bu kadar üzerinde zaman harcanmaması gereken işler. Aynı raporu, aynı PRD taslağını, aynı kontrol listelerini tekrar tekrar yazıyoruz. Çoğu zaman Slack’teki konuşmaları manuel olarak tek tek okuyoruz, “aman bir şey kaçırmayayım” diye hayıflanıyoruz ve yine de kaçırıyoruz. Ancak sektör bu rutinleri otomatikleştirmeye doğru hızla yöneliyor. Rakamlar da bunu doğrular nitelikte:

• 2025’te şirketlerin %78’i AI’ı, %71’i genAI’ı düzenli kullanıyor; %21’i de bazı iş akışlarını yeniden kurguladığını söylüyor (McKinsey 2025).
• Geliştiriciler tarafında eğilim benzer: öğrenenlerin %84’ü, profesyonellerin %77’si AI araçlarını kullanıyor ya da kullanmayı planlıyor (Stack Overflow 2025).
• Accenture’a göre şirketlerin %86’sı genAI yatırımlarını artırmaya hazır, %60’ı da bu yılı ölçekleme yılı olarak görüyor (Accenture 2025).

Yani mesele bir “hype” değil; sektör, rutinleri otomatikleştirerek anlamlı işlere odaklanmayı daha değerli hâle getiriyor. Peki ürün yöneticileri bunun neresinde?

‍

Kendi işe alım görüşmelerimde her 10 adaydan 9’unun PM olarak yapay zekâ kullanımının hâlâ “ChatGPT’de hızlıca bir şey yazdırma” seviyesinde kaldığını görüyorum. Buna karşılık ekip içinde %50+ oranında AI prototyping süreçlerini benimsemiş olsak da, rutin işlerini otomasyonla gerçekten uçtan uca hızlandıran kişi sayısı şu an yalnızca 1. Elbette bu bilimsel bir örneklem değil; ama pratikte gördüğüm boşluk net: prototip üretmek var, PRD yazmak var; ancak rutin akışı kalıcı otomasyona bağlamak konusunda gidecek çok yolumuz var.

Peki bu beceriyi nasıl geliştirip sistematikleştirebiliriz? Benim kullandığım basit bir yöntem var: 4D — Discover, Design, Delegate, Defend. Bu benim kendimce belirlediğim yöntemim; siz kendinize uygun şekilde düzenleyip isimlendirebilirsiniz.

‍

‍

Discover: Önce tekrar eden işleri yakalıyorsun. Haftada kaç kez aynı formatta rapor yazıyorsun, hangi toplantı notlarını hep sen toparlıyorsun, hangi Jira issue’ları hep aynı şekilde etiketleniyor? Baktın ki aynı işlere sürekli zaman harcıyorsun; o zaman elinde iyi bir aday var.

Design: Sonra akışı çiziyorsun: Girdi nereden geliyor (CSV, e‑mail, Slack mesajı, Jira issue, API çağrısı), model tam olarak ne yapacak (özet mi yapacak, içerik mi üretecek vb.), orkestrasyonu kim/neyle tetikleyecek (n8n, Make, Zapier vb.) ve çıktı nereye inecek (Jira güncellemesi, Slack mesajı, PR açma, Google Sheets’e yazma). Ben tercihen dijitalden çok kâğıt üstünde akışlarımı görselleştirmeyi seviyorum; kafamda daha net oturuyor.

Delegate: Üçüncü adım delege etmek. Prompt’u bir kere yazıp bırakmamak gerekiyor. Tıpkı bir kişiye iş delege eder gibi takibini yapmak şart. Küçük “context paketleri” hazırlamak, hata durumunda ne yapılacağını düşünmek (retry, farklı model, insan onayı), prompt’ları versiyonlamak ve loglamak… Bunlar ilk günden koyulursa akış sonradan bozulduğunda panik yaşanmıyor ve müdahale edilebiliyor.

Defend: Ve son olarak savunmak: KPI’ları belirlemeden başarıyı ölçemezsin. Başta “ne kadar zaman kazanacağız, hata oranı nasıl değişecek, lead time kaç gün kısalacak” gibi net hedefler yazınca projenin ROI’si net bir şekilde anlaşılabiliyor. Loglama ve eval setlerini belirlemeden bu otomasyonun sürdürülebilirliğini sağlamak zor. O yüzden tasarım aşamasında neleri ölçmek istediğimizi iyi belirlememiz gerekiyor.

‍

Bunlar soyut kalmasın. PM tarafında backlog yönetimini otomatik etiketleyen bir bot, kullanıcı görüşmesi transkriptlerinden insight kartları çıkaran bir özetleyici, kritik Slack kanallarının gün sonu özetini size raporlayan bir otomasyon, PRD’nin ilk taslağını şablona göre üreten bir yardımcı; A/B test sonuçlarını istatistik raporundan karara çeviren bir “anlatıcı”; haftalık stakeholder güncellemesini e‑posta ve Slack için farklı tonlarda yazan bir dönüştürücü… Hepsi pekâlâ iki üç saatlik POC’lerle başlayıp oturabilir. Hepsi aynı mantığın varyasyonları.

Product ekipleri için bu otomasyonların somut faydası ne? Öncelikle zamanı ürün yöneticilerine geri veriyor. Backlog yönetimi, araştırma ve kullanıcı yorumlarını özetleme, haftalık durum notları ve tekrarlayan dokümantasyon işlerini akışa verdiğinde PM’in odağı yeniden probleme ve çözüme dönüyor. İkincisi, tempo artıyor: fikir → deneme → öğrenme döngüsü kısalıyor; “bir sonraki en iyi adım”a karar verme süresi kısalıyor. Üçüncüsü, kalite standardı oluşmaya başlıyor: PRD’ler, changelog’lar ve stakeholder güncellemeleri aynı formatta ve eksiksiz çıkıyor; el yazısı farkı ve unutulan alanlar azalıyor. Dördüncüsü, hizalanma kolaylaşıyor: Akış log’ları ve otomatik özetler sayesinde herkes aynı bilgi setinden ilerliyor; durum toplantılarının sayısı doğal olarak düşüyor. Son olarak, kapasite genişliyor: Daha çok hipotez aynı sprinte sığıyor, deney sayısı artıyor, hatalı el sıkışmaları (handoff) azalıyor.

Peki sektör nereye gidecek? Ürün yöneticilerinin zaten muğlak olan iş tanımı biraz daha bulanıklaşabilir. Backlog yöneten ürüncülerin büyük oranda azalacağını ve bir noktada biteceğini; yeni nesil, yapay zekâ destekli ürün yöneticilerinin ise değer kazanacağını düşünüyorum.

O yüzden bir başlangıç noktası olarak bir çağrıyla bitirelim:
Seçtiğin basit, tek bir akışı 4D ile tasarla; ufak bir POC çıkar; sprint sonunda ölç ve iyileştir. Çalışıyorsa şablonlaştırıp yaygınlaştır; diğer ekip arkadaşlarının da benimsemesini sağla.

‍