brick by brick'e hoş geldiniz!

Yirmi altıncı sayıdan selamlar!

Yılı yarıladık... now let that sink in...

1 Ocak'ta koyduğun yeni yıl hedeflerini yepisyeni ajandanın arkasındaki boş sayfalara yazdığından beri 6 ay geçti. Yıllık gym üyeliğine verdiğin parayla şuan neler yapabilirdin düşündün mü? Ortamlarda sorulunca "okudum tabii ya" dediğin DEVASA Dostoyevski kitabını bu yıl gerçekten okuduğun yıl oldu mu? Peki öğrenmek istediğin o yeni dil... Duolingo baykuşu seni hâlâ umutla mı bekliyor? brick by brick yazarı böyle sinirimize dokunmayı nereden öğrendi?
​
Merak etme, hesap sormaya gelmedik.
​
Sadece küçük bir hatırlatma yapmaya geldik: Yılın diğer yarısı hâlâ önünde.

Hazır takvimi açmışken bir de 1 Ekim tarihine git. Çünkü bugünden tam 3 ay sonra Alive Bakü'de olacağız. 🇦🇿

Ürün, tasarım ve AI dünyasından insanlarla ekiplerin nasıl değiştiğini, rollerin nasıl evrildiğini ve AI'ın gerçekten workflow'un neresine oturduğunu konuşacağız.

Yeni bir şehir. Yeni bir ekosistem.

Ama değişmeyen tek şey yine aynı merak: Daha iyi ürünler nasıl inşa edilir? Ekipler nasıl evrilir? AI gerçekten iş yapış şeklimizi nasıl değiştiriyor?

Bugünkü bülteni de tam bu ruhla açıyoruz.

Çünkü iyi bir ürün inşa etmenin yolu bazen en temel soruya geri dönmekten geçiyor: Gerçekten product-market fit'e ulaştınız mı? Ve bu soru düşündüğünüz kadar önemli mi?

İlk yazımız da tam olarak bunun üzerine.

Product Market Fit

Çoğu ekip bu soruyu bir bitiş çizgisi sanıyor. Halbuki PMF bir kapı değil, bir tablo.

Ürün ekiplerinin en sevdiği cümlelerden biri: "Sanırım PMF'e ulaştık."

Kulağa güzel geliyor. Ama çoğu zaman bu cümle bir şeyi ölçmüyor, bir hissi anlatıyor.

Durumun pek iç açıcı olmadığını bir rakamla anlatalım. First Round Capital'ın yüzlerce startup üzerinde yaptığı çalışmaya göre girişimlerin yaklaşık %60'ı PMF yolculuğunda ikinci seviyeyi hiç geçemiyor. Yani "PMF'e ulaştık" diyenlerin çoğu aslında yolun ortasında duruyor. 📊

Peki neden? Çünkü yanlış soruyu soruyoruz.

Tek boyut değil, üç boyut

PMF'i tek bir "evet/hayır" sanıyoruz. Halbuki First Round'dan Todd Jackson'ın çerçevesi (şurada) PMF'i üç ayrı boyuta ayırıyor:

Talep: İsteniyor mu? Pazardan çekiş var mı, kullanıcının gerçekten ihtiyacı var mı? 📈

Memnuniyet: Seviliyor mu? Çözüm işi çözüyor mu, kullanıcı geri geliyor mu? 💚

Verimlilik: Sürdürülebilir mi? Müşteriyi ne kadara alıp ne kadar tutuyoruz, ölçeklenebilir mi? ⚙️

Üçü de birbirine bağlı. Talep yoksa memnuniyeti ölçemezsin. Memnuniyet yoksa verimliliği büyütmenin anlamı yok.

Bir de şu var: üçüne aynı anda, ilk günden bakmıyorsun. Jackson'ın çerçevesinde her seviyenin bir odağı var. Başta memnuniyet — bir avuç müşteri ürünü gerçekten "bırakamıyor mu"? Sonra talep — bunu tekrarlanabilir bir kanaldan büyütebiliyor musun? Verimlilik en sona kalıyor. Yani "verimliliğimiz zayıf" her zaman kötü haber değil; hangi seviyede olduğuna bağlı. Erken aşamada bilerek verimsiz olabilirsin. Ama onu sonsuza kadar erteleyemezsin.

1 dolara 100 dolar veren otomat

Todd Jackson'ın bir örneği var, bayıldım. San Francisco'nun ortasına bir otomat koyuyorsun: 1 dolar atınca 100 dolar veriyor.

