Ürün Yaşam Döngüsü: Bir Ürün Özelliğinin Yolculuğu

Bu, bir ürün adayının Ürün Yönetimi dünyasına girmesine yardımcı olmak amacıyla yazdığım beş bölümlük bir dizinin dördüncü yazısı.

Son yazımda , Ürün Yönetimi adaylarının bir şirket içindeki veya genel olarak kariyer yörüngelerini anlamalarına yardımcı olmak amacıyla Ürün Yönetimi disiplinini dört bölüme ayırdım. Bu yazıda, bir Ürün Yönetimi adayının bir Ürün Yöneticisi rolünün neleri kapsadığı konusunda 360 derecelik bir bakış açısı kazanmasına yardımcı olmak için, bir ürün özelliğinin fikir aşamasından terk edilmeye kadar olan yaşam yolculuğundan bahsedeceğim.

T – 30 gün

Gerekliliğin icadın anası olduğu söylenir. Bir ürün özelliğinin doğuşunun söz konusu olduğu durum tam anlamıyla budur. Her şey bir miktar rahatsızlıkla başlar.
Şirketteki bazı çalışanlar günlük görevlerinden birini yerine getirirken rahatsızlık duyuyor - belki kullanıcı tabanı arttı ve eski süreçlerle yönetemiyor. Şirketteki bazı yöneticiler bir excel sayfasına bakar ve örneğin çok sayıda ürün iptali nedeniyle şirketin çok fazla para kaybettiğini düşünür. Ya da belki bir rakip, müşterilerin söz konusu şirketin ürününden ayrılmalarına neden olan bir ürün özelliği başlattı. Pazarlama dönüşüm hunisine bakan biri, belirli bir aşamada yüksek düşüşler fark etti ve bu optimizasyonun üç aylık hedefine ulaşmasına yardımcı olabileceğini hissetti. Veya ortak bir sorun için çok sayıda müşteri şikayetinden, geçen hafta ankete katılan kullanıcıların çoğunluğu tarafından yeni bir özelliğin talep edilmesine kadar 100 farklı neden olabilir. Mesele şu ki – her şey bir miktar rahatsızlıkla başlar.

Şimdi bu rahatsızlık Ürün Müdürünün dikkatine sunulur; ya da belki Ürün Müdürü bunu ilk fark edendir. Bu, yeni bir özelliğin doğuşuna yol açabilecek bir olaylar zincirini başlatan noktadır.

T – 25 gün

Ürün Yöneticisinin sorun bildirimi üzerinde düşünmesinin zamanı geldi. Gidiyor ve rahatsızlığı bildiren müşterilerle veya iç paydaşlarla ve ardından bunu gerçekten yaşayanlarla konuşuyor; hepsi tek bir amaç için – 'kök' sorun ifadesini belirlediğinden emin olmak. Bu aşama hafife alınırsa veya Ürün Müdürü buna yeterince zaman ayırmazsa, ortaya çıkan ürün özellikleri kırılgan, çarpık ve oldukça hızlı bir şekilde sona erer.
Ürün Müdürü, temel sorun ifadesini belirledikten sonra, bunun çözülmeye değer olup olmadığına karar verir. Rahatsızlık gerçekten büyük mü yoksa biraz abartılı mı yoksa daha mı kötü, sadece uydurulmuş mu? Bunu çözmek gerçekten müşteriye ve/veya şirkete önemli bir değer katar mı? Çözülmesi müşteriye ve/veya şirkete ciddi bir ceza getirmez mi? Bu sorunu, süreçlerde küçük bir ince ayar yaparak veya ürün değişikliği gerektirmeyen herhangi bir etkinlikle çözmenin bir yolu var mı? fazladan bir çalışan, içerikte, grafiklerde, harekete geçirici mesaj düğmesinde vb. değişiklikler?

Temel olarak, ürün değişiklikleri içermeyen bir yöntemden benzer katma değer elde etmemizin bir yolu varsa, o zaman üründeki herhangi bir şeyi değiştirmek yerine buna gideriz – bu, ekleme veya çıkarma anlamına gelir. Ürün Müdürü, sorun ifadesini çözmenin önemli bir değer sağlayacağına ve ürün düzeyinde bir değişikliğin (zaman, para ve çaba v/s değeri dikkate alındığında) ürün düzeyinde olmayan bir değişiklikten çok daha fazla yatırım getirisi sağlayacağına ikna olduğunda, yeni bir ürün özelliği ekilmiştir.

T – 15 gün

