Üretim Bandı Bülten ekibinden herkese merhaba!

Bu sayıda:

• Modadaki tabiriyle “zamansız” bir konu olduğunu düşündüğümüz “ekip ve organizasyon şekilleri” üzerine bir derleme yaptık. Bu konu biraz geniş ve türlü türlü görüşler var, ilerleyen zamanlarda tekrar ziyaret de edebiliriz o yüzden.

• Fikirlerimizi derleme yöntemimizi değiştirdik. Formatla alakalı bir yorumunuz olursa duymayı çok isteriz!

• İlginizi çekebilecek ve ürün yönetimine dair yayınlanmış veya başka türlü haberdar olduğumuz iş ilanlarına yer vermeye başladık.

Aklınızda yer eden, araştırmak ve öğrenmek istediğiniz başka başka konuları ya da içerikleri bizimle LinkedIn üzerinden (Burcu ve Eran) paylaşırsanız, bu bülten serisini ihtiyaç duydukça dönüp bakabileceğimiz bir bilgi merkezi haline getirebiliriz.

İyi internetler,
Burcu

Burcu: Şirketin büyüme fazındaki ilk basamaklarında olduğunu düşünelim: Ekipte henüz bir ürün yöneticisinin olmadığı zamanları. Ne zaman ilk ürüncüyü ekibe dahil etmeli?

Ken Norton, “When should you hire your first PM?” isimli yazısında bu konu üzerine düşünmüş. Kurucu ekibe dahil olmayan ilk ürün yöneticisinin asli görevinin kolları sıvayıp ürünün günlük düzeydeki işlerine koşturmak olacağını söylemiş ve yaşayacağı tipik zorlukları özetlemiş: Ürüncü işlevini kurucu ekipteki ürün sorumluluğunu üstlenen kişiden alma, ekip içinde kredibilite kazanma, kurucu ekibe direkt bağlı çalışacağı için bu ekiple olan ilişkilerin dinamiğini yönetebilme.

Yazının devamı ilk ürüncüyü işe alma zamanını anlamayı sağlayacak ipuçlarını içeriyor ve bazı kaynaklara yönlendiriyor. Açıkçası bir startupta çalışmanın en zorlayıcı taraflarının tam da yazıda bahsedilen PM One ya da PM Two kişisi olmakla birebir ilgili olduğunu düşünüyorum. Özellikle bu konuda kariyerini şekillendirmeye çalışan kişiler için aydınlatıcı olabilir bu yazı.

Diyelim bir ürün ekibimiz var artık, yani birden fazla ürüncü olan bir şirkette çalışıyoruz. Bu organizasyonu neye göre şekillendireceğiz?

Eran: Bu konuda birçok farklı yöntem var aslında. Eski Microsoft yöneticisi ve mevcutta a16z venture capital firmasında ortak olarak çalışan Steven Sinofsky, Microsoft deneyimlerini temel alarak şu soruyu çok detaylı bir şekilde incelemiş: “Takımları fonksiyonlara göre mi, ürün gruplarına göre mi yapmak gerekir?” İki modelin de artı ve eksilerini belirtmiş ve vermek istediği mesaj şu: Önce ihtiyacınızı anlayın, sonra modelinizi seçin. Önerim uzun bir yazı olduğu için sakin kafayla, vaktiniz varken, sindire sindire okuyun.

Burcu: Farklı yöntemler var gerçekten. Startup’ın bulunduğu büyüme fazına göre aranacak profillerin farklı olması gerektiğini ve bu farkları vurgulayan bir yazı okudum, First Round Review’dan yine. Yazı oldukça uzun ve detaylı, ama inanılmaz bir rehber olmuş toplamda çünkü her bir büyüme fazının neye benzediği ve o fazda işe alım yaparken düşülebilecek hatalar bir bir okunaklı bir şekilde anlatılmış. Hint: Yazının sonunda fazları özetleyen ve karşılaştıran güzel bir tablo var.

Bir başka yaklaşım da şirket kültürünün ürün ekibine yansıması üzerine, başarı anlayışı şirket için neyse onu ekip yapısına yansıtın diyor. Yazıyı baya özgün buldum, user-centered ve design-centered ekiplere yakın buldum kendimi. Tabii şirketin ürün geliştirme döngüsünde payı olan en önemli ikinci ekip yazılım ekibi olduğu için, orada da ürün odaklı bir ekip kurmak elzem. Bu konu üzerine okuduğum yazının en çok katıldığım yeri, yazılım ekibinin neyi niye yaptığını özümsemesi için ürün ekibiyle beraber kullanıcı görüşmelerine katılmasını önerdiği yer oldu. Cross-functional bir ekip yapısının kurulumunu yapıp etkilerini izledim ve en büyük faydalarından biri de yazılım ekibinin çözmeye çalıştığımız problemlere sıkı sıkı sarılması olmuştu gerçekten.

