Bülten #24: Yeni Özellik Geliştirmek-1: Keşif
nedir, neden önemli, araştırma teknikleri ve kullanıcı görüşmeleri, koordinasyon, kapsam, topluluk üyelerimizden görüşler..
Bültene hoş geldin 👋
Bu sayıda uzun soluklu bir yazı dizisine başladık: Yeni bir özellik geliştirmek. Bu konuyu farklı sektörlerden, farklı iş modellerinden ürün ekipleri yeni bir özellik geliştirirken hangi süreçlerden geçiyor, mevcut süreçlerini nasıl iyileştirebilirler, örnek uygulamalar neler gibi konulara değinebilmek için seçtik.
Her bir organizasyonun hatta ekibin yeni bir özellik geliştirmede izlediği adımlar farklı olabiliyor, biz de o yüzden genelde kabul görmüş ortak adımlar üzerinden gidip, bu adımlarda uygulanan pratiklerin ya da işleyişlerin farklarını görmeyi amaçlıyoruz. Bu genelleme üzerinden her bir sayıda bahsedeceğimiz adımları şöyle belirledik: keşif, planlama, koordinasyon, canlıya alma, canlı sonrası. Her bir adımda topluluk üyelerimize de danışıp, mini röportajlarla değişik bakış açılarına yer vereceğiz 🥁
Bu sayının konusu olan “Keşif”te üzerinde duracağımız konular araştırma ve fikirleştirme olacak; yani bir problem üzerine çalışmaya karar verilen noktadan, çözüm olarak geliştirilecek özelliğin kapsamına karar verilen noktaya kadar yapılanların üzerinde duracağız. Oldukça geniş ve çok yönlü bir adım olduğundan, konunun özünde kalmaya çalışarak bu sayıyı tamamlamaya gayret ettik. Umarız bu seri kenarından köşesinden fikirler verir ve ilham olur!
İyi internetler,
Burcu
Hatırlatma: Üretim Bandı Slack! 🎉
Slack’te her geçen gün daha aktifiz: Podcast bölümlerini ilk elden Slack’ten duyuruyoruz, üyelerimiz de ilk elden iş ilanlarını buradan paylaşıyor. Üyelere özel webinarlara da başladık! Ürün geliştirmeyle alakalı birçok konuda sorular sorup cevaplar alabildiğimiz bir platform olma yolundayız, soruların veya bildiğin konularda topluluğa katkı sağlayabilecek cevapların için bekliyoruz:
Yeni Özellik Geliştirmek-1: Keşif
Keşif: Nedir? Neden önemli?
Keşif süreci: İhtiyacı anlamak ve kapsamı belirlemek
Faydalı Kaynaklar
1. Keşif: Nedir? Neden önemli?
Ürün geliştirme terminolojisinde keşif (discovery) kavramı, kullanıcı ihtiyaçlarını anlamak ve geliştirilecek ürünü ya da özelliği bu ihtiyaçlara cevap verecek şekilde kurgulamak anlamında kullanılıyor.
Daha geniş bir tanımda, keşif adımı aslında son durumda ne yapılacağına karar verirken şu parametreleri göz önünde bulundurmaya yarıyor:
ürün stratejisine göre hareket ederek, ekip üyelerinin beklentilerini karşılıyor muyuz? (vizyon)
kullanıcılar üreteceğimiz çözümü anlayıp, kullanabiliyor mu? kullanıcıların gerçekten umursadığı bir problemi mi çözüyoruz? (validasyon)
bu çözümü üretecek kaynağımız, yetkinliğimiz var mı? (uygulanabilirlik)
Bu sorulara cevap aramak da aslında çıktı (output) yerine sonuca (outcome) odaklanmaya yarıyor. Birçok organizasyonda bir özelliği geliştirmek ve kullanıcıya ulaştırmak, o özelliğin çözdüğü problemi derinlemesine anlamaktan daha anlamlı görülebiliyor; bu da aslında bir anlamda keşif süreçlerini hafife almak demek oluyor. Ekip üyelerinin gözlemleri ve deneyimleriyle edindiği içgörülerin keşif sürecinin bir parçası olması beklenen ve önerilen, ancak problemi anlamak ya da doğru çözüme yönlenmek için her zaman yeterli olmayabiliyor. Özellikle de geliştirilen özelliğin kapsamı kararlaştırılırken, kullanıcıların ortak ihtiyaçlarına hitap eden bir kabiliyetler listesine karar verebilmek için kullanıcıların da bir parçası olduğu keşif pratikleri yapmak elzem görülüyor. Bu konuyla alakalı fikir yürüttüğümüz geçmiş bir sayımıza da şuradan ulaşabilirsiniz: “Input > Output > Outcome”.
2. Keşif süreci: İhtiyacı anlamak ve kapsamı belirlemek
Keşif süreçleri iki ana kısımdan oluşuyor: araştırma ve fikirleştirme. Araştırmalar keşif sürecinin ilk kısmı ve genel olarak kullanıcı geri bildirimleri edinmek ve bu bilgilerle ihtiyacı anlamak ve doğrulamak üzerine oluyor. İhtiyaçları anladıktan sonra gelen ikinci kısım ise kapsamı belirlemek yani fikirleştirme. Bu kısımda da genel olarak ihtiyacı doğruladıktan sonra gelen olası çözüm önerilerini test etme ve farklı parametrelerle yoğurduktan sonra kapsamı netleştirme üzerine çalışılıyor.
Araştırma teknikleri
Kullanıcıların belirli bir probleme dair beklentilerini ve ihtiyaçlarını anlamak için uygulanabilecek birçok araştırma tekniği var: Anketler, A/B testler, yüz yüze ve bire bir görüşmeler, focus grupları, veri anlamlandırma ve analitiği, market analizi, gibi gibi. Bu tekniklere, ne zaman hangi tekniğin uygulanabileceğine ve nelere dikkat edilebileceğine önceki sayılarımızda yer vermiştik, daha detaylı bilgi için inceleyebilirsiniz: “Nitel (qualitative) kullanıcı araştırmaları” ve “Nicel (quantitative) kullanıcı araştırmaları”.
Bu araştırma tekniklerinin kullanımı üzerine topluluk üyelerimizin fikirlerini aldık:
Can Ülker (Product Manager) - Booking.com:
Ürün geliştirmeyi bitmek tükenmek bilmeyen bir araştırma ve çıktı yaratma süreci olarak görüyorum ve bu doğrultuda ürün geliştirme sürecindeki ihtiyaca göre yukarıda örneklediğin bütün teknikleri yeri geldiğinde kullanıyorum. Burada altı çizilmesi gereken nokta ürün geliştirme sürecinde bulunduğun nokta aslına bakarsan. Örnek olarak tamamen yeni bir iş alanına ve değer önerisine giriyorsan market ve rekabet analizi çok alakalı iken mevcut bir ürünün iterasyonunda zaman kaybı olabilir. Dolayısıyla araştırma teknikleri kadar, hatta belki daha da fazla, araştırmadan çıktı beklentisine (research outcome) odaklanılması gerektiğini düşünüyorum.
İrem Çilingir (Product Manager) - Segmentify:
B2B SaaS platformu olarak Segmentify’da müşterilerimiz ile birebir görüşmelere çok değer veriyoruz. Bu noktada en çok kullandığımız ve öncelik verdiğimiz araştırma tekniği diyebilirim. Bu görüşmeler özellikle hizmet verdiğimiz müşterilerin problemlerini ve ihtiyaçlarını yakından dinlememizde, en değerli küçük problemi bulmamızda ve bu problemi çözecek en değerli küçük ürünü oluşturmamızda yol gösterici oluyor. Bunun yanı sıra hizmet verdiğimiz e-ticaret sektörünün dinamik ve değişken bir yapıya sahip olması nedeniyle değerli kuruluşların paylaştığı pazar analiz raporlarını ekip olarak düzenli bir şekilde takip ediyoruz. Çok yakın zamanda Mixpanel’i özellikle ürünlerimizin kullanımı noktasında quantitative verilere dayandırarak varsayımlarımızın sonuçlarını değerlendirmede değerli bir kaynak olarak kullanmaya başladık. İç ekiplerimizi (Account Management, Customer Success, Satış) yakından ilgilendiren araştırmalar için de sıkça anketler paylaşıp geri bildirimleri toplamaya çalışıyoruz.
Melih Özbekoğlu (Principal Product Manager) - letgo:
Şu anda aslında bu saydığın tekniklerin hepsini kullanıyoruz. Özellikle büyük geliştirmeler gerektiren stratejik işlerde araştırma ekibi ve birlikte çalıştığı iş ortaklarının koordinasyonuyla anket, focus group, 1-1 görüşmeler sonucu detaylı bir rapor oluşturuluyor. Bunu bir de strateji ekibinden ya da farklı kaynaklardan aldığımız market dokümanları ile birleştiriyoruz. Aynı zamanda kendi verilerimiz üzerinden bir analiz çalışması ile de destekliyoruz bunları.
Bunun dışında ürün ekibi olarak development öncesi hipotezlerimizi doğrulamak için prototip testleri ya da smoke test gibi yöntemlerden faydalanıyoruz.
En nihayetinde de mutlaka A/B testi uyguluyoruz. A/B testleri bizim ürün geliştirme kültürümüzün çok önemli bir parçası. Sadece yeni özellikler için değil, neredeyse her değişiklikte A/B testi uyguluyoruz. letgo'da A/B testi yapılmadan bir özellik çıkmaz diyebilirim.
Ecem Keskin (Director of Product Design) - Jotform:
JotForm'da ürün geliştirme süreci kabaca ikiye ayrılıyor ve aslında izlediğimiz araştırma süreci de ona göre şekilleniyor.
1. Varolan kullanıcı etkileşimini/aktifliğini ve bağlılığını arttırmak: Kullanıcılarımızın ürüne olan bağlılığını arttırmak, onların iş akışlarına doğrudan kolaylık sağlamak için izlediğimiz süreç.Bu süreçte kullanıcı yorumlarını günlük olarak takip ediyoruz. Bu sayede bir sonraki adımımızı genellikle önceden tespit etmemizi sağlıyor.
Kullanıcılarımızın farklı ürünlerimizden bizlere ulaştırdığı yorumlarını analiz etmekle başlıyoruz ve bu yorumları bir kaç gruba bölüyoruz: Improvement Suggesstions, Feature Requests, Bugs, Nice to do's, gibi. Bu kategoriler içinde oluşan grupları yorumluyor ve daha derin bir analiz yapmak için doğru soruları sormaya çalışıyoruz. Sorularımızı belirledikten sonra yorum/istek yapmış olan kullanıcı gruplarımızdan bir segment belirliyoruz (ürünümüzdeki aktiflikleri, kullandıkları özellikler ışığında) ve bir kaç farklı grup oluşturmuş oluyoruz. Sonraısnda bu grupları User Research takımımıza iletip görüşme sürecini başlatıyoruz.
Görüşmeler küçük bir kullanıcı grubu ile yapıldığı için A/B testler bizim vazgeçilmezimiz. Çözümlerimizi A/B testleriyle değerlendiriyoruz ve kullanıcılarımızdan gelen isteklerle bizim sunduğumuz çözümlerin belirlediğimiz başarı metrikleri üzerindeki etkilerini gözlemliyoruz.
Bu noktada Data ekibimiz toplanan verinin anlamlandırılması konusunda takımları destekliyor ve testin kapatılması gereken vakti, doğruluk payı gibi daha bir çok farklı bilgi ve önerilerini takımlarla paylaşıyor.
2. Yeni kullanıcı kazanmak ve farklı pazarlarda büyümek, bunu yaparken varolan kullanıcımızın akışlarını da kolaylaştırmak.
Market analizi yine bizim için hiç durmayan bir süreç, ama potansiyel bir hedef belirlediğimiz zaman market/rakip analizlerine de özellikle odaklanıyoruz.
Kullanıcılarımızın aktif olarak JotForm dışında kullandığı ürünler gibi noktalarda yine varsa veri ve kullanıcı görüşmeleri gibi yardımcı gereçlere de başvurarak belirliyoruz.
Özetlemek gerekirse her ürünün ya da stratejinin kendine göre farklı süreçleri oluyor, bu sebeple duruma göre ilerleyeceğimiz yöntemler üzerinde kendi kombinasyonumuzu ve sıralamamızı yapıyoruz. Bana göre test yöntemlerinin da her zaman test edilmesi gerekiyor.
Kullanıcılarla etkileşime geçmek
Araştırma tekniklerinden biri olan kullanıcı görüşmelerini diğerlerinden biraz daha ayrı tutmak istedik, çünkü problemi derinlemesine anlamak için kişisel görüşüm bu görüşmelerin en etkili yöntem olduğu yönünde. Kullanıcılarla hangi durumlarda ve hangi adımlarda etkileşime geçtiklerini, ve kimlerle görüşeceklerine nasıl karar verdiklerini topluluk üyelerimize sorduk:
Ecem Keskin:
Görüşme süreçlerinde oluşturmuş olduğumuz sorular ışığında kullanıcılarımızdan onların pain pointlerini ve düzeltme önerilerini alıyoruz. Varsa iş süreçleri için kullandıkları 3rd party ürünleri öğreniyor ve JotForm'u complete bir çözüm yapmak için değerlendirmeler yapıyoruz. Bütün bu bilgiler ışığında artık kullanıcıların önündeki engelleri kaldırma ve çözümler üretme vakti gelmiş oluyor ve farklı çözüm önerileri ve iterasyonlar yapıyoruz.
Can Ülker:
A/B test süreci Booking için biraz ayrı olduğundan onu ayırmam gerekli, ama diğer kalitatif ve kantitatif yöntemleri ortalama en az çeyrekte bir kere kullanarak kullanıcılarla etkileşime geçiyorum. Bu konuda özellikle ROI (return on investment) çoğunlukla gözden kaçan çok önemli bir etmen. Özellikle ciddi zaman ve kaynak yatırımı yapma potansiyeli olduğunu öngördüğüm durumlarda problem tespiti ve problemi iyi anlama, konsept geliştirme ve erken dönem validasyona ciddi zaman ayırıyorum. Ürünü canlıya çıktıktan sonra erken dönem araştırma sürecinde kurduğumuz ana hipotezlerin ne kadar doğru çıktığını veriye bakarak ve AB testlerle bir kez daha valide ediyoruz. Çoğunlukla bu süreçte bu sefer çalışan ürün üzerinden ya da çalışan ürünün ufak iterasyonlu prototipi üzerinden kullanıcı testleri gerçekleştiriyoruz ve roadmap sürekli olarak bu verilerden besleniyor.
Araştırma senaryosu geliştirme sürecinde user researcherlar ana sorumluluğu alıyor, buna uygun kullanıcı seçme (screening) süreçleri dahil. Burada daha ziyade onlardan gelen soruları cevaplıyorum ve doğru kullanıcılarla görüştüğümüzden emin olmaya çalışıyorum.
İrem Çilingir:
Müşterilerimizden geribildirimleri toplama, ihtiyaçlarını anlama noktasında Account Management ve Satış ekibimiz çok büyük bir rol oynuyor. Tüm istekleri Jira üzerinde “Requests” adlı projemizde toplayıp önceliklendiriyor veya ihtiyacı, problemi daha net anlamak adına detaylandırıyoruz. Fakat bizler sadece bu feedbackler üzerinden değil müşteriler ile birebir görüşerek de ihtiyaçları veya problemleri müşterilerimizin bakış açısıyla dinlemeye çalışıyoruz. Product ekibimizdeki Product Manager ve Product Ownerlarımızın haftada en az iki müşteri toplantısına girme hedefi mevcut. Müşterilerimiz ile ürün geliştirme sürecinin her aşamasında görüşüyoruz. Özellikle roadmap planlama noktasında müşterilerimizin problemlerini daha iyi anlamak adına analiz öncesinde, bulduğumuz çözümün müşterinin problemini doğru bir şekilde çözüp çözmediğini ve anlaşılır, kullanılabilir olduğunu netleştirmek adına analiz esnasında ve çözümün iterasyonu noktasında çözüm geliştirildikten sonra sık sık müşterilerimizle görüşmeye, geri bildirimlerini almaya çalışıyoruz. Müşterimize sunduğumuz hizmet nedeniyle sadece e-ticaret siteleri değil, müşterilerimiz ile ilerlettiğimiz süreçlerin aynısını iç ekiplerimizle de ilerletmeye çalışıyoruz. Görüşeceğimiz müşterileri iki farklı şekilde ve temel amaca hizmet edecek şekilde belirliyoruz diyebilirim. Görüşmeler yeni kabiliyetler içinse Account Management veya Satış ekibimiz aracılığıyla ihtiyacını daha önceden görüşmelerde belirtmiş kullanıcıları seçmeye çalışıyoruz. Amacımız ürün kullanımını artırmak ve deneyimi iyileştirmeksa somut veriye dayalı şekilde ürünümüzü pasif bir şekilde kullanan veya çok aktif kullanan müşterilerimizi tercih ediyoruz.
Melih Özbekoğlu:
Kullanıcılarımızla farklı ülkelerde olduğumuz için birebir temas etme imkanımız pek fazla olmuyor. Ancak elbette farklı farklı geri bildirim alma yöntemleri kullanıyoruz. Öncelikle şunu söyleyebilirim: letgo daha çok nicel veri odaklı bir şirket (ve bunun da çok faydasını gördük) ve kullanıcı geri bildirimlerini kesin sonuçlara varmak yerine daha çok soru sormak için kullanıyoruz. Bir geri bildirim üzerine veriye detaylıca girip o zamana kadar farkına varılmamış bir problemi ortaya çıkarabiliyoruz.
Sorunları tespit etme, problemi anlama aşamasında 1-1 görüşmeler, kullanılabilirlik testleri sıklıkla başvurduğumuz yöntemler. Bunun dışında varsayımları test etmek adına prototip testleri, smoke test ve A/B testlerine başvuruyoruz genelde.
Görüşeceğimiz kullanıcıları belirlemek adına çok detaylı kriterlerimiz yok. Milyonlarca kullanıcının kullandığı bir ürün olduğu için çok farklı profillerden önemli geri bildirimler alabiliyoruz. Üzerinde çalıştığımız özelliğe ya da projeye göre bazen belirli profiller gerekebiliyor.
Koordinasyon
İhtiyacı anlamak üzerine araştırmalar ve analizler yaparken, diğer fonksiyonlarla koordine hareket etmek büyük yarar sağlıyor. Bazı organizasyonlarda kullanıcı araştırmaları üzerine kurulmuş spesifik ekipler bulunuyor ve ürün yöneticileri bu ekiplerle çalışıyor; bazılarında da bu sorumluluğu ürün yöneticileri üstleniyor ve kullanıcılarla doğrudan iletişimi olan Müşteri Deneyimi ya da benzeri ekiplerle ortaklaşarak süreci yönetiyor. Her iki durumda da ürün yöneticileri sürecin önemli bir parçası oluyor.
Topluluk üyelerimize bu süreçlerde diğer ekiplerle nasıl koordine olduklarını ve araştırma sonuçlarını nasıl paylaştıklarını sorduk:
Melih Özbekoğlu:
Diğer ekiplerin sürece etkisi oluyor mutlaka. Sadece satış, pazarlama gibi ekipler değil aynı zamanda CRM, mühendislik, data ekipleri de burada önemli stakeholder'lar oluyor. Genellikle problem tanımı yapıldığında çözümler için brainstorming'den başlıyoruz birlikte çalışmaya. Herkesin tasarımında yer aldığı bir ürün/özellik herkes tarafından daha çabuk sahipleniliyor ve benimseniyor.
Çoğunlukla araştırma sonuçları tüm şirketle paylaşıyoruz. Şeffaflık çok önemli bizim için. Bütün şirkete açık olan read out oturumları yapıyoruz ya da bir rapor varsa onu paylaşıyoruz. Ayrıca A/B testi sonuçları bütün şirket ile bir email üzerinden paylaşılır ve herkesin bilgilenmesi sağlanır.
İrem Çilingir:
Segmentify’da hizmet verdiğimiz müşterilere yarattığımız en büyük değerlerden biri Customer Success ekibimiz ile müşterilerimize verdiğimiz destek. POC sürecinden itibaren müşterimiz ile Account Managerımız çok yakın bir iletişim sürdürüyor. Bu noktada düzenlediğimiz birebir görüşmeleri çoğunlukla Account Managerımızın eşliğinde gerçekleştiriyoruz. Account Management ekibimiz genellikle toplantı ayarlama ve müşteri ile bizi bir araya getirme noktasında bir köprü işlevi görüyor.
Ecem Keskin:
Cross-functional takımlar olarak çalışıyoruz ve takımlarımızın içinde o takımın üzerinde çalıştığı geliştirmelere özel araştırmalar yapan bir User Researcher oluyor. Aynı zamanda büyük resme odaklı User Research ekibimizde var.
Takımdaki User Research ve Designer dirsek temasında çalıyor. Takım içinde kullanıcıların savunuculuğunu yapan birinin olması her toplantıda hem designer hem developer olmak üzere herkesi tek bir paydada buluşturuyor. Günlük bazda ürün üzerindeki experience problemleri kullanıcıların takıldıkları yerleri tartışıyor ve hızlı iterasyonlarla hem araştırmaları hem tasarımları yeniliyorlar.
Can Ülker:
Yerine göre ekipteki her bir kişi bir şekilde dahil oluyor ama genellikle mutlaka kullanıcı deneyimi ekipleri (UX Design, UX Copywriter, UX Researcher) masada bulunuyor. Burada araştırma sürecine özel ekipler var, örneğin UX ve Market Research ekipleri merkezi ekipler ve ürün ve pazarlama ekiplerine yakın çalışıyorlar. Ben Ürün Yöneticisi olarak genellikle bu ekiplerden talep eden konumundayım ama execution sürecinde hands on dahil oluyorum ve araştırma süreçlerinde onlarla birlikte çalışıyorum. Yani araştırma ekipleri sürece liderlik ederken ürün geliştiren ekibin ürün yöneticisi de tasarımcısı da yazılımcısı da hands on dahil oluyor.
Araştırma sonuçları genelde sunum formatında şirketin FB vari iletişim portalında paylaşılıyor. Özellikle birincil düzeyde etkilenebilecek diğer ekiplerin ürün yöneticileri ile ben direkt olarak da paylaşıyorum.
Kapsamı belirlemek
Araştırma süreçleri bittikten sonra aslında kapsam az çok ortaya çıkmış oluyor. Bu sonuç üzerine karar alma süreçlerini nasıl yönettiklerini topluluk üyelerimize sorduk:
İrem Çilingir:
Analiz sonrası müşterinin ihtiyaçlarını ve şirketin genel stratejisini en önde tutarak, yazılım geliştiricilerimiz ile görüşerek müşterinin problemlerini çözebileceğimiz en yalın ve en değerli kapsama karar kılıyoruz. Bu sürece hem teknik ekibimiz hem de iç ekiplerimiz çok yakından dahil olarak katkıda bulunmaya çalışıyorlar. Olabildiğince feedback alabilmek için ekipler ile toplantılar düzenleyerek görüşlerini öğreniyoruz.
Can Ülker:
Özellik kapsamını belirleme sürecinde araştırma diğer pek çok başka şey gibi bir girdi, araştırmadan kesinlikle ürün ekibinin işi olan karar alımını yapmasını beklemiyorum. Araştırma çıktılarından ürün kapsamına giden süreçte aslında kendi ekibim başta olmak üzere alakalı partilerle yürüttüğüm fikir alışverişine dayalı, karar almayı hedefleyen iteratif bir yaklaşım var. Buna araştırma ana çıktıları üzerinden yaptığımız brainstorming çalışmalarından ekiple gerçekleştirdiğimiz grooming çalışmalarına, üst yönetimden gelen geri bildirimden diğer ekiplerden gelen girdilere kadar pek çok farklı şey dahil. En sonunda bu yine bir ROI oyununa dönüyor; kısaca ne kadar zaman ve emek harcayarak ne çıktı yaratmak istiyorsun? Ve de tabii ki scope mevzusu; bu çıktıyı yaratmak için doğru konumlanmış mısın, ihtiyacın olan şeylere sahip misin? Ana karar alımı kriterlerim sanırım bu şekilde.
Melih Özbekoğlu:
Lean product development felsefesini uygulamaya çalışıyoruz böyle durumlara. Büyük projeler yerine MVP mantalitesinde hızlı şekilde ürün geliştirip kullanıcılardan veriyi toplayıp sonra bu verilerle optimize ederek, değişiklikler yaparak ilerleme alışkanlığımız var şirket olarak. Burada MVP içeriğini belirlemek önemli bir problem tabi. Bunun için de kullanıcı araştırmaları ve veri analizi ortaya çıkan ana pain point'e odaklanmaya çalışıyoruz. Farklı birimleri etkileyen bir üründen söz edersek de o ekiplerle bu verileri tartışıp MVP tanımında el sıkışarak ilerliyoruz.
4. Faydalı kaynaklar
The Evolution of Modern Product Discovery - Link - Ürün keşif koçu Teresa Torres’ten, keşif süreçlerinin tarihi gelişimine dair bir konuşma ve konuşma metni.
Product Discovery - Link - Marty Cagan’ın konunun özüne dair fikirlerini aktardığı bir blog.
Product Discovery: A Practical Guide for Agile Teams - Link - Tim Herbig’den keşif süreçleri üzerine kapsamlı bir yol haritası ve model.
A step-by-step guide for conducting better product discovery - Link - productboard’dan problem ve çözüm alanları üzerine çalışırken uyguladıkları “Double Diamond Approach” üzerine bir blog.
Continuous user research in 11.6 seconds - Link - Kullanıcı araştırmalarının özellik bazında olmadan, devamlı yapılmasının gerekliliği ve faydaları üzerine bir blog.
Üretim Bandı Podcast 🎙
Dilara Neutze ile Tasarım, Organizasyon ve Ürün - Buradan dinleyin
Burak Akgün ile Büyük Veri Mühendisliği - Buradan dinleyin
Önceki Sayılar 📚
Bülten #23: Ürün yönetiminde içgörüler (insights)
Bülten #22: Ürün/Özellik Durum Takibi
Bülten #21: Ürün Gereksinimleri Dökümanı (Product Requirements Document, PRD)
İş İlanları
Tüm aktif ilanları görmek, ilk elden ilanı paylaşan üyelerimize ulaşmak ya da yeni bir ilan paylaşmak için Slack grubumuza katılın!
Bu sayılık bu kadar!
Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz: