Bir kullanıcı özellik istediğinde çoğu zaman kendi çözüm önerisini anlatır. “Excel aktarımı ekleyin” talebinin arkasında rapor hazırlama, başka sistemle çalışma, kontrol yapma veya veriyi saklama ihtiyacı bulunabilir. Aynı düğme isteği farklı işler için ortaya çıkabilir.
Ürün kararı vermeden önce çözüm önerisini ciddiye alıp problemi ayrıca anlamak gerekir. Kullanıcının söylediğini reddetmek ile her talebi doğrudan geliştirme listesine almak arasında araştırmaya dayanan bir yol vardır.
Son gerçek örneği istemek
Genel “bunu neden istiyorsun?” sorusu kolayca soyut cevap üretir. Bunun yerine kişinin bu ihtiyacı en son ne zaman yaşadığını, hangi işi yapmaya çalıştığını ve nerede durduğunu öğren. Mümkünse kişisel veya hassas verileri çıkartılmış bir örnek üzerinden ilerle.
İşin başlangıcı, kullanılan bilgiler, mevcut adımlar ve beklenen sonuç ayrı not edilsin. Talep edilen özelliğin bu akışın hangi noktasında işe yarayacağı böyle anlaşılır. Bazen önerilen çözüm sorunun yalnız görünür son adımını kapsar.
Görüşmede kullanıcıyı ürünün mevcut sınırlarına göre cevap vermeye zorlamamak gerekir. Ama her ihtiyacın bu ürün tarafından karşılanması gerektiği de varsayılmaz. Problemin gerçek olması, ürün kapsamına uygun olduğunu tek başına kanıtlamaz.
İş, engel ve sonuç ayrımı
Problem cümlesi üç parçayla yazılabilir: hangi kişi hangi koşulda ne yapmaya çalışıyor, hangi engelle karşılaşıyor, bunun sonucu ne oluyor? “Dışa aktarma yok” yalnız eksik çözüm tanımıdır. “Operasyon sorumlusu haftalık sipariş uyuşmazlığını bulmak için kayıtları elle birleştiriyor” daha araştırılabilir bir problemdir.
Sonucun büyüklüğünü kanıtla. Kaybedilen süre, hata, bekleyen müşteri veya tamamlanamayan karar olabilir. Kullanıcı kesin ölçmemişse verdiği tahmini gerçek süre gibi kaydetme. Gözlem, tahmin ve yorum ayrı kalsın.
Ayrıca mevcut geçici çözümü öğren. İnsanlar bir işi yapabilmek için ne kurmuş? Geçici çözümün varlığı ihtiyacın önemine dair sinyal olabilir; fakat otomatik ödeme isteği veya geniş pazar kanıtı değildir.
Benzer taleplerin aynı problem olup olmadığını sınamak
Birden fazla kişi aynı özelliği isteyebilir ama farklı sonuç bekleyebilir. Talepleri yalnız anahtar kelimeye göre birleştirmek, hiçbirine tam uymayan bir çözüm üretebilir. Kullanıcı rolü, iş sıklığı, veri kapsamı ve beklenen karar karşılaştırılmalıdır.
Tersine farklı özellik istekleri aynı temel engelden doğabilir. Bildirim, liste filtresi ve rapor talebi, sahipsiz işleri fark edememekle ilgili olabilir. Bu durumda ortak problemi çözmek üç ayrı özelliği geliştirmekten daha etkili bir seçenek yaratabilir.
Gruplama kararının gerekçesi kaydedilsin. Yeni kanıt geldiğinde ayrıştırmak kolay olmalıdır. Problem sınıfları değişmez gerçekler değil, araştırmayı düzenleyen çalışma araçlarıdır.
Çözüm seçeneklerini çoğaltmak
Problem anlaşıldıktan sonra en azından mevcut süreci iyileştirme, bilgi sunumunu değiştirme ve yeni işlev geliştirme seçeneklerini karşılaştır. Her çözüm kod gerektirmeyebilir. Bazen isimlendirme, varsayılan filtre veya görev sahipliği yeterli olabilir.
Her seçenek için kullanıcıya ne kazandıracağı, neyi değiştirmeyeceği ve hangi yeni yükü yaratacağı yazılır. Otomatik rapor, veri tanımları tutarsızsa yalnız yanlış bilgiyi daha hızlı dağıtabilir.
İlk talebe sadakat, talep edilen düğmeyi aynen yapmak değil, kullanıcının önemli işini daha iyi desteklemektir. Ancak araştırma sonucunu kullanıcıya açıklarken kendi ihtiyacını yanlış anladığını ima etmek yerine öğrendiğin bağlamı paylaş.
Karar öncesi küçük doğrulama
Önerilen çözümü gerçek göreve yakın bir örnekle sınayabilirsin. Kâğıt akış, tıklanabilir prototip veya sınırlı manuel hizmet yeterli olabilir. Kullanıcının çözümü beğenmesiyle işi tamamlayabilmesi ayrı değerlendirilir.
Kabul koşulunu önceden yaz: kişi hangi girdilerle hangi sonucu, hangi belirsizliği yaşamadan elde edebilmeli? Hatalı veya eksik veri durumunu da dahil et. Yalnız en kolay örnekte çalışan çözüm gerçek problemi taşımayabilir.
Karar kaydında talep edilen özellik, anlaşılan problem, kanıt, seçilen seçenek ve açık sorular birlikte yer alsın. Böylece birkaç ay sonra aynı istek geldiğinde yalnız “reddedildi” notu yerine gerekçeye dönülebilir. MerchNivo problemden ürün kararına rehberi bu yaklaşımı bir proje çalışma planı olarak genişletir.