Başarılı ürünler geliştirirken öğrendiğimiz 50 ders [Çeviri]

1. Küçük ekipler (6 kişi veya daha az) harika ürünler yapabilir, ancak bunun için hedef belirleme, yol haritası önceliklendirme, metrik seçimi, kullanıcılarla iletişim ve kodu hızla dağıtma gibi konularda tam özerkliğe sahip olmaları gerekir.

2. Bir ürünün başarısı, onu yapan insanlara bağlıdır. İşe alım çıtasını yüksek tutmak kritiktir, çünkü yetenek birikimli etki yaratır. Kötü bir işe alım, takımın hızını diğer tüm etkenlerden daha fazla düşürür.

3. Harika ürünler yapmak için güven şarttır. Güven eksikliği ekipteki en büyük darboğazlardan biridir; bunun nedeni genelde yetersiz birini işe almak ya da o kişiye gelişmesi için doğru geri bildirimi vermemektir.

4. Güven, şeffaflıkla da inşa edilir. Açık çalışın, tartışmaları açık alanlarda yürütün ve yapılan işleri belgelendirin. Böylece herkes ihtiyaç duyduğu bağlamı paylaşır ve birçok şirkette görülen siyasi çekişmeler ortadan kalkar.

5. Süreçten çok güvene ve geri bildirime dayanın. Bu bizim temel değerlerimizden biridir. İnsanların istediği şeyleri üretip büyütmek incelikli bir iştir; bu yüzden çalışanların muhakemesine güveniriz. İşler ters giderse de doğrudan geri bildirim veririz.

6. Yönetim, şirket hedeflerini paylaşmalı; ürün ekipleri (mühendisler) ise bunlara ulaşmak için ne inşa edeceklerine ve kendi hedeflerine karar vermelidir. Her iki taraf da gerçek etkiyi metrikler ve kullanıcı geri bildirimiyle değerlendirmelidir.

7. Ürün, ideal müşteri profiline (ideal customer profile, ICP) bağlıdır. Ne inşa edeceğinizi belirleyen en önemli unsur ICP'dir. Doğru bir ICP, yalnızca hedef müşteriyi değil, ürünün ve pazara giriş stratejisinin tüm yönlerini tanımlar.

8. ICP'yi bulmak için önce tahmin edin ve test edin. Kayıt sırasında sorular sorun, tutunma oranlarını karşılaştırın, power user'ları belirleyin ve NPS anketleri yapın. Bilgi ve güven arttıkça ayrıntı ekleyin.

9. Ürün ilkeleri oluşturun. Bizim ilkelerimiz arasında “başarıyı değerlendirmek için gerekli tüm araçları sağlamak, proaktif olmak ve müşteri ile ürün verileri için tek doğruluk kaynağı olmak” yer alıyor. Bu, fikir tartışmaları ve kararlar için ortak bir dil sunar.

10. Kullanıcıların isteyebileceği her şeyi haritalayın. Yol haritası önceliklendirmesi yaparken buna ihtiyaç duyarsınız. Böylece ufkun ötesindeki harika fikirleri kaçırmazsınız.

11. Ürün, sadece özelliklerden ibaret değildir. Aynı zamanda markadır ve başkalarına sunduğunuz ürün deneyimidir. Her özelliğe yaptığınız yatırımın boyutu, işe aldığınız insanlar, inşa kararları, öne çıkan özellikler, müşteri iletişimi ve fiyatlandırma politikanız özgünlüğü oluşturur.

12. Web sitesi, ürünün ilk izlenimidir. Sıkıcı ve şablon gibi görünen bir site, arkasındaki ürünün ve ekibin zayıf olduğu sinyalini verir. Kendi benzersiz sitenizi ideal müşteri profilinize göre oluşturmak bunu önler ve kullanıcı kazanımını hızlandırır.

13. Bazen sorun ürün değil, pazardır. Örneğin Monzo'nun kurucusu ve YC partneri Tom Blomfield, üniversite arkadaşları için fatura paylaşım hizmeti geliştirirken, inşa etmeyi bırakıp kullanıcı kazanmaya odaklanması yönünde tavsiye aldı. 4 hafta cold call yaptıktan sonra sadece bir kullanıcı kazanabildiğinde pivot zamanının geldiğini anladı.

