Zephyrnet Logosu

Ürün Yönetimini B Serisinden IPO'ya Ölçeklendirme: Önce Müşteri Kuruluşunu Kurmak – OpenView

Tarih:

Editörün notu: Bu, ürün yönetimini B Serisinden halka arza ölçeklendirmeye ilişkin bir dizinin üçüncü bölümüdür. Birinci ve ikinci bölümleri okuyun okuyun ve okuyun.

Başarılı bir organizasyon - ürün ve diğer - müşteri odaklıdır. Bu odak kaybolduğunda, aşağıdaki gibi sorunların farkına varırsınız:

  • Tutarsız ürün deneyimleri
  • Düşük NPS
  • Düşen kullanıcı deneyimi ve
  • Yetersiz kullanıcı ve/veya müşteri tutma.

B Serisinden halka arza ölçeklendirme söz konusu olduğunda, müşteri odaklı olmak çoğu zaman doğru sorunların ve projelerin peşine düşmek gibi görünür. Bir şirket büyüdükçe ve riskler arttıkça hataya daha az yer olur. Ar-Ge zamanınızı nereye yatırdığınız önemlidir ve maksimum etkiye sahip yatırımları seçmek isteyeceksiniz. Müşteri öncelikli bir kuruluş oluşturmak, doğru seçimleri yapma şansınızı artırır.

SendGrid'de Ürün Yönetiminden Sorumlu Başkan Yardımcısı ve GitLab'da CPO olarak kendi deneyimlerimde, müşterilere ve kullanıcılara odaklanmanın hiper büyümenin baskısına dayanabilen bir ürünle nasıl sonuçlandığını ilk elden gördüm. Ve müşteri odaklılığın asıl anlamı şudur:

a) kimin için inşa ettiğinizi bilmek ve
b) sorunlarını etkili bir şekilde çözen şeyler inşa etmek.

Her ikisini de doğru yapmak için bir sorun ve çözüm doğrulama çerçevesi oluşturmanız, müşterilerle görüşmeniz, kuruluş şemanızı göndermekten kaçınmanız ve güvenle hayır demek için doğrulama bulgularını kullanmanız gerekir.

1. Bir sorun ve çözüm doğrulama çerçevesi oluşturun

Hem SendGrid'de hem de GitLab'da, neleri inşa edip neleri yapmadığımıza rehberlik eden net bir sorun ve çözüm doğrulama süreci oluşturduk. Ancak önerilen bir çözümün ciddi bir müşteri sorununu etkili bir şekilde çözeceğinden emin olduktan sonra geliştirme başlayabilir.

Bu güvene sahip değilsek, doğrulama sürecine devam etmemiz veya fikri rafa kaldırmamız gerekiyordu.

GitLab'da özellikle ürün geliştirme akışımızı iki yola ayırdık: doğrulama ve oluşturma. Bu iki yol birbirinden bağımsız hareket etse de, büyük bir proje veya özellik, doğrulamadan başarıyla geçene kadar derleme yoluna giremez. Göre GitLab el kitabı, doğrulama yolunun amacı:

  • Anlama çözmeye çalıştığımız kullanıcı sorunu
  • Belirlemek başarıyı belirlemek için iş hedefleri ve temel ölçütler
  • Oluşturmak hipotezler ve araştırma/deney/kullanıcı testi
  • Tanımlama Minimum Uygulanabilir Değişiklik (MVC) tasarım modeli ve gelecekteki olası yinelemeler
  • Azaltmak niteliksel ve niceliksel analiz ile değer, kullanılabilirlik, fizibilite ve iş uygulanabilirliği riskleri

Yeni, büyük veya iyi anlaşılmamış sorunlu alanlar için Proje Yöneticileri, sorunu derinlemesine anlamak için Kullanıcı Deneyimi Uzmanları ile birlikte çalışır. Bu aşama tipik olarak hedef kullanıcılarla en az beş problemli görüşme yapmaktan ve ardından projenin bir sayfalık bir özetini tek bir dosyada toplamaktan oluşur. Fırsat Kanvasıürün ve tasarım liderliği ile gözden geçirilmektedir. Onaylanan tuval incelemeleri, Çözüm Doğrulama aşamasına geçer.

