Amazon’ın PR/FAQ yaklaşımında ürün geliştirmeden önce müşteri faydası açıkça yazılır. Basın bülteni, çözüm hazır olduğunda kullanıcı için neyin değişeceğini anlatır; sık sorulan sorular bölümü ise uygulama, maliyet ve zor noktaları görünür yapar. Amaç pazarlama metnini erkenden yayımlamak değil, fikrin gerçekten anlamlı bir ihtiyaca cevap verip vermediğini düşünmek. Siz de ofiste yeni bir dosya veya araç önerirken özellik listesiyle başlamadan önce kullanıcının hangi işini daha kolay yapacağını açıklayabilirsiniz.
Neden önce çözümün faydası konuşuluyor?
Yeni bir fikir önerildiğinde ekip hemen özellik toplamaya başlayabilir. Daha fazla ekran, seçenek ve rapor eklenir. Ancak ürünün neden gerekli olduğu belirsizse geliştirme büyürken kullanıcı ihtiyacı geride kalabilir. Yazılı kısa anlatım bu belirsizliği erken gösterir.
Amazon’ın yayımladığı uygulayıcı anlatımı, Working Backwards yaklaşımında basın bülteni ve soru-cevap belgesini birlikte ele alıyor. Bülten müşteri deneyimine odaklanırken sorular, çözümün ayrıntılarını ve yapım zorluklarını araştırıyor. Belgenin birçok kez gözden geçirilmesi, fikirdeki eksikleri bulmak için kullanılıyor. Bu bir yöntem kaydıdır; kısa belge yazmanın her projeyi başarılı yapacağı iddiası değil.
Ofis hayatına taşınabilecek asıl ayrım, özellik ile fayda arasında. “Beş sekmeli bir takip dosyası” özellik olabilir. “Yanıt bekleyen işi doğru kişiyle takip etmek” ise kullanıcı ihtiyacına daha yakındır. İlkini tasarlamadan önce ikincisini anlamak gerekir.
İlk öğrenim: Kullanıcıyı genel bırakmayın
“Herkesin işini kolaylaştıracağız” cümlesi ilgi çekici ama zayıf bir başlangıç olabilir. Herkes aynı görevi yapmaz, aynı veriye erişmez ve aynı sorunda beklemez. Önce belirli bir kullanıcı ve gerçek bir iş seçin. Kapsam sonradan genişleyebilir.
Örneğin satın alma ekibi için hazırlanacak araçta kullanıcı teklif kontrolünü yapan analist olabilir. Sorunu, onay mesajlarının farklı yazışmalarda kalmasıdır. Bu durumda teklifin bütün hesaplarını yeniden yapacak büyük bir sistem yerine, onay yerini anlaşılır tutan dar bir çözüm yeterli olabilir.
Kullanıcıdan genel beğeni istemek yerine son işi nasıl yaptığını öğrenin. Hangi belgeyi açtı, neyi bulamadı, kime sordu? Gerçek görev anlatımı, önerinin gerekli olup olmadığını görmenize yardım eder. Kendi fikrinizi erken savunmaya başlarsanız bu ayrıntıları kaçırabilirsiniz.
İkinci öğrenim: Fayda mevcut durumla karşılaştırılır
Yeni aracın güzel görünmesi bir fayda olabilir, fakat iş ihtiyacı için yeterli olmayabilir. Kullanıcı bugünkü yöntemle zaten gerekli sonuca ulaşıyorsa değişikliğin neden yapılacağını açıklamanız gerekir. Başka bir sorun çözülüyorsa onu açık yazın.
Karşılaştırma büyük rakamla başlamak zorunda değil. “Güncel onayı tek yerden bulmak” somut bir değişimdir. Bundan yüzde tasarruf uydurmak yerine kullanım sırasında kontrol edin. Yeni düzenin bakım yükünü ve ek adımlarını da hesaba katın.
Karar için yeterli bilgiyi seçmek, öneri hazırlığını ölçülü tutmanıza yardımcı olur. Her özellik için sonsuz araştırma gerekmez. Ama kritik varsayım bilinmeden büyük kapsamı onaylamak da risklidir. Önce kararın etkisini düşünün.
Üçüncü öğrenim: Zor soru fikre karşı olmak değildir
Bir önerinin veri kaynağı, bakım sahibi veya maliyeti sorulduğunda bunu kişisel ret gibi algılamak kolaydır. Oysa bu sorular uygulamayı daha sağlam hale getirebilir. İyi fikir, zor soruyu kaldırabilecek biçimde açıklanmalıdır. Bilmediğiniz kısmı açık bırakabilirsiniz.
Örneğin yeni takip dosyası kimin güncellemesiyle doğru kalacak? Yanlış bilgi girilirse kim fark edecek? Aynı işin resmi kaydı başka yerde mi? Bu soruları baştan düşünmek, sonradan kullanıcıya sürpriz yük bindirmeyi azaltır. Her sorunun hemen cevabı olmayabilir.
Soruları karar ihtiyacına göre sıralayın. İlk deneme için zorunlu olanla genişleme aşamasında gerekli olanı ayırın. Böylece kapsamı küçük tutarken önemli riski unutmazsınız. Tartışma, daha çok özellik toplamak yerine doğru denemeyi seçmeye hizmet eder.
- Kullanıcıyı seçin
Çözümün kimin hangi işini kolaylaştıracağını yazın.
- Farkı anlatın
Mevcut durumdan farklı olarak neyin mümkün olacağını açıklayın.
- Zor soruyu sorun
Uygulama için gerekli maliyet, bilgi ve riski görünür yapın.
Onay takibi için kısa bir öneri metni
Şöyle bir durum düşünün: Bir operasyon ekibinde belge onaylarının yazışmalarda kaybolduğu görülüyor. Yeni takip dosyasını hemen hazırlamak yerine önce kısa fayda metni yazıyorsunuz: “Belgeyi gönderen çalışan, hangi kontrolün tamamlandığını ve kimin görüşünün beklendiğini ortak kayıttan görebilecek.” Bu cümle daha yapılmamış ürünün hedefini açıklar.
Ardından üç soru geliyor. Hangi belgeler kapsama girecek? Resmi onay nerede geçerli sayılacak? Ortak kayıt kim tarafından güncellenecek? Bu sorulara cevap olmadan dosyanın bütün kuruma açılması doğru olmayabilir. İlk denemeyi tek belge türünde sınırlıyorsunuz.
Doldurulmuş notta kullanıcı “haftalık sevkiyat dosyasını hazırlayan çalışan”, sorun “görüş beklenen kişinin belirsizliği”, çözüm “durum ve kaynak bağlantısının tek kayıtta görünmesi” olarak yazılıyor. Resmi onay yerini değiştirmek kapsam dışı. Böylece yardımcı kayıtla geçerli karar birbirine karışmıyor.
Denemede kullanıcının dosyayı gerçekten açıp açmadığını ve gerekli bilgiye ulaşıp ulaşmadığını izleyin. Kayıt eskiyse yanlış güven yaratabilir. Bakım sorumlusu belli değilse o noktayı düzeltin. Kullanılmayan bir araçta yalnız yeni alanlar eklemek sorunu büyütebilir.
Bir çalışma arkadaşınız önerinin faydasını kendi cümlesiyle anlatsın. Farklı bir ihtiyaç tarif ediyorsa metin yeterince açık olmayabilir. Teknik konuyu uzman olmayan birine anlatmak, araç özelliklerini kullanıcı diline çevirmek için iyi bir tamamlayıcıdır.
Deneme sonunda karar notu hazırlayın. Devam edecekse hangi sorun çözülmüş görünüyor? Değişecekse hangi varsayım yanlış çıktı? Bırakılacaksa mevcut yöntem neyi daha iyi sağlıyor? Bu üç sonuç da öğrenimdir. Fikri savunmak için yalnız olumlu yorumu seçmeyin.
Öneri için küçük bir yazılı hazırlık, uzun sunumu tamamen gereksiz yapmaz. Ama fikrin ana mantığını erken görmenizi sağlayabilir. Sonradan sunum hazırladığınızda artık yalnız özellik anlatmaz, ihtiyacı ve gerekli kararı açıklarsınız. Yazının uzunluğu değil düşüncenin netliği önemlidir.
Bugün önermek istediğiniz bir araç için kullanıcı, sorun ve farkı birer cümleyle yazabilirsiniz. İşte önerilerinizi daha somut anlatmak ve gelişiminizi düşünmek için kariyer gelişim kursunun programını inceleyebilirsiniz.
Sık sorulan sorular
Basın bülteni gerçekten yayımlanıyor mu?
Bu kullanımda belge fikri düşünmek için hazırlanır; yayımlanmış bir sonuç değildir. Henüz gerçekleşmemiş faydayı işin hedefi olarak tarif eder. Gerçek ürün duyurusuyla karıştırmadan, gerekli soruları ve deneme ihtiyacını belirlemek için kullanılır.
Küçük ofis önerisinde uzun soru-cevap gerekiyor mu?
Gerekmeyebilir. Kararın etkisine uygun birkaç soru yeterli olabilir. Kullanıcı, veri kaynağı, bakım ve kapsam gibi temel konularla başlayın. Büyük belge hazırlamak yerine önemli belirsizliği çözmek daha faydalıdır. Yeni risk çıktığında kapsamı gözden geçirin.
Öneriye gelen eleştiriye nasıl yaklaşmalıyım?
Önce hangi örneğe dayandığını ve neyin belirsiz bulunduğunu öğrenin. Eleştiriyi savunmaya geçmeden konuşmak, önerinizi korumakla geliştirilebilir noktayı anlamayı ayırmaya yardımcı olur. Her görüşü aynı anda uygulamak zorunda değilsiniz.
Fikrin iyi olduğu nasıl anlaşılır?
Belirli bir kullanıcı ihtiyacına cevap vermesi, önemli varsayımlarının sınanması ve gerekli uygulamanın mümkün görünmesi gerekir. Beğenilen sunum yeterli kanıt değildir. Küçük gerçek kullanım denemesi, önerinin hangi bölümünün faydalı olduğunu daha iyi gösterebilir.
