Ürün yönetimi, hikâye anlatmaktır.
Bu yüzden size bir hikâye anlatarak benim ürün yönetimini nasıl düşündüğümü ve yapay zekânın bunu nasıl değiştirdiğini paylaşayım.
Asla unutmayacağım mülakat sorusu
Kariyerime RealNetworks'te mühendis olarak başladım ve birkaç yıl içinde RealPlayer'ın ürün ve mühendislik ekibinden sorumlu oldum. O zamanlar oldukça anlamlı bir tüketici ürünüydü; yüz milyonlarca kullanıcısı vardı ve ses ile videoyu erken internet dönemine taşıyan öncülerden biriydi. İş tarafındaki insanlarla toplantılarda oturur, "Oynatıcı her açıldığında bir reklam göstermeliyiz" gibi fikirler önerirlerdi. Bunun doğru olmadığını biliyordum ama ne kadar para kazanacağımızı gösteren Excel tablolarına karşı argüman üretecek bir yolum yoktu. Gerçek bir ürün müdürü olmak istiyordum ve muhtemelen işletme okuluna gitmem gerektiği sonucuna vardım.
Berkeley'de işletme okuluna başladım ve varışımın hemen ardından eski üniversite e-posta listemde LinkedIn'in işe alım yaptığını gördüm. Başvurdum ve kendimi Reid Hoffman ile bir mülakatta buldum. Oturdu ve asla unutmayacağım bir mülakat sorusu sordu:
"Yani, ürün müdürü olmak istiyorsun. Bir ürün müdürünün ürettiği 'artefakt' (çıktı) nedir?"
Açıkladı. Mühendislerin bir artefaktı vardır: kod. İş geliştirme uzmanlarının bir artefaktı vardır: imzalanmış sözleşmeler. Tasarımcılar görsel görünümü ve grafikleri üretir. CEO'nun ise organizasyon şeması, finansman planı ve herkesi bir arada tutan vizyonu vardır. Peki ya bir ürün müdürü?
Ona, ürün müdürlerinin gerçekten böyle "artefaktlara" sahip olduğundan emin olmadığımı söyledim ama temel yaptığımız şeyin olan biten her şeyi toplayıp bir spec'te (ürün gereksinim dokümanı) yazmak olduğunu belirttim. Spec, plandır. Gereksinimleri ve yapacağımız her şeyi tanımladığımız yerdir ve tüm ekiplerin oradan başlayarak inşa etmesini sağladığı için şirketin en önemli belgelerinden biri haline gelir.
Bellki ki gergindim. Sanırım fark etti, çünkü bunun iyi bir cevap olduğunu söyleyerek beni rahatlattı. Sonunda işi aldım, LinkedIn'e katılmak için işletme okulunu bıraktım ve o soruyu o zamandan beri düşünüyorum.
Spec'ten hikâyeye evrim
Çünkü yanlış cevabı vermiştim.
Bu hâlâ yazılım geliştirmede Şelale (Waterfall) Dönemi'ydi. LinkedIn'de sosyal bir platform içinde bir iş platformunu yeniden hayal etmeye çalışıyorduk; burada işe alım yöneticileri, karşılıklı bağlantılar bağlamında iş başvurularını görebilir, adaylar iş ilanlarını görebilir ve ağları üzerinden ön kapıya ulaşmanın yollarını bulabilirdi. Bu keşif sürecinde, tüm deneyimi ve gereksinimleri tanımlayan 120 sayfalık bir spec yazdım.
Aradan geçen yıllarda bu konu üzerine çok düşündüm. Çünkü o spec, açıkça görüldüğü üzere, en önemli artefakt değil. En önemlisi hikâye.
Spec, bir sistemi, ne yapması gerektiğini ve tamamlanmadan önce hangi kutucukların işaretlenmesi gerektiğini tanımlar. Bu, ürün yönetiminin sanatı değildir. Ürün yönetimi, ürünü kullanacak insanların hikâyesini ve bunun hayatlarında neden önemli olacağını anlatmaktır. Kiminle konuşuyorsanız olsun, anında anlaşılır olmalıdır. Ve tekrarlanabilir olmalıdır - insanlar onu odada siz olmadan da sadakatle birbirlerine aktarabilmelidir.
Bu tamamen farklı bir belge ve tamamen farklı bir iştir.
On yıl önce ürün yönetimi hakkında bir konuşma yaptım ve insanlar bana hâlâ onu gönderiyor; bu ya gurur verici ya da alanın ilerlemediğinin bir işareti. Her iki ihtimali de göz önünde bulunduruyorum. Neyse, tüm konuşma tek bir cümleye indirgenmişti: "Bir ürün müdürü, ekibine (ve şirketine) kullanıcılarına doğru ürünü sunmasına yardımcı olur." Konuşmanın büyük bölümünü bu cümleyi kelime kelime parçalayarak geçirdim.
- Ekiplerine yardım eder. Lider siz değilsiniz. Çoğu insan ürün müdürünün lider olduğunu düşünür. Siz, işin gerçekleşmesine yardım eden kişisiniz. Bu da şu anlama gelir...
- Ekibinizi ve şirketinizi anlamanız gerekir. Ekip sizin alanınızdır: onu anlamak zorundasınız! Ve daha büyük resmin içinde nasıl konumlandığını da anlamalısınız ki sadece kendi hedeflerinizi değil, şirketin hedeflerini de hizmet edebilesiniz.
- Sunmak (Ship). İstediğimiz kadar konuşabiliriz ama günün sonunda önemli olan tek şey, ürünü müşterilerin önüne koymaktır.
- Kullanıcılarınız için doğru ürün. Sonunda işe geldik: "doğru"nun gerçekte ne demek olduğuna odaklanmak.
Yapay zekâ çağında bunların ne kadarı değişiyor?
Neler Değişiyor?
Açıkça bir şeyler değişti, aslında birkaç şey. Bir yandan, kodlama şeklimizi ve bir fikirden çalışan bir şeye ne kadar hızlı geçebileceğimizi değiştiriyor. Diğer yandan, kullanıcıların bir üründen ne beklediğini değiştiriyor. Bence henüz bunun kabuğunu bile kıramadık, özellikle tüketici tarafında. İhtiyacınızı tarif edip ürünün onu sunmasını sağlayabilmek, belki arka planda çalışan ajanlarla, öğrenmek veya arayüzle uğraşmak zorunda kalmadan.
Bir şeyler yapmanın maliyetinin çöktüğüne dair hiçbir şüphe yok. Artık bir şeyi kapsamlandırmak ve denemek o kadar da zor değil; bu size muazzam bir esneklik sağlıyor. Ancak yargılama maliyeti hiç değişmedi. Ne inşa edileceğini belirlemek her zamankinden daha önemli hale geldi.
Ürün geliştirme bir döngüdür. Eskiden biri bir fikre sahipti - ve bu siz olmak zorunda değil; iyi bir şirkette her yerden gelebilir. Denersiniz. Bir spec, bir ürün brifi veya o belge için ne adlandırıyorsanız onu yazarsınız. Bunun bir ön maliyeti vardır: kapsamlandırma, tasarım, tartışma - değerli mühendislik zamanını harcamadan önce olması gereken her şey. Bunların hepsi, mühendislik zamanını kötü kararlardan korumak için icat ettiğimiz ritüellerdir. Çünkü yılda ancak altı-sekiz kez bu döngünün etrafından dönebiliyordunuz.
Sonra bir şeyler yapmak absürt derecede ucuzladı. Biraz daha ucuz değil; farklı bir büyüklük mertebesinde. Ve olan şey gerçekten ilginç. O eski döngü hâlâ orada duruyor - sadece yeni bir sırayla yeniden düzenlenmiş halde.
Eski döngü şöyleydi: fikir, spec, maliyetlendirme, kapsamlandırma, diğer her şey, sonra inşa etmek. Şimdi:
- Önce, fikri alın ve AI ile hızla inşa edin, sadece nasıl çalıştığını ve nasıl hissettirdiğini görmek için.
- Onunla oynayın, nasıl hissettirdiğini ve genel resme nasıl uyduğunu anlayın. Prototipler, "ya şöyle olsaydı"lardan her zaman daha iyidir.
- Sonra tasarlayın. Artık onunla oynadığınıza göre, onun ne olduğunu biliyorsunuz ve bunun bir prototipten fazlası olması için ne gerekeceğini gerçekten konuşabilirsiniz. Burada tasarımı her iki anlamda da kastediyorum: görsel ve UX tasarımı, ayrıca mühendislik tasarımı.
- Ardından sunun ve öğrenin.
Tamamen tersine çevrildi: spec-kapsamdan, inşa-oyna'ya. Bence bu, şu anda yaşanan diğer her şeyden daha fazla ürün yönetimini değiştiriyor.
Bu nihayetinde spec'in artık teslim edilebilir çıktı olmadığı anlamına geliyor; gerçek anlamda. Uzun bir belge yazarak ve kağıt üzerinde her şeyi doğru yaparak başlamak zorunda değilsiniz. Bu eskiden idealist bir anlamda doğruydu, ama şimdi literal anlamda bariz bir şekilde doğru.
Ancak dikkatli olmak istiyorum, çünkü yapılabilecek eşit ve zıt bir hata daha var.
Demolar artık neredeyse bedava. Çalışan ürünler değil. Bu yeni yaklaşımın madalyonun öteki yüzünü sürekli görüyorum: "Harika, hemen sun." Hâlâ böyle işlemiyor. Hepimiz bir prototipten gerçek bir şeye giden mesafenin aşılması için hâlâ zaman gerektiği gerçeğine saygı duymalıyız.
Ürün müdürleri hakkında, işlerinin çoğunlukla "Programa sığar mı?" diye sormak olduğu yönünde bir klişe vardır. Bu fikri tamamen atın. En önemli soru şudur: Ürüne sığar mı?
Hepimizin harika fikirleri var ve artık hepimizin bizim için kod yazabilen ajanları var. Ne inşa edeceğine karar vermek resmi olarak bir kaynak tartışması değil. Bir etki tartışmasıdır. "Bu ya da şu", "bu ya da hiçbiri" değil. Dünyaya ne yapmak istediğinizi bildiğiniz bir vizyonunuz olduğunda, zevk ve kürasyon burada çok önemlidir. Ancak inşa ettiğiniz sistem yine de eksiksiz hissettirmelidir.
AI hakkındaki en büyük endişem, bizi daha hızlı hareket ettirmesi ve dolayısıyla her şeyi sıkıştırıp doldurmamıza izin vermesidir. İçerikte "AI slop"tan (AI çöpünden) bahsediyoruz; ürün için AI slop'un anlamı budur. Birkaç yerde zaten bunun olduğunu gördüm ve sanırım hepimiz biraz endişeliyiz. Herkesin her şeyi inşa edebildiği bir dünyada, ne inşa edeceğine karar vermek tüm iştir. Ve bu bir hikâye problemidir. Hangi hikâyeyi anlatmak istiyorsunuz? Müşterilerinizin hangi hikâyeyi anlamasını istiyorsunuz? Akıllarında hangi hikâyenin yaşamasını istiyorsunuz?
Bir PM olarak göreviniz, ürünün ne yapacağına dair bir spec yazmak değildir. Göreviniz, ortak bir anlayış yaratmaktır - ne yaptığımız ve neden yaptığımız konusunda ortak bir resim. Kullanıcı neden burada? Her adımda ne hissediyor ve bu neden önemli? Nerede etkileyici, nerede sıkıcı? Bir ürünün ara sıra sıkıcı olması sorun değildir, yeter ki nerede olduğunu bilin. Ama iyi bir senaryo yazamıyorsanız, ürün sıkıcı olacaktır.
AI'nin size verdiği hediye, bunu şimdi ücretsiz olarak, en baştan öğrenebilmenizdir. Hızlıca inşa edebilir, bir his edinebilir, onunla oynayabilir ve o tek cümleyi bulabilirsiniz: Bu ürün birinin hayatında kimin için ne yapıyor? Çünkü buna cevap verebilirseniz, benim soruma da cevap verebilirsiniz: "İnsanlar gerçekten kullanıyor mu?" Çünkü artık ne yaptığını söylediniz ve onların bunu yapıp yapmadığını soruyorsunuz.
Değişmeyen Şeyler
Ürününüz için bir "vizyona" sahip olmak ne anlama gelir?
Vizyon derken bir misyon bildirgesini kastetmiyorum. Onlar önemlidir ama vizyon değillerdir. Vizyon, ürünün kullanıcılar için var olmasının uçtan uca nedenidir. Bunun için basit bir çerçevem var:
- Amaç. Birisi neden ürününüzü eline alıyor ve hayatına dahil ediyor?
- Temel eylemler. Eline aldığında gerçekte ne yapıyor? Birden fazla şey olabilir, hepsini anlamak zorundasınız.
- Döngü. Bu temel eylemlerin her biri için beklenen frekans nedir?
Kariyerim boyunca kurucular ve diğer ürün insanlarıyla görüşmelerimde onlara hep şunu sorarım: İnsanlar ürününüzü kullanıyor mu? Ve neredeyse her zaman doğrudan kullanıcı verilerine atlarlar. "%50 DAU/MAU oranımız var. 10.000 kaydı aştık. Bekleme listemizde bir milyon kişi var. ARR'miz bir milyon. Günde dört milyar token işliyoruz. App Store'da #3 numara olduk."
Bunların hiçbiri sorduğum soruya bir cevap mı?
Bazen soruyu tekrar sorarım ama bir kelime daha eklerim: İnsanlar ürününüzü gerçekten mi kullanıyor? Ve sonra bazen neyi sorduğumu kavrarlar.
LinkedIn'in amacı bulmak ve bulunmaktı. Belki bazı insanlar için temel eylem, biri ulaştığında yanıt vermekti. Çoğu insan için bu günlük bir şey değildir; yılda bir veya iki kez olabilir.
Döngüye bakın - yılda bir veya iki kez. Bunu anlamak, LinkedIn'in işe yaraması için kritikti çünkü ağın, bulunmaya istekli çok sayıda insana ve en azından bazı arama yapan insanlara ihtiyacı vardı.
Sonuçta LinkedIn bir sosyal ağdı, bu yüzden kullanıcıları her gün eylem almaya teşvik etmeye kalkışabilirsiniz. Biz bunu yapmadık. Bunun yerine, ilk günlerde insanların profillerini güncel tutmalarını sağlamak için muazzam zaman harcadık. Yılda bir veya iki kez bulunmanız tamamen sorun değildi, yeter ki bu gerçekleştiğinde, tıklayıp "bana biri ulaşıyor, harika" diyerek anlayabilesiniz.
Ürününüzün işe yarayıp yaramadığını ölçerken, bu temel eylemler önemlidir. Doğrudan trafiğe odaklanın: kelimenin tam anlamıyla size gelen insanları bulun. Uygulamayı yüklemiş ve simgeye tıklamışlardır ya da alan adınızı elle yazmışlardır; kendi iradeleriyle size gelmişlerdir. Önemli olan trafik budur, birini o an geri getirmenin diğer tüm yollarının aksine.
Ve sonra yalnızca temel eylemleri gerçekleştiren insanları sayın. "Uygulamayı kısa süreliğine açtı" değil, gerçekten etkileşime geçti. Discord'da bu, "canlı bir oturuma girdi. Gerçekten mesaj okudu ve gönderdi" olurdu.
Bu temel eylemlerin ne olduğunu tanımlayamıyorsanız, ürününüz yoktur, çünkü anladığınız bir şeye sahip değilsiniz demektir.
Şimdi, yeni olan ve sevdiğim bir şey var: Kullanıcının ürünle konuştuğu veya ona bir şekilde prompt verdiği AI ürünlerinde, artık kullanıcı yolculuğunuzun literal bir transkriptine sahipsiniz. İnsanların kendi kelimeleriyle ne söylediğini görebilirsiniz. Birinin pes edip yeniden ifade ettiği tam anı görebilirsiniz. Ürünün yapmasını bekledikleri ama yapamadığı şeyi görebilirsiniz. BUNLARI OKUYUN! AI, daha önce görmeyeceğiniz şeyleri ortaya çıkarmak için harikadır, ama her şeyi özetletmemeli ve sizin yerinize fikir oluşturmasına izin vermemelisiniz. Fikrinizi oluşturmak - hikâyenin gerçekte ne olduğunu anlamak - ürün yönetiminin işi ve sanatıdır.
Onboarding (Kullanıcı Karşılama)
Onboarding, bir müşteriye hikâyenizi anlatmak için sahip olduğunuz en önemli andır. Ürününüzü keşfettiler - belki bir reklam, viral bir davet, bir makale yoluyla, ne olursa olsun. Var olduğunuzu biliyorlar; meraklılar ve denemek istiyorlar. Onlardan bundan daha fazla ilgiyi bir daha asla alamayacaksınız.
Bu noktada hatırlamanız gereken şey, herkesin ürününüze aynı motivasyonla gelmediğidir. Hevesliler vardır. İçeri girmek çok isterler. Gitmeye hazırlardır. Ve net olmak gerekirse, şirkette çalışıyorsanız, Hevesli Diyarı'nda yaşıyorsunuzdur. Şirketinizdeki herkes Hevesli gibi ele alınmalıdır; zaten her gün ürünün içindedirler. Ürüne onboarding yaparken "Ne yaptığımı biliyorum, bu sıkıcı, bu adım neden burada?" diye düşünürler.
Öte yandan Geçiciler (Fly-bys) vardır. Sizinle pek ilgilenmezler. Duydular, baktılar ama mesaj ulaşmadı ve kaçacaklar.
Bu iki tür kullanıcı, dağılımın uçlarıdır. Aralarında büyük, bulanık bir orta kısım vardır. Bunlar bir sebeple gelen insanlardır: Meraklılar! Daha fazlasını öğrenmek istiyorlar! Ve onları gerçekten ürününüzün çekirdek kullanıcılarına dönüştürebilirsiniz. Etrafında inşaa etmeniz gereken insanlar bunlardır. Heveslileri zaten alırsınız. Anlamanız gereken orta kısımdır.
Kullanıcılarınızın motive ve meraklı olduğunu varsayın. Ürünü adım adım tanıtmak için zaman ayırın. Daha basit adımlar, daha az karmaşık adımları yener. Yıllar içinde birden fazla şirkette A/B testleriyle bunu kanıtladım. Her adım ayrık ve basitse, ne istediğiniz ve ne öğrettiğiniz açıksa, bu tek büyük ekranları veya adım sayısını düşük tutmak için karmaşık seçimleri yener. Her seferinde.
Peki bunu gerçekte nasıl inşa edersiniz?
Temel mesajı tekrarlayarak başlayın: Bu şunun için. Bağlamı ürünün içinde belirtin. Temel bilgileri istemek sorun değil - e-posta, şifre, telefon. Geri kalan her şey için, neden sorduğunuzu ve bununla nasıl ilişkili olduğunu açıklayın. Ardından ürününüzü, kullanıcının atması gereken net bir eylemle birlikte ana kavramlarına bölün.
AI ürünleri bunu kolaylaştırmadı, zorlaştırdı. Boş prompt kutusunu alırsınız. Bazı açılardan tasarlanmış en kötü onboarding ekranıdır. Sihirli bir kutu. Her şeyi yapabilir. Yani... ne yapmak istiyorsunuz?
Günümüzde birçok ürün "Merhaba, yardım etmek için buradayım, bana herhangi bir şey sor!" diyerek başlıyor. Kendim adına konuşursam, o anda en akıcı veya yaratıcı kişi ben değilim. Yetenekleri kavram kavram öğretmelisiniz. "Böyle bir şey sorarsan, yapabilirim." Ve sonra ürünün bunu yapmasına izin verin. Kullanıcıyı, ideal olarak kendi verileriyle, en az bir değerli kullanım durumuna hızla getirin ki onlar için gerçekten değerli olsun.
Bazen bana soruyorlar: Daha uzun bir akışla daha fazla kişi vazgeçmez mi? Evet! Ama tamamlayanlar, ürününüzü gerçekten kullanma olasılığı çok daha yüksek olanlardır. İki farklı onboarding akışını A/B test ediyorsanız, akışın sonuna kaç kişinin ulaştığına BAKMAYIN. Ertesi gün veya sonraki hafta kaç kişinin geri döndüğüne ve kaçının temel bir eylem aldığına bakın. O anda onlara "Bu ürün nedir?" diye sorarsanız, aşağı yukarı doğru cevabı vermelidir. Bundan sonraki elde tutma (retention) verileriniz, karnenizdir.
Twitter'dan Bir Hikâye
Tüm bunları Twitter'dan bir hikâye anlatarak bir araya getireceğim.
2009'un sonunda Twitter'a katıldım. Bir büyüme sorunumuz vardı - aslında büyüme sorunu değildi. Twitter sürekli haberlerdeydi. İnsanlar blog yazıları yazıyordu, medya hakkında konuşuyordu ve birçok kişi şunu soruyordu: "Bu Twitter denen şey nedir? Anlamam ve kayıt olmam gerekiyor." Ve sonra milyonlarca kişi yaptı. Ama bir daha geri gelmediler.
Sorun, kimsenin Twitter'ın ne olduğunu size anlatamamasıydı. Bunu kanıtlayabilirim:
Başlık: "Sonunda bir numaraya ulaştık."
Onboarding'i yaptığımız şekil şuydu: insanlar kayıt olur ve "Arkadaşlarını Bul" veya "20 Rastgele Kişiyi Takip Et" seçeneklerini görürdü. Çoğu kişi bunu atlar ve şu görünen bir sayfaya inerdi:
Bu oldukça berbat! Büyük boş bir kutu. İnsanlar ona bakar ve "...Söyleyecek bir şeyim yok" diye düşünürdü. Ve sonra giderlerdi. O anda onlara "Twitter nedir?" diye sorsanız, "Sanırım dünyaya bir şey söylemekle ilgili? Ya da arkadaşlarımı bulmakla? Bilmiyorum" derlerdi.
Bu yüzden onboarding'i birkaç yıl içinde yeniden inşa ettik ve işe yarayan şeyi bulduk: Learn Flow (Öğrenme Akışı). Onlara Twitter'ı, bir hikâye olarak, kavram kavram öğretti. Ve o yıl sunduğumuz diğer her şeyden daha fazla elde tutmayı artırdı.
Learn Flow, ekran ekran
Önce, yeni ana sayfa: "Twitter'a Hoş Geldiniz." Oraya içerik koymaya çalışmadık, sadece şunu dedik: "Umursadığınız kişiler ve kuruluşlarla şu anda neler olup bittiğini öğrenin." Açıkçası, Twitter için oldukça iyi bir tanım.
Sonra: Bu bir tweet. Kısa bir mesaj, en fazla 140 karakter ve linkler içerebilir. Artık tweetlerin bu şeyin birimi olduğunu biliyorsunuz.
Sonra zaman çizelgenizi (timeline) oluşturmanız gerekir. Bu yüzden size bir zaman çizelgesi gösterdik. Soldaki insanlarda "takip et"e tıklamanızı sağladık. Ve takip ettiklerinde, tweetleri sağda belirdi. Böylece tüm fikri tek bir harekette alırsınız: Takip et'e tıklarım, tweetler görünür, bu benim zaman çizelgem. Bu da Twitter'ın gerçek kavramıdır - tweetler, takip etme ve bir zaman çizelgesi.
Ve sonra, sonunda, zaman çizelgeniz. Üzerindeki her hesabı tanırsınız, çünkü onları gerçekten siz takip etmiştiniz.
Onboarding, sizin hikayenizdir.
Kullanıcılarınız İçin Doğru Ürün
Bir ürün müdürü olarak göreviniz, ekibinize ve şirketinize kullanıcılarına doğru ürünü sunmasına yardımcı olmaktır. AI dünyasında, sunmak (ship) eskisi kadar sorun değil. Doğru ürünü ve kullanıcılarınızın kim olduğunu anlamak, her zamanki kadar, hatta belki daha da önemli.
Her zaman insanların ürününüzü gerçekten kullanıp kullanmadığını sorun. Bunun ne anlama geldiğini anlayın. Amacı, temel eylemleri, döngüyü düşünün. Mantıklı göründüğünden daha fazla zamanı onboarding'e harcayın. Bulanık ortayı dönüştürdüğünüz ve ürününüzün hikâyesini gerçekten anlattığınız yer burasıdır.
Prototiplerde daha hızlı gitmek için AI'yi kullanın — ama yargınızı hızlandırmayın. Yargınızdan vazgeçmeyin. Sadece "Test edip görelim" demeyin. Bu, savruk bir ürünle sonuçlanmanın yoludur. Yargınızı her yerde koruyun. İşin en zor kısmı, hâlâ ürün müdürleri olarak tüm yaratıcılığımızı, artık erişimimiz olan tüm verilerle dengelemektir.
Bol şans!
