Ürün yöneticilerinin yaptığı 4 hata

Ürün yöneticilerinin yaptığı 4 hata

Ürün yöneticisi olarak işe başladığınızda, aynı gün içerisinde defalarca sevinç ve keder arasında gidip gelmeye de başlarsınız. Zamanla, çok talep edilen bir özelliği piyasaya sürmenin ve bir yığın yazılım hatası altında ezilmenin iniş ve çıkışlarını yönetmeyi öğrenirsiniz, ancak bu his asla tamamen kaybolmayacaktır.

Doğrusunu söylemek gerekirse, zaten bu hissin yok olmasını hiç istemem çünkü, ne öğreniliyorsa en çok bu kaos ortamında öğreniliyor. 

Bir ürünün, projenin yönetiminin büyük bir kısmı deneyimle öğrenilse de, ilk başladığınızda yine de “Keşke bunları daha önce bilseydim” dediğiniz birçok konu oluyor.

Ürün ve proje yönetimi sanatını öğrenirken, kendi iniş çıkışlarınızı da yönetmenize yardımcı olmak adına, dünya için küçük ama ürün yöneticileri için büyük etkileri olan konulardan kısaca bahsedeceğim.

“O, bizim kullanıcımız değil.”

Karşılaşılması muhtemel durum: Herhangi bir kullanıcı, iş arkadaşı veya arkadaşınız, ürününüzün diğer tüm iyi niteliklerini hiçe sayan bir şeyle karşılaşıyor ve sizi yerle bir eden bir geri bildirimde bulunuyor. Onsuz asla yapamayacakları bir özellik ürününüzde yok. Alıştıkları bir kullanım var ve şimdi kalkıp sizin ürününüzü kullanmayı istemiyorlar. Sizin sunduğunuz tüm o diğer değerleri göremiyorlar.

Siz de o hayalkırıklığı ile konuşmaya katılıyor ve: “Bizim kullanıcımız o değil.” diyorsunuz. Yani, onların – kullanıcıların – çok acil dediği ihtiyaçları karşılamak zorunda olmadığınızı, çünkü ürününüzü bu kişiler için yaratmadığınızı dile getiriyorsunuz. Ve bu mantık da, o geri bildirimlerin üzerine çizgi çekebileceğinizi düşünmenize neden oluyor.

Peki, o zaman, bu mantığın tehlikeli olabileceği kısımlara gelelim.

Çıkarılacak en büyük ders, dikkate almayı tercih ettiğiniz geri bildirimler konusunda seçici olamayacağınız gerçeği. Herhangi biriyle ürününüz hakkında konuşma fırsatı bulduğunuzda, bunu, eyleme dönüştürebileceğiniz bir geribildirim alma ve ürünü piyasaya sürdüğünüzde nasıl karşılanacağına dair fikir edinme şansı olarak düşünün. Aslında, müthiş ürünler neredeyse hiçbir zaman tek bir şahıs veya ihtiyacı karşılamaz. Müthiş bir ürün çevik, erişilebilir ve geniş bir yelpazede uygulanabilecek şekilde kıvraktır. Eğer, ideal kullanıcınıza uymuyor diye bir kişinin geribildirimini görmezden gelirseniz, buradaki önemli noktayı tamamen kaçırmışsınız demektir. Çünkü, piyasada, kafanızdaki ideal kullanıcıya uymayacak muhtemel kullanıcıların sayısı, uyacak olanlara göre bir hayli fazla olacaktır.

“O özelliği kapsamdan çıkartamayız.”

Ürününüzün bir özelliği olması gerektiği gibi çalışmıyorsa, bu durumu kabullenecek kadar cesur ve alçakgönüllü olun. Müthiş teknik zorluklar atlatarak bu ürünü hazırlamanız, veya 4 hafta boyunca, tam zamanlı çalışan 3 kişinin bu ürünü yaratmış olması kullanıcınızın umrunda bile değil.

Hele yenilgiyi kabul ettiğinizde, ekibinizin size duyduğu saygının azalması ihtimali hiç umurlarında değil. Kullanıcınızın derdi, geliştirdiğiniz özellik ihtiyaçlarını karşılamadığı için uygulamanızda olumsuz bir deneyim yaşaması. Kullanıcınız için bu sorunu çözün. Eğer bir özellik çalışmıyorsa ve kullanıcılarla baştan itibaren sık temas halindeyseniz, neyin çalışmadığını çabuk fark edebilirsiniz. Ayrıca, uygulamanızın her yönünü ölçümlüyor olmanız gerekir, çünkü böylelikle, bir özellik çözüm üretmediğinde değerlendirmenizi verilerle desteklemiş olursunuz. Intercom.io’nun Ürün Müdür Yardımcısı Des Traynor’ın bu verilerle tam olarak ne yapabileceğinizi anlatan güzel bir yazısı var, buna da göz atabilirsiniz.

Şöyle de düşünebilirsiniz: Eğer birileri bu özelliği kullanıyorsa bu ürünü çöpe atmamalıyız. Nasıl olur da onu sadık bir kullanıcının elinden alırsınız? Esasen, bu özelliğin ilave değeri kullanıcı tabanınızın tamamında yarattığı bilişsel yükten muhtemelen daha azdır. Sonuçta, herkesin istediği her şeyi yaratmak gibi bir göreviniz yok.