14. Pivot yapacaksanız büyük yapın. Stewart Butterfield, iki oyun şirketini Flickr ve Slack'e dönüştürdü. LinkedIn kurucu ortağı Reid Hoffman, startup kurucularının başarısızlıktan başarıya pivot yapabilmesi için işin geri kalanını “slash and burn” etmesi gerektiğini söyler. Benzer görünüyorsa daha da uzağa gidin.

15. 37signals'tan Jason Fried'in dediği gibi: “Bir fikri doğrulayamazsınız. Çünkü ortada yoktur; gerçekten yapmanız gerekir. Doğrulamayı pazar yapacaktır.”

16. Planlar faydalıdır ama onlara katı biçimde bağlı kalınmamalıdır. İyi icra, belirli bir planı uygulamak değil, en önemli işi tekrar tekrar yapmaktır. İnsanları “plana uyma” durumuna göre değil; teslim ettikleri şeyler, dağıtım sıklığı ve etkilerine göre değerlendirin.

17. Bir şeyi “bir hafta daha” ertelemek neredeyse her zaman kötü bir fikirdir. Bu tutum aylar boyunca biriktiğinde momentumu ciddi biçimde düşürür. Bir şeyi ne kadar erken kullanıcıların eline verirseniz, değerini o kadar çabuk öğrenir ve iyileştirebilirsiniz.

18. Devam eden işi azaltın. PR'ler bir gün içinde bitmeli, güne başkalarının review taleplerine yanıt vererek başlamalı, her an merge edebilmeli, feature flag arkasında deploy etmeli ve production'da test etmelisiniz. Bunların hepsi işin bağlam yükünü azaltır.

19. Hızlı dağıtım, ürün geliştirme felsefemizin merkezindedir ama bunun trade-off'ları vardır. Teknik tedarik, planlama toplantıları, agile ritüeller ve metrik incelemeleri ikinci plana düşer. Asenkron çalışma bunu daha da mümkün kılar.

20. Ürüne yeni teknolojiyi yalnızca aşırı maliyet, ölçekleme sorunu veya müşteri talepleri gibi acil problemlerde dahil edin. Çözüm teknolojisini, ekibinizin ya da başka ekiplerin bunu doğrudan nasıl çözdüğünü sorarak bulabilirsiniz.

21. Yapay deadline'lar ekipleri daha hızlı yapmaz. Aksine, teknik borç yığınları ve tükenmişlik getiren yıkıcı bir döngü yaratır. Ekibi yavaşlatan süreçleri kaldırın ve küçük ekiplere hızlı dağıtım için özerklik verin.

22. Daha hızlı dağıtım için bir başka yöntem de varsayılan tasarımı ortadan kaldırmaktır. Bir design system kurduktan sonra mühendislerin inşa etmesine izin verin. Gerekirse dağıtılmış olan şeyi sonradan design review ile iyileştirin.

23. Feature flag'ler, ürün mühendislerinin değişiklikleri hızlıca dağıtmasına, production'da test etmesine ve gerçek kullanıcı geri bildirimi almasına olanak tanır. Beklendiği gibi çalışmadığında kill switch görevi görerek riski de azaltır.

24. PostHog'da en iyi iletişim biçimi pull request'tir. Mesajlardan veya issue'lerden farklı olarak, geri bildirimi anında etkiye dönüştürür. Bu, eylem odaklı yapımıza uyar ve daha sıkı bir geri bildirim döngüsü oluşturur.

25. Sahipliği netleştirin. Ne inşa edileceğine karar vermek böylece çok daha açık ve hızlı olur. Sahiplikten kaçınan ekipler, dağıtım yapmak yerine zamanlarını planlama, beyin fırtınası, toplantı ve proje yönetiminde harcar.

26. Mühendisler ne inşa edeceklerine karar verebilir. Çünkü teknik kısıtları anlar, özellik kalıplarını fark eder ve sorunların nasıl çözüleceğini bilirler. Ancak kullanıcı ihtiyaçları konusunda bir bilgi darboğazı olabilir.

27. Ürün yöneticileri, mühendisleri kontrol etmek yerine; ürün analitiği, kullanıcı araştırması ve rakip incelemesi gibi araçlarla ürün ekibine bağlam sağlamalıdır.

28. Çoğu kişi Steve Jobs değildir. En baştan “kendiliğinden” ne inşa edeceğini bilen bir vizyona ya da dev bir resme sahip değildir. Bunun yerine bir şey yayınlar, kullanıcıya sunar ve geri bildirim döngüsünü tekrarlar. Bu hız ne kadar yüksekse ürün de o kadar iyi olur.

29. Ürün mühendisi işe alın ve onlara güvenin. Onlar, ürün inşa etmek için gereken full-stack becerileri ile müşteri takıntısını bir arada taşır. Kullanıcılarla konuşmalı, röportaj yapmalı, yeni özellik testleri için katılımcı bulmalı, geri bildirim toplamalı, destek vermeli ve incident'lara müdahale etmelidirler.

30. The Mom Test'i okuyun. Potansiyel kullanıcıların sorunları hakkında nasıl konuşulacağını öğretir. Temel fikir, iki tür kullanıcı görüşmesidir: problemi keşfetme ve çözümü doğrulama. İlki gelecekteki ürün kararlarına rehberlik eder, ikincisi ise şu anda üzerinde çalıştığınız şeyi iyileştirmenize yardımcı olur.

31. Kullanıcı görüşmelerinden en yüksek verimi almak için, kullanıcıların (ICP) kim olduğunu, ürünü nasıl kullandıklarını ve sırada neyi inşa edeceğinizi önceden bilin. Böylece görüşmeler sonraki adımların odağını netleştirir, kafa karıştırmaz.

32. Potansiyel olarak inşa edilebilecek şeyler içinde en “gerçek” olan, destek talepleridir. Çünkü belirli bir kullanıcı somut bir sorun yaşıyordur; bunu çözdüğünüzde ürün anında iyileşir. Diğer değişiklikler bu kadar sezgisel değildir.

33. Mühendisler destek işini üstlendiğinde, fikir aşamasından uygulamaya ve sürekli bakıma kadar tüm ürün yaşam döngüsünün sahipliğini teşvik eder. Her aşama, gerçek müşteri acı noktalarıyla ve sorunların arkasındaki kod bağlamıyla birikerek birbirine bağlanır.

34. Mühendislerin destek vermesi, kullanıcı sorunu ile dağıtılan düzeltme arasındaki döngüyü kısaltır. Destek personeli, ürün yöneticileri veya planlama süreçleri araya girmez. Bonus olarak kullanıcılar da buna bayılır.

35. Kendi ürününü kullanmak (dogfooding), dağıtım hızını artırmaya, sorunları kullanıcıya ulaşmadan fark etmeye, ürünü derinlemesine anlamaya ve kullanıcı empatisi kurmaya yardımcı olur. Ancak bu, kullanıcılarla konuşmanın, gerçek geri bildirim almanın ve kullanım metriklerini takip etmenin yerine geçmez.

36. Ürün ekibimizin interview popup ile kendi ihtiyacını çözmesi örneğinde olduğu gibi, kendi ihtiyaçlarını çözmek kullanım senaryosunu doğrulamak için etkilidir. Kendi ürününüzü kullanmanız gerekirken kullanmıyorsanız bu bir şeylerin yanlış olduğunun işaretidir; düzeltin.

37. Harika ürün geliştiriciler her zaman prototipleme ve deney yapma hâlindedir. MVP'ler ve proof-of-concept'ler inşa etmeye, tamamlanmamış işleri yayınlamaya, geri bildirim toplamaya ve başarısız olursa pivot yapmaya alışık olmalıdırlar. Altyapıdan tasarıma kadar sıfırdan ürün inşa etmeye yönelik tüm becerilere de ihtiyaç duyarlar.

