Geri bildirim toplamak kolay, onu karara çevirmek zordur. Talepler çoğunlukla çözüm önerisi biçiminde gelir: “şuraya bir buton koyun”, “Excel'e aktarma ekleyin”. Yol haritası ise çözümlerden değil, problemlerden kurulur.
1. Talebi problem cümlesine geri çevirin
“Excel'e aktarma” talebinin arkasında genellikle “sonucu ekibimle paylaşmam gerekiyor” problemi vardır. Aynı problem paylaşılabilir bir bağlantıyla da çözülebilir ve bu çoğu zaman daha ucuzdur. Bu yüzden her talebi kaydederken iki alan tutun: talep edilen çözüm ve altındaki iş.
2. Frekans değil, engel ağırlığı sayın
- Engelleyici: kullanıcı işini hiç bitiremiyor.
- Yavaşlatıcı: bitiriyor ama fazladan adım harcıyor.
- İstek: işi etkilemiyor, deneyimi iyileştiriyor.
Beş kişiden gelen bir engelleyici, elli kişiden gelen bir istekten önce gelir. Sayının tek başına anlamı yoktur; hangi kullanıcı grubundan geldiği ve işi ne kadar durdurduğu belirleyicidir.
3. Karar verilemeyen talepleri ölçüme bağlayın
Bazı taleplerde haklılık tartışmayla çözülmez. Bu durumda özelliği yazmadan önce mevcut davranışı ölçün: ilgili ekranda kullanıcılar nerede duruyor, hangi adımdan sonra çıkıyor. Ölçüm yoksa karar tahmindir.
4. Yol haritasını üç ufka bölün
| Ufuk | İçerik | Taahhüt düzeyi |
|---|---|---|
| Şimdi | Engelleyiciler ve devam eden iş | Tarih verilir |
| Sırada | Doğrulanmış problemler, çözümü netleşmemiş | Sıra verilir, tarih verilmez |
| Araştırma | Sinyali zayıf, ölçüm bekleyen konular | Taahhüt yok |
Bu ayrım kullanıcıya “hayır” demeyi de kolaylaştırır: talep reddedilmez, ufka yerleştirilir ve hangi sinyalin onu öne taşıyacağı söylenir.