Sprint retrospektiflerinde oturan bir ürün yöneticisiyseniz muhtemelen bir şeyi fark etmişsinizdir: Konuşma mühendislik sürecine doğru kayıyor. Sprint nasıl planlandı? İyi tahmin ettik mi? Engelleyenler var mıydı? İş akışımızda neleri geliştirebiliriz?
Bunlar meşru sorulardır. Ancak rolünüzle ilgili temel bir şeyi gözden kaçırıyorlar: Doğru şeyleri mi geliştiriyoruz?
Sprint retroları teslimat için optimize ediliyor. Ürün retroları öğrenme ve değer için optimize edilir. Her ikisine de ihtiyacınız var ve bir Proje Yöneticisi olarak ürün odaklı sürümü hayata geçirmesi gereken kişi muhtemelen sizsiniz.
Bir Ürünü Retro'dan Farklı Kılan Nedir?
Standart bir sprint retrosu uygulamaya bakar. Bir ürün retrosu sonuçlara bakar. Aradaki fark ince ama önemlidir.
Uygulama odaklı bir retroda soru şu: "Taahhüt ettiğimiz şeyi yerine getirdik mi ve süreç nasıldı?" Sonuç odaklı bir retroda soru şu: "Sunduklarımız beklediğimiz değeri yarattı mı ve ne öğrendik?"
Bir Proje Yöneticisi olarak bu iki bakış açısı arasında köprü kurabilecek benzersiz bir konumdasınız. Müşteri ihtiyacını, stratejik bahsi, mühendislik ödünleşimlerini ve pazarın tepkisini görüyorsunuz. Ürün retrosu, tüm bunları sentezleyerek ekibinizin harekete geçebileceği öğrenime dönüştürdüğünüz yerdir.
Bir sprint retrosunun genellikle inceleyemediği, bir ürün retrosunun incelediği şeyler şunlardır:
- Gönderdiğiniz özelliklerin önemsediğiniz metrikleri taşıyıp taşımadığı
- Planlarınızı değiştirmesi gereken müşteriler hakkında öğrendikleriniz
- Bahislerinizin ve hipotezlerinizin doğrulanıp doğrulanmadığı veya geçersiz kılınması
- Ürün, mühendislik, tasarım ve diğer işlevlerin (yalnızca teslimatlar için değil) kararlarda ne kadar iyi işbirliği yaptığı
- Şu anda bildiklerinize göre yol haritanızın hâlâ anlamlı olup olmadığı
Gerçekten İşe Yarayan Beş Format
Farklı durumlar farklı yaklaşımlar gerektirir. İşte her biri farklı bir bağlama uygun olan beş format. Her seferinde aynı seçeneği varsayılan olarak ayarlamayın.
1. Keşif / Oluşturma / Lansman
En iyisi: Daha uzun döngülerde çalışan veya önemli bir girişimi yeni tamamlamış ekipler.
Retro'yu ürün yaşam döngüsünün üç aşamasına bölün:
- Keşif: Çözüme geçmeden önce sorunu yeterince iyi anladık mı? Kaçırdığımız veya göz ardı ettiğimiz sinyaller var mıydı? Yeterince doğru müşteriyle konuştuk mu?
- Derleme: Oluşturduğumuz çözüm aslında tanımladığımız soruna çözüm buldu mu? Kapsamın genişlemesi veya teknik kısıtlamalar sunduklarımızı amaçladığımıza göre nerede değiştirdi?
- Lansman: Lansman doğru kitleye ulaştı mı? Evlat edinme beklentileri karşıladı mı? Müşterilerin tepkisinde bizi şaşırtan şey neydi?
Bu format işe yarıyor çünkü ekibi yalnızca son kilometreyi değil yolculuğun tamamını değerlendirmeye zorluyor.
2. Müşteri / Ekip / İşletme
En iyisi: Ürün, mühendislik, tasarım, pazarlama ve desteğin uyum içinde olması gereken işlevler arası ekipler.
Aynı dönemdeki üç mercek:
- Müşteri: Müşterilerimiz hakkında ne öğrendik? Gerçek sorunları mı yoksa varsayılan sorunları mı çözdük? Lansman sonrasında ne tür geri bildirimler alıyoruz?
- Ekip: Çeşitli işlevlerde birlikte ne kadar iyi çalıştık? Doğru zamanda doğru kişiler mi dahil oldu? Aktarımlar nerede bozuldu?
- İş: Bu çalışma iş hedeflerimize katkıda bulundu mu? Taahhüt ettiğimiz ölçümlere uygun yolda mıyız? YG nasıl görünüyor?
Bu biçim, müşterilerin istekleri, ekibin sunabilecekleri ve işletmenin ihtiyaçları arasında gerilim olduğunda kullanışlıdır. Gerginliği açıkça ortaya koymak, kaynamasına izin vermekten daha sağlıklıdır.
3. Hipotez / Deney / Öğrenme
En iyisi: Büyüme odaklı ekipler, erken aşamadaki ürünler veya çok sayıda deneme yapan ekipler.
Retro'yu öğrenme döngünüz etrafında yapılandırın:
- Varsayım: Bu döngüye girerken neye inandık? Hipotezlerimiz açıkça ifade edilmiş miydi, yoksa hiçbir zaman dile getirmediğimiz varsayımlar üzerine mi inşa ediyorduk?
- Deney: Bu hipotezleri test etmek için ne yaptık? Öğrenmenin en hızlı yolu bu muydu, yoksa doğrulamadan önce gereğinden fazla mı geliştirme yaptık?
- Öğrenim: Daha önce bilmediğimiz neyi şimdi biliyoruz? Bu planlarımızı nasıl değiştirmeli? Hangi yeni hipotezleri oluşturmalıyız?
Bu biçim kasıtlı olarak rahatsız edicidir. Bilmediğinizi ve neyi yanlış yaptığınızı kabul etmeyi gerektirir. Önemli olan da bu.
4. Neler Gönderildi / Neler Öğrendik / Sırada Ne Var
En iyisi: Sık sık gönderim yapan ve hızlı, hafif bir formata ihtiyaç duyan sürekli teslimat ekipleri.
Üç sütun, hızlı geçişler:
- Gönderildi: Kapıdan ne çıktı? Planladığımız şey miydi yoksa öncelikler mi değişti?
- Öğrenildi: Kullanım verileri, müşteri geri bildirimleri ve ekip deneyimi bize ne anlatıyor? Sürpriz var mı?
- Sonraki: Öğrendiklerimize dayanarak bundan sonra neye öncelik vermeliyiz? Yol haritasında herhangi bir şeyin değişmesi gerekiyor mu?
Bu en pragmatik formattır. Konuşmayı son çalışmalara ve ileriye dönük bir temele oturtuyor. İki haftada bir retro yapan ve düşünmeye bir saat bile harcamak istemeyen takımlar için iyi.
5. Başlat / Durdur / Devam Et (Ürün Kararları Sürümü)
En iyisi: Zorlu önceliklendirme çağrıları yapması gereken ekipler.
Klasik başlat/durdur/devam et, ancak süreçten ziyade özellikle ürün kararlarına uygulanır:
- Başlayın: Şu anda göz ardı ettiğimiz neye yatırım yapmaya başlamalıyız? Hangi müşteri ihtiyaçlarına veya pazar sinyallerine yanıt vermiyoruz?
- Dur: Zaten zaman ayırmış olsak bile ne yapmayı bırakmalıyız? Hangi bahisler sonuç vermiyor? Kimsenin kullanmadığı hangi özellikleri koruyoruz?
- Devam: İşe yarayan ve daha fazla yatırımı hak eden şey nedir? Nerede ilgi görüyoruz?
"Durdur" sütunu en zor ve en değerli kısımdır. Proje Yöneticilerinin nadiren "bunu sonlandırmalıyız" diyecek bir forumları olur; bu format onlara bir forum sağlar.
Ürüne Özel Sorulacak Sorular
Biçimi ne olursa olsun, dönüşümlü olarak okuduğunuz soruların bir listesini tutun. Her zaman hepsini değil. Mevcut döngüyle alakalı olduğunu düşündüğünüz iki veya üç tanesini seçin.
Müşteri değeri hakkında:
- Bu sprintte hiçbir şey göndermeseydik müşteriler neyi kaçırırdı?
- Başlattığımız özellikleri duyuyor muyuz yoksa sessizlik mi var?
- Yaptıklarımızla müşterilerin gerçekte ihtiyaç duyduğu şeyler arasındaki fark nedir?
Stratejik uyum hakkında:
- Az önce tamamladığımız çalışma bizi üç aylık hedeflerimize yaklaştırıyor mu?
- Stratejik açıdan alakasız acil işlere zaman mı harcıyoruz?
- Bir rakip geçen ayki üretimimizi görseydi stratejimiz hakkında ne gibi bir sonuca varırdı?
Öğrenme hızı hakkında:
- Geçen döngüde öğrenemediğimiz neyi bu döngüde öğrendik?
- Geri bildirim almak için nerede çok uzun süre bekledik?
- Hangi varsayımın yanlış olduğu ortaya çıktı ve biz buna nasıl karşılık verdik?
Fonksiyonlar arası sağlık hakkında:
- Tasarım ihtiyaç duyduğu şeyi yeterince erken elde etti mi?
- Mühendislik girdisi gerektiren ancak bunu çok geç alınana kadar alamadığınız kararlar var mıydı?
- Destek ve satış, bizim duymadığımız şeyleri mi görüyor?
Eylem Öğelerinin Kalıcı Hale Getirilmesi
Ürün retroları için en büyük başarısızlık modu, hiçbir yere varmayan analizler üretmektir. Toplantıdan enerji dolu ayrılıyorsunuz ve iki hafta sonra hiçbir şey değişmedi.
Çözüm spesifikliktir. Bunları karşılaştırın:
Belirsiz: "Müşterilerle daha fazla konuşmamız gerekiyor."
Özel: "Bildirimlerin yeniden tasarımını belirlemeden önce, [PM adı] bildirim tercihlerine odaklanan beş müşteri görüşmesi gerçekleştirecek. Görüşmeler 14 Mart'a kadar tamamlanacak."
Belirsiz: "Daha çok veriye dayalı olmalıyız."
Belirli: "Geliştirme başlamadan önce her özelliğe ilişkin başarı ölçümlerini tanımlayacağız ve bunları lansmandan sonraki iki hafta retro döneminde inceleyeceğiz."
Belirsiz: "Fonksiyonlar arası iletişimin iyileştirilmesi gerekiyor."
Özel: "Tasarım, geri bildirim için sprint planlamasından en az üç gün önce #product kanalındaki tel çerçeveleri paylaşacak. Sonraki sprint'e başlıyoruz."
Her eylem öğesinin bir sahibi, bir teslimatı ve bir tarihi olmalıdır. Her yeni retronun başlangıcında önceki retronun eylem öğelerini gözden geçirin. Aynı işlem öğesi hiçbir ilerleme olmadan iki kez görünüyorsa bu, ya daha fazla ayrıntıya bölünmesi gerektiğinin ya da aslında bir öncelik olmadığının işaretidir.
Zamanlama ve Ritim
İki haftada bir çoğu ürün ekibi için iyi bir varsayılan değerdir. Yaygın sprint uzunluklarına uygundur ve yeni verilerin ve müşteri tepkilerinin ortaya çıkması için yeterli süreyi sağlar.
Aylık, daha uzun keşif döngüleri yapan ekipler için veya Proje Yöneticisinin birden fazla ekibi denetlediği ve gerçekçi bir şekilde her biriyle iki haftada bir retrospektif çalışmalar yapamadığı durumlarda daha iyi çalışır.
Büyük dönüm noktalarından sonra (büyük bir lansman, bir dönüm noktası, başarısız bir deney), normal temponuz ne olursa olsun özel bir retro dönemi garanti eder. Bunlar genellikle daha uzun (60 ila 90 dakika) ve daha stratejik olma eğilimindedir.
Normal ritim ritminizi 45 ila 60 dakika arasında tutun. Sürekli olarak aşırı koşuyorsanız ya çok fazla kapsamı kaplıyorsunuz ya da zamanı etkili bir şekilde işleyemiyorsunuz.
İzlenecek Anti-Desenler
"Her şey yolunda" retrosu. Eğer retrolarınız hiçbir zaman sorun çıkarmıyorsa, bir şeyler ters gidiyor demektir. Ya insanlar eleştirel olma konusunda kendilerini güvende hissetmiyorlar ya da yeterince anlamlı sorular sormuyorsunuz. Daha dürüst geri bildirim almak için anonim girdi toplamayı deneyin.
PM monologu. Konuşmanın çoğunu Başbakan yaparsa, retro bir öğrenme oturumu değil, bir durum güncellemesi haline gelir. Sizin göreviniz mevcut olmak değil, kolaylaştırmaktır. Soru sorun ve boşluğu başkalarının doldurmasına izin verin.
Suçlama oturumu. Retrolar bireylerle değil, sistemler ve süreçlerle ilgili olmalıdır. Konuşma "şu kişi X'i yapmadı" şeklinde bir noktaya doğru kayarsa, "Sürecimiz bu boşluğun oluşmasına nasıl izin verdi?" sorusuna yönlendirin.
"Bir dahaki sefere düzelteceğiz" döngüsü. Aynı sorunları çözmeden tanımlamaya devam ederseniz, retro, gelişmek yerine şüphecilik yaratır. Yinelenen sorunları, seviyeleri atlamak, toplantı planlamak veya mimari incelemeleri gibi, bunları gerçekten çözebilecek herhangi bir foruma iletin.
Başlarken
Daha önce ürüne özel bir retro yürütmemiş bir PM iseniz, başlamanın en basit yolu şudur: Bir sonraki sprint retronuzun sonuna 15 dakika ekleyin ve bir soru sorun:
"Bu sprint'te neler gönderdiğimize baktığımızda, bunun müşteriler için önemli olduğuna dair elimizde hangi kanıt var?"
Bu soru tek başına konuşmayı çıktıdan sonuçlara kaydıracaktır. Ekip bu soruyu değerli bulursa (ki kesinlikle öyle yapacaktır) özel bir ürün retrosu önerme fırsatına sahip olursunuz.
Ürün yönetimi temel olarak rakiplerinizden daha hızlı öğrenmekle ilgilidir. Düzenli ürün retrosu, öğrenmeyi tesadüfi olmaktan ziyade sistematik hale getiren uygulamadır.
NextRetro'yi ücretsiz deneyin -- Tartışmaları odaklı tutmak için yerleşik oylama ve aşama yönetimi özelliklerine sahip, ürün ekipleri için tasarlanmış 17'den fazla retrospektif şablon arasından seçim yapın.
Son Güncelleme: Şubat 2026
Okuma Süresi: 8 dakika
