Ürün yöneticiliği (product management) son birkaç yılda sessizce ama derinden değişti. Bu değişimin merkezinde yapay zeka var ama mesele sadece yeni araçlar öğrenmek değil. Mesele, bu araçları kullanarak masaya ne getirdiğimizin tamamen farklılaşması.

‍
Bu rehberde, beş yıllık ürün yöneticiliği deneyiminden süzülmüş somut iki örnek üzerinden bu dönüşümün ne anlama geldiğini ele alacağız. Klasik tanımlardan ve teorik çerçevelerden ziyade, gerçekten ne yaptığımıza, hangi araçları nasıl kullandığımıza odaklanacağız. Finans odaklı bir uygulamanın onboarding sürecinden, bir n8n otomasyonunun production'a taşınmasına kadar iki farklı uçtan örnek göreceksiniz.

‍
Eğer henüz prototip üretme refleksi geliştirmediyseniz, yarın işe başlarken nasıl bir adım atabileceğinizi düşünmenize yardımcı olacak somut bir yol haritası elde edeceksiniz. Ve göreceksiniz ki, mesele kod yazmayı öğrenmekten çok daha farklı bir şey.

‍

Dönüşümün Hissedildiği An: Bir Toplantı Anekdotu

‍
Dönüşümün net olarak ne zaman gerçekleştiğini sormak gerekirse, geçen senenin ilk çeyreğinde olduğunu söyleyebilirim. Sıradan görünen bir toplantıya katıldım. Ama bu sefer farklı bir şey yaptım: Klasik dökümanlar yerine çalışan bir prototip götürdüm.
Toplantı bir anda level atladı. Çünkü herkes aynı şeye bakıyordu. Konuşma "şunu yapalım mı, ne zaman yapalım, kim yapar?" sorularından çıktı ve bir anda "şu eşik doğru mu, buraya bu mu gelse, tasarım şöyle nasıl olur, burada bir gamification olabilir mi?" sorularına döndü.
O gün toplantıdan çıkarken net bir şey anladım: Mesele benim hızım ya da iş yapma şeklim değildi. Masaya ne getirdiğimdi. Aslında bu rehberin tamamı bu cümlenin açılımı olacak.

‍
Aynı Sorun, İki Farklı PM

‍
Aynı soruna iki farklı ürün yöneticisinin yaklaşımını düşünün:

Birinci PM: Briefle gelir. Toplantı "yapalım mı, yapmayalım mı" eksenine sıkışır. Tartışma soyut kalır, herkes farklı şeyler hayal eder.
İkinci PM: Çalışan bir parçayla gelir. Konuşma doğrudan "bunu nasıl daha iyi yaparız?" eksenine kayar. Eksikler ekrana yansır, saklanamaz.

Bu fark, artık bir ünvandan ziyade bir refleks olarak ele alınmalı.

‍

Beceri Metalaştı: Asıl Fark Yaratan Nedir?

‍
LinkedIn'de paylaştığım bir yazıda da değinmiştim: Araç artık herkeste var, ama beceri metalaştı. İki ürün yöneticisini ayıran şey yetkinlik değil, oturup yapma cesareti. Elini kirletme, bir şeyleri deneme isteği.

‍
Bu cümle ilk anda iddialı gelebilir ama gerçeği yansıtıyor. Yapay zeka çağında ayrım tam da burada başlıyor. Bir şeyleri denemek, test etmek, prototipe bakmak sizi en azından bir adım öne geçiriyor. Tabii bu da geçici bir avantaj çünkü herkes yavaş yavaş denemeye başladı. Zaman içinde farklılaşma noktaları yeniden şekillenecek.
‍

Bunun Bir Trend Olmadığının Kanıtları

‍
Şirketlerin işe alım kriterlerine bakınca bu dönüşümün ne kadar derin olduğu görülüyor:

