“Product engineer” eski bir işe verilmiş yeni bir unvan gibi duyulabilir, ancak aradaki fark gerçektir. Geleneksel mühendis, çıktıyla ölçülür: kapattığı ticket’lar ve spesifikasyona uygun teslim ettiği özellikler. Product engineer ise sonuçla ölçülür: Kullanıcılar eylemi gerçekten tamamladı mı? Metrik değişti mi? İşletme parasını ödediği değeri elde etti mi? Kod aynıdır; yazmaya başlamadan önce sorduğunuz soru farklıdır.
Bir product engineer pratikte bazı şeyleri farklı yapar. “Nasıl?”dan önce “Neden?” diye sorar: Hangi sorunu, kimin için çözüyoruz ve işe yaradığını nasıl anlayacağız? Daha basit bir sürüm aynı değeri zamanın üçte birinde sağlayacaksa spesifikasyona itiraz eder. Yalnızca tasarımdaki sorunsuz akışa değil, yüklenme, hata ve boş durumlar dâhil kullanıcının bütün yolculuğuna bakar. Yayından sonra da sadece yeşil CI rozetine değil; analitik verilere, destek taleplerine ve oturum kayıtlarına göz atar.
Bu rol geniş bir bakış gerektirir. En iyi veritabanı uzmanı ya da tasarımcı olmak gerekmez, ancak veri modelinden API’ye, UI’dan dağıtıma, analitikten artık AI’a kadar tüm akışta rahat olmak gerekir. Bu yüzden full-stack mühendisleri sık sık product engineer rolüne evrilir: bir özelliği baştan sona üstlenince “neden” sorusunu devredecek kimse yoktur. Benim için bu, Postgres şemasından Next.js ekranına ve özelliğin kullanılıp kullanılmadığını gösteren olaya kadar uzanır.
Product engineer küçük parçalar hâlinde teslim eder ve hızla öğrenir. İlk sürüm, altı ay sonra açılacak bir platform değil; feature flag arkasında, üretimde ölçülen tek bir eylemdir. Nerede taviz verilebileceğini (yönetim paneli çirkin olabilir, elle yapılan adım bir ay daha elle kalabilir) ve nerede verilemeyeceğini (ödemeler, izinler, veri bütünlüğü) bilir. İşin çoğunu bu muhakeme oluşturur; ancak kararlarının sonuçlarını bizzat yaşayınca gelişir.
Bu aynı zamanda bir iletişim rolüdür. Product engineer kurucularla framework’leri değil, riskleri, maliyeti ve süreyi konuşur. Tasarımcılara bir şeyin yapım maliyetini anlatır ve daha uygun alternatifler önerir. Fırsat buldukça kullanıcılarla konuşur. Kararları da yazar: Bir seçimin neden yapıldığını açıklayan kısa bir not, altı ay sonra çoğu zaman kodun kendisinden daha değerlidir.
Kendime product engineer diyorum çünkü işin en çok önemsediğim kısmı bu: pull request değil, gerçek bir kişinin yaptığımız ürünü kullanıp işini görebildiği an. İki haftalık devir teslimlerdense uzun süreli çalışmayı tercih etmemin sebebi de bu; etkisini görmediğiniz bir sonucun sorumluluğunu alamazsınız. Rahatsız edici sorular sorup ardından çözümü teslim edecek bir mühendise ihtiyacınız varsa bana yazın.
Bir sonraki ürüne kalacak birini verin.
Başlamaya hazır mısınız? Bana yazın — hemen başlayabilir ve kalabilirim. İki haftalık devir değil, uzun vadeli iş birliği. Projenizi, gereksinimleri ve ilerlemenin en iyi yolunu konuşalım.