Talep tavan, önünde kuyruk. Memnuniyet tavan, herkes bayram ediyor. Ama verimlilik? Sıfır. Ortada iş yok, sadece para yakan bir makine var.

WeWork ve Casper'ı hatırlayın. Talep vardı, memnuniyet vardı. Verimlilik hiç oturmadı, hikaye de öyle bitti. (Adam haklı beyler — biz verimliliği "nasılsa zamanla gelir" diye görmezden geliyoruz.) 😬

Şimdi asıl mesele

Rakamları ve örnekleri gördük ama asıl atladığımız kısım burada başlıyor.

PMF ürünün tamamı için tek bir skor değil.

Ürününü tek bir kitle kullanmıyor. Farklı segmentler var ve her birinin PMF'i başka. Birinde talep güçlü, memnuniyet yüksek, verimlilik oturmuş. Diğerinde daha yeni emekliyorsun.

Somut olsun: diyelim bir SaaS ürününüz var. KOBİ'ler bayılıyor, kendiliğinden geliyor, ucuza alıyorsunuz — orada üç boyut da yeşil. Kurumsal tarafta ise talep var, ilgi var, ama satış döngüsü aylar sürüyor, entegrasyon bitmiyor, bir müşteriyi kazanmak servete mal oluyor. Aynı ürün, iki bambaşka PMF.

"Ürünümüzün PMF'i var" dediğinde işte bu ikisinin ortalamasını alıyorsun. Ve ortalama yalancıdır.

Şu meşhur şaka gibi: kafası fırında, ayakları buzdolabında olan adamın ortalaması gayet konforlu. 🥵🧊 Bir segmentteki güçlü fit, zayıf üç segmenti rahatça örter. Rakamların iyi görünür — ta ki o tek segment doyana kadar.

Doğrusu şu:

Toplam PMF = Segment 1 PMF + Segment 2 PMF + Segment 3 PMF + …

Yani PMF bir kapı değil, bir tablo. Her hücreyi doldurmadan "geçtik" diyemezsin.

"Ama her şeyi segmente bölersek…"

Burada haklı bir itiraz var: her şeyi sonsuza kadar segmentlere bölersen, elinde her biri "özel" olan yüz tane mikro-pazar kalır ve hiçbirine odaklanamazsın. Doğru.

Mesele ürünü atomlarına ayırmak değil. Mesele, kararlarınızı etkileyecek kadar anlamlı, birbirinden gerçekten farklı davranan segmentleri görmek. İki değil, yirmi değil — genelde üç-dört tanesi işi anlatır. Amaç daha çok kutucuk değil; ortalamanın sakladığı gerçeği görmek.

Peki ne yapmalı?

Bir dahaki PMF toplantısında formülü değiştirin:

• Yapmayın: "PMF'imiz var mı?" diye ürünün geneline sormayın. Ortalama sizi kandırır.
• Yapın: Anlamlı segmentlerinizi tek tek yazın, her biri için talep–memnuniyet–verimlilik üçlüsünü Güçlü / Orta / Zayıf diye skorlayın.
• Yaklaşın: Çıkan haritaya dürüstçe bakın. Nerede gerçek bir fit var, nerede kendinizi kandırıyorsunuz — göreceksiniz.

Talep güçlü ama verimlilik zayıfsa iş modelinde bir problem var. Memnuniyet zayıfsa büyütmeden önce ürüne dönmek lazım. Harita size ne büyüteceğinizi de, neyi bırakacağınızı da söylüyor.

Cevaplar muhtemelen sizi biraz rahatsız edecek. Ama en işe yarayan cevaplar da onlardır. PMF tek bir "evet" değil; segment segment kazanılan bir şey. Kolay gelsin. 🧱

Gerçek PMF, bir varış noktası değil.

Çünkü kullanıcı değişiyor, pazar değişiyor, rakip değişiyor.

Ürün de bunlarla birlikte değişebiliyorsa ayakta kalıyor.

Peki bunu sistematik olarak nasıl yapıyoruz?

Sıradaki yazıda son dönemde sıkça konuşulan bir yaklaşımı inceliyoruz: Loop Engineering.

Loop Engineering

Geçtiğimiz ay gündemi tararken aynı örüntü inatla önümüze düştü. Anatoli Kopadze'nin 12 milyon kez görüntülenen bir yazısı vardı — ve tam da bizim aylardır mırıldandığımız şeyi söylüyordu: çoğumuz AI'ı yıllardır elimizde tutuyoruz ama hâlâ en yavaş viteste kullanıyoruz.