38. Başarılı bir A/B testinin temelinde, neyin ve neden test edildiğini açıklayan iyi bir hipotez vardır. Testin bağlamını, değişiklikleri, metrikleri ve beklenen sonucu dahil edin.

39. Ürün deneylerinde başarısız olup kaldırılabileceğini kabul edin. Bunu feature flag ile kolayca kaldırılabilir şekilde kurun ve mükemmel bakımı yapılan, tam ölçeklenebilir bir sürüm yerine “yeterince iyi” bir sürüm yayınlayın. Başarılı olursa sonra iyileştirirsiniz.

40. Ürün deneyleri, düşündüğünüzden çok daha “aptalca” yapılabilir. Tüm özelliği inşa etmek yerine fake door testi deneyin. Yani aslında hiçbir şey yapmayan bir seçenek veya buton ekleyip insanların tıklayıp tıklamadığına bakın.

41. Ürün deneyinin başarısız olması dünyanın sonu değildir. Google'da deneylerin %80-90'ı “başarısız” olur. Bu zaman kaybı gibi görünebilir, ancak büyük ölçekte %10'luk başarı tüm başarısızlıkları telafi eder. Örneğin Bing'de başlık gösterimine ilişkin bir A/B testi geliri %12 artırdı (100 milyon doların üzerinde).

42. Büyümeye odaklanırken growth engineer gibi düşünün ve önceliklendirin. Hedef alanı belirleyin, temsil edici metrik seçin, iyileştirme hipotezi kurun ve bunu mümkün olan en küçük deneyle test edecek uygulamayı yapın.

43. Analitik kurmak için neredeyse hiçbir zaman çok erken değildir. Yayınlanmamış ürünler için bu doğru olabilir, ancak “henüz erken” diyerek analitik olmadan çıkmak sahte bir tasarruftur. Yayından sonra öncelik, mümkün olan en yüksek hızla dağıtımdan, doğru şeyi mümkün olan en yüksek hızla dağıtmaya kayar.

44. Analitiğe başlarken küçük başlayın. Belirli bir ürün veya özellik seçin, autocapture ile kullanımı izleyin, bunu trend ve retention grafikleriyle görselleştirin ve bunları iyileştirecek özellikler yayınlamayı deneyin. “Modern data stack industry complex” işleri gerçekte olduğundan daha karmaşık gösterir.

45. Başlangıç metriğinizin ne olması gerektiğini bilmiyorsanız activation'ı öneririm. Diğer metriklerin üstünde yer alır, mühendisler tarafından doğrudan etkilenebilir ve organizasyonun tamamı için faydalıdır.

46. activation'ın yanında retention da inşa ettiğiniz şeyin etkisini anlamak için bir başka temel metriktir. Haftalık değişimleri izlemek, yaptığınız değişikliklerin kullanıcı tutmaya yardımcı olup olmadığını anlamanızı sağlar.

47. Ürün-pazar uyumunu ölçerken, kullanıcı etkileşiminin kullanıcı büyümesinden üstel biçimde artıp artmadığına ve retention'ın yataylaşıp yataylaşmadığına (%0'ın üzerinde) bakın. Sonrasında ICP kullanıcılarının güçlü retention gösterip göstermediğine ve ücretli müşterilerin ICP içinde olup olmadığına bakın.

48. Growth review'ler, ekibin inşa ettiği şeylerin gelir, ürün analitiği ve kullanıcı geri bildirimi gibi önemli metrikleri etkileyip etkilemediğini kontrol eder. PostHog'da bu, ürün yöneticisinin temel sorumluluklarından biridir.

49. Birden fazla ürün inşa ediyorsanız, her bir ürünü küçük bir startup gibi ele alın. Kendi ürün kararları, fiyatlandırması, geliri, maliyetleri ve müşteriyle yüz yüze çalışan ekiplerle koordinasyonu olmalıdır.

50. İlginç ürünlere bağlı kalın. PostHog kurucu ortağı James'in ürün-pazar uyumu rehberinde yazdığı gibi: “İlgilenmiyorsan pivot yap. Hepsi bu. Kendi hissini verdiğin işlere bağlı kaldığında daha büyük sonuçlar elde edersin.”