Yapay Zekâ Ürün Yöneticilerini Rollerinin Ötesine Nasıl Taşıyor

Ürün yönetimine giden yol

Artık 15 yılı aşkın süredir ürün yöneticisiyim. Kariyerimin ilk dönemlerinde tasarım, satış, danışmanlık, pazarlama ve hatta PHP dönemlerinde kodlama da dahil olmak üzere yapabileceğim diğer her şeyi yaptım — iğrenç.

Çeşitli konular arasında geçiş yapmaktan ve kullanıcılar, geliştiriciler, yöneticiler vb. kişilerle iletişim kurmaktan gerçekten keyif aldığım için ürün yönetimine girdim. Ayrıca tasarım konusunda oldukça iyi bir gözüm ve ürün anlayışım vardı. Uzun bir araştırmadan sonra bunlara gerçekten uygun bir rol olduğunu buldum — Ürün Yönetimi. Böylece ilk ürün yöneticisi pozisyonuma başvurdum ve buraya bu şekilde geldim.

Her türlü sektörde çalıştım: B2B, B2B2C, perakende ve tüketici yazılımları. On yılı aşkın süre önce General Assembly'de ürün yönetimi dersleri vermeye başladım; sonrasında Udemy ve daha sonra LinkedIn Learning üzerinden bağımsız olarak kendi çevrim içi kurslarımı yayınladım. Bugün, her iki platformda toplam 1,6 milyondan fazla öğrencim var. Ayrıca Google'la birlikte Ukrayna'nın Kyiv kentinde bir ürün kursu vermek de dahil olmak üzere ürün ve proje yönetimi hakkında pek çok konferansta konuşma yaptım.

Şu anda a16z tarafından finanse edilen, deterministik bir veri aracısı uygulaması olan Probably.dev ile çalışıyorum. Küçük bir ekibiz; dolayısıyla yalnızca ürün yöneticisi değil, aynı zamanda mühendis, satış temsilcisi, tasarımcı vb. görevleri de üstleniyorum.

Uygulamamız, verilen herhangi bir doğal dil sorgusunu hassas veriler makinenizden ayrılmadan doğrudan yanıtlamak için destekleyici görselleştirmelerle birlikte deterministik, doktora düzeyinde veri bilimi gerçekleştiren yerel bir masaüstü uygulamasıdır. Bunu bir "veri yardımcısı" olarak düşünebilirsiniz. Doğrudan veri ambarı şemaları (ör. BigQuery, Snowflake, Clickhouse vb.) üzerinde ve CSV, JSON ve Parquet gibi yerel dosyalarla çalışıyoruz. Aracımızın sağladığı tüm yanıtlar bir insan tarafından izlenebilir ve yeniden üretilebilir; bu nedenle tipik LLM halüsinasyonları sorun teşkil etmiyor. Bu yalnızca başka bir SQL oluşturucu aracı değil; milyarlarca satır/sütun ve on binlerce tablo içeren karmaşık şemalarla da çalışabiliyoruz.

You should also read

• Yapay Zekâ Destekli Proje Yöneticisi ve Eğitimci, Projelerin İşleyişini Temelden Değiştiren Basit Bir Yapay Zekâ İş Akışını Paylaşıyor

• Bir Asana Uygulama Ajansında Teslimat Başkanının Kullandığı Gerçek Dünya Yapay Zekâ İş Akışları

Yapay zekâ ekiplerin kişi başına daha fazla iş yapmasına nasıl yardımcı oluyor?

Yapay zekânın çalışmalarım üzerinde büyük bir etkisi oldu. Eskiden "sadece bir ürün yöneticisiydim". Bu kulağa saçma geliyor çünkü ürün yöneticileri çok fazla iş yapıyor; ancak artık mühendislik ve satış gibi diğer alanlara da katkıda bulunabiliyorum. Bu da ekibin işlerini hızlandırıyor. Yapay zekâ proje yönetimini dönüştürürken, geleneksel rol sınırları da daha esnek hâle geliyor.