Çözüm Doğrulamada tasarımcılar, soruna bir çözüm tasavvur etmek için gerçeğe uygun bir prototip oluşturarak liderliği ele alırlar. Ardından tasarımcılar ve Proje Yöneticileri, prototip tasarımının kullanıcının problemini yeterince çözdüğünü doğrulamak için hedef kullanıcılarla en az beş görüşme daha yapar. Oradan, proje Yapım Yoluna girer.

2. Müşteri görüşmelerine öncelik verin

SendGrid'deki ilk 18 ayımda ~100 müşteriyle tanıştım. GitLab'daki ilk iki çeyreğimde, ürün organizasyonunun OKR'lerinden biri olan "ÖM başına tamamlanan müşteri görüşmesi sayısı"nı yaptım. Bu bana ve ürün organizasyonuna müşterilerimizin kim olduğu ve ne istedikleri konusunda sağlam bir temel bilgi verdi. Bu araştırma, kuruluş düzeyindeki geliştirme önceliklerimizi bilgilendirdi, ekipler arasında değerli içgörüleri paylaşmamıza olanak sağladı ve güvenilirliğimizi artırdı.

Unutmayın; ne öğrenmeniz gerektiği konusunda bilinçli değilseniz veya nitel görüşme en iyi uygulamalarını takip etmiyorsanız, müşterilerle konuşmak için harcanan zaman boşa harcanabilir. Yüksek kaliteli görüşmeler yapmak temel bir Proje Yöneticisi becerisidir, bu nedenle SendGrid'de tüm ekip, Cooper Design tarafından verilen niteliksel bir görüşme eğitimine katıldı ve GitLab'da ekibin çoğu, adı verilen mükemmel bir uzaktan eğitim aldı. Sürekli Görüşme Teresa Torres'ten. Her ekip üyesi, değerli müşteri görüşmesi süresinden içgörü kalitesini en üst düzeye çıkarabildiğinden, tüm ekibi müşteri görüşmesi konusunda yetkin bir düzeye çıkarmak çok büyük faydalar sağladı.

Görüşme en iyi uygulama önerileri

Bu görüşmelere, her müşteriyle birlikte üzerinden geçilecek bir soru listesi oluşturarak hazırlandım. Bu tutarlılık, görüşülen kişiler arasındaki içgörüleri çapraz kontrol etmemi sağladı. Birden çok kişinin hepsi aynı şeyi gündeme getiriyorsa, bu onların duygularının çok daha geniş bir müşteri segmentinde paylaşılabileceğinin iyi bir göstergesidir.

Diğer en iyi uygulama önerileri şunları içerir:

  • Açık uçlu sorular sorun ve evet/hayır veya yönlendirici sorulardan kaçının
  • Onlardan gerçekte ne yaptıklarını açıklamalarını isteyin, yapmak istediklerinden ziyade
  • Sorunlu görüşmeler için, Çözümünüzü soruna sonuna kadar sunmaktan kaçının, hiç değilse
  • Çözüm görüşmeleri için, etkileşimli bir prototip getirin herhangi bir yönlendirme veya yönlendirme olmaksızın amaçlanan problemi prototipi kullanarak çözmelerini isteyin ve deneyimle ilgili hisleri ve tepkileri hakkında yüksek sesle konuşun.
  • Görüşülen kişilere olumsuz veya sert geri bildirimlerin uygun olduğu konusunda güvence verin ve sana hakaret etme konusunda endişelenme

Mülakat lojistiği ve planlamasındaki sürtüşmeleri ortadan kaldırma

