Backlog’un büyüklüğü, müşteriyle konuşma sıklığıyla ters orantılıdır

• Müşterilerle ne kadar sık konuşulursa backlog’un büyüklüğü o kadar azalır
• Planlama zamanını müşterilerle yapılan konuşmalarla değiştirmek önemlidir
• Geliştiriciler ile müşteriler arasında ne kadar çok aracı varsa, ürünün müşterinin ihtiyaçlarını karşılama olasılığı o kadar düşer
• Büyük bir backlog, çok sayıda doğrulanmamış varsayım olduğu ve müşteri değeri yaratma olasılığının düşük olduğu anlamına gelir

UI tasarımından çok teknik bileşen tasarımına odaklanın

• UI tasarımına fazla zaman harcamayın; temel bir UI’ı hızla yayına alıp, müşteri geri bildirimiyle geliştirmek önemlidir
• Teknik borcu düşük tutarak müşterilerin ihtiyaç duyduğu değişiklikleri hızlıca yapabilmelisiniz

İnsanların bir uygulamayı kullandığını düşündüğünüz biçim ile gerçekte kullanma biçimleri farklıdır

• Müşterilerin uygulamayı nasıl kullandığını gözlemlemek önemlidir
• Kullanıcı davranışını doğrudan gözlemlemek, yalnızca nicel metriklerle görülemeyen içgörüler sağlayabilir

Hesap spoofing uygulaması

• Belirli bir müşterinin gerçekte hangi ekranı gördüğünü anlamak için hesap spoofing özelliğine yatırım yapmak önemlidir
  • Hesap spoofing(Account Spoofing), yöneticinin belirli bir production kullanıcısı gibi uygulamayı kullanabilmesini sağlayan özelliktir
• Bu sayede sorunlar etkili biçimde teşhis edilebilir ve test verisine olan bağımlılık azaltılabilir

İlk sayfanın önemi

• Uygulamaya ilk kez giren müşteriye en ilgili bilgileri kısa ve net biçimde sunmalısınız
• İlk sayfaya çok fazla bilgi koymaya çalışmak, kullanıcının bilişsel yükünü artırır

En önemli pazarlamacı müşteridir

• NPS(Net Promoter Score), müşterinin ürünü tavsiye edecek kadar güçlü bir memnuniyet duyup duymadığını gösteren iyi bir metriktir
• Reklam bütçesi harcanabilir, ancak memnun müşterilerden başlamak daha etkili bir pazarlama stratejisidir

MVP, yinelemeli iyileştirme olmadan anlam taşımaz

• MVP, yalnızca tarih baskısını gerekçe göstererek düşük kaliteli bir müşteri deneyimi sunmanın bahanesi olmamalıdır
• MVP, ek iterasyon gerekip gerekmediğini ve gerekiyorsa hangi noktaların iyileştirilmesi gerektiğini belirlemeye yardımcı olur

GN⁺ görüşü

• Bu yazıdaki en önemli nokta, müşterilerle sürekli diyalog kurarak gerçek kullanıcı ihtiyaçlarını yansıtan ürün geliştirmenin önemidir
• Müşteri geri bildirimini hızla yansıtabilen esnek UI tasarımı ile teknik bileşenlerin önemini vurgular
• MVP’nin ötesine geçip ürünü sürekli iyileştirmenin ve müşteri memnuniyetini artırmanın uzun vadeli başarıya yol açabileceğini gösterir
• Bu yazı, startup hayatından çıkarılan dersleri paylaşarak kuruculara ve geliştiricilere pratik içgörüler sunar

[GN⁺]

Hacker News görüşleri