Bir şey yaz, bekle, düzelt, tekrar sor. Her adım senden geçiyor. Sen durduğun an, AI da duruyor. Yani asıl bottleneck AI değil — sensin. (Kötü haber, biliyoruz.)

İşte tam burada bir kırılma var. Ve adı da konmuş: loop engineering.

"Loop" ne demek, neden herkes aynı anda konuşuyor?

Basitçe: loop, kendi kendini tetikleyen bir prompt. Sen AI'ya tek tek talimat vermiyorsun — bir hedef tanımlıyorsun, o deniyor, sonucu kontrol ediyor, düzeltiyor, tekrar deniyor. Sen uyurken bile. (Evet, sabah kalkıp "bunu ben mi yaptım" dediğin o iş.)

Cobus Greyling'in konuyu toparladığı repo'da tanım çok net: loop engineering, agent'ı prompt'layan kişi olmaktan çıkıp, o işi yapan sistemi tasarlamak demek. Yani artık kürek çekmiyorsun; kürek çeken makineyi kuruyorsun. (Terfi gibi bir şey. Maaşa yansıması ayrı mesele.)

Bunu havadan söylemiyoruz. Claude Code'un yaratıcısı Boris Cherny geçen ay şöyle dedi: "Loop'lar, agent'lardan bir sonraki adıma geçiş — kaynak koddan agent'lara geçmek kadar büyük bir sıçrama." Kendi ifadesiyle, artık Claude'u o prompt'lamıyor; kurduğu loop'lar prompt'luyor. Ortalama bir günde kodunun üçte birini kendisi değil, loop'ları yazıyor. (Kalan üçte ikiyi de yazsın bari.)

Bir tarafta Anthropic'in Opus 4.8'e eklediği Dynamic Workflow var — Claude bir orkestrasyon script'i yazıyor, sub-agent'ları deploy ediyor, çıktılarını doğruluyor, sonucu sunuyor. Diğer tarafta aynı hafta çıkan onlarca araç. Aynı dil, aynı anda. Tesadüf değil.

Ve şunu görüyoruz: iyi prompt yazmakla iyi loop kurmak aynı kas değil. (Prompt yazmayı daha yeni oturttuk derken kurallar değişti — evet, biraz sinir bozucu :))

Peki bu iş pratikte nasıl işliyor?

En sevdiğimiz çerçeveyi Lenny's Podcast'ten Claire koydu: bir loop'u, birini işe alır gibi düşün. Neyi kontrol edecek, ne sıklıkta, hangi çıktıyı istiyorsun, bir şey ters giderse kime haber verecek? "Her cuma 10.00'da tüm merge edilen PR'ları incele ve eksik kalan becerileri çıkar" — bu bir iş tanımı. Aynı zamanda bir loop. (Üstelik izin de istemiyor.)

İşin güzel yanı: başlamak için kod bile gerekmiyor. Claude Cowork'te her sabah takvimini ve mailini kontrol edip sana özet geçen bir scheduled task — o zaten çalışan bir loop. Gerisi bunu büyütmek.

Bunun ciddi hali de var. Mozilla'dan Brian Grinstead, bir ayda Firefox'a 423 güvenlik düzeltmesi göndermiş. Sırrı daha iyi bir model değil, modelin etrafına kurdukları harness (aracı çevreleyen kontrol katmanı) olmuş: dosyaları riskine göre puanlayan bir LLM hakem, hedef odaklı loop'lar, hataları doğrulayan sub-agent'lar ve döngüde kalan bir insan gözü. Agent yorulmuyor — bir bug'ı tetiklemek için 14 kez deniyor, insanın çoktan "boş ver ya" dediği yerde o hâlâ deniyor.

Momentumun gerçek olduğunu gösteren sinyaller de bunu doğruluyor. Microsoft "her zaman açık" kişisel agent Scout'u tanıttı. Higgsfield, pazarlamayı uçtan uca yürüten, her run'dan öğrenen bir agent playbook'u paylaştı. "2026 agent'ların yılı" lafı — her yıl bir şeyin yılı ilan edilir ya, bu sefer boş bir slogan gibi durmuyor.

Ama loop bedava değil — ve asıl mesele burada başlıyor

Şüpheci tarafı atlamayalım, çünkü haklılar. Loop çalıştırmak, token-zengini bir yerden bakınca çok kolay görünüyor. Goldman Sachs'ın modeline göre agentic token tüketimi dört yılda 24 katına çıkacak. Sınırsız bütçeyle "döngüyü çalıştır" demek başka; ay sonu bütçesi kısıtlı bir yerden aynı tavsiye neredeyse imkânsız. (Loop uyurken çalışıyor, token faturası da uyumuyor.)

Cobus'un repo'sundaki uyarılar da tam bu noktada: sub-agent'lar ve uzun loop'larla token maliyeti patlayabilir. Doğrulama hâlâ sende — gözetimsiz loop, gözetimsiz hata üretir. Ve bir "comprehension debt" birikiyor: loop'un ne gönderdiğini okumazsan, sistemi anladığını sanıp aslında yavaş yavaş kaybediyorsun.

Addy Osmani bunu güzel özetlemiş: loop'u kur, ama "başlat"a basıp çekilen kişi gibi değil, mühendis olarak kalacakmış gibi kur.

Bize göre doğru bakış da bu. Loop'un gerçek bir yeri var — hızlı bir PoC çıkarmak, bir bug sistematik mi diye anlamak, prototipi hızlandırmak. Ama sihir değil. Ölçmeden, okumadan, "başlat"a basıp tatile gitmek — orası tuzak.

Brick tarafında biz nasıl bakıyoruz?

Aslında bu bir öğrenme meselesi. Ve iyi haber şu: bilgi bedava. Stanford, Anthropic'in yüksek maaşla aradığı LLM mimarisini 1 saatlik ücretsiz bir derste anlattı. Loop engineering repo'su açık. Agentic design pattern'leri, ücretsiz müfredatlar ortalıkta. (Bilgi bedava, token değil — dengesi bu.)

Ama bilgi ≠ beceri. Bir loop'u okumak başka, kendi işine oturan bir loop kurup token'ını, çıktısını, nerede insan müdahalesi gerektiğini görmek başka. Bu tuğla tuğla, yaparak öğrenilir.

AI konusunda tavrımız değişmedi: ne hype ne ret. Deneyeceksin, ölçeceksin, sana uyuyor mu göreceksin. Biz de tam burada duruyoruz — deneyerek, üreterek, sonuçları paylaşarak.

Kısa..Kısa..Jr

Aynı haftalarda radarımıza takılan, ana konuya girmeyen ama not düşmeye değer birkaç şey:

dbt MCP'ye OAuth geldi (beta). Artık ekibin Claude, ChatGPT ya da OAuth destekli herhangi bir aracı, mevcut kimlik ve izinlerle dbt'ye bağlayabiliyor. Küçük gibi duran ama "agent'lar gerçek araçlarımıza güvenli erişsin" tarafında önemli bir tuğla. 👌 (kaynak)​

Google, DiffusionGemma'yı açtı. Metni token token değil, bloklar halinde üreten deneysel açık bir model — text diffusion tarafı hızlanıyor. İzlemekte fayda var. (kaynak)​

Anthropic'in KOBİ'lere yönelik 31 hazır Claude Skill paketi 24 saatte 382 bin indirme aldı. Finanstan İK'ya, satıştan pazarlamaya hazır workflow'lar. "Yaparak öğren" için düşük eşikli bir başlangıç noktası. 🧱 (kaynak)​

Loop'ları bu sayıda kavram olarak açtık. Bir sonraki adım, kendi işimizden gerçek bir loop kurup — token'ıyla, hatasıyla, işe yarayanıyla — sana anlatmak. Onu da yakında paylaşacağız.

AI tarafında ne yapıp ne öğrendiğimizi hep birlikte deneyerek görüyoruz. Sen de bu döngüye girmek istersen, AI eğitimlerimize göz atabilirsin.

Sevgiyle kalın! 🧱

Kısa Kısa...

AI

Figma yok, Jira yok, döküman yok — yine de 10 haftada ürün çıktı: Gusto'nun CTO'su Eddie Kim, 5 kişilik bir ekiple yepyeni bir AI ürün hattını 10 haftada çıkardıklarını anlatıyor. Üstelik Figma, Jira ve döküman olmadan — sadece Claude Code ve sürekli açık bir Zoom odasıyla. Lenny'nin bu söyleşisi "araç mı, iletişim mi" sorusunu yeniden açıyor; builder ekipler için okuması şart. 🧱

AI üç yıldır çözülemeyen bir araştırmayı çözdü: İmmünolog Derya Unutmaz, T hücreleriyle ilgili 3 yıldır takıldığı bir bilmeceyi GPT-5 Pro ile çözmüş. Kanser ve otoimmün hastalık tedavisine kapı aralayabilecek bir an. OpenAI'ın paylaştığı bu hikaye "AI gerçekten ne işe yarıyor" sorusuna slogan değil, somut bir cevap veriyor. 💡

AI verimliliği en çok kimin işine yarıyor? Üç yıllık verinin ardından net bir cevap çıkıyor: AI, en çok zaten zorlanan ya da işini kaybetme riski olan kişilerin performansını yukarı çekiyor. AI Weekly'nin bu sayısı hype'a kapılmadan dürüst bir tablo çiziyor — bizim AI'a bakışımıza da denk düşüyor. 🤔

AI'ı tavırla kullan, yoksa ürün sen olursun: Bu yazı, builder ve PM'ler için "critical AI literacy" üzerine bir çerçeve sunuyor. Microsoft ve MIT araştırmalarına dayanarak AI'a fazla yaslanmanın eleştirel düşünmeyi nasıl köreltiğini gösteriyor; dört fiillik bir modelle insan ajanlığını korumayı öneriyor. Karo Zieminski'nin yazısı tam da "deneyerek ama sorgulayarak" çizgimizde. 👌

Ürün Yönetimi

PM ekibi "vibe coding"i sahada test etti: Bir ürün ekibi, AI'la kod yazma araçlarını bir hackathon'da deneyip gerçek sınırlarını çıkarmış. Kod bilmeden AI ile yazılım kurmanın nerede çalıştığını, nerede duvara tosladığını dürüstçe anlatıyor. Product Breaks'in bu yazısı builder PM merak edenler için pratik bir saha notu. 🚀

Ürün liderleri yeniden "işin içine" giriyor: Üst düzey ürün liderleri sadece strateji ve yönetimle yetinmeyip tekrar IC işine dönüyor. Gympass dönüşümünün arkasındaki Joca Torres, AI'ın ürünü nasıl değiştirdiğini birinci elden anlamak için kendisinin de masaya geri oturduğunu anlatıyor. Bu yazı "lider = sadece yönlendiren" varsayımını sarsıyor. 🤔

Ürün liderlerinden AI ve PM'in geleceğine dair 5 not: Deneyimli ürün liderleri, AI'ın product management'ı nasıl dönüştürdüğünü kendi pratiklerinden anlatıyor. Aha!'nın derlediği bu yazı, "AI PM'i bitirecek mi" paniğine kapılmadan rolün nasıl evrildiğine sakin bir bakış sunuyor. 💡

Kullanıcıların kendisi builder'a dönüşünce ne olur? Google ve u.com'dan ürün lideri Saurabh Sharma ile bu söyleşi, enterprise AI çağında product management'ın nasıl değiştiğini konuşuyor: product primitive'ler, AI workflow'ları ve agent'ları yönetmek. Product Coalition'ın bu bölümü discovery'yi yeni baştan düşündürüyor. 🧱

Tasarım

Tasarım sisteminin yeni bir yazarı var — ve o bir agent: AI agent'lar artık design system'leri sadece okumuyor, doğrudan değiştiriyor. Figma'nın MCP server'ı ve Storybook 10.3 gibi araçlarla agent'lar bileşenleri kendi eliyle düzenliyor — üstelik insan review'undan daha hızlı. Bu yazı "AI tüketici değil, yazar oldu" diyor; design system tutan herkesin düşünmesi gereken bir kayma. 🤔

Claude'a kendini tekrar tekrar anlatmaktan kurtul: Yazar, Claude'un her oturumda hafızasını sıfırlaması sorununa basit bir çözüm getiriyor: "identity files" — Claude'un her yanıttan önce okuduğu birkaç markdown dosyası. Tercihlerini bir kere yazıyorsun, her sohbette baştan anlatmıyorsun. uxdesign.cc'deki bu yazı AI'la çalışan herkes için pratik bir hile. 👌

AI ürün tasarımının altı katmanı: Emily Campbell, AI deneyimini altı katmanda okuyor: arayüz, context, harness, model, governance ve emergence. Tezi net — tasarımcı artık sadece UI'da kalmamalı, deneyimi şekillendiren alttaki sistemleri ve kısıtları da tasarlamalı. Bu çerçeve UX'in AI çağında nereye genişlediğini düşünmek için iyi bir harita. 💡

Araca erişmek, ustalık değildir: Bu yazı, AI tasarım araçlarına erişmekle gerçek tasarım ustalığı arasındaki farkı ayırıyor. AI herkesi prototip üretebilir hale getiriyor; ama yargı, pattern tanıma ve bağlamı okuma hâlâ kıdemli tasarımcıyı değerli kılıyor. uxdesign.cc'deki bu yazı "polymath UX architect" tartışmasına iyi bir katkı. 🧱

Yaklaşan Brick Institute Eğitimleri

Bülteni bitirirken de biraz kendimizden bahsedelim. Bu ay yaklaşan eğitimlerimizi bir göz atmanız için şöyle özetliyoruz:

Sertifika Programları

Ürün Yönetimi Eğitimleri

15 Eylül - 1 Ekim - Yazılım Geçmişi Olmayanlar için Yazılım - Tech Lead & Product Engineer Mustafa Biçer ile yazılımın kapısını aralayın! "Yazılım dünyası bana çok uzak" diyenler için teknik ekiplerle konuşabilmenin, API'lerden database'lere jargonu çözmenin ve teknik kararların mantığını anlamanın sistematik yolu.

Tasarım Eğitimleri

15 Eylül - 8 Ekim - Baştan Sona Uygulamalı Figma Eğitimi - Digital Product Designer Ramazan Güler ile Figma'da ustalaşın! Sıfırdan ileri seviyeye, component'lerden auto-layout'a, prototype'lardan developer handoff'a kadar her şeyi pratikte öğreniyoruz.

15 Eylül - 8 Ekim - Yapay Zeka Destekli UX Araştırma Eğitimi - UX Researcher İlayda Sena Topçu ve Mustafa Terzioğlu ile AI ile araştırma süper gücü! Kullanıcı görüşmelerinden anket analizine, persona oluşturmadan insight çıkarmaya yapay zeka destekli UX araştırma yöntemlerini öğreniyoruz.

15 Eylül - 27 Ekim - Advanced UX Eğitimi - Senior UX Designer Burç Taluğ ile UX uzmanlığında bir sonraki seviye! Temel bilgilerin ötesine geçip karmaşık tasarım problemlerine ileri seviye çözümler üretmeyi, araştırma yöntemlerini derinlemesine uygulamayı öğreniyoruz.

22 Eylül - 8 Ekim - Yapay Zeka Destekli UI Eğitimi - Senior UI Designer Uğur Anlak ile AI ile piksellerin psikolojisini çözün! Renk teorisinden tipografiye, grid sistemlerinden animasyonlara kadar yapay zeka araçlarıyla desteklenerek kullanıcıların "vay be!" dedirten arayüzler tasarlamayı öğreniyoruz.

Ücretsiz Eğitimler

1 Temmuz - Perde Arkası AI: Agent Sistemleri Nasıl Optimize Edilir? - Data Scientist & AI/ML Developer Advocate Enes Fehmi Manan ile agent sistemlerinin kapağını açın! AI agent'larının nasıl çalıştığını, performanslarını nasıl optimize edeceğinizi ve verimli agent sistemleri kurmanın tekniklerini öğreniyoruz.

2 Temmuz - Brickstage: Build. Ship. Tell. #2 - AI Native Product Manager Altan Kurt ve Sr. Learning & Development Specialist Sertan Çevik ile sevilen etkinliğimizin ikincisi! Katılımcılar ürünlerini/projelerini sahneye taşıyıp hikayelerini anlatıyor, geri bildirim alıyor ve deneyimlerini paylaşıyoruz.

7 Temmuz - Tasarımın Politikası: Revize Krizleri ve Müşteri Yönetimi - Product Design Lead Arda Arıcan ile tasarımın görünmeyen tarafı! Sonu gelmeyen revize taleplerini yönetmeyi, zorlu müşteri ilişkilerinde sınır koymayı ve tasarım sürecinde politikayı lehinize çevirmeyi öğreniyoruz.

8 Temmuz - Yaşam Odaklı Tasarım: Kariyerini Bir Deneyim Olarak Tasarla - Experience Designer & Researcher Ece Kiray Gedik ile tasarım prensiplerini hayatınıza uygulayın! Kariyerinizi bir deneyim gibi tasarlamayı, yaşam odaklı yaklaşımla anlamlı ve tatmin edici bir profesyonel yolculuk inşa etmeyi keşfediyoruz.

​
Sektörün en deneyimli isimleriyle, teoriden sıkılmadan pratik odaklı öğrenme garantisi!

👋 Tasarım, ürün ve AI dünyasında gelişme bitmez. Ancak bu haftalık bizden bu kadar diyelim! İki hafta sonra yeni sayıyla gelene kadar okuyun, paylaşın ve kendinize iyi bakın!