30 saniyelik özet

Customer müşteri, user kullanıcı demektir. Ürün çalışmasında müşteri ilişkisi satın alma, hizmet alma ve ticari taahhütlerle; kullanıcı ilişkisi ise ürünle yapılan görevlerle birlikte incelenir. Bu roller aynı kişide birleşebilir veya farklı kişiler arasında dağılabilir. Kurumsal yazılımda sözleşmenin tarafı şirket, bütçeyi onaylayan kişi yönetici, günlük kullanıcı ise operasyon uzmanı olabilir. Product Owner, yani ürün sahibi, hem kullanımda oluşacak faydayı hem satın alma kararının koşullarını anlamalıdır. Satışın gerçekleşmesi, ürünün işe yaradığını tek başına göstermez. Kullanıcıların ürünü sevmesi de kurumun satın alma koşullarının karşılandığını kanıtlamaz. Araştırma planı bu farklı ilişkileri görünür kılmalıdır.

Neden önemli?

Bir ürün gösteriminde yönetici rapor ekranını beğeniyor. Sözleşme imzalanıyor, kurulum tamamlanıyor. Ancak çalışanlar günlük kayıtlarını başka bir araçta tutmaya devam ediyor. Yönetim raporu artık mevcut olsa da beslendiği veriler eksik kalıyor. Satın alma beklentisi karşılanmış görünürken kullanım sorunu iş sonucunu zayıflatıyor.

Tersi de mümkündür. Çalışanlar kolay kullanılabilen bir aracı kendi ekiplerinde benimser. Kurum genelinde yaygınlaştırma gündeme geldiğinde erişim yönetimi, destek koşulları ve maliyet yapısı değerlendirilmeye başlanır. İlk kullanıcıların memnuniyeti bu soruları cevaplamaz.

Bu ayrım ürün sahibinin hangi bilgiyi kimden alacağını değiştirir. Bütçeyi onaylayan kişi yatırımın gerekçesini açıklayabilir. Günlük kullanıcı, görevi tamamlarken nerede zorlandığını gösterebilir. Sistem yöneticisi ise ürünü işletmek için gereken koşulları anlatabilir. Her görüşme aynı soruyla yürütülürse bu farklı bilgiler birbirine karışır.

Yönetim açısından sonuç, satış ile benimseme arasındaki ilişkinin daha doğru kurulmasıdır. Benimseme, insanların ürünü işlerinde kullanmaya başlaması ve kullanmayı sürdürmesidir. Satış vaadi günlük çalışma koşullarıyla uyuşmuyorsa eğitim ve destek yükü artabilir. Ürün yatırımını değerlendirirken sözleşmenin kazanılmasıyla işin değişmesi arasındaki aşamalar da incelenmelidir.

Terim nedir?

Bu yazıda customer, ürünün müşteri ilişkisini temsil eden tarafı; user ise ürünü fiilen kullanan kişiyi ifade eder. Müşteriyi her durumda yalnızca ödemeyi yapan kişiyle eşitlemek yeterli değildir. Bir hizmetin müşterisi kurum olabilir; satın alma kararını, sözleşmeyi ve bütçeyi kurum içindeki farklı kişiler yönetebilir.

B2B, işletmeler arası ticareti; B2C, işletmenin bireysel tüketiciye ürün veya hizmet sunduğu ilişkiyi anlatır. Bireysel bir uygulamada satın alan ve kullanan kişi çoğunlukla aynı olabilir. Ancak ebeveynin satın aldığı, çocuğun kullandığı bir eğitim ürününde roller ayrılır. Kurumsal bir üründe de satın alma sürecine katılan kişi aynı zamanda günlük kullanıcı olabilir. Ayrım kişileri değişmez kutulara yerleştirmek için yapılmaz.

Araştırmada en azından şu ilişkilerin açıklanması yararlıdır: Kim kullanıyor, kim fayda bekliyor, kim bütçeyi onaylıyor, kim teknik koşulları değerlendiriyor ve kim sözleşme sürecini yürütüyor? Bu kişilerden biri ürünü öneren iç destekçi de olabilir. İç destekçi, ürünün kurumda değerlendirilmesini sağlayan kişidir; satın alma yetkisi olduğu varsayılmamalıdır.

Görüşme notlarına sadece “müşteri istedi” yazmak bu ilişkileri kaybettirir. Talebi kimin, hangi görev veya karar için ilettiği kaydedilmelidir. Böylece yönetici raporu ihtiyacıyla günlük veri girişi ihtiyacı ayrı incelenebilir ve aralarındaki bağımlılık görülebilir.

Gerçek vaka: Slack’te çalışan deneyimi ve kurumsal kontrol

TIME’ın 4 Ekim 2018 tarihli röportajında Slack’in dönemin üründen sorumlu üst yöneticisi April Underwood, geleneksel kurumsal yazılım kararlarının günlük kullanıcılar yerine bilgi teknolojileri yöneticileri tarafından verilebildiğini anlatıyor. Slack’in benimsenmesinde çalışanların tercihinin etkili olduğunu belirtiyor. Kanal ve bildirim deneyimini de insanların iletişimi kendi ihtiyaçlarına göre yönetmesiyle ilişkilendiriyor.

Slack’in 6 Ağustos 2019 tarihli resmi yayını ise Enterprise Grid için kurum yöneticilerine sunulan erişim ve veri paylaşımı kontrollerini açıklıyor. Onaylı cihazlardan erişim ve mobil cihazlarda dosya indirme veya mesaj kopyalamayı sınırlama gibi yetenekler ele alınıyor.

