30 sn özet

Ürün yönetimi, hangi müşteri probleminin çözülmeye değer olduğunu belirleme ve bu çözümün şirket için sürdürülebilir bir sonuç üretmesini sağlama disiplinidir. Başarısı, yayımlanan özelliklerin sayısıyla açıklanamaz. Müşterinin davranışında neyin değiştiği, bu değişimin işletmeye nasıl yansıdığı ve çözümü sürdürmenin maliyeti birlikte değerlendirilir. Ürün yöneticisi araştırma, tasarım, mühendislik ve ticari ekipler arasında ortak karar zemini kurar. Temel soru şudur: Sınırlı kaynaklarımızı hangi probleme ayırırsak müşteri ve şirket açısından anlamlı bir ilerleme sağlarız?

Neden önemli?

Bir şirketin geliştirme kapasitesi dolu olabilir; buna rağmen müşterileri üründen beklediği faydayı alamayabilir. Satış ekibinin talepleri, yönetimin fikirleri ve rakiplerin özellikleri iş listesine dönüşürken asıl problem gözden kaçabilir. Ürün yönetimi, bu taleplerin altında yatan ihtiyacı araştırarak yatırım kararını daha sağlam bir temele oturtur.

Her geliştirme kararı bir fırsat maliyeti taşır: Aynı kaynakla yapılabilecek başka bir işten vazgeçilir. Bu nedenle bir özelliğin mümkün olması, öncelikli olması için yeterli değildir. Kararın müşteri açısından önemi, şirketin hedefleriyle ilişkisi ve eldeki kanıtın gücü birlikte ele alınmalıdır. Böylece öncelik tartışması, kimin daha yüksek sesle konuştuğundan uzaklaşıp hangi seçeneğin daha iyi gerekçelendirildiğine yaklaşır.

Yönetici açısından ürün yönetiminin değeri burada görünür olur. Bütçe talebi, yapılacak ekranların listesinden çıkar; çözülmek istenen problem, beklenen sonuç ve belirsizliklerle ilişkilendirilir. Junior bir iş analisti veya ürün sahibi açısından ise aynı yaklaşım, verilen talebi anlamlandırmayı sağlar. Gereksinimi doğru yazmak kadar, o gereksinimin hangi kararı desteklediğini bilmek de önemlidir.

Terim nedir?

Ürün yönetimi; müşteri ihtiyacını, işletmenin ekonomik ve stratejik amaçlarını, teknik olanakları ve kullanım deneyimini bir arada değerlendirerek ürünün yönünü belirler. Buradaki ürün, bir mobil uygulama kadar şirketlerin kullandığı bir hizmet veya dijital destekle sunulan bir operasyon çözümü de olabilir.

Çalışma, problem keşfiyle başlar. Kimin hangi durumda zorlandığı, mevcut çözümünün neden yetersiz kaldığı ve problemin çözülmemesinin neye yol açtığı araştırılır. Ardından farklı seçenekler karşılaştırılır, kritik varsayımlar sınanır ve geliştirme kararı verilir. Kullanıma sunulan çözümün etkisi izlenerek sonraki kararlar şekillendirilir. Ürünün gelişimini durdurmak veya bir özelliği kaldırmak da bu sorumluluğun içindedir.

Ürün yöneticisi bütün uzmanlıkların yerine geçmez. Mühendis teknik seçenekleri, tasarımcı kullanım deneyimini, iş analisti gereksinimleri ve süreç ilişkilerini derinleştirir. Ürün yöneticisi bu katkıları ortak amaç etrafında birleştirir; seçeneklerin gerekçelerini ve ödünleşimlerini görünür kılar. Ödünleşim, bir faydayı elde ederken başka bir faydadan veya kapasiteden vazgeçmek demektir.

Proje yönetimiyle ürün yönetimi arasında güçlü bir ilişki vardır. Proje yönetimi, belirli bir çalışmanın kapsam, süre ve kaynaklar çerçevesinde yürütülmesini düzenler. Ürün yönetimi ise hangi çalışmanın neden yapılacağını ve tamamlandıktan sonra neyi değiştirmesi gerektiğini sorgular. Kuruma göre görevler örtüşebilir; önemli olan karar ve sonuç sorumluluklarının açık olmasıdır.

Gerçek vaka: Amazon’un müşteriden geriye doğru çalışma yaklaşımı

AWS’nin “The Secrets to AWS Product Management” yazısı, Amazon’un ürün kararlarını müşteriden geriye doğru çalışma yaklaşımıyla ele aldığını anlatır. Working Backwards adı verilen bu yöntemde ekip, geliştirmeden önce gelecekteki ürün için bir basın bülteni hazırlar. Metin, hedef müşteriyi ve ürünün sağlayacağı faydayı anlaşılır biçimde ortaya koymayı amaçlar.

Buna FAQ, yani sık sorulan sorular belgesi eşlik eder. Belge hem müşterinin güvenlik ve alternatifler gibi sorularını hem de şirketin kârlılık ve kaynak ihtiyacı gibi sorularını ele alır. Böylece müşteri vaadiyle işletmenin ürünü sunabilme koşulları aynı karar sürecine girer.

Kaynak, EC2 adlı bulut bilişim hizmetinin ilk sürümünde de zor kapsam kararları alındığını aktarır. Ekip daha sınırlı bir sürümü önce sunmuş, sonraki özellikleri veriye dayanarak aşamalı biçimde geliştirmiştir. Yazıdaki bu örnek için sayısal bir etki sonucu verilmediğinden, burada gelir veya verimlilik artışı iddiası kurulmuyor.