Araştırma ve analiz gibi zaman alan işler çok daha hızlı tamamlanıyor; zaman tasarrufu da paydaşlarla çok daha fazla yüz yüze görüşme ve iletişim kurulmasını sağlıyor. Ayrıca daha hızlı karar alınmasına da olanak tanıyor.

Bir ürün yöneticisinin işinin büyük bölümü, diğer herkesin kendi işlerini etkili bir şekilde yapabilmesini sağlamaktır. Dolayısıyla benim kendim daha fazlasını yapabilmem sayesinde kişi başına çok daha fazla iş tamamlayabiliyoruz. Bu insan-yapay zekâ hibrit yaklaşımı, modern teslimat ekipleri için vazgeçilmez hâle geliyor.

Yapay zekânın derinlemesine anlaşılması ürün yöneticilerinin neredeyse her şeyi yapmasına neden olanak tanıyor?

Konunun içine girdikçe, etkili ve verimli yapay zekâ/LLM kullanımındaki öğrenme eğrisinin aslında ne kadar dik olduğunu ve bunu çevrenizdeki veya ekiplerinizdeki insanların tercih ettiği iş akışlarına uydurmanın başlı başına bir alt beceri olduğunu daha iyi anlıyorum. Bu da bir şirketteki herkesin yalnızca genel olarak LLM'lere ve mevcut modellere değil, aynı zamanda MCP'ler gibi çevrelerindeki çok sayıdaki ekosistem aracına, CLI ve GUI gibi kullanım biçimlerine ve en önemlisi dönüştürücü mimarisine de yakından aşina olması gerektiğine dair inancımı pekiştiriyor. Bu teknolojileri etkili şekilde uygulama konusunda bilgilerini derinleştirmek isteyenler için yapay zekâ proje yönetimi kitaplarını incelemek değerli bilgiler sağlayabilir.

İster içerik ister araç olsun, günümüzdeki uçsuz bucaksız yapay zekâ çöplüğü içinde yapay zekâyla iyi çalışmak, geliştirmeniz gereken bir beceridir ve bu ancak deneyimle kazanılabilir. LLM'lerin nasıl çalıştığını ve en iyi sonuçları elde edip en yüksek performansı gösterebilmek için neleri iyi yapıp neleri yapamadıklarını anlayabilmeniz gerekir.

Örneğin PRD'ler hazırlamak gibi işler için piyasadaki pek çok “çığır açan" SaaS ürünü ve aracı iyi çözümler gibi görünüyor; ancak yukarıdaki kavramları anladığınız ve LLM'leri etkili bir şekilde kullanma becerisine sahip olduğunuz sürece, ihtiyacınız olan her şeyin %99'unu kendiniz daha ucuza, daha hızlı, daha özelleştirilmiş ve çok daha iyi bir şekilde yapabileceğinizi gördüm.

Bu, bir kişinin basit bir şey yaptığını gösterdikleri, ardından bunun ne kadar "zor" olduğunu anlatıp o küçücük kullanım alanını çözmek için size koca bir cihaz satmaya çalıştıkları bilgi reklamlarına benziyor. Örneğin normal bir insan gibi muzu bıçakla parçalara ayırmak yerine, tüm parçaları tek bir hareketle kesen muz şeklinde bir dilimleyici satmak istiyorlar...

Bıçak bir LLM'dir ve muz dilimleyici işe yaramaz, niş bir uygulamadır. Lanet olası bıçağı kullanmayı öğrenin. Kaliteli bir tane alın, kullanın, öğrenin ve teknoloji Twitter'ı rastgele bir SaaS uygulamasının "tasarımcıları gereksiz hâle getirdiğini" veya "kodlamayı bitirdiğini" söylüyor diye aptalca şeyler satın almayı bırakın.

