Geçen ay a16z'nin bir blog yazısı sessiz sedasız yayınlandı. Başlık sıradan görünüyordu ama içinde bir cümle vardı:
"Her yapılabilecek özellik yapılacak."
Bu cümleyi iki kere okudum. Sonra bir kere daha.
Yazılım geliştirme, tarihsel olarak kıtlık üzerine kuruluydu. Mühendislik kapasitesi sınırlıydı, sprint planlaması bu kıtlığı yönetmek için vardı. Backlog bir bekleme listesiydi — "bunları yapmak istiyoruz ama şu an sıra yok."
AI coding agentları bu denklemi değiştirdi. Artık küçük bir özellik saatler içinde yapılabiliyor. Orta boyutlu bir şey birkaç gün. Teknik kısıt hâlâ var, ama eskisi kadar değil.
Peki bu PM için ne anlama geliyor?
İlk tepki genellikle şu oluyor: "Harika! Artık daha fazlasını yapabiliriz."
Ama bu yanlış soru.
Asıl soru: kapasite kısıtı ortadan kalkınca, önceliklendirmenin anlamı ne kalıyor?
Medibulut'ta çalışırken backlog listesine bakıyorum. Diş hekimleri şunu istiyor, diyetisyenler bunu, genel klinikler başka bir şey. Hepsi makul. Hepsi "yapılabilir." Ve şimdi a16z bana "hepsini yapabilirsin" diyor.
Yapabiliriz. Ama yapmalı mıyız?
İşte bu noktada bir şey fark ettim.
Kısıt mühendislikte değilken, gerçek kısıt karar mekanizmasına geçiyor. Ve çoğu ürün ekibi bu geçişe hazır değil.
Backlog eskiden "kapasiteye göre filtrelenmiş istek listesi"ydi. Şimdi ne?
Eğer her şey yapılabilirse ve çoğunu da yapıyorsak, kullanıcıya aslında ne söylüyoruz? Ürünün odağı nerede? Hangi problemi gerçekten çözüyoruz?
Bu sorular eskiden lüks sorulardı — zamansız, soyut. Şimdi operasyonel.
a16z'nin aynı yazısında bir itiraf daha var: "Modeller neyi inşa edeceğine henüz iyi karar veremiyor. Fikirler genellikle sıradan ve türev oluyor."
Yani AI her şeyi yapabilir. Ama hangi şeyi yapacağını bilemiyor.
Bu tam olarak PM'in değer ürettiği yer.
Ama sadece "neyi inşa edeceğiz?" değil — "neyi inşa etmeyeceğiz?" de.
Diyetbulut'ta bir kullanıcı geçen ay "Tanita verilerini grafikle gösterin, haftalık trend çıkarın" dedi. Makul talep. Teknik olarak bir günde yapılabilir artık.
Yapmadık.
Çünkü aynı hafta başka bir kullanıcı "randevu hatırlatması çalışmıyor" dedi. Bu daha az gösterişli, daha az "özellik" gibi görünen bir problem. Ama kullanıcının her gün dokunduğu bir şey.
Tercih yapmak bu. Ve bu tercih, mühendislik kapasitesine bakarak değil, neyin kullanıcıya gerçekten önemli olduğuna bakarak yapılabiliyor.
Araçlar meselesine de değinmek lazım. a16z aynı yazıda şunu söylüyor: mevcut tüm araçlar icra içindir — IDE'ler kod yazmak için, Figma tasarım için, tablolar model için. Ama keşif araçları yok. Düşünmemize yardım eden, önceliklendirme yapan, "hayır" deme gerekçesi sunan modern bir araç yok.
Bu boşluk tesadüf değil. Araç pazarı "yapabilme kapasitesi"ni şekillendirmek için yarışıyor. "Neyi yapmamalıyız?" sorusunu yanıtlayacak araç henüz yazılmadı.
Belki bu bir iş fırsatı. Belki sadece PM'lerin çıplak gözle yapması gereken iş. Ama ikisi de kabul edelim ki kolay değil.
Paul Graham'ın eski bir yazısında şöyle bir şey var: "İyi ürün özellik eklemek değil, eklememeye karar vermektir."
Bu cümle AI öncesinde de doğruydu. Şimdi daha acil.
Çünkü artık "yapamayız" geçerli bir özür değil. "Yapmamayı seçtik" demen gerekiyor. Ve bunu neden seçtiğini açıklaman gerekiyor.
Bu PM için daha güç, daha görünür, daha hesap verebilir bir pozisyon.
Ve kimse bunun için hazırlanmadı.