Bir ürünün problem listesi çoğu zaman müşteri sorunları, özellik istekleri, kurucunun fikirleri ve teknik borçların aynı yerde birikmesiyle oluşur. Bu listeyi yalnız önem sırasına koymak yeterli değildir; önce maddelerin aynı tür kararları temsil edip etmediğini anlamak gerekir. MerchNivo için bu yazıda önerdiğim yöntem, mağaza sorunlarını ürün kararına dönüştürürken kullanılabilecek bir çalışma düzenidir.
Burada tamamlanmış müşteri araştırması veya kanıtlanmış ürün başarısı sunulmuyor. MerchNivo’daki kurucu ve proje yöneticisi rolüm doğrultusunda bir uygulama çerçevesi paylaşıyorum. Örnekler temsili; kullanıcı sayısı, gelir veya dönüşüm sonucu iddiası taşımıyor.
Problem cümlesini özellik adından ayırmak
“AI raporu ekleyelim” bir çözüm önerisidir. Hangi kullanıcının hangi kararını kolaylaştıracağı belirsizse bu öneriyi önceliklendirmek erken olur. Daha kullanışlı bir problem cümlesi şöyle kurulabilir: “Mağaza yöneticisi, bulunan hataların hangisinin önce düzeltilmesi gerektiğini belirleyemiyor.” Bu da başlangıçta bir hipotezdir; gerçek görüşme veya görev gözlemiyle doğrulanmalıdır.
Bir problem kaydında kullanıcı rolü, tetikleyici olay, tamamlanmak istenen görev, mevcut yöntem ve yaşanan güçlük bulunur. İstenen özellik ayrı alanda tutulur. Böylece bir çözüm elendiğinde problem kaybolmaz; farklı bir yöntem değerlendirilebilir.
Örneğin uzun bir raporu anlamakta zorlanan kullanıcı için daha fazla açıklama metni doğru çözüm olmayabilir. Öncelik sırası, örnek düzeltme veya bir insanla kısa değerlendirme daha uygun olabilir. Problem cümlesi bu alternatifleri açık tutmalıdır.
Kanıtları aynı ağırlıkta saymamak
Bir kişinin “bunu kullanırım” demesiyle aynı kişinin mevcut işini tamamlamak için tekrar tekrar yardım istemesi farklı kanıtlardır. İkisi de kayda değer olabilir, fakat aynı puana dönüştürülmemelidir. Talebin geldiği koşul ve davranışın tekrar edip etmediği belirtilmelidir.
Problem kaydında gözlem, yorum ve varsayım ayrı sütunlarda bulunabilir. “Kullanıcı raporu açtıktan sonra destek istedi” gözlemdir. “Raporu anlamadı” yorumdur. “Öncelik sırası eklenirse kendi başına ilerler” test edilecek varsayımdır. Bu ayrım olmadan görüşme notları kolayca kesin ürün kararları gibi görünür.
| Alan | Örnek kayıt | Sonraki soru |
|---|---|---|
| Gözlem | Kullanıcı üç bulgudan sonra yardım istedi | Hangi kararda durdu? |
| Bağlam | İlk mağaza değerlendirmesini yapıyordu | Deneyimli kullanıcıda da oluyor mu? |
| Mevcut yöntem | Bir uzmana ekran görüntüsü gönderdi | Yardımın asıl katkısı neydi? |
| Hipotez | Etki ve çaba açıklaması kararı kolaylaştırır | Kullanıcı açıklamayla doğru sırayı seçebiliyor mu? |
| Açık risk | Veri eksikken kesin öneri üretilebilir | Belirsizlik nasıl gösterilecek? |
Tablodaki örneklerin gerçek MerchNivo araştırma kaydı olmadığı açık tutulmalıdır. Uygulamada her satır bir görüşme veya test kimliğine bağlanır; kişisel bilgiler yayımlanmaz.
Problem grupları nasıl oluşur?
Aynı kelimeyi kullanan talepleri bir araya getirmek yeterli değildir. “Raporu dışa aktar” talebi bir kullanıcı için ekip paylaşımı, başka biri için müşteriye sunum, üçüncüsü için kendi arşivi anlamına gelebilir. Ortak düğme aynı olsa da başarı koşulları farklıdır.
Grupları tamamlanmak istenen iş üzerinden kurmak daha açıklayıcıdır: sorunu fark etme, önemini anlama, düzeltme yapma, düzeltmenin etkisini doğrulama ve başkasına aktarma. Her grubun kullanıcı bağlamı ayrıca korunur. Büyük bir ajansla tek kişilik mağazanın ihtiyaçlarını ortalamak, ikisine de uygun olmayan bir ürün doğurabilir.
İlk ürün sınırı için tek bir kullanıcı grubunun tek kararına odaklanmak mümkündür. Bunun diğer grupların önemsiz olduğu anlamına gelmediğini yazmak gerekir. Kapsam dışında bırakılan talepler gerekçeleriyle tutulur; sessizce kaybolmaz.
Öncelik puanı yerine karar notu
Etki, sıklık ve çaba için sayılar vermek tartışmayı düzenleyebilir, ancak belirsiz girdilerden çıkan hassas toplam yanıltıcıdır. “8,4 puan” gibi bir değer, altında tek görüşme bulunduğunda güvenilirlik kazandırmaz. Öncelik kararında kanıtın gücü ve yanlış çıkma maliyeti ayrıca görünmelidir.
Kısa bir karar notu şu soruları cevaplayabilir: Bu problem neden şimdi ele alınıyor? Hangi kanıt yeterli görülüyor? Hangi kullanıcılar kapsam dışında? En ucuz öğrenme yöntemi ne? Hangi sonuçta geliştirmeye devam edilmeyecek?
Bu düzen, ilk sıradaki işin mutlaka yeni özellik olmasını da önler. Eksik olay kaydı eklemek veya hata mesajını anlaşılır kılmak, büyük bir AI modülünden önce gelmesi gereken çalışma olabilir. Kararı ürünün heyecanı değil, öğrenilmesi gereken belirsizlik belirler.
Çözümden önce küçük bir görev testi
Önceliklendirme açıklamasını sınamak için tam ürün geliştirmek gerekmez. Doğrulanmış birkaç mağaza bulgusu üzerinden elle hazırlanmış bir örnek rapor kullanılabilir. Test katılımcısından ilk yapacağı düzeltmeyi seçmesi ve nedenini açıklaması istenir.
Ölçüm yalnız “beğendi mi?” sorusu olmamalıdır. Kullanıcı hangi bilgiye baktı, hangi kavramı yanlış anladı, belirsiz bulguyu kesin sonuç sandı mı, uygulanamayacak öneriyi fark etti mi? Bu gözlemler sonraki tasarım kararına daha doğrudan katkı sağlar.
Testin sınırları korunmalıdır. Elle hazırlanmış raporun anlaşılması, otomatik sistemin aynı kalitede rapor üreteceğini kanıtlamaz. Açıklama kalitesi ve otomatik tespit doğruluğu ayrı değerlendirmelerdir. İlk testte öğrenilen şeyi ikinci alanın başarısı gibi sunmamak gerekir.
Ölçüm planı ve durdurma koşulu
MerchNivo için önerilen kayıt, her problem grubunda üç ayrı çıktı tutar: kullanıcı kararının doğruluğu, görevi tamamlamak için ihtiyaç duyulan yardım ve önerinin uygulanabilirliği. Süre yararlı olabilir; fakat hızlı verilen yanlış karar başarı değildir.
Başlangıçta sayısal başarı eşiğini verisiz belirlemek yerine mevcut yöntemle karşılaştırılacak görevi tanımlamak gerekir. Aynı zorluktaki örnekler kullanılır, deneyim farkı kaydedilir ve ölçüm sırasında verilen yardım not edilir. Az sayıda katılımcının sonucu bütün pazara genellenmez.
Durdurma koşulu da baştan yazılır. Kullanıcıların çözmek istemediği bir problem, gerekli verinin erişilemez oluşu veya yanlış önerinin kabul edilemez etkisi projeyi yeniden çerçevelemeyi gerektirebilir. Daha çok özellik eklemek her belirsizliği çözmez.
Yayınlanabilir ilerleme kaydı
Bir sonraki kamuya açık not, “ürünümüz dönüşümü artırdı” gibi kanıtsız bir sonuç yerine hangi hipotezin sınandığını, hangi örneklerin kullanıldığını ve hangi kararın değiştiğini anlatabilir. Çalışmayan yaklaşım da öğrenme kaydının parçasıdır. Bir testin tamamlanması, ürünün pazara hazır olduğu anlamına gelmez.
Bu rehberin önerdiği somut teslim; temizlenmiş problem listesi, seçilen kullanıcı grubu, bir görev testi ve gerekçeli karar notudur. Destek konuşmalarını ürün kararına taşımak için İngilizce CRO backlog rehberi, otomatik açıklamaların sınırını değerlendirmek için otomasyon ve agent seçimi de okunabilir.