Ürün Müdürünün önceden bir deneyimi varsa, bu deneyime dayalı olarak bir çözüm önerebilir. Ancak, bu her durumda en iyi çözüm olmayabilir.
Sorun ifadesi son derece teknik bir çözüm gerektiriyorsa, Ürün Müdürü aynı şeyi geliştiriciler ve mühendislik yöneticileriyle tartışır ve bu konuda en iyi yol hakkında tavsiyelerini alır. Çözüm, tasarım düzeyinde değişiklikler gerektiriyorsa, UX liderine danışılabilir. Ürün Yöneticisi ve UX çalışanı bir tasarım sprinti düzenleyebilir ve bu özelliğin gerçek kullanıcıları tarafından iyi karşılanan çözümü seçebilir. Bazen sorun tamamen işle ilgilidir ve bu nedenle üst yönetimin katılımını gerektirir.
Dolayısıyla, bir çözümün kesinleştirilmesinin birden fazla yolu olabilir. Ancak bir kez gerçekleştiğinde, bu teorik çözümü aktif bir ürün özelliğine dönüştürmekten Ürün Müdürü sorumludur.

T = 0 (ürün özelliğinin doğuşu olarak da bilinir)

Belirli bir çözüm belirlendiğinde, Ürün Yöneticisi ilgili ekiple işbirliği içinde çözümün temel bir taslağını çıkarır. Çözümün bir prototipini içerebilir veya içermeyebilir. Bazen, belirli bir CTA'nın bir kullanıcıya ne zaman gösterileceğini vb.
Ürün Müdürü, çözümü ilgili PRD'de (Ürün Gereksinimleri Belgesi) kelimelere döker. Özellik küçükse, daha büyük bir özellik için mevcut bir PRD'deki bir paragraf olabilir. Bazen özellik o kadar büyüktür ki, sadece doğru şekilde detaylandırmak için eksiksiz bir PRD gerektirir. PRD, ilgili ekipler tarafından yürütülür ve Ürün Müdürü, özellikle ilgili geniş bir fikir birliğinin var olduğundan emin olur.

T + 15 gün

Küçük özelliklerin dondurulması bir günden az sürebilir. Büyük özellikler, bazen herkesin ilerlemesini sağlamak için 30 günden fazla zaman alır.
Yenidoğan özelliğinin geliştiricilere tanıtıldığı zamanın bu olduğunu söylemek için ortalama 15 gün sürelim. Proje üzerinde çalışan geliştiricilerin 5W'ler (Ne, Neden, Ne Zaman, Nerede, Kim) ve test senaryoları (özellik yayınlandıktan sonra nasıl davranması veya davranmaması gerektiği) hakkında bilgilendirildiği uygun bir tasarım ve PRD devri gerçekleşir. .
Mühendislik yöneticisi ile birlikte, geliştirmenin ne zaman sona ereceği, testin ne zaman başlayacağı, bildirilen hataların ne zaman düzeltileceği ve nihai yayın tarihi ile ilgili son tarihler ile özellik için uygun bir yayın planına karar verilir. Ardından tüm zaman çizelgesi ölçülebilir sprintlere bölünür (genellikle 15 gün sürer). Geliştiriciler tatmin olduktan sonra geliştirme başlar.

T + 30 gün

Sprint 1 biter. Ürün özelliğinin bir kısmı kullanıma sunuldu. Henüz müşteriye dönük olmayabilir, ancak çoğu ekip yazılım geliştirme için bugün Agile metodolojilerini takip ediyor - bu, aşamalı ve yinelemeli olarak inşa ettiğimiz anlamına geliyor. Bu nedenle, 6 ayda büyük bir özellik oluşturup hepsini bir kerede yayınlamak yerine, her şeyi kendi başlarına çalışabilen (bir grup Kullanıcı Hikayesi) ve hızla gözden geçirilmeye ve yinelenmeye hazır olan bağımsız parçalara bölüyoruz.
Ürün Yöneticisi, proje üzerinde çalışan ilgili mühendislik yöneticisi ile günlük scrum toplantıları ve tartışmalar yoluyla sürüm zaman çizelgesinin yolunda olduğundan emin olur. Bir gecikme olması durumunda, zaman çizelgeleri buna göre ayarlanır veya sürümün zamanında olduğundan emin olmak için özelliklerin küçük parçaları çıkarılır. Her sprintten sonra, kaydedilen ilerleme bir toplantıda Ürün Müdürü ve ilgili paydaşlara sunulur ve onay sonrası yayınlanır.
UpGrad'ın Ürün Yönetimi Programında Bir Yıl

T + x gün