Bir CLI'da, web tarayıcısında ve arada bir n8n gibi açık uçlu, göreve özgü olmayan bir otomasyon aracıyla bir LLM kullanarak temelde yapamayacağınız hiçbir şey yoktur.

Paranızı biriktirin ve bir gecede ortaya çıkan SaaS aracının çıktısını kabul etmek yerine, öğrendiğiniz deneyimlerin bilgeliğini yansıtan şeyler oluşturmayı öğrenin.

Bunun geçerli olmayacağı tek durum, özellikle saf öncü modellerindeki (yani ince ayar yapılmamış modellerdeki) dönüştürücü LLM mimarisinin doğası gereği kusurlu olduğu sorunları çözmeye odaklanan tek amaçlı araçlardır. Örneğin, büyük ölçekli veri bilimi veya matematik.

Bir ürün yöneticisi olarak yapay zekâyla öğrenmeye nasıl başlanır

LLM'lerin en iyi yanı, onlara kendileri hakkında nasıl öğrenebileceğinizi sorabilmenizdir. Benim gibi görsel öğreniyorsanız YouTube pastanın üzerindeki krema gibidir; orada yapay zekâ ve LLM'ler hakkında tonlarca iyi kaynak var.

Yeniden başlıyor olsaydım öğrenmeye şöyle yaklaşırdım: Bir LLM'e, yapay zekâ/LLM alanındaki her şeyi teknik anlayış seviyenize uyarlanmış şekilde öğrenmek istediğinizi söyleyin. Hatta yapay zekâ/LLM alanındaki herhangi bir konu için, temellerden başlayarak mevcut yeterlilik seviyenizi anlamak amacıyla size giderek daha teknik sorular sormasını bile isteyebilirsiniz. Ve bilgi seviyenizi aşan bir noktaya geldiğinizde, dönüştürücü mimarisinin temellerinden ChatGPT gibi bir uygulamanın nasıl çalıştığına kadar öğrenmeniz gereken konuları önermesini sağlayabilirsiniz.

Fikir, öğrenilecek konuların bir listesini çıkarmak ve ardından her konuyu anlamak için bir video bulmak üzere bunların her birini YouTube'da aramaktır.

İşte örnek bir istem:

Yapay zekâ/LLM “başlangıç noktası” değerlendiricim olarak hareket et.

Şunları ölçmek için bana en fazla 12 soru sor (kolay ve teknik soruları karıştır):