Anthropic: Developer olmayan ekiplerden bile Claude ile bir prototip kurabilmelerini istiyor.
Zapier: Adaylarından yapay zeka ile prototip oluşturmasını bekliyor. Adayları AI araçlarını canlı kullanırken izliyor, ne yaptığını, nasıl hareket ettiklerini gözlemliyor.

Gupta ve Yadav şirketleri ise "ajanın 3 dakikadan 6 saate çıkmasıyla" işin yönünün artık sistem tasarlamaya kaydığını söylüyor. PM artık yazılım üretmiyor, sistemi tarif ediyor.

‍
Doküman ve Prototipin Farkı

‍
Bir dokümana "kullanıcı tercihlerini seçer" yazarsınız. Herkes okur, kafa sallar, "tamam" der. Ama o tercihlerin ne olduğunu kimse o anda düşünmez, sorgulamaz.
Çalışan bir parçada ise her boşluk ekrana yansır. Saklayamazsınız. Herkes gözünün önünde olan şeyi çok daha açık, iş bitirici ve hızlı şekilde konuşur. Bu durum hem işin hızlanmasına hem de kalitenin artmasına yol açar.

Örnek 1: Onboarding Tıkanıklığı ve Prototiple Açılma

‍
İlk örnek en sevdiğim örnek, çünkü gerçekten uzun süre içimize sinmemiş, çözüme ulaşamayan bir konumuz vardı. Bizi epey uğraştırmıştı.

Finans odaklı bir uygulama geliştiriyorduk. Burada risk profili çok kritik. Kullanıcının finansal risk iştahını doğru ölçmemiz, hem kullanıcıyı kaybetmememiz hem de doğru kategorilendirme yapabilmemiz lazımdı.

‍
Onboarding'in iki temel hedefi vardı:

1. Kullanıcıyı içeride tutmak (kayıp oranını düşürmek).

2. Kullanıcının doğru kategoriye yerleşmesini sağlamak ve bunu ona şeffafça bildirmek.

‍
Ekip günlerce bu işle uğraştı. Benchmark çalışmaları yapıldı, netnografi raporları çıkarıldı, PRD (Product Requirements Document) yazıldı. Toplantı üstüne toplantı yapıldı. Ama iş bir türlü kapanmıyordu.

‍
Sistemin özünde şu mantık vardı: Kullanıcı, finansal risk profiline göre üç kategoriden birine yerleştirilecekti. Üç aşamalı bir filtre kurguladık:

1. Aşama: Sorulara göre ilk profil belirleniyor. Düşük riskli çoğunluk burada zaten yerine oturuyor.

2. Aşama: Yalnızca risk iştahı gösteren kullanıcılar ilerliyor.

3 Aşama: Beyanı doğrulayan gizli kontroller var. "Şu an profilin bu, risk iştahın daha yüksek görünüyor" gibi dürüst bildirimlerle kullanıcı bilgilendiriliyor.

Bolt ile Prototipi Kurmak

‍
Burada yaptığım şey bir kod yazmaktan ziyade sistem kurmaktı. Bu mantığı dokümana döktükten sonra Bolt'u açtım. Hazırladığım promptu sisteme verdim ve onboarding'i çalışır halde kurmasını istedim. Ortaya çıkan prototip kaba ve basitti ama tasarımcı, developer ve tüm ekibin kafasındaki belirsizliği aniden ortadan kaldırdı. Sorular zaten önceden belirlenmişti, her sorunun ağırlıklı bir ortalaması vardı.
Prototipin akışı şöyle ilerliyordu:

Soru 1: "Parayla ilişkini nasıl tanımlarsın?" → "Gerekirse risk alırım"
Soru 2: "Yatırım kararı sana neyi hissettirmeli?" → "Doğasında var"
Soru 3: "Şu an yatırım yapacak olsan hangisini seçerdin?" → Kripto, teknoloji vb.
Sonuç: "4 yüksek riskli cevap verdin, risk iştahın yüksek tespit edildi."