• Özellik/iyileştirmeleri organize etme yöntemine dair görüş

  • Deneyime göre, her fikri bir ticket'a dönüştürme stratejisi verimsizdir. Bu, asla kullanılmayacak fikirlerle dolu bir "icebox" oluşturur.
  • Önemli bir anlaşma için icebox'taki bir fikre ihtiyaç duyulduğunda bile, o fikrin var olduğu hatırlanmadığı için yeni bir ticket oluşturulur.
  • Kısa veya orta vadede gerçekleştirilebilir ticket'lar tercih edilir; diğer fikirler ise ayrı yerde saklanır.
  • Mühendislik ekibi çözmek istediği teknik borçların listesini, PM ise proje bazlı iyileştirme fırsatları listesini tutar.
  • Yeni özellik/ürünler için PRD yazılır, ancak bunlar hemen ticket'a dönüştürülmez.
  • Büyük kısmı asla ele alınmayacak devasa bir backlog, "hayır" demekten korkan zayıf bir PM'in işaretidir.

• Backlog büyüklüğü ile PM değişim oranı arasındaki ilişki

  • Backlog'un büyüklüğü, PM değişim oranıyla ters orantılıdır.
  • Kıdemli PM'ler için backlog, geçmiş ürün konuşmalarına dair bir hafıza yardımcısıdır.
  • Yeni PM'ler backlog'a bakınca kafası karışır ve anlamadıkları şeyleri temizlemeye çalışır.

• Müşteri temelli backlog tutmaya karşı görüş

  • Backlog tutan ekiplerin çoğu backlog'u müşterilerden alır.
  • "Müşterinin hayatını iyileştirecek özellikleri bulup bir sonraki özelliği yap" demek o kadar basit değildir.
  • Birden fazla müşteri varsa ve her birinin hayatını iyileştirecek özellikler birbiriyle alakasız ve karmaşıksa ne yapılacaktır?
  • Müşteri talepleri her zaman dinlenmelidir, ancak talep ettikleri şey neredeyse hiç doğrudan yapılmamalıdır.
  • Müşteriler, yalnızca UX uygulamasını değil; problemi ve şu anda kullandıkları iş süreçlerini ima eden özellikler talep eder.
  • İş problemini tespit etmek, UX uygulama fikirlerini ve sürece özgü ayrıntıları ayıklayıp atmak gerekir.
  • İş problemini çözen en küçük özellik, ekonomik biçimde, iyi bir UX tasarımıyla ve tutarlı şekilde inşa edilmelidir.

• Müşteri gereksinimlerini kaydetmek için PM ihtiyacı

  • PM'in müşteri gereksinimlerini kaydedebileceği bir yere ihtiyacı vardır.
  • Özel bir araç yoksa, gereksinimler çoğunlukla Jira ticket'larına dönüşür.
  • ProductBoard ve Jira Product Discovery olmak üzere iki yaklaşım vardır.
  • ProductBoard, CRM yaklaşımıyla çalışır; tüm müşteri etkileşimlerini kaydeder ve daha sonra bunları gereksinimlere ve istek listesine ayırır.
  • Jira Product Discovery ise fikirlerle başlar ve müşterilerden duyulan her şeyi anında uzun bir gereksinim ve istek listesine ayırmayı gerektirir.
  • Jira Product Discovery'nin avantajı, fikir listesini geliştirici backlog'undan ayırmasıdır; ancak bunun yerine başka bir uzun liste oluşturur.
  • Ürün önceliklerini müşteri konuşmalarına dayanarak analiz etmek için ProductBoard daha iyi bir ürün keşfi aracıdır.

• Müşteri geri bildirimiyle rafine edilen backlog'un önemi

  • Neredeyse her gün müşterilerle konuşulduğu için, backlog'daki özellikler ve iyileştirmeler doğrudan müşteri geri bildiriminden beslenir ve bununla rafine edilir.
  • Yapılacak işler her zaman çoktur, ancak farkı yaratan şey backlog'un müşteri geri bildirimiyle şekillenip şekillenmediğidir.