• genel teknik yeterliliğim (kodlama, veri, API'ler)
• LLM'lerin nasıl çalıştığına dair anlayışım (CLI ve GUI gibi model kiplerinin yanı sıra belirteçler, bağlam, halüsinasyonlar vb.)
• modern LLM uygulama kalıplarına aşinalığım (RAG/gömüler, aracı sistemler/araç kullanımı)
• kaliteyi değerlendirme becerim (değerlendirmeler, doğrulama)
• risklere dair farkındalığım (gizlilik, istem enjeksiyonu vb.)
• yapay zekânın sınırlamalarına dair farkındalığım (LLM'ler için iyi ve kötü kullanım alanları, doğruluk, LLM çıktılarının kontrol edilemez doğası vb.)

Yanıtladıktan sonra YALNIZCA şunu çıktı olarak ver:

• Sonraki adımda öğrenmem gereken, en yüksek getirili 5–10 YouTube konusu; öncelik sırasına göre düzenle. Her madde bir YouTube arama ifadesi (cümle değil) + “neden önemli” açıklaması olarak 5–10 kelimeden oluşmalı.

Şimdi sorularınla başla.

Ürün yöneticileri öncelikle hangi yapay zekâ becerilerini öğrenmeli?

Bence LLM'leri nerede ve nasıl kullanabileceğinizi anlamak önemli. Bununla kastettiğim, onların bir uygulamada, bilgisayarınızın terminalinde veya MCP'ler ya da API'ler aracılığıyla bir otomasyonda çalışan kodun içinde bulunabileceğini anlamaktır.

İkinci olarak, onların şunlar olduğunu mutlaka anlamalısınız:

1. Deterministik olmayan, kontrol edilemeyen ve hataya yatkın
2. Özellikle kritik kararlarda doğru bilgi için asla güvenilmemesi gereken
3. Kullanım alanınıza bağlı olarak, önceki iki maddenin etkilerini azaltmak için yaratıcı biçimde otomatikleştirilebilen

Verdiğim klasik örnek, bir denemeyi tamamen sizin için yazması amacıyla asla bir LLM kullanmamanızdır; ancak sırada ne yazacağınız konusunda takılıp kaldıysanız, ondan izleyebileceğiniz bazı yönlere dair fikirleri listelemesini istemeniz tamamen uygundur. Başka bir deyişle, LLM'ler insan zihnini harika biçimde destekler; ancak insan zihninin yerine tüm düşünme işini onlara yaptırmaya çalıştığınızda bu, karanlık bir yola dönüşür.

Burada değineceğim son şey, yukarıdaki kavramları öğrenirken bunları kendiniz deniyor olmanız gerektiğidir. Örneğin istem mühendisliğinin nasıl çalıştığını öğreniyorsanız, çıktıda oluşan farkı görmek için aynı soruyu bir LLM'e iki farklı şekilde ifade ederek sormalısınız. Öğrenmeyi aynı anda uygulamadan asla öğrenmeyin.

Yüksek değerli müşteri etkileşimlerini neden yapay zekâyla otomatikleştirmemelisiniz?

Bilmeniz gerekenleri öğrendikten sonra neredeyse her şeyi yapabilirsiniz. Ancak bu, yapmanız gerektiği anlamına gelmez.

Üst segment bir ürüne sahip, erken aşamadaki bir şirket için müşteri etkileşimi ve satışlar, yapay zekâ ve otomasyona en uygun alanlar gibi “görünür”. Ancak pratikte, insani bir dokunuşun kesinlikle gerekli olduğunu gördüm. Şahsen kullanıcılarla veya potansiyel müşterilerle etkileşimi her iki taraf için de önemli bir değer katkısı olarak görüyorum ve bunu otomatikleştirmeyi denemek bile istemiyorum.

Bir PM olarak, kullanıcılarla konuşmaktan herhangi bir ölçüde uzak durmak kendinize haksızlık olur. Onlarla kendi sesinizle kişisel olarak ne kadar çok konuşursanız, o kadar fazla bilgi edinir ve o kadar çok güven oluşturursunuz.

Ürün yöneticilerinin koda katkıda bulunmasının zor ama mümkün olmasının nedeni

Bu nedenle AI'ı ne amaçla kullandığım konusunda temkinliyim, ancak onu çok kullanıyorum.

Örneğin, canlıya alınmadan hemen önce her zaman bir hata düzeltme telaşı yaşanır. Genellikle daha büyük bir şirkette bu tür son dokunuşları mühendisler ve QA ekibi yapardı. Elbette kıdemli ürün çalışanı da sürece dahil olurdu, ancak aynı zamanda bir sonraki adımları ve sürümün izlenmesine yönelik stratejileri planlar, kullanıcı geri bildirimlerini toplar, birkaç döngü sonrasını hazırlamaya çalışır veya özellik ya da ürün kullanıma sunulduktan sonra metrikleri toplardı.

Şu anda daha küçük bir şirkette olduğum için, mühendislerle birlikte hataları hızla gidermeye yardımcı olabilmek benim için oyunun kurallarını değiştirdi ve bunu yalnızca AI/LLM'lerin kullanımı sayesinde başarabildim.

Kariyerim boyunca ürünlerde ve özelliklerde QA süreçlerine her zaman dahil oldum, ancak tam yığın üzerinde kod değişiklikleri gerektiren bir hatayı sahaya inerek düzeltme fırsatım nadiren oldu.

Deneyimli teknoloji çalışanları, mühendislerin kod tabanları ve kodlama standartları konusunda çok titiz olduğunu bilir. Dolayısıyla belirli bir hatayı nasıl düzelteceğinizi teknik olarak bilseniz bile kodlama standartlarının ve mühendislik ekibindeki kişiliklerin bağlamına sahip olmanız, ayrıca kodun her bölümünde çalışmış mühendisleri anlamanız gerekir. Bu nedenle bazı hataları düzeltmek, nasıl yapılacağını bilseniz bile kolay olmaktan birkaç adım uzaktadır ve çoğu mühendis düzeltme için açtığınız çekme isteğini küçümserdi.

Ancak AI sayesinde yalnızca ana dala doğrudan kod göndererek koda katkıda bulunmakla kalmadım, aynı zamanda işin içindeki ikincil kültürel faktörleri de giderebildim.

Kod tabanınıza güvenli bir şekilde katkıda bulunabilen bir AI ajanı nasıl oluşturulur?

İlk yaklaşımım, Claude Code'da bir ajan sürüsünün son altı ay boyunca tüm depoyu incelemesini ve kodlama stilini, deponun Claude.md dosyasını ve en önemlisi GitHub farklarındaki tüm yorumları, çakışma çözümlerini, işlem kayıtlarını ve PR'larda yapılan düzenlemeleri özümsemesini sağlayarak bir kodlama standartları Markdown belgesi oluşturmaktı.

Bunun ardından, oldukça sağlam bir kodlama standartları belgesine sahip oldum. Bu belgeyi Claude Code'da bir dizi beceri ve komuta dönüştürerek, hata düzeltmesi için oluşturduğum herhangi bir kodun kod tabanında ekibin daha önce uyguladığı kodlama standartlarına göre düzeltilmesini sağladım. Daha sonra GitHub ile kancalar kullanan ve manuel olarak da tetikleyebileceğim başka bir alt ajan oluşturdum. Bu ajan, yazdığım kodun yanı sıra yorumları veya düzeltmeleri inceleyecek ve tüm bunları kodlama standartları belgesine eklenecek bir içerik hâline getirecekti.

Sonunda, yalnızca birkaç PR'dan sonra, belirli bir düzeltme için oluşturduğum kod, aslında birden fazla zamanlanmış iş ve Claude Code ile otomasyonlar aracılığıyla tetiklenen, sürekli gelişen ve kendi kendine öğrenen bir kodlama stili rehberi olan basit bir Markdown belgesi sayesinde kod tabanında görmek istediğimiz kod türüne çok kolay bir şekilde dönüştürülebiliyordu.

Ajan artık o kadar iyi ki doğrudan ana dala birleştirme yapabiliyorum.

Küçük ürün ekipleri çevikliği nasıl artırabilir?

Bu, geleneksel PM rolünün ötesine nasıl geçtiğime dair iyi bir örnek. Ancak geleneksel rollerin ötesine geçmek iyi süreçler gerektirir.

Linear'da iyi düzenlenmiş ve etiketlenmiş bir iş listemiz var ve pazartesi, çarşamba ve cuma sabahları zorunlu toplantılar yapıyoruz. Eş zamanlı toplantı olmayan günlerde Slack'te günlük durum kontrolüyle güncel kalıyoruz. Diğer tüm önceliklendirme ve tartışmalar gerçek zamanlı olarak Slack üzerinden gerçekleşiyor.

Bu, daha büyük şirketler için en iyi çözüm olmayabilir, ancak bu kullanım alanı için ne kadar iyi çalıştığına ve bizi ne kadar çevik tuttuğuna şaşırabilirsiniz. Eskiden Google Drive, e-tablolar, belgeler, slaytlar ve milyonlarca başka uygulama kullanırdım. Artık küçük bir ekip olarak GSuite, Slack, Linear ve GitHub ile işimizi yürütebiliyoruz.

Bu sürekli gelişen AI/LLM alanında hafif PM yöntemleri önemlidir. Kullanıcı geri bildirimleri veya potansiyel rakiplerin sürümleri nedeniyle haftanın herhangi bir günü bir şeyler olabilir ve bunları hızla takip edip önceliklendirmemiz gerekebilir.

AI, ürün ekiplerini rutinlerini yeniden düşünmeye nasıl zorluyor?

Rutinler söz konusu olduğunda en büyük yeniden düşünme noktası, bunun artık sürekli oluşturup başvurmanız gereken durağan belgeleri olan bir şey değil, gerçekten döngüsel ve hiç bitmeyen bir rutin olmasıdır.

Kapsam, ayrıntı düzeyi değişken olan, sıkı tanımlanmış bir Linear bileti olarak başlar. Ardından AI'ı belirsizlikleri, uç durumları ve sıralama seçeneklerini stres testine tabi tutmak için kullanırım ve en küçük dilimde kullanıma sunulabilir hâle gelene kadar kapsamı daraltırım.

Küçük ve uzaktan çalışan bir ekip olarak bizim için uyum büyük ölçüde eşzamansızdır — net bir karar ve sonraki adımlarla sona eren kısa bir Slack ileti dizisi; hafif günlük durum toplantıları ise Geekbot tarafından yürütülür. Bununla birlikte, birlikte fikir üretmek ve ekip moralini yükseltmek için haftada üç veya dört ekip toplantısının hâlâ büyük değeri var.

Doğrulama konusunda daha gevşek değil, daha katı hâle geldim. LLM'ler, bunları nasıl doğru kullanacağınızı bilmiyorsanız genellikle ikna edici bir saçmalık üretir. Bu nedenle her özellik veya uygulama değişikliği için AI'ın taslak oluşturmaya yardımcı olabileceği ancak benim düzenleyip test edeceğim gerçekçi girdiler, beklenen çıktılar ve karşıt durumlar içeren küçük bir değerlendirme düzeneği oluşturuyoruz.

Yürütme ise yalnızca Linear + Claude Code + kendi barındırdığımız Posthog analizlerinden ibaret. Yayına al, gözlemle, ayarla ve döngüyü hızlı tut; çünkü teknoloji pazarı bugünlerde saatlik bir hızla değişiyormuş gibi görünüyor.

Minimalist, yapay zekâ öncelikli bir araç seti neden en iyisidir?

İşte temel PM araç setim:

• GSuite
• Slack
• Geekbot Slack botu (günlük toplantılar için)
• Linear
• VSCode
• CLI tabanlı LLM (bizim durumumuzda Claude Code)

Neden Linear? Yalnızca temel gereksinimlere odaklanır. Bir proje ekibinin ihtiyaç duyabileceği neredeyse her talebi karşılayacak kadar güçlü, ancak herkesin kolayca kullanabileceği kadar basittir. JIRA'nın antitezidir. En önemlisi de GitHub ve Slack ile kolayca entegre olur; mühendisler zaten işe başlamak için bu platformlarda çalışır. Basit, hafif ve mühendislerin görevleri takip etmesi veya güncellemesi için eklenen sürtünmeyi en aza indirir. Ayrıca son derece genişletilebilirdir; örneğin CLI'nizdeki LLM'iniz, bir hata taslak PR'da bildirildiğinde, bir insan incelemeye başlamadan önce hatayı otomatik olarak düzeltmeyi deneyebilir.

Bunun dışında başka hiçbir şeye ihtiyaç yok. Bunun dışındaki her türlü iş, terminaldeki açık kaynaklı araçlarla yapılabilir.

Cole'un kişisel üretkenlik için favori yapay zekâ aracı

Kişisel, ekip dışı kullanım düzeyinde üretkenlik için Raycast'e kesinlikle bayılıyorum. Mac'teki berbat "Spotlight" uygulamasının veya Windows'taki "Windows" tuşunun yerini alan, hızlı erişim sağlayan, tamamen özelleştirilebilir ve son derece hafif bir uygulamadır. Çoğu iş için fare kullanımınızı %75 oranında azaltabilirsiniz. Mevcut entegrasyonlarıyla neredeyse her uygulamayı entegre edebilir veya kolayca kendi özel entegrasyonlarınızı oluşturabilirsiniz — Claude Code'dan sizin için bir eklenti oluşturmasını istemeniz yeterli!

Bir görselde gördüğüm metni panoma almak istersem Raycast kısayol tuşlarına basar, "OCR" yazıp Enter'a basarım. Bu işlem cleanshotX OCR ekran görüntüsü aracını tetikler ve herhangi bir görseldeki metni beş saniyeden kısa sürede elde ederim. Benzer şekilde kısayola basıp "Spotify'a sor" yazabilir, ardından "yüksek enerjili, güzel kodlama müzikleri öner" gibi doğal dilde bir cümle yazabilirim. Bu işlem cümlemi bir LLM aracılığıyla yorumlar, Spotify API'sinde müzik etiketlerini ve özelliklerini arar, ardından istediğim müzik türünden bir çalma listesini Spotify'da anında başlatır.

Kullanım alanları sınırsızdır. Uygulamayı indirip kendi API anahtarlarınız veya abonelikleri aracılığıyla yapay zekâyı etkinleştirin ve web sitelerindeki en iyi eklentilere göz atarak sizin için yararlı olacağını düşündüğünüz şeyleri bulun. Tam anlamıyla oyunun kurallarını değiştiriyor.

Ürün yönetimi ve mühendislik neden örtüşmeye başlıyor?

Yakında çoğu özellik mühendisi, ürün yöneticileri gibi düşünmeye ve kararlar almaya zorlanacak; ürün yöneticilerinin de makine öğrenimi, sinir ağları, LLM'ler ve çeşitli mimariler hakkında, LLM kullanan bir mühendis olmadan ona mümkün olduğunca yaklaşabilmelerini sağlayacak kadar bilgi edinmeleri gerekecek. Bu dönüşüm, geleneksel rolleri yeniden şekillendiren yapay zekâ entegrasyonuna yönelik cesur yaklaşımları yansıtıyor.

Açıkçası bunun geçerli olmayacağı pek çok istisna ve alan var, ancak genel olarak bir şirketteki satıştan pazarlamaya, üründen mühendisliğe kadar tüm önceki rollerin Venn şeması kaçınılmaz olarak birbirine yaklaşacak ve beceriler açısından belirli bir role özel kalan çok az şey olacak.

Yapay zekâ ürün çalışmalarını yeniden şekillendirirken kaçınılmaz varoluşsal krizden nasıl kaçınılır?

İşte tavsiyem: Bu teknoloji çağı gelişmeye devam ederken yaşamanızın kaçınılmaz görünebileceği varoluşsal krizden kaçınmaya çalışın.

Bunun yerine, deneyim yoluyla geliştirdiğiniz zihinsel becerilerinize odaklanın. LLM'ler içerik üretebilir, ancak iyi bir zevke sahip olma konusunda gerçekten berbattırlar.

Artık cevaplar çok kolay bulunuyor; dolayısıyla yapay zekâya özgün ve deneyime dayalı sorular sormak başlı başına bir beceri. Dahası, zihninizde sorulacak doğru soruyu keşfetmek gerçek entelektüel çalışmadır.

Takip edin

Cole, PM'ler için mümkün olanları zorlamaya devam ederken onu X'te ve kişisel web sitesinde takip edebilirsiniz. Ayrıca Probably.dev'e de göz atın!

The Digital Project Manager'da daha fazla uzman röportajı sizleri bekliyor!