'N' sayıda sprintten sonra geliştirme tamamlanır ve tüm özellik sona erer. Müşterilerin özelliği yalnızca tamamen yayınlandığında kullanması gerekli değildir. Sprint 1'in sonundaki sürümden bu yana kullanıyor olabilirler. Her bir sonraki sprint döngüsü sürümü, özelliği yalnızca daha sağlam hale getirir ve olması amaçlanan şeye daha da yakınlaştırır.
Bir özelliği başlatmanın kendisi bir sanattır ve atlayacağımız birçok adımı içerir ve sadece birçok davul ve göğüs gümbürtüsünden sonra dünyaya bir özelliğin yayınlandığının ilan edildiğini varsayarız. Bu, CEO'nun kendisinin yeni lansman hakkında konuştuğu tam kapsamlı bir Basın Bülteni kadar karmaşık olabilir veya yalnızca, özelliği kullanacak ve muhtemelen bunu talep eden belirli bir departmana bir postanın gönderildiği bir şey olabilir. ilk yer. Şimdi özellik orada olduğuna göre, bu özelliğe bir isim verelim – Bay Özellik.

T + y gün

Son sürümden sonra bile, bazen işler ters gider. Bir zamanlar parlak ve değerli olan Bay Özellik artık eskisi gibi olmayabilir ve bunun birçok nedeni olabilir. Bir ürünün döngüsündeki bu aşama, ürünü desteklemekle ilgilidir. Güzel bir gün, Mr. Feature'ın istenmeyen şekillerde çalışmasına (yani buggy haline gelmesine) neden olan başka bir sürüm yapıldı veya belki Mr. Feature'a bazı bağımlılıkları olan başka bir özellik kaldırıldı ve bu, buggy davranışına neden oldu. Ayrıca, özellik yapıldığında, onu kullanacak olan kullanıcı sayısını hafife almış olabiliriz veya tüm kullanım durumlarını planlamamış olabiliriz ve şimdi özelliğin bu kadar çok sayıda kullanıcıya veya kullanım senaryosuna ölçeklenememektedir.

Bu, ya test ekibi tarafından periyodik incelemelerinde rapor edilir ya da özelliği kullanırken keşfeden bazı ekip üyeleri tarafından rapor edilir. Müşteriye dönük özellikler olması durumunda, bu şikayetler ürünün gerçek müşterilerinden gelebilir ve Müşteri Deneyimi ekibi aracılığıyla Ürün Müdürü'ne iletilebilir.

Ürün Yöneticisi, hatanın temel nedenini anlamaya çalışır ve önceliğe göre düzeltmeyi bir sonraki sürüm döngüsü için planlar - yüksek öncelikliyse veya sonraki sprintlerde mevcut sprint'e eklenebilir. Hata giderilip serbest bırakıldıktan sonra, Bay Özellik, Ürün Yöneticisi ve mühendislik ekibi sayesinde yeniden düzenlenmiş bir biçimde de olsa - Bay Özellik 2.0 - başka bir gün görmek için yaşıyor. Tebrikler!

T + z günleri

Her güzel şeyin bir sonu olması gerektiği söylenir. Ne yazık ki Mr. Feature için de durum böyle, versiyonu ne olursa olsun – belki Mr. Feature 9.263.75! Bu, Bay Özel'in uzun ve mutlu bir hayat yaşadığı anlamına geliyor, ama artık yolun sonu burada.
Çeşitli sebeplerden dolayı olabilir. Bay Özellik ihtiyacını tamamen gereksiz kılan yeni bir özellik geldi. Aşırı bir şey de olabilir - şirketin, bu özelliğin kullanıcılarına değer katmasına rağmen, artık onlar için ekonomik bir anlam ifade etmediğine karar vermesi gibi.

Sebep ne olursa olsun, Bay Özellik'in hizmetlerine artık ihtiyaç duyulmayacağı Ürün Müdürü'ne (veya tartışmayı başlatan kişidir) iletilir. Şimdi, ne kadar yürek parçalayıcı olsa da, Ürün Müdürünün görevi Bay Özelliği rahat bırakmaktır. Bundan önce, Bay Özelliği kullanan kullanıcılara belirli bir tarihten sonra kullanılamayacağını bildirmek gibi birkaç şeyden emin olması gerekmesine rağmen, yeni özellik Bay Özelliği kaldırmadan önce iyi çalışıyor, başka hiçbir şey yok. Bay Özellik gittiğinde akış etkilenir vb.

O halde Mr. Feature'a RIP demenin zamanı geldi. Ürün yönetimi kariyerinizde bunu defalarca yapmanız gerekecek. Ama unutmayın, bir özelliğin sonu diğerinin başlangıcıdır ve döngü devam eder. Ürün yönetimi hayatı böyledir!

Dünyanın en iyi Üniversitelerinden çevrimiçi Ürün Yönetimi Kurslarını inceleyin . Kariyerinizi hızlandırmak için Master, Executive PGP veya Advanced Certificate Programları kazanın.

Sizin için Öne Çıkan Program: Duke CE'den Design Thinking Sertifikasyon Programı