• Müşterilerle günlük konuşmalar yoluyla backlog yönetimi

  • Teknik bir kişi olarak her gün müşterilerle konuşurken, teori cazip gelse de bazı sorunlar vardır.
  • Güncellik yanlılığı ve fırsat maliyeti: daha yüksek öncelikler nedeniyle kasıtlı olarak çalışılmayan problem alanları hakkında da geri bildirim toplamayı sürdürmek gerekir.
  • Tepkisel geliştirme: geri bildirimi kaydetme adımı atlanırsa, en son ve en kolay erişilebilen işlere odaklanılır ve eski problemler gözden kaçırılır.
  • Ekip bilgi tabanı: geri bildirim toplayıp çözüm sunacak tek bir sorumlu varsa, OP'nin iddiası geçerli olabilir.
  • Ekip işin içindeyse, veri noktalarını eşzamansız olarak kaydedip arayabilecekleri ortak bir veritabanına ihtiyaç vardır.
  • Backlog hızla büyüyebilir, ancak karmaşık sistemler ve insanlarla uğraşmak doğası gereği zorluk taşır.
  • İyi organize olmuş ekipler için backlog'un iyi yönetimi gerekir; buna alakasız işleri arşivlemek, mükerrer işleri kaldırmak, düzenli önceliklendirme yapmak ve araçları en iyi şekilde kullanmak dahildir.
  • Önemli olan araçtan çok backlog'u yönetmektir; ayrıca gerektiğinde daha derine inilebilecek bilgileri yüzeye çıkaran, backlog'un üzerinde bir "façade" katmanı gerekebilir.

• Uygulama kullanıcılarını gözlemlemenin önemi

  • Müşterilerin uygulamayı nasıl kullandığını gözlemlemek önemlidir.
  • Her metriği takip edebilirsiniz, ancak bir kullanıcının bir şeyi bulmak için kaydırdığını, geri tuşuna bastığını ya da tıklanamayan bir şeye tıklamaya çalıştığını görmek çok daha gerçek bir deneyimdir.
  • Apple, Google ve diğer tüm şirketlerin kullanıcıları her gün birden fazla kez gözlemlemesini isterdim.

• Büyük backlog'ların faydasızlığı

  • Büyük backlog'lar çok sayıda belirsiz varsayım içerir ve müşteri değeri üretme olasılıkları düşüktür.
  • Bir şeyin değerli olduğunu varsayma hatası defalarca yapılmıştır ve çoğu zaman kimsenin umurunda olmadığı görülür.
  • Büyük backlog'lar, müşterilerle konuşma sıklığının düşük olduğunu yansıttığı için onlara son derece şüpheci yaklaşmak gerekir.

• Hesap spoofing uygulamasına dair uyarı

  • Hesap spoofing, prod ortamındaki sorunları test etmenin kolay bir yolu olabilir; ancak destek ve geliştirme ekiplerinin prod verisine güven duyması gerekir.
  • Bazı sektörlerde bu, müşteriler için ciddi bir problem olabilir.
  • Son çalışılan startup'ta geliştiricilerin prod verisine hiçbir şekilde erişmesine izin verilmiyordu.
  • Bu, güvenlik açısından yalnızca son çare olarak görülmelidir; müşteri verisine erişilemeyeceği varsayımıyla çalışmak daha iyidir.

• Ürün planlamasının ağaç yapısı

  • Ürün planlaması her zaman ağaç yapısında olmalıdır.
  • En üst düğüm iş hedefleridir; onun altında ürünler, onların altında müşteri problemleri ve onların altında backlog kalemleri yer alır.
  • Çok fazla backlog kalemine sahip olmak, doğru yapının kurulmadığını ve önceliklendirilmiş bir iş hedefleri listesi olmadığını gösterebilir.
  • "Müşterilerle konuşmak", müşteri problemlerini anlamak için faydalıdır; ancak önce iş hedeflerini bilmek gerekir. Aksi halde zaten üzerinde çalışılmayacak alanlardan geri bildirim toplayarak zaman kaybedilir.