Bir içeriğin okunması, o konuyla ilgili bir yazılım ürününe talep olduğu anlamına gelmez. Okur bir kavramı merak ediyor, tek seferlik bir karar veriyor veya başka birinin işini araştırıyor olabilir. Keşif Atlası için önerdiğim içerikten ürün hipotezine geçiş yöntemi bu ayrımı korumayı amaçlıyor. Bu yazı tamamlanmış bir ürün keşfi raporu değil; uygulanabilecek araştırma ve ölçüm planıdır.
Kurucu ve proje yöneticisi olarak burada kesinleştirdiğim şey ürünün ne olacağı değil, hangi kanıtın hangi kararı destekleyebileceğidir. Gerçek kullanıcı araştırması, ücretli talep veya kullanım sonucu paylaşılmadığı için bunların yerine varsayımsal başarı rakamları koymuyorum.
İçerik talebi ile iş akışı talebi
Bir rehber “nasıl yapılır?” sorusunu cevaplayabilir. Ürün ise aynı işi tekrar yapan kişinin zamanını, hata riskini veya koordinasyon yükünü azaltmalıdır. Okurun rehberi bir kez okuyup kendi çözümünü kurması, içeriğin başarılı olduğu fakat yazılım ihtiyacının zayıf kaldığı bir durum olabilir.
Bu nedenle araştırmanın ilk sorusu “hangi yazı daha çok okundu?” değil, “okur bu bilgiden sonra hangi işi yapmaya çalışıyor?” olur. Bir sonraki adım veri toplamak, seçenek karşılaştırmak, sonucu bir ekibe aktarmak veya düzenli kontrol yapmak olabilir. Ürün hipotezi bu işin çevresinde kurulmalıdır.
Örneğin farklı araçları karşılaştıran bir içerik trafik alıyor olabilir. Buradan otomatik olarak yeni bir karşılaştırma platformu kurma kararı çıkmaz. Okurların kararı ne sıklıkta verdiğini, bilgileri nerede sakladığını ve mevcut yöntemin hangi noktasında zorlandığını araştırmak gerekir.
İçerik sinyallerini doğru sınıflandırmak
Arama görünürlüğü, sayfa ziyareti, bir örneği indirme, bir soru gönderme ve aynı işi tekrar yapmak farklı sinyallerdir. Bunları tek bir “ilgi puanı” altında toplamak davranışın anlamını kaybettirebilir. Her sinyalin desteklediği ve desteklemediği çıkarım ayrı yazılmalıdır.
| Sinyal | Destekleyebileceği yorum | Kanıtlamadığı şey |
|---|---|---|
| Arama gösterimi | Konuyla sayfa arasında görünürlük oluşuyor | Okurun ürüne ihtiyacı olduğu |
| Rehber ziyareti | Bilgiye ulaşılmış olabilir | Görevin tamamlandığı |
| Örnek dosya talebi | Uygulamaya geçme isteği olabilir | Düzenli kullanım veya ödeme isteği |
| Ayrıntılı destek sorusu | Çözülemeyen bir adım bulunabilir | Aynı sorunun bütün okurlarda olduğu |
| Tekrarlanan görev | Süreklilik taşıyan ihtiyaç olabilir | Yazılımın en iyi çözüm olduğu |
Google’ın Search Console ölçüm tanımlarında gösterim ve tıklama arama sonucundaki etkileşimleri anlatır. Bu ölçümleri ürün kullanımının yerine koymamak gerekir. Keşif Atlası çalışmasında arama verisi araştırılacak soruyu seçmeye yardımcı olabilir; ticari doğrulamanın kendisi olamaz.
Tek bir iş seçmek
İlk hipotez için geniş bir kitle ve çok sayıda görev seçmek öğrenmeyi zorlaştırır. Bir kullanıcı rolü, bir tetikleyici olay ve bir çıktı tanımlanabilir. “Araştırma yapan herkes” yerine “haftalık seçenek karşılaştırmasını ekibine aktaran kişi” gibi daha somut bir bağlam araştırılabilir.
Bu örnek Keşif Atlası’nın doğrulanmış hedef kitlesi değildir. Ama kapsamın nasıl daraltılabileceğini gösterir. Gerçek araştırma başka bir iş ortaya çıkarırsa tanım değişmelidir. İlk cümleyi korumak için veriyi zorlamak ürün keşfinin amacını bozar.
Seçilen iş için mevcut yöntem kaydedilir. Okur bir tablo mu kullanıyor, not mu alıyor, uzman görüşü mü satın alıyor, yoksa işi hiç tamamlamıyor mu? Mevcut yöntemin işe yarayan taraflarını bilmeden yeni ürünün yalnız eksikleri çözmesi beklenemez.
Görüşmeyi fikir beğenisine çevirmemek
“Böyle bir araç olsa kullanır mıydın?” sorusu kolay bir olumlu yanıt üretir. Daha yararlı yaklaşım son gerçek örneği konuşmaktır. İş ne zaman ortaya çıktı, hangi kaynaklar kullanıldı, hangi adım tekrarlandı, ne kadar yardım gerekti ve sonuç nerede kullanıldı?
Katılımcıdan hassas bilgi istemeden işin yapısını anlamak mümkündür. Boş bir şablon, anonimleştirilmiş örnek veya adımların sözlü anlatımı yeterli olabilir. Araştırmanın amacı işletmenin özel verisini toplamak değil, ürünün çözmeye aday olduğu güçlüğü anlamaktır.
Katılımcılar yalnız en ilgili okurlardan seçilirse sonuç olumluya kayabilir. Konuyla ilgilenip devam etmeyen kişilerin neden durduğunu da öğrenmek gerekir. Bazılarının hiçbir sorunu olmayabilir; bu da kapsamı doğru sınırlamaya yarar.
Yazılım kurmadan bir hizmet denemesi
Tekrarlanan bir iş bulunduğunda küçük bir elle yürütülen deneme tasarlanabilir. Kullanıcı gerekli girdiyi sağlar, ekip üzerinde anlaşılan çıktıyı üretir ve kullanıcı o çıktıyı gerçek görevinde kullanır. Böylece çıktı gerçekten işe yarıyor mu, hangi bilgi eksik kalıyor ve iş ne zaman tekrar ediyor görülebilir.
Denemenin elle yürütüldüğü açıkça belirtilmelidir. Otomatik olmayan bir hizmeti otomatik ürün gibi sunmak, hem beklentiyi hem öğrenmeyi bozar. Kullanıcıya teslim süresi, kapsam ve desteğin niteliği anlaşılır biçimde anlatılır.
Elle başarıyla tamamlanan bir görev otomasyonun ekonomik olacağını kanıtlamaz. Veri erişimi, istisnalar, kalite kontrolü ve destek ihtiyacı ayrıca değerlendirilir. Bu nedenle denemede yalnız kullanıcı sonucu değil, işi üretmek için gereken emek de kaydedilir.
Hipotez kartı nasıl doldurulur?
Keşif Atlası için önerilen kart beş cümleden oluşabilir. Belirli bir kullanıcı, belirli bir olaydan sonra bir işi yapmak istiyor. Mevcut yöntemde şu güçlük yaşanıyor. Önerilen çıktı bu güçlüğü şu yolla azaltabilir. Bunu şu gerçek görev üzerinden değerlendireceğiz. Şu bulgu ortaya çıkarsa hipotezi değiştireceğiz.
“Okurlar beğenirse devam” bir değerlendirme koşulu olarak zayıftır. Kullanıcının çıktıyı gerçekten kullanması, yeniden aynı işi istemesi veya mevcut yöntemi neden değiştirmediğini açıklaması daha somut kanıt sağlar. Ödeme denemesi yapılacaksa sunulan şey, teslim koşulu ve ücret açık olmalıdır; mevcut olmayan ürüne belirsiz vaat verilmemelidir.
Başarı ve vazgeçme ölçütleri
İlk değerlendirmede tamamlanan görev oranı, sonuca ulaşmak için gereken yardım, tekrar kullanım nedeni ve üretim maliyeti birlikte incelenebilir. Küçük örneklemde yüzdeleri tek başına sunmak yerine kişi ve görev sayısını da belirtmek gerekir. Bir kişinin tekrar dönmesi değerli olabilir, fakat geniş pazar talebi değildir.
İş çok seyrek yapılıyorsa, kişiye özgü uzmanlık gerektiriyorsa veya veri hazırlığı çıktıdan daha maliyetliyse yazılım ürünü yerine içerik ya da hizmet daha uygun kalabilir. Bu, içerik projesinin başarısızlığı değildir. Doğru ürün sınırı bazen yeni ürün geliştirmemektir.
Çalışmanın sonunda yayınlanabilecek kayıt; araştırılan iş, kullanılan örnekler, değişen varsayım ve sonraki karardır. Gerçek deney tamamlanmadan “içerikten ürüne dönüşüm sağlandı” denmez. Teknik görünürlük için Google’ın Search Console ölçüm tanımları, site içindeki içerik yapısı için SEO ve performans yönetimi ve dijital eğitim rehberi yardımcı başlangıç kaynaklarıdır.