Zephyrnet Logosu

Ürün Başkan Yardımcınız Kime Rapor Vermeli? | SaaStr

Tarih:

Son zamanlarda 5'ten fazla SaaS şirketiyle çalışıyorum ve hepsi ilk Ürün Başkan Yardımcısını işe alıyor. Çoğu 6 milyon ila 10 milyon dolar arası ARR civarında, ancak biri 2 milyon dolarlık ARR'yi biraz geçiyor. Ve en önemlisi, çoğunun gerçekten güçlü bir CEO-CTO ortaklığı var. Her ikisi de harika liderler ve her ikisi de ürünü ve geleceğini belirleme konusunda harikalar. Bu, genellikle ilk Ürün Başkan Yardımcısının kime rapor vermesi gerektiğinin tamamen açık olmadığı anlamına gelir.

Birkaç genel öğrenme:

  • CTO'ya/Mühendisliğe Rapor Veren Bir Ürün Başkan Yardımcısı Nadiren Bu Kadar Çok Müşteriyle Buluşuyor. Bunu sadece tekrar tekrar görüyorum. Mühendisliğin içinde yer alan Üründen Sorumlu Başkan Yardımcısı, oldukça içsel odaklı hale gelir. Bu, bir API veya benzer hizmet için iyi olabilir, ancak bunun kurumsal bir SaaS veya müşteriye yönelik önemli özelliklere ve iş akışlarına sahip bir SaaS için büyük bir ödün olduğunu düşünüyorum.
  • Hiçbir Zaman Gerçekten Gerçekten Yönetilmemiş Bir Ürün Başkan Yardımcısı Mühendisler, Mühendisliğin Saygısını Kazanmak İçin Sıklıkla Mücadele Ederler. Bu aynı zamanda bir gerçektir.  Tekrar tekrar, daha önce hiçbir mühendisi gerçekten yönetmemiş, esnek bir ürün başkanının veya hatta Ürün Başkan Yardımcısı'nın işe alındığını görüyorum. Ve geliştirme ekibi daha sonra onları kısmen reddediyor. Sadece doğru otoriteyle konuşmuyorlar. Bunu tüm Ürün Başkan Yardımcısı adaylarına sorduğunuzdan ve öğrendiğinizden emin olun.
  • Ürün Başkan Yardımcısı, Mühendislik Başkan Yardımcısının yerine geçmez.  Burada kararın belirsizleşmesinin bir nedeni, bir SaaS şirketi ölçeklenirken, karmaşıklığın artması nedeniyle CTO'nun ürün konusunda yardıma ihtiyaç duymasıdır. Dolayısıyla VPP'nin CTO'ya rapor vermesi doğal olarak mantıklı görünüyor. Ama çoğu zaman yaptıkları şey Gerçekten mi Scale'e yardıma ihtiyacım var, Müh. Başkan Yardımcısı. Bu, en azından geliştirmenin daha tekrarlanabilir / kanıtlanmış / yeni olmayan kısımlarını (işe alma, teknik operasyonlar, geliştirme operasyonları, teknik borç, veritabanı vb.) devralabilir.
  • Çoğu Mühendislik Başkan Yardımcısı, Ürün Başkan Yardımcısının Kendilerine Rapor Vermesini Gerçekten İstemez. Bazıları bunu yapar ama çoğu yapmaz. Bunu fark ettiğinizde bu bir nevi “A-Ha” anıdır.  Mühendislik Başkan Yardımcılarının çoğu, Product'ın ortakları, kanat kişileri olmasını, dışarı çıkıp harici işleri yapmasını ve ardından neyin inşa edileceğine karar vermede ortakları olmasını istiyor. Deneyimli Mühendislik Başkan Yardımcılarından çok daha erken aşamadaki kurucu-CTO'lar VPP'nin kendilerine rapor vermesini istiyor. Bu çok anlamlı.

Burada mükemmel bir cevap yok ama kurucu ortak olarak karar vermeden önce birkaç öneri:

  • Öncelikle yukarıdaki ödünleşimleri anladığınızdan emin olun ve bunları tartışın. Yukarıdaki madde işaretlerinin üzerinden birlikte geçin.
  • İkinci olarak, Mühendislikten Sorumlu Başkan Yardımcısına da ihtiyacınız olmadığından emin olun.. Muhtemelen ikisine de ihtiyacınız var.
  • Üçüncüsü, eğer CEO daha çok Ürün Başkan Yardımcısı ise, VPP'nin CEO'ya rapor vermesi mantıklı olacaktır.. İşin ağır yükünü CTO yapıyor olsa bile.
  • Dördüncüsü, ihtiyaçlar ne kadar az müşteriyle karşılanırsa mühendisliğe rapor veren bir VPP'ye sahip olmak o kadar anlamlı olur, bu gerçekten de bir mühendisti.
  • Beşinci. En iyi yöntem, bir noktada bir mühendislik ekibini bizzat yönetmiş olan bir Ürün Başkan Yardımcısını işe almaktır. Takasları alacaklar. Küçük bir ekip olabilir, dış kaynaklı bir ekip olabilir ve kendilerinin gerçek bir kodlayıcı olmasına gerek yoktur. Ancak uzun bir süre boyunca bir geliştirme ekibini doğrudan yönettilerse bunu alırlar.

Sonuçta, çoğu kurumsal ve iş akışı SaaS ürününde, yukarıdaki nedenlerden dolayı CEO'ya rapor veren bir Ürün Başkan Yardımcısı bulunmalıdır. Ama en azından karar vermeden önce yukarıdaki düşünce alıştırmasını yapın.

[Gömülü içerik]

İlgili Mesajlar

spot_img

En Son İstihbarat

spot_img