Çok benimsenmeyen bir özelliği devam ettirme ya da bırakma arasında karar verirken şöyle bir soru yöneltebilirsiniz kendinize: “Hipotezimin doğru olduğundan emin miyim?” Eğer bu özelliği yaratmanızı sağlayan hipotezinizin doğruluğundan eminseniz, devam edin. Yoksa bırakın. Traynor’un da dediği gibi: “Eğer iyi tanımlanmış bir ürün istiyorsanız, özelliklerin bazılarını yok etmekten çekinmeyin.”

Sorun değil yalnızca çözüm üzerine düşünmek

Eğer işinizi seviyorsanız, muhtemelen sorun çözmeye bayılıyorsunuzdur. Ancak yalnızca potansiyel çözümlere kafa yormak sıkıntı yaratır. Problemin kendisi üzerine düşünemez olursunuz. Bu durum tehlikelidir çünkü düşünme yapınızı belli birtakım çözümlerle sınırlandırmanıza yol açar. Bunun yerine, asıl kullanıcınız için çözmeye çalıştığınız sorunun ne olduğu üzerine düşünün ve en iyi çözümü sunabilmek için yalnızca dertlerini anlamakla yetinmeyin, bu derdin kaynağını da anlamaya çalışın.

Sorun alanı ve çözüm alanı diye adlandırılan bu kavram çok uzun süredir literatürde yer alır ve ürün müdürleri için inanılmaz derecede önemlidir. Çözüm alanından ziyade sorun alanında dolanarak müşterinin derdiyle baş etmeye çalışmanın tipik örneği TurboTax’tır. TurboTax piyasaya sürülürken şöyle bir farkındalık yaşandı: “Vergilerimi hazırla” problemine çözüm yaratmak, “vergileriniz için yazılım” çözümü üretmekten tamamen farklı bir şeydi. Bu ayrımın sonucunda şirket rakiplerine fark atan bir ürün piyasaya sundu. (Bu örnek Dan Olsen’ın Yalın Ürün Yönetimi adlı müthiş seminerinden alınmıştır. Eğer ürün yönetimiyle ilgileniyorsanız bu seminerle başlamak çok işinize yarayacaktır.)

Bu sorunun önemli bir başka boyutu ise sizin, ürün yöneticisi olarak çözümlerden çok sorunların asıl sahibi olduğunuz gerçeğidir. Asıl çözümleri sunacak ve sahiplenecek olanlar ise yazılımcılarınız. Eğer bir çözüme çok erken aşamada adapte olursanız, yazılım ekibinizin sahip olduğu birçok yetenekten tam olarak istifade edemezsiniz.

“Henüz hazır değil.”

Bir özelliğin ömrünün ilk safhasında, o özelliği iyileştirme eğilimi gösterirsiniz. Üzerine çok kafa yorduğunuz bu özelliğin değerini katlayarak artıracak birçok ince ayar aklınıza gelebilir. Ürünü mevcut haliyle piyasaya sürmek hem kendinize, hem yazılımcılarınıza, hem de kullanıcıya haksızlık olurdu, değil mi? Evet, muhtemelen bu hataya hepimiz düşüyoruz. “En mükemmeli” olsun istiyoruz fakat o “mükemmele” ulaşmayı beklersek, ortada, kullanıcılar tarafından kullanılabilen bir ürün hiçbir zaman olmaz.

İşte ürün yöneticisi olarak, belki de yapacağınız en büyük hata budur. Bu ek özelliklerin hiçbiri, özelliğinizi ya da ürününüzü gerçek kullanıcıya sunmakla aynı değeri yaratmaz. Hiçbiri. Hatta çoğunlukla kötü haliyle bırakmak daha iyi sonuç bile verir. İlk kullanıcınıza ürünü sunmakta sabırsız olun.

Alçakgönüllülük, çeviklik ve sebat

Girişimciler Ciz.io kanvasları ile fikirlerini kolayca anlaşılır iş fikirlerine dönüştürüyor ve başkalarıyla paylaşıyor. Ücretsiz kayıt olmak için tıklayın.

Ürün yöneticilerinin, hataları başarıyla gidermesini ya da hatadan tamamen kaçmasını sağlayan üç nitelik vardır: tevazu, kıvraklık ve sebat. Gördüğüm bütün iyi ürün yöneticileri, bu nitelikleri barındırıyor. Böylelikle harika ürünler yaratmak üzere ekiplerine ilham veren vizyon ve üslupla, kullanıcıları odak noktası haline getirdikleri çözümler üretebiliyorlar.

Bugün ilk makalen bizdendi.
Daha fazlası için SHERPA Blog okuru olmalısın.
Giriş Yap Ücretsiz kaydol
SENİN İÇİN ÖNERİYORUZ
6 bilim kurgu efsanesinin kullanıcı deneyimi karnesi star-wars-ui-design
Eda Utku Küngör

6 bilim kurgu efsanesinin kullanıcı deneyimi karnesi