Birçok Proje Yöneticisinin yeterince görüşme yapmamasının bir nedeni, müşteri görüşmelerini belirlemenin, kaynak sağlamanın, planlamanın ve yürütmenin lojistik açıdan zor olmasıdır. Ekip üyeleri için süreçteki sürtüşmeleri ortadan kaldırmak için bir ürün lideri olarak elinizden gelen her şeyi yapın. SendGrid ve GitLab'da, görüşme için müşteri bulma ve planlama konusunda yardımcı olan bir UX Koordinatörü tutmayı seçtik.

Yardım etmesi için özel bir kişiyi işe alamıyorsanız, süreci otomatikleştirmenin veya basitleştirmenin başka yollarını düşünün; örneğin, görüşme yapmak isteyen müşterilerin/olasılıkların bir veritabanını tutmak, müşterilerin doğrudan üründe görüşme yuvalarına kaydolmalarını sağlamak veya Ürün ekibi için Satış/Müşteri Başarısı sıralaması görüşmeleri yapmak.

3. Kuruluş şemanızı göndermeyin

Bir şirket tekrarlanabilir bir doğrulama sürecinden yoksun olduğunda, önemli olmayan şeyleri inşa etmek çok daha kolaydır. Sıklıkla gördüğüm bir şey, Proje Yöneticisi ekiplerinin kuruluş şemalarını göndermeye başlamasıdır. Müşterinin kullanım durum(lar)ını hesaba katmadan, sahip olduğunuz alan ne olursa olsun optimize edilmiş bir ürün oluşturduğunuzda bu böyle görünür.

CA Technologies'de ürün yönetiminin kıdemli direktörü olarak çalışırken, dört ürün alanının yakınsamasından oluşan yeni bir iş biriminin parçasıydım. Amacımız, müşterilerin bu iş biriminin neden var olduğunu anlamalarına yardımcı olmaktı ve gerçekten bu dört ürün grubu arasında sinerji yaratmak istedik. Tüm sorunlarımızı çözeceğini düşündüğümüz bir fikir geliştirdik.

Kağıt üzerinde harika görünüyordu. İş biriminin neden var olduğunu açıkça açıklıyor ve bir müşteri için ilginç olabilecek bir şey gibi görünüyordu. Ardından, hepsini bir araya getiren bir ürün özelliği tasarladık ve hemen onu oluşturmak için yola çıktık.

Entegrasyon, amaçladığımız gibi çapraz satış sağlamadı. Kimse kullanmadı. Çünkü kimse umursamadı. Dört ürünün birlikte nasıl çalışacağını asla sormadılar. Onlar için gerçek bir sorunu çözdü mü? Cevap hayırdı.

İç yapınıza değil, kullanım durumuna odaklanın

Her bir ürün yöneticiniz kendi ürün dilimine bakıyorsa, ekipler arasında dikişler görünmeye başlar. Bir Proje Yöneticisi veya tasarımcı olarak, sahip olduğunuz alandaki sonuçları yönlendirmeye teşvik edilirsiniz; bu, bir bütün olarak ürün genelinde daha geniş bir sonuç olması gerekmez. Bu, ürün bölümlerinde gerçekleştiğinde, kopuk hissettiren bir ürün deneyimi yaşarsınız.

GitLab'da temel özelliklerimizden biri birleştirme isteğiydi ve birden çok ekip buna katkıda bulunuyordu. Bir noktada, bu özelliğin performansının yavaşladığını ve karmaşık kullanıcı deneyiminden zarar gördüğünü fark ettik. Ekip sınırlarını göz ardı etmek ve kullanım senaryosuna odaklanmak için özel talimatlarla birleştirme isteği özelliğini denetleyen bir UX araştırma ekibimiz vardı.

Ekip, kullanıcı yolculuğundaki iyi ve kötü deneyimleri tam olarak belirleyen bir kullanıcı yolculuğu haritası oluşturdu. Ardından, kötü deneyim düzeltmelerini onlara sahip olan ekiplere sunabildik ve zaman içinde kullanım durumu düzeyine odaklanarak bu uçtan uca deneyimi iyileştirebildik.