Sonra sistem beni bir sonraki aşamaya geçiriyor, finansal bilgi düzeyimi ölçüyordu. Üçüncü aşamada ise beni test edip nihai sınıflandırmamı yapıyordu. Örneğin profilim "dengeli yatırımcı" olarak çıktı ve hangi yatırım araçlarının bana uygun olduğu listelendi.

‍
Prototipin Yarattığı Etki

‍
Bu prototipi aldıktan sonra gerçekten her şey netleşti. Tasarımcısından developerına kadar herkes ne yapması gerektiğini biliyordu. Bu uygulama şu anda canlıda. Ve canlıdaki halinde, tasarımcının ve developer'ın elinden geçmiş, gamification eklenmiş, çok daha profesyonel bir hale gelmiş durumda.
Canlı versiyonda örneğin "dengeli yatırımcı" sonucu doğrudan verilmiyor. Bunun yerine bir yay görseliyle "hem güvenlik hem kazanç peşindesin, kontrollü adımlarla gidiyorsun" gibi bir anlatım var.

‍
Çıkarılacak Ders

‍
Buradaki ana ders şu: Uzun süren toplantılar, dökümantasyonlar, raporlar ortada olan bir sorunu çözmüyordu. Ama bir prototip, tüm ekibi anında aynı sayfada buluşturdu ve önümüzü gördük. Aynı sistem, aynı mantık. Arada sadece zaman vardı. Kod tarafıyla ben neredeyse hiç ilgilenmedim. Bolt yazıyor, ben sadece sistemin tarifini yapıyorum. PM'in işi tam da bu.

Örnek 2: n8n Otomasyonundan Production-Ready Koda

‍
İkinci örnek tamamen farklı bir uçtan geliyor. Çünkü prototip refleksi tek bir biçimde gelmiyor. Bambaşka bir üründe, bambaşka bir ihtiyaca da aynı yaklaşımla çözüm bulabiliyorsunuz.

Bir üründe n8n otomasyonu kullanıyorduk. Doğrulama (validation) ve test aşamasında bize hayli hayli yetiyordu. Ama ürünün doğası gereği production'a (canlı ortam) yaklaştıkça n8n sıkıntı yaratmaya başladı:

- Güncellemeler sorun çıkarıyordu
- Auto-caching tarafında problemler vardı
- Göremediğiniz, takip edemediğiniz şeyler oluyordu
- Kısacası altyapı çatırdamaya başlamıştı

Ekipler bir yandan geliştirmeye devam ediyordu. Production'a yavaş yavaş hazırlanıyorduk. "Ne yapacağız, nasıl gideceğiz?" sorusu ortada duruyordu.
‍

Claude Code ile Dönüşüm

‍
Şöyle düşündüm: n8n'den JSON export alabiliyorum. Madem böyle, neden bunu doğrudan koda çevirmiyorum? Otomasyonun JSON export'unu aldım ve Claude Code'a verdim. Yapıyı birebir, birkaç iterasyon sonrası, koda çevirdi.

Sonuç şuydu:

- Çok daha sağlam bir altyapı
- Çalışır durumda bir versiyon
- Aklımızda olup da beklettiğimiz birkaç özelliği üstüne eklediğimde, elimde oldukça kapsamlı bir prototip vardı

Bu işi neredeyse bir günde tamamladım.

‍
Toplantıda Yarattığı Etki

‍
Ertesi gün ekiplerle yaptığım toplantıda bu prototipi gösterdim. Production'a böyle çıkmamız gerektiğini hep birlikte gördük.

O toplantıdan sonra:

-Developer ne yapacağını net biliyordu
-Neden ve nasıl yapacağını da biliyordu
-Toplantı sırasında ekip bu yapılanların üstüne büyük katkılar da koydu

Briefle bu netliğe ulaşmak belki haftalar sürerdi. Belli kurgular üzerinden tartışırdık, "olur mu, olmaz mı" diye konuşurduk. Ama çalışan bir parça, tek bir oturumda bize bunun hepsini verdi.

İki Örnek, Tek Refleks

‍
Bu iki örneğin ortak noktası şu: Aynı refleksin iki farklı ucu.

Onboarding örneğinde: Tıkanmış bir kararı çalışan bir parçayla açtık.
n8n örneğinde: Yetersiz kalmaya başlayan bir altyapıyı, AI ile koda çevirerek production-ready hale getirdik.

İki durumda da PM olarak ben sistemi tarif ettim. Kodu AI yazdı. Ama hayat kurtaran prototipler ortaya çıktı.

‍
Bu Yaklaşımın Üç Kazancı

‍
Bu refleksin bize sağladığı üç temel kazanç var:

Hız: Haftalar süren tartışmalar günlere, hatta saatlere iniyor.
Netlik: Ekip aynı şeye baktığı için varsayımlar ortadan kalkıyor.
Kalite: Konuşma "yapalım mı?" değil "nasıl daha iyi yaparız?" eksenine kayıyor. Bu da daha iyi ürün demek.

Yarın Nereden Başlamalı? Pratik Bir Yol Haritası

‍

‍
Henüz bu refleksi geliştirmemiş arkadaşlar için bazı somut öneriler:

Küçük Bir Sorunla Başlayın

Devasa bir prototipe girişmeyin ilk başta. Ekibinizdeki en sıkışık, en tıkanmış kararı seçin. Belki bir onboarding akışı, belki bir filtreleme mantığı, belki bir bildirim sistemi.

Önce Sistemi Tarif Edin

Bolt, Claude Code, Cursor, v0 gibi araçlardan herhangi birini açmadan önce sistemin mantığını dokümana dökün. Hangi adımlar var, hangi koşullar tetikleniyor, kullanıcı nereye yöneliyor? Bu tarif ne kadar netse, prototip o kadar başarılı çıkar.

Mükemmeli Hedeflemeyin

İlk prototipiniz kaba olacak, basit olacak. Bu bir kusur değil, özellik. Çünkü amaç production'a göndermek değil, ekip ile aynı sayfada olmak. Tasarımcı ve developer bu prototiğin üstüne çok daha iyi bir versiyon çıkaracaktır.

Toplantıya Prototiple Gidin

Bir sonraki kritik toplantınıza brief yerine prototiple gidin. Konuşmanın seyri nasıl değişiyor, gözlemleyin. Tartışma "yapalım mı?"dan "nasıl daha iyi olur?" sorusuna ne hızda geçiyor, dikkat edin.

Kod Yazmaya Çalışmayın

PM olarak kod yazmak zorunda değilsiniz. Kodu AI yazsın. Sizin işiniz sistemi tarif etmek, mantığı kurmak ve sonucu değerlendirmek. Bu zihinsel ayrımı yapmak çok rahatlatıcıdır.

Ürün yöneticiliği rolünün dönüşümü artık aşikar. Bu bir trend yazısı değil, sahanın gerçeği. Türkiye'deki ve dünyadaki meslektaşlarımla yaptığım konuşmalar, işe alım kriterlerindeki değişimler, hep aynı yöne işaret ediyor.
Asıl mesaj şu: Mesele araç değil, refleks. Bolt'u, Claude Code'u, Cursor'ı, v0'ı bilmek yeterli değil. Önemli olan, oturup denemek, elini kirletmek, masaya çalışan bir parça getirme cesaretini göstermek.

‍
Onboarding örneğinde tıkanmış bir kararı, n8n örneğinde çatırdayan bir altyapıyı aynı refleksle çözebildik. Sizin de sahanızda bekleyen, haftalardır tartışılan, kapanmayan kararlar olacaktır. Yarın işe başladığınızda bu kararlardan en zorlu olanını seçin ve bir prototip ile geri dönün. Sonucu kendiniz göreceksiniz. Unutmayın: Aynı sorun, iki farklı PM. Biri brief ile geliyor, diğeri çalışan bir parçayla. Aradaki fark, kariyerinizin bundan sonraki seyrini belirleyecek.

‍