Bu vakadan çıkarılabilecek ders, müşteri vaadini geliştirme başlamadan sınanabilir hâle getirmektir. Ekip, müşterinin hangi ihtiyacına yanıt verdiğini açıklayamıyorsa kapsamı büyütmek kararın kalitesini artırmayabilir. Basın bülteni biçimi yardımcı bir araçtır; asıl mesele, çözümün gerekçesini ve bilinmeyenleri erken tartışmaktır.

Varsayımsal örnek: Rapor ekranı talebinden ürün kararına

E-ticaret işletmelerine sipariş yönetimi hizmeti sunan bir şirket düşünelim. Satış ekibi, müşterilerin daha ayrıntılı rapor istediğini söylüyor. Talep ilk bakışta yeni bir rapor ekranına işaret ediyor. Ürün yöneticisi ise önce raporun hangi işte kullanılacağını araştırıyor.

Müşteri görüşmelerinde operasyon sorumlularının asıl ihtiyacının gecikme riski taşıyan siparişleri zamanında fark etmek olduğu anlaşılıyor. Kullanıcılar mevcut raporu indirip başka bir dosyayla karşılaştırıyor; ardından ilgili kişilere haber veriyor. Burada çözülmesi gereken problem, rapor ayrıntısından önce karar için gerekli bilginin geç görünür olması olabilir.

Ekip üç seçeneği değerlendiriyor: Raporu genişletmek, riskli siparişleri mevcut ekranda göstermek veya otomatik bildirim göndermek. Teknik incelemede risk işaretinin üretilebilmesi için veri güncelliğinin yeterli olup olmadığı kontrol ediliyor. Kullanıcılarla yapılan denemede ise uyarının anlaşılması ve doğru kişiye ulaşması inceleniyor.

Başarı ölçümü, ekranın yayımlanmasına bağlanmıyor. Riskin görünür olmasıyla müdahale arasındaki süre ve müdahalenin siparişin zamanında tamamlanmasıyla ilişkisi izleniyor. Gereksiz uyarılar da kontrol ediliyor; sürekli yanlış alarm üreten bir çözüm kullanıcı güvenini zayıflatabilir. Bu örnekte hiçbir sonuç ölçülmüş kabul edilmiyor. Önce mevcut durum belirlenmeli, ardından gerçekçi hedef ve değerlendirme yöntemi kararlaştırılmalıdır.

Yaygın 3 hata

  1. Müşteri talebini doğrudan çözüm kabul etmek

“Excel çıktısı istiyoruz” ifadesi değerli bir ipucudur. Ancak müşterinin hangi kararı vereceğini veya hangi işi tamamlayacağını tek başına açıklamaz. Talebin arkasındaki amaç araştırılmadan geliştirmeye başlanırsa, daha kullanışlı bir seçenek gözden kaçabilir. Görüşmede müşterinin son yaşadığı somut olayı anlatmasını istemek, genel beklentilerden daha açıklayıcı olabilir.

  1. Teslimatı başarıyla eşitlemek

Çıktı, üretilen ekran veya özellik gibi teslim edilen şeydir. Sonuç ise müşterinin ya da işletmenin durumunda oluşan değişimdir. Bir özellik zamanında teslim edilebilir, fakat kullanılmayabilir. Bu yüzden teslimat planına, beklenen davranış değişimi ve onu izleyecek ölçüm de eklenmelidir.

  1. Ürün yöneticisini tek karar kaynağına dönüştürmek

Bütün kararların tek kişinin sezgisine bağlanması, uzmanlık katkısını ve karar hızını zayıflatır. Ürün yöneticisinin sorumluluğu her cevabı bilmek değildir. Hangi bilginin eksik olduğunu ortaya koymak, doğru uzmanları sürece katmak ve kararın dayanağını açıklamak gerekir. Kararı değiştirecek yeni kanıtın ne olacağı da baştan konuşulmalıdır.

Mini uygulama: Ürün karar notu

Bir sonraki geliştirme talebini aşağıdaki kısa notla değerlendirebilirsiniz. Bilinmeyen alanları tahminle doldurmak yerine “henüz doğrulanmadı” olarak işaretleyin.

Hedef müşteri
Problemi yaşayan kişi veya müşteri grubu kim?
Problem ve bağlam
Hangi işi, hangi koşulda tamamlamakta zorlanıyor?
Mevcut kanıt
Görüşme, kullanım verisi veya süreç gözlemi ne gösteriyor?
Bugünkü alternatif
Müşteri ihtiyacını şu anda nasıl karşılıyor?
Beklenen sonuç
Çözüm kullanıldığında hangi davranış veya iş sonucu değişmeli?
Seçenekler
Hangi yollar değerlendirildi, tercih edilen yol neden uygun?
Kritik varsayım
Hangi kabul yanlışsa bu yatırım anlamını kaybeder?
İlk doğrulama
Bu kabulü geliştirmeden önce nasıl sınayacağız?
Ölçüm ve karar
Mevcut durum nedir, hangi bulguda devam edeceğiz veya yön değiştireceğiz?

Notu ilgili ekiplerle tartışırken özellikle kanıt ile yorum arasındaki sınırı kontrol edin. Aynı problemi kabul etmeyen ekiplerin kapsam üzerinde uzlaşması kalıcı olmayacaktır.

Gerçek vaka kaynağı

AWS Executive Insights, The Secrets to AWS Product Management, Choong W. Lee.

İlgili terimler

Ürün Vizyonu, Ürün Stratejisi, Problem Keşfi, Ürün Keşfi, Değer Önerisi, Önceliklendirme, Ürün Yol Haritası, Product Owner, Outcome ve Output, Ürün Yaşam Döngüsü