Müşteriler toplu düzenleme istiyor, mühendislik “beş hafta” diyor, kimse faturaların neden bu kadar çok düzeltildiğini sormuyor. 2026'da aynı iş beş hafta değil, bir öğleden sonra. Maliyet düşünce “yazmayalım” demek için elinde ne kalıyor?
The Product Notebook'un 3 Ekim sayısı tanıdık bir sahneyle açılıyor. Küçük işletmelere fatura aracı yapan bir ekibin ürün yöneticisisin. Destek sohbetlerinde, satış görüşmelerinde, mağaza yorumlarında aynı talep dönüp duruyor: faturalar için bulk edit (toplu düzenleme). Tasarım çoklu seçim akışını çiziyor, mühendislik işi beş hafta olarak boyutlandırıyor, biri ticket açıyor ve iş roadmap'e oturuyor.
Yazar Seyifunmi Olafioye, hukuktan fintech'e geçmiş ve kredi ürünlerinde çalışan bir ürün yöneticisi; bülteni üç yıldır yazıyor. Yazısının tezi tek cümle:
Müşterinin sorunu, kendiliğinden bir feature (özellik) talebi demek değil.
Seyifunmi Olafioye, The Product Notebook, 3 Ekim 2026 (çeviri bize ait)Olafioye'ye göre tuzak, sorunun sessizce değişmesinde. Müşteri görüşmesinden çıkarken soru şu: neden zorlanıyorlar ve ne gerçekten iyileştirir? Sprint planlamasına varana kadar “ne inşa edelim”e dönüşüyor. İlki bütün seçenekleri açık bırakıyor, “bu şimdi çözmeye değmez” dahil. İkincisi cevabın bir feature olduğuna çoktan karar vermiş; sadece hangisi olacağını tartışıyor.
Yazılımdan önce dört basamak
Önerisi bir merdiven: “en basit müdahale testi”. Bir şikayet roadmap'e girmeden önce beş sorudan geçiyor ve yazılım ancak sonuncusunda konuşuluyor.
Çoğu ekibin erken durduğu yer üçüncü basamak. Fatura örneğinde müşterilerin neyi düzelttiğine bakınca desen hemen çıkıyor: neredeyse hep KDV. Hesapların büyük kısmı yanlış vergi ayarıyla açılmış. Kimi mükellef olmadığı halde KDV eklemiş, kimi yüzde 7,5 kesmesi gerekirken boş bırakmış. Bir adım daha geri gidince kaynak görünüyor: onboarding'in üçüncü adımına gömülmüş, muhasebe diliyle yazılmış, açıklamasız bir soru. İnsanlar tahmin edip geçiyor, sonra aylarca o tahminin arkasını topluyor.
Senaryodaki ekip bulk edit'i yazmıyor. Onboarding'deki soruyu sade dille yeniden yazıyor, KDV'nin ne zaman geçerli olduğunu anlatan tek satır ekliyor, destek ekibi etkilenen hesaplara ulaşıp ayarı bir kez düzeltiyor. Düzenleme talepleri büyük oranda kesiliyor, beş hafta başka işe gidiyor. Olafioye'nin hükmü: bulk edit temizliği hızlandırırdı, dağınıklığı durdurmazdı.
Peki ekipler neden hep yazılıma koşuyor? Olafioye üç neden sayıyor. Yazılım görünür: lansmanı, sürüm notu, iş değerlendirmesinde gösterilecek bir satırı var. Ürün yöneticisi neyi yazmamayı seçtiğiyle değil, neyi çıkardığıyla ölçülüyor; “bir e-postayla çözdük” diyene genel toplantıda kimse teşekkür etmiyor. Bir de sprint'te boş kapasite varsa onu doldurmanın en kolay yolu bir müşteri şikayeti.
Aynı günlerde X'te soru başkaydı: yazmak bedavaysa?
Yazı tek başına okunsa iyi bilinen bir dersin temiz anlatımı. Onu gündeme taşıyan şey, bir hafta önce başlayan tartışma. 26 Eylül'de yazılım danışmanı Lewis Campbell şunu yazdı:
Altına yüzlerce cevap geldi. Bir kısmı itiraz etmedi, düzeltti: etki var, ama ters yönde. Kurucu Alex Mrvaljevich'in cevabındaki cümle tartışmanın özeti gibi: ürün ekipleri ihtiyaç duymadığımız feature'ları taşırıyor, çünkü “bir PR prompt'lamak patronunla tartışmaktan kolay”. @woodilicious daha kısa yazdı: çok yeni feature görüyorum, çok yeni faydalı feature görmüyorum.
Dört gün sonra Allen Holub aynı yere parmak bastı. Holub, yazılım mimarisi ve çevik yöntemler üzerine onlarca yıldır yazan ve ekiplere danışmanlık veren bir isim:
İki gün sonra bir düşünce deneyi ekledi. Bütün darboğazlar kalksın, sekiz aylık işi sekiz saatte çıkar. O sekiz aylık iş programın yüzde 10'unu değiştiriyorsa kullanıcı her sabah yüzde 10'u baştan öğrenmek zorunda kalır. Öyle bir program kullanılamaz, çünkü değişimin hızı insanın değişimi kaldırma kapasitesini geçemez. Teknoloji analisti Ben Dickson da aynı gün benzer bir cümle kurdu: herkes AI'a olabildiğince çok kod yazdırıyor, neyin yazılmayacağına karar veren az.
Bu, Olafioye'nin örneğine yeni bir soru sorduruyor. Bulk edit beş hafta değil de bir öğleden sonra sürseydi, ekip yine yazmamayı seçer miydi?
Karşı cephe: pahalı olduğu için yapılamayanlar
Campbell'ın altındaki itirazlardan biri Yeni Zelandalı yazılımcı Daniel'den geldi:
Bu ciddiye alınacak bir itiraz. Her backlog'da maliyet yüzünden yıllarca bekleyen, kimsenin “kötü fikir” demediği işler var. Holub'un altında @zynque aynı yere başka açıdan geldi: sana gereksiz görünen feature'ların çoğu başka bir müşterinin sorununu çözüyor; o zaman mesele sayı değil, onları karmaşıklık yaratmadan sunabilmek.
Olafioye de kendi tezinin sınırını çiziyor. Ayda 200 müşteride işleyen elle çözüm 20.000'de sessizce kırılıyor: destek ekibi yükü emiyor, sonra tükeniyor, operasyon maliyeti hiçbir roadmap'te görünmediği için kriz olana kadar kimse fark etmiyor. Önerisi, yazılım dışı çözümü son kullanma tarihi olan bir karar gibi ele almak: hangi hacimde ya da maliyette yeniden bakacağını baştan belirle ve gerçekten bak.
“Önce dur” diyenler
- Şikayet sorunun göründüğü yer, başladığı yer değil
- Her feature öğrenilecek, test edilecek, desteklenecek kalıcı bir yüzey
- Kullanıcının değişimi kaldırma kapasitesi sınırlı
“Ucuzsa yaz” diyenler
- Maliyet yüzünden bekleyen iyi fikirler artık yapılabiliyor
- Sana gereksiz gelen feature başka müşterinin sorununu çözüyor
- Elle çözüm, ölçek büyüyünce destek ekibini tüketiyor
Dördüncü basamak artık eleme yapmıyor
İki cephe de yarı haklı, ama merdivenin farklı basamaklarından konuşuyorlar. Daniel dördüncü basamağı anlatıyor: en ucuz çözüm ne? 2026'da bu sorunun cevabı giderek daha sık “yazılım” çıkıyor. Bir ajanla bir öğleden sonrada biten bulk edit, onboarding metnini yeniden yazıp destek ekibine tek tek hesap düzelttirmekten ucuz bile olabilir.
Olafioye'nin örneğinde bulk edit'i eleyen şey ise beş haftalık maliyet değil. Onu eleyen üçüncü basamak: sorun onboarding'de başlıyor ve bulk edit oraya dokunmuyor. Yazmak bedava olsaydı da yanlış yere yazılmış olurdu. Yeni açılan her hesap aynı yanlış ayarla başlamaya, müşteri de aynı temizliği yapmaya devam ederdi; sadece daha hızlı.
Yani maliyet düşünce merdivenin yükü yer değiştiriyor. Eskiden kötü fikirlerin çoğunu mühendislik tahmini elerdi. O filtre gevşedi; artık işi üçüncü basamağın görmesi gerekiyor. “Yazmayalım” demek için elindeki tek gerekçe “pahalı” idiyse, o gerekçe artık yok.
Yazmak ucuzladı. Ürüne eklediğin şeyle yaşamak ucuzlamadı.
Ucuzlayan inşanın iyi bir tarafı da var ve Daniel'in “iç araçlar” dediği yer tam orası. Aynı öğleden sonrayı bulk edit yerine bir sorguya harcayabilirsin: son üç ayda düzenlenen faturalarda hangi alan değişmiş? Bu, kullanıcının önüne hiçbir şey koymayan ve işi bitince atılabilen bir araç. Ucuz yazılımın en güvenli kullanımı ürünü büyütmek değil, üçüncü basamağı hızlandırmak.
Fatura aracı gerçek bir vaka değil. Olafioye sahneyi “diyelim ki” diye kuruyor; taleplerin kesilmesi de senaryonun parçası, ölçülmüş bir sonuç değil. X tarafındaki cümleler de izlenim: bu tartışmada kimse çıkan feature'ların ne kadarının kullanılmadığını saymadı. Campbell'ın “sıfır etki”si bir gözlem, Holub'un yüzde 10'u bir düşünce deneyi, Daniel'in iç araçlar notu kendi çevresinden bir tanıklık. Elimizde bir kalıp ve iyi kurulmuş bir argüman var, veri yok.
Brick'in duruşu
Bize göre asıl soru “yazalım mı, yazmayalım mı” değil. O bir maliyet sorusu ve maliyet her ay değişiyor. Değişmeyen soru şu: sorun nerede başlıyor? Buna cevabın yoksa bedava feature bile pahalı, çünkü yanlış yere konmuş bir çözüm asıl sorunu görünmez kılıyor. Bulk edit çıksaydı şikayetler de azalırdı ve onboarding'deki o soruya bir daha kimse bakmazdı.
Alive Baku'da iki konuşma aynı yere farklı kapılardan girmişti. Commencis ekibi fikirleri öldüren soruyu “kaç gün sürer” diye teşhis etti. O sorunun cevabı “bir öğleden sonra” olunca iyi fikirler kurtuluyor, ama kötü fikirleri durduran fren de kalkıyor. Maksim Evdokimov da AI'ın “nasıl”ı hızlandırdığını, “ne”yi hızlandırmadığını anlatmıştı. Olafioye'nin merdiveni o “ne” sorusunun gündelik hali.
Backlog'undaki en çok istenen talebi al. Boyutlandırmadan önce talebin arkasındaki davranıştan 20 örnek topla ve tek bir şeyi etiketle: kullanıcı tam olarak neyi yapıyor, neyi düzeltiyor? Desen çıkarsa bir adım geri git ve nerede başladığına bak. Yazılım dışı bir çözüm seçersen yanına bir eşik yaz: “ayda şu kadar talebi geçerse yeniden bakarız.”
Senin backlog'unda maliyeti düştüğü için öne geçen kaç iş var ve kaçında sorunun nerede başladığını biliyorsun?
Bizce inşa etmek ucuzladıkça, neyi inşa etmediğin ürününün asıl imzası oluyor. 🧱