4. Güvenle hayır demek için doğrulama sürecini kullanın

SendGrid'de sıkı bir gemi yönettik. İşletme, ürünün her gün milyarlarca e-posta göndermesini gerektirecek şekilde hiper hızda büyüyordu. Sistemin her yönünün muazzam seviyelere ölçeklenmesi gereken bu ortamda, mühendisliğin "iki kez ölç ve bir kez kes" gibi bir zihniyeti vardı. Bu düzeyde titizlik ve incelemeye sahip olmak, geliştirme sürecinin zaman alması ve ürün kuruluşunun mühendislikten yapmasını istediğimiz şey konusunda çok seçici olmasını gerektirmesi anlamına geliyordu; bu nedenle, aksi takdirde geliştirme ekibimizin zamanının ve enerjisinin çoğunu tüketebilecek şeyleri erkenden eledik. . Sorun cephesinde, doğrulama sürecinin yalnızca yarısı geçti.

Örnek olarak, bir yönetici bizden self servis satın alma akışlarımızı birden çok para birimini kabul edecek şekilde yükseltmemizi istedi. Bu kişi daha önceki bir şirkette benzer bir proje yürütmüş ve çok başarılı olmuştu. Projeyi doğrulama aşamasına geldik ve yerel para birimi sunmak isteyebileceğimizi düşündüğümüz çeşitli ülkelerdeki potansiyel müşterilerle görüştük. Öğrendiğimiz şey, ABD doları cinsinden ödeme yapmanın ciddi bir acı noktası olmadığıydı. Müşterilerimizin çoğu akıcı bir şekilde İngilizce konuşuyordu ve kredi kartlarıyla ABD doları üzerinden alışveriş yapmaya alışkındılar.

Elbette, ek para birimlerini barındırmak güzel bir özellik olurdu, ancak mevcut kurulumun insanların satın alma kararlarını önemli ölçüde etkilemediğini gördük. Sadece en iyi ürünü alacaklardı. Ek para birimleri sunmaktan elde edilen artan gelir, uygulanması pahalı fiyat etiketine değmezdi, bu yüzden hayır dedik.

Ürün liderleri ve erken aşamadaki kurucular için önemli çıkarımlar

  1. Müşterilerinizi tanımak için zaman ayırın. Bir ürün lideri olarak, kimin için inşa ettiğinize ve onların sorunlarına dair derin bir anlayışa sahip olmak, yalnızca yönetici seviyesindeki önceliklere rehberlik etmekle kalmayacak, aynı zamanda ekipleriniz genelinde güvenilirliğinizi artıracaktır.
  2. Büyük projeleri net bir sorun ve çözüm doğrulama süreciyle yürütün. Özellikle geniş ölçekte, müşterilerinizin umursamadığı bir şeyi inşa etmeye veya sorunlarına yeterince hitap etmeyen bir çözümü uygulamaya koymaya zamanınız yok. Doğrulama çerçevesi, Koruyucu Bakım kuruluş kültürünüzdeki müşteri odağını sağlamlaştırır.
  3. Kuruluş şemanızı göndermeyin. Ekibinizin sahip olduğu alan ne olursa olsun optimize edilmiş bir ürün oluşturmak yerine, birden fazla ekibin katkısını gerektirse bile müşterinin kullanım durumlarına odaklanın.
  4. Güvenle hayır demek için doğrulama sürecinizi kullanın. Hangi projeleri ve özellikleri takip ettiğinizi ne kadar çok incelerseniz o kadar iyi olur. Geriye işaret etmek için yerleşik bir doğrulama sürecine sahip olmak, karar verme sürecinizi diğer ekiplere iletmenize yardımcı olabilir.

Ölçeklendirme Ürün Yönetimi serisinin bir sonraki bölümü için gözünüz açık olsun. abone ol OpenView bülteni ve benimle bağlantı kur LinkedIn ilk bilen olmak!

spot_img

En Son İstihbarat

spot_img