Ekip kurma ve şekillendirme deneyimlerini internette paylaşan da pek yok bu arada, örnek uygulama diyebileceğimiz.

Eran: En yaygın bilinen örnekleri Spotify ve Buffer diyebilirim.

Buffer aslen sosyal medya yönetimi yazılımları üreten bir firma, daha çok transparan yönetim kültürü ve iç politikalarını açıklığıyla paylaşmalarıyla biliniyor. Ürün takımlarının zaman içerisinde ne şekilde değiştiğini, denedikleri farklı yöntemleri yazmışlar. Sonunda Spotify modeline benzer bir yapıya gelmişler. Tabii Buffer’ın remote çalıştığını belirtmekte de fayda var çünkü Spotify modelinde sıkı iletişimin çok büyük önemi var. Yazıda ilgimi çeken, takım yapılarının içerisinde kişilerin yanında “Act, Decide, Advise” gibi şeyler yazmasıydı. Biraz daha irdeleyince karar verme mekanizmalarında iki ana prensip olduğunu gördüm:

1) Her bir takım, konu, iş için 1 veya 2 karar verici olacak.
2) Karar vericilerin farklı konularda kimlerden destek alacağı belli olacak. Destek alma sıklığı kararın önemine göre değişecek.

Spotify‘ın ürün ve yazılım takımlarının nasıl organize olduğunu anlatan videoyu da mutlaka görmüşsünüzdür. Ben de ilk gördüğümde çok ideal bir yapı olduğunu düşündüm – otonomi sağlayan, ölçeklenebilir, multi fonksiyonel ürün takımları. Bu ürün takımlarını ve bireyleri bağlayan tribe, chapter, squad gibi yapılarla genel yapıyı sıkılaştırmaya çalışmışlar. Çok mantıklı. Kelimesi kelimesine olmasa da genel mantığı ile belli bir büyüklükteki firmalar için faydalı bir yapı.

Fakat orada 1 seneden az çalışmış Jeremiah Lee adlı yazılımcı öyle düşünmüyor. Hatta Spotify’ın videodaki yapısının olumsuz taraflarının bol olduğuna dikkat çekiyor. Bu yapının kağıt üzerinde güzel ama günlük hayatta aslında dertli olduğunu yazmış. Bunu gören Marty Cagan ise (ki anladığım kadarıyla kendisi Spotify’a danışmanlık vermiş) Jeremiah’ya cevap niteliğinde bir yazı yazıyor.

Özetle – Hiçbir yapı mükemmel değildir, her birinin olumlu olumsuz tarafları vardır. Bence Jeremiah Lee de bunu vurgulamaya çalışmış. Spotify videosunu izleyip motamot uygulamaya çalışmayın, çünkü her modelin olduğu gibi bu modelin de sıkıntıları var.

Türkiye’de de ekip yapıları konusuyla alakalı örnek uygulamaları konuştuğumuz bir podcast’imiz var aslında, oradan iyzico ve Paraşüt bölümlerini seçtim bu bülten için. iyzico otonomik ürün takımları ile ürün geliştiren şirketlerden bir tanesi ve Circle adını verdikleri bu yapıları konuştuğumuz bölümümüz şurada. Paraşüt’leyse kuruluşundan 2018’e kadar ürün takımını nasıl organize ettiğini, yaklaşık 12 ayda bir takım yapısını değiştirerek ihtiyaçlara daha rahat çözüm bulabilme eforunu konuştuğumuz bölümümüz burada.

Aranıyor

• Brainly (Krakow, Polonya), Product Manager

• Zeplin (İstanbul, Türkiye), Lead Product Manager

• Insider (İstanbul, Türkiye), Senior Product Manager

• Insider (İstanbul, Türkiye), Group Product Manager

• Mutlubiev (İstanbul, Türkiye), Head of Product

• (İçeriden) Meditopia (İstanbul, Türkiye), Web Product Manager: Henüz bir iş ilanı yok, ancak güncel yatırım haberlerinin üzerine ekiplerini büyütmeye karar vermişler ve web ürünlerini yönetecek, SEO geçmişi/bilgisi olan, UX ve CRO know-how’ı sağlam birine ihtiyaçları var. Başvurular sevinc@meditopia.com’a.

• WeWalk (İstanbul, Türkiye), Mobile Product Manager

Bu sayılık bu kadar!

Bizi seveceğini düşündüğünüz birileri varsa, aşağıdaki butonu kullanarak haberdar edebilirsiniz:

Share Üretim Bandı Bülten