Bu iki kaynak birlikte değerlendirildiğinde, günlük kullanıcı deneyimiyle kurumsal kontrol ihtiyacının ürün içinde ayrı biçimlerde ele alındığı görülüyor. Bu bir ürün değerlendirmesidir; söz konusu özelliklerin satış veya kullanım üzerindeki etkisini tek başına kanıtlamaz. Vakanın dersi, kullanıcı faydasının ve kurumun kabul koşullarının birlikte araştırılması gerektiğidir.

Kaynak
TIME, 9 Questions for Slack Chief Product Officer April Underwood, 4 Ekim 2018.
https
//time.com/5413070/april-underwood-slack/
Kaynak
Slack, Guardrails, not gates: New enterprise security controls for Slack, 6 Ağustos 2019.
https
//slack.com/blog/transformation/new-slack-enterprise-grid-security-features

Varsayımsal örnek: Satın alma otomasyonu ürünü

Bir şirket teklif toplama ve satın alma onaylarını yönetmek için yazılım arıyor. Finans yöneticisi harcamaların izlenebilir olmasını, satın alma müdürü bekleyen onayları görmeyi, uzmanlar ise teklifleri tekrar tekrar yazmadan karşılaştırmayı istiyor. Sözleşme sürecini ayrı bir satın alma ekibi yürütüyor.

Product Owner yalnızca finans yöneticisiyle görüşürse raporlamayı öne alabilir. Oysa uzmanların aynı bilgiyi farklı ekranlara girmesi gerekiyorsa kayıtların güncelliği bozulabilir. Bu durumda finans yöneticisinin beklediği görünürlük de oluşmaz. Kullanım kolaylığı, yönetim faydasının oluşması için gerekli olabilir.

Ürün sahibi uzmanların gerçek bir teklif karşılaştırmasını nasıl hazırladığını gözlemliyor. Hangi bilgilerin nereden alındığını, nerede düzeltme yapıldığını ve istisnaların nasıl çözüldüğünü inceliyor. Finans yöneticisiyle ise hangi harcama kararlarının mevcut bilgilerle verilemediğini konuşuyor. Teknik ekipten kurumun erişim ve veri aktarımı koşullarını öğreniyor.

Başarı ölçütleri role göre ayrılıyor. Uzman için işlemi tamamlama süresi ve düzeltme ihtiyacı; müdür için onay bekleyen taleplerin görünürlüğü; finans için kayıtların tutarlılığı değerlendiriliyor. Başlangıç verisi incelenmeden sayısal iyileşme hedefi yazılmıyor.

Çözüm adaylarından biri, tedarikçi tekliflerinin belirli alanlara aktarılması olsun. Bu seçenek kullanıcıların yükünü azaltabilir; fakat aktarım hataları kontrol edilmezse finansın beklediği tutarlılığı zayıflatabilir. Ekip, hızın yanında doğruluğu da değerlendirecek bir deneme tasarlıyor. Böylece bir rolün ihtiyacını karşılarken diğerinin sonucunu bozma riski görünür oluyor.

Yaygın üç hata

  1. Satın alanın söylediklerini kullanım kanıtı saymak

Bir yönetici çalışanların ne yaptığını doğru biçimde özetleyebilir; yine de kullanım koşulları ayrıca incelenmelidir. Gerçek görevleri gözlemleyin, farklı kullanıcılarla görüşün ve anlatılan süreçle uygulanan süreç arasındaki farkları araştırın. Satın alma görüşmesini kullanım araştırmasının yerine koymayın.

  1. Kullanıcı memnuniyetini satın alma gerekçesiyle eşitlemek

Bir aracın beğenilmesi, kurumun yatırım kararını açıklamak için yeterli olmayabilir. Beklenen iş sonucunu, uygulama yükünü ve kurumun değerlendirme koşullarını öğrenin. Kullanıcıların sağladığı kanıtı ticari değerlendirmeye taşıyın; memnuniyetten doğrudan gelir sonucu çıkarmayın.

  1. Farklı rollerin ölçütlerini tek göstergede toplamak

Toplam giriş sayısı, kullanıcıların temel görevlerini tamamladığını veya yöneticinin fayda elde ettiğini göstermez. Hangi rol için hangi sonucun beklendiğini tanımlayın. Aynı kişinin birden fazla rol taşıdığı durumlarda da ihtiyaçları ayrı değerlendirin.

Mini uygulama / şablon

Yaklaşan bir ürün kararını seçin. Her önemli rol için aşağıdaki alanları doldurun.

Kişi veya grup
—
Müşteri ilişkisi ve kullanım rolü
—
Günlük görevi veya satın alma kararı
—
Çözülmesini beklediği problem
—
Mevcut davranış ve gözlenen kanıt
—
Satın alma veya kullanım koşulu
—
Beklenen fayda
—
Başarı ölçütü ve veri kaynağı
—
Diğer rollerle bağımlılığı
—
Çatışan ihtiyaç
—
Araştırmada sorulacak açık soru
—

Sonra roller arasındaki ilişkiyi inceleyin. Kullanıcı görevi kolaylaşmadan yönetici faydası oluşabiliyor mu? Kurumsal koşullar kullanımın önüne geçiyor mu? Çözüm yeni bir manuel iş yaratıyor mu? Görüşmelerde edinilen bilgiyi bu sorularla karşılaştırın. Karar kaydında hangi ihtiyacın neden öne alındığını ve hangi belirsizliğin araştırılacağını açıklayın.

İlgili terimler

Stakeholder, Buyer Persona, User Persona, Customer Interview, Customer Discovery, Value Proposition, Product Discovery, Jobs to Be Done, Activation ve Aha Moment, Retention ve Churn, Product Goal, Acceptance Criteria