ürün yönetimi 0. gün taktikleri ve hack’leri

(Bu yazıdaki anlamıyla kullanılan Hack’in tam türkçesi olmadığı için Çakallık olarak çevirdim, pek sevimli olmadı kusura bakmayın)

Artık pek yapamasam da, gönlümde her zaman ürün yöneticisi olmak vardır. Aslen ürün yöneticiliği, disiplin ve konsantrasyon gerektiren tam zamanlı bir iştir. Satış ekibiyle ve CEO (bazen kendisi ceo dur) ile yakın çalışarak, müşterileri ilk elden dinler ve development ekibine, kullandıkları yazılım geliştirme tekniğinin gerektirdiği şekilde neler yapılacağını anlatır.

Çoğu ürün yöneticisinin bir numaralı zaafı, ürünün tümünü düşünmeye çalışmasıdır. Ürün çalışırken akla gelen ve üzerinde çalışılan vizyon heyecan vericidir, ancak gerçekleşen durumlara bakıldığı zaman, istenilen vizyona ilk günden ulaşmak çoğu zaman mümkün olmaz. Lean vs. gibi kavramlar da burada devreye girer. Burada ürün yöneticisinin dilini ısırıp, biraz da yaratıcı (çakal – hacker) olarak, eldeki az kaynak ile işe yarayacak bir 0.gün stratejisi çizmesi çok önemlidir. Çünkü 0. gün geçilmeden, istenilen vizyona ulaşmak çoğu zaman mümkün olmaz. Özellikle kafamızdaki ürün tavuk-yumurta problemine sahipse (örn: hem alıcı hem de satıcı gerektiren bir portal) ilk giren kullanıcının yaşayacağı deneyimi iyi planlamak gerekir. Çok detaya girmeden, kısaca özetlemem gerekirse, pazar araştırması kısımlarını tamamladıktan sonra bence yeni çıkan bir üründe veya startup’da ürün yöneticisinin ilk düşünmesi gerekenler aşağıdakilerdir (Birazdan bir örnek üzerinden de gideceğim) :

  • Ürünün ilk ve en basit versiyonunu en erken ne zaman hayata geçirmeliyim, ne kadar zamanım var? (evet, düşünülmez ama zaman – kaynak sınırı koymak, MVP yi yaratmakta önemli kısıtlayıcı kriterlerden birisidir. Bir kısıtlama olmazsa, aylarca ürün düşünülür, tüm geliştirme kaynakları da henüz kimseye gösterilme şansı olmayan bir ürün için harcanır)
  • Ürünü yayına aldığım anda, ilk giren kullanıcının deneyimi nasıl olacak? 
  • Ürünü kullanmak için bağımlı olduğum diğer servislerden nasıl kurtulabilirim? En az bağımlılıkla istediğim deneyimi nasıl sağlayabilirim?
  • Ürünümde tavuk-yumurta problemi varsa, bu problemi aşmanın akıllıca ve belki de geçici bir yolunu bulabilir miyim?
  • Elimde ürünün eşik noktasına ulaşmak için yeterli kaynak yoksa, hangi alternatif yollar ile bu kaynağı yaratmaya çalışabilirim?
  • İlk gelen kullanıcının deneyimi tatminkar olduktan sonra, o kişinin bana yeni kullanıcı getirmesini nasıl sağlayabilirim? (eğer mümkün ise)

Aslında bu noktaların çoğunu kapsayan soru, yukarıdaki “Ürünü yayına aldığım anda, ilk giren kullanıcı deneyimi nasıl olacak?” sorusudur. Burada benim önerim, eğer başka bir yol yok ise, çakallık yapmayı düşünmektir. 

Bir örnek üzerinden gidelim: Geçen blog yazımla alakalı olsun diye taksi uygulaması yapıyoruz ve piyasa da henüz alternatifi yok diyelim. İlk deneyen biz olacağız ve henüz ferrari mizi satıp projeye koymadık, o sebeple de büyük bir bütçemiz yokmuş gibi düşünelim.

“ilk gün deneyimi” sorusunu sorduğumuz anda, elimizde “kimin deneyimi?” cevabı vardır. Buradan da tavuk-yumurta problemini yaşadığımız bir ürün olduğunu anlarız. Sistemde hem taksici, hem de müşteri olması gerekir. Bir de üzerine, cografik bölgeleri eklersek, aslında elimizde epey bir taksi olması gerekmektedir.

Ancak henüz paramız yok, yatırımcıya da gittğimizde “önce çalıştığını kanıtla öyle gel” diyor. Peki ben bunun çalıştığını nasıl kanıtlayabilirim? Gerçekten ürünün tutup tutmayacağıyla ilgili, düşük maliyetli ne deneyebilirim? Belli bir bölgeye sınırlasak bile, taksicilere uygulama yükletmek çok maliyetli. Tanıtım yapıldığı an, uygulamaya girecek bir kullanıcı ise, içeride taksi görmediği an uygulamayı bir daha açmayacak, hatta kötü referans olacak. Kısacası, yazıyı daha heyecanlı bir yere çekmek için, düşünelim ki hiçbir şekilde taksicilere uygulama yükletme şansımız yok, sınırlı bölgede başlamak da kabul edilebilir bir alternatif değil.

Hemen bir hack (çakallık) düşünelim: Amacımız ya uygulamayı yükleyen bir son kullanıcının içeride yeterince taksi görmesini sağlamak, ya da taksicilerin bu uygulamayı yükler yüklemez bir sürü müşteri almasını sağlamak. Eldeki imkanlarla şu anda bu ikisini bir arada gerçekleştiremiyoruz. Peki neler biliyoruz?

  • Hali hazırda istanbul’da durak sistemi var ve telefon ile taksi çağırmak mümkün. İyi durumlarda 20 saniye içerisinde taksi söylenebiliyor.
  • Taksi duraklarının telefon – isim ve adres bilgileri taksiciler birliğinin sitesinden alınabiliyor.
  • Bir adrese genellikle birden çok durak hizmet verebiliyor.
  • Duraklar, hangi plakalı aracın adrese ulaşacağını ve ne kadar sürede ulaşacağını söyleyebiliyor.

Çakallığımız:

Uygulamanın Proof of Concept’ini tamamlayana, yani çalışır olduğunu kanıtlamak için, geçici olarak:

  • Taksi durakları uygulamada Taksi olarak harita üzerinde gösterilir.
  • Kullanıcı “çevremde taksi istiyorum” tuşuna bastığı zaman, ekranda “Taksilere ulaşılıyor, lütfen bekleyiniz” diyecek.
  • Bu sırada çağrı merkezi operatörleri (başlangıçta ekip de olabilir) kişiye en yakın 3 taksi durağını paralel arayarak taksi sorarlar.
  • İlk onayı alan operatör, plaka ve zaman bilgisini arayarak taksiyi yönlendirir, diğerleri vazgeçtiklerini söyleyerek kaparlar. (burada zaman içinde arayan sayısı değişmeli). Duraklarda taksi bulunamazsa, uygun hata mesajı verilir.
  • Operatör kendi ekranından “09 plaka, 3 dakika” yı seçtiği an, kullanıcının telefonunda “09 plaka, 3 dakika içerisinde orada” der ve geri sayım başlar.
  • Taksici böyle bir uygulamanın olduğundan bile haberdar olmaz, o telefona gitmiştir.  (biraz şaşkınlık yaratacaktır)
  • Kullanıcı bu sistemin çalıştığını düşünür. (taksici “telefonla arayan sen miydin abi?” derse biraz şaşkınlık yaşanabilir)
  • Olası sorunları anlamak için (taksi ulaşmadı, müşteri başka taksiye bindi vs.) her iki taraf da manuel olarak operatör tarafından aranarak geri bildirim alınır. (özellikle taksiciden almak gerekir, son kullanıcı yine uygulama üzerinden geri bildirimde bulunabilir)
  • Bu sistem sadece kısa vadede işe yarayacaktır. Bu nedenle gerçek anlamıyla bu işi hayata geçirmek için gereken hazırlıklar paralelde başlatılabilirse çok faydalı olur. (taksicilere cihaz dağıtmak ve tanıtım için gereken aşamalar)

Evet, yukarıdaki senaryo aslında ürün yöneticimizin ilk aklına gelen mükemmel sistem değil ve kusursuz çalışmıyor, ancak yine de gerçeğe yakın bir deneyim sunacaktır. Böylece, uygulamayı deneyen bir miktar kullanıcıya ulaşabilirsiniz ve devam edip etmeme kararını daha kolay verebilirsiniz.  Yapılan mübah mıdır? Bence deneme süreci için yaratıcı bir yöntemdir. Eğer bu konuda içiniz rahat etmediyse, uygulamanın (en gözüken yerine değil) bir noktasına nasıl çalıştığıyla ilgili bir uyarı koyabilirsiniz. Burada ürün yöneticisinin asıl sorması gereken soru şudur: Böyle bir yöntem seçilirken yaşanan deneyim kaybı, uygulamanın başarısız olacağının zannedilmesine neden olabilir mi? Hızlı başlayabilmek için bazı şeylerden vazgeçerken, insanların uygulamayı kullanmasını sağlayacak ana sebeplerini yok ediyor muyuz? Bunu anlamak için de ekstra efor sarfetmek gerekecektir.

images

Kısacası, özellikle bir startup içerisindeyseniz, kendinizi sadece “ürün yöneticisi” ve vizyoner olarak görmemeniz gerekiyor. Her ürün yöneticisi, bir girişimci gibi düşünüp, elimdeki kısıtlı kaynaklar ile 0. gün, ürünü nasıl hayata çıkarırım ı düşünmeli. Emin olun, ürünün 0. adımını planlamak, 3 sene sonra geleceği yeri planlamaktan çok daha zor. Bu biraz “futurist” ler konusu gibi. 20 yıl sonra dünya’nın nasıl olacağını çoğu tahmin edebiliyor ama 3 ay sonra ne olacağını tahmin etmek çok zor. Yukarıdaki örnek sadece bir düşünce şeklinin anlatması açısından hızlıca, yüzeysel düşünülerek yazıldı, eminim daha iyi bir alternatif veya örnek bulunabilirdi. Hatta sizin böyle bir örneğiniz varsa comment lere yazarsanız sevinirim.

not: sevgili okuyucu, arkadaşlar: Blog yazma konusunda epey amatörüm🙂 O nedenle eleştirileriniz varsa yazmaktan çekinmeyin lütfen. Sanırım ilk olarak daha kısa yazılar yazmayı başarmalıyım. Sevgiler

2 thoughts on “ürün yönetimi 0. gün taktikleri ve hack’leri

  1. Merhabalar,

    Özellikle bu konulardaki paylaşımlarınızı uzun zamandır takip ediyorum (FF ve iletken zamanlarından beri).

    Bu da gayet güzel bir yazı olmuş. Umarım bu tür konularda daha çok yazı yazarsınız. Birçok kişiye yol gösterici olacaktır. Kısa olmuş uzun olmuş fark etmez her türlü okunur🙂

  2. Bence yazının en kritik yeri: “Hızlı başlayabilmek için bazı şeylerden vazgeçerken, insanların uygulamayı kullanmasını sağlayacak ana sebeplerini yok ediyor muyuz? Bunu anlamak için de ekstra efor sarfetmek gerekecektir.” Artık lean bütün dillere düşmüş durumda, evet ürünlerimiz için deney yapmalıyız. Fakat “doğru deneyi tasarlamak” konusuna henüz eğilmiyoruz. Sanırım lean startup’dan sonraki gündemimiz de bu olacak.. Bu arada yazıdakine çok benzer bir şeyden bahseden şöyle bir talk var: (http://www.youtube.com/watch?v=2wJRdn71NK8). MVP(Minimum viable product) yerine MVE(Minimum Viable Experience) ve MVV(Minimum Viable Value)’nun neden doğru strateji olduğunu anlatıyor… Ellerine sağlık!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s