Marty Cagan on the future of Product Management - ProductTank Sydney
Mind the Product · 2025-09-29 · 1ч 45м · 3 639 просмотров · YouTube ↗
Топики: product-discovery-loop
🎧 Аудио
📝 Summary
model=deepseek-v4-flash · prompt=summary-v7 · 22 200→4 523 tokens · 2026-07-20 14:54:22
🎯 Главная суть
Роль продукт-менеджера проходит фундаментальную трансформацию: процессные роли (product owner, feature team PM) вытесняются, а на смену приходит «создатель продукта» — человек, отвечающий за бизнес-результаты и непрерывное продуктовое открытие. Компании всё активнее переходят от фичерных роадмапов к работе по outcomes, а новые AI-инструменты радикально удешевляют прототипирование и ускоряют discovery. Ключевой навык — не управление беклогом, а умение разбираться в сложных рисках (ценность, юзабилити, реализуемость, жизнеспособность) и получать доказательства до начала разработки.
Кризис традиционных PM-ролей и восход «создателя продукта»
Исторически сложились три типа PM. Первый — product owner, чья работа сводится к ведению беклога и спринтов. Это чисто процессная роль, и она становится всё менее востребованной: Scrum, Kanban, XP — это инструменты доставки, а не создания ценности. В Европе product owner’ы уже теряют работу, и Cagan рекомендует им как можно быстрее повышать квалификацию. Второй тип — feature team product manager, который получает готовый roadmap сверху и просто следит за реализацией. По сути это проектный менеджер, а не настоящий PM. Третий тип — настоящий product creator (или empowered product manager), который сам отвечает за открытие и поставку решения, приносящего измеримый бизнес-результат. Именно у таких специалистов зарплаты растут, а рынок охотно их нанимает.
Почему outcomes важнее output: 85% фич не работают
Harvard Business Review опубликовала данные Microsoft: 85% элементов любого roadmap не приносят бизнес-ценности. Только 15% создают реальный возврат. Компании десятилетиями строили по feature-based планам и наконец осознали, что нужно ориентироваться на outcomes. Разница между feature team и empowered team в том, что первая может взять обязательства только по output (выпустить функцию), а вторая — по outcome (решить проблему клиента или бизнеса). Чтобы брать на себя такие обязательства, нужно ещё до разработки получить доказательства, что решение сработает. Как говорит коллега Кэгана Кристиан: «Каждый занимается product discovery — либо до того, как построил, либо после». Большинство компаний делают это после, когда уже потратили ресурсы.
Как начать менять подход снизу, даже без поддержки топ-менеджмента
Даже в feature team можно сделать первый шаг — начать измерять impact того, что уже выпущено. Пример: e-commerce компания внедрила Apple Pay, а PM не знал, повлияло ли это на конверсию оформления заказа. Простейшая проверка — посмотреть данные по abandon rate. Получив цифры, можно инициировать разговор с руководством: «это сработало, давайте пробовать ещё». Другой приём — предложить провести эксперимент: на одной команде попробовать достичь конкретного business outcome, не меняя всю компанию. Руководство редко отказывает, если это представлено как пилот. Самое мощное — использовать prototyping (инструменты типа Lovable) и show, not tell: создать прототип решения, протестировать его на пользователях и стейкхолдерах, а затем показать лидеру. Часто лидер, который до этого говорил «нет», меняет мнение, видя рабочий прототип.
Проблема лидерства: не micromanagement и не under-management
«Каждая продуктовая проблема — это проблема продуктового лидерства», — цитирует Cagan Шриаша Доши. Многие компании либо микроменеджерят (диктуют, что строить), либо наоборот — полностью делегируют без всякого направления (under-management). Empowered teams не требуют меньшего лидерства — они требуют лучшего. Две главные обязанности лидера: 1) развивать людей в craft — учить их настоящему product management, дизайну, engineering. Если сам менеджер не умеет, можно нанять продуктового leadership-коуча. 2) Предоставлять стратегический контекст: product vision, product strategy, team topology. Когда команда понимает, как её часть вписывается в целое, она принимает сотни правильных решений в неделю, не мешая другим.
Продуктовое открытие в эпоху AI: четыре типа прототипов
Discovery всегда строится вокруг прототипирования четырёх рисков: ценности (value), юзабилити (usability), реализуемости (feasibility) и жизнеспособности (viability). Раньше «живые» data-прототипы были самыми дорогими и требовали времени разработчиков. Теперь, с появлением Lovable, Bolt и других AI-инструментов, их можно создать за часы вообще без участия разработчика. Это кардинально меняет экономику discovery. Однако Cagan подчёркивает: прототипы для discovery и production code для delivery — разные вещи. Инструменты вроде Lovable хороши для быстрых прототипов, но English-запросы не позволяют задать недвусмысленно сотни и тысячи use cases. Для серьёзных продуктов (как Jira с десятками тысяч кейсов) нужны senior-инженеры и инструменты вроде Cursor / Claude Code, где инженер управляет десятками агентов. Оба класса инструментов будут улучшаться, но останутся разными.
AI-инструменты и AI-продукты: два разных мира
Важно различать: AI-помощники для создания любых продуктов (Lovable, Cursor) и продукты, которые сами являются AI (probabilistic, недетерминированные). Для последних есть особые сложности: acceptance testing для вероятностных продуктов называется eval и требует постоянного мониторинга, чтобы система не делала опасных или неверных вещей. Пример: Waymo — один из самых сложных интеллектуальных продуктов, с 10 млн миль автоматических тестов и удалённым человеческим контролем в нестандартных ситуациях. Cagan советует всем, кто может, покататься на Waymo — это расширяет сознание product person. Для AI-продуктов непрерывное улучшение — не опция, а необходимость.
Два пути: не путать AI product manager с «обычным» PM
Сейчас много говорят о новых нишевых PM-ролях (growth PM, AI PM). Cagan считает, что AI product manager — это временная метка, как когда-то «mobile product manager». Через несколько лет AI станет неотъемлемой частью любого продукта, и отдельная специализация исчезнет. А вот продуктов, которые целиком основаны на AI (probabilistic), будет меньше, но они требуют специфических навыков, особенно в eval. Совместно с Марили Никой он написал статью «AI Product Management», где разобраны эти отличия.
Команды будущего: меньше инженеров, больше scope на команду
С внедрением AI-инструментов средний размер продуктовой команды сокращается. Если раньше было PM + tech lead + 5 инженеров, то скоро будет 3–4 инженера. Однако Cagan не верит, что один «triple threat» (PM, умеющий и дизайн, и код) заменит всю команду — такие уникумы крайне редки. Лучший вариант — как минимум два человека: product manager (понимание бизнеса, данных, клиентов) и senior engineer / tech lead. Дизайнер остаётся важным для продуктов, где UX критичен, но всё чаще дизайн может обеспечиваться хорошей дизайн-системой. Ещё более значимый тренд — изменение team topology: scope одной команды расширится. Вместо 100 маленьких squads, каждая отвечающих за микроскопический кусочек продукта, появится ~20 команд с end-to-end ответственностью за целые потоки. Это даст командам больше автономии и impact.
Пример Palantir: как строится настоящая product-компания на B2B
Palantir поставляет продукты для сложных сред — военных, разведки, здравоохранения. Они не берут заказы от клиента («постройте нам то-то»), а сами определяют решение, которое приведёт к нужному outcome. Для этого они отправляют «forward deployed engineers» (FDE) к клиенту на месяцы, чтобы изучить пользователей, данные, ограничения и стейкхолдеров. Они прототипируют, опираясь на внутреннюю платформу, а платформенная команда затем абстрагирует лучшие решения, усиливая саму платформу. Результат: Palantir стоит $400 млрд, тогда как Accenture (работающая как feature team) — $150 млрд. Разница в том, что Palantir глубоко знает клиента и его среду, что создаёт «moat» гораздо более сильный, чем копирование фич.
Аналогии с Нью-Йорком и состояние продуктового комьюнити в Сиднее
Многие в Австралии чувствуют, что отстают от Кремниевой долины. Cagan уверяет: это заблуждение. Везде есть смесь продуктово-зрелых компаний (Atlassian, Canva) и отстающих (особенно банки). Похожая ситуация была в Нью-Йорке, где главным работодателем были банки, которые «золотыми наручниками» удерживали таланты. После финансового кризиса многие инженеры и PM ушли из банков, основали стартапы или пошли в Etsy, и сейчас Нью-Йорк не уступает Сан-Франциско. В Сиднеye есть аналогичный потенциал: много талантливых людей сидят в банках, но при правильном триггере они могут перейти в продуктовые компании, что поднимет всю экосистему.
Как стать «создателем продукта»: практические советы
Тратить не менее 4 часов в день на «creator-активности»: прототипирование, тестирование прототипов с пользователями, покупателями, стейкхолдерами, инженерами. Прорабатывать все четыре риска: value, usability, feasibility, viability. Ключевая ошибка — делегировать мышление AI-инструментам (ChatGPT). Нужно использовать их как thought partners, а не как замену собственному анализу. Пример Терезы Торрес: лёжа с травмой, она освоила создание AI-продукта, но делала это с высочайшей agency — не доверяла слепо выхлопу, а разбиралась в каждом слое.
Различие между PM и дизайнером при использовании AI-прототипов
Раньше прототипы создавали дизайнеры (в Figma) или инженеры (в коде). Теперь любой член команды может создать прототип с помощью Lovable. Ключевой сдвиг: навык не в создании, а в оценке прототипа. Хороший дизайнер определит, что пользовательский опыт плох; хороший product manager оценит compliance, go-to-market, business viability; хороший инженер поймёт trade-offs между точностью, скоростью и стоимостью (особенно критично для AI-продуктов). Поэтому прототипом может сделать любой, а вот качественно его протестировать — только профессионалы.
Сложности AI-продуктов: eval, continuous improvement, cost
В обычных детерминированных продуктах acceptance testing — одноразовое действие: проверили, и если не меняется код, результат стабилен. Для вероятностных продуктов это не работает: модель может сегодня отвечать хорошо, завтра — плохо из-за изменения данных или дрейфа. Нужна система eval, которая постоянно контролирует guardrails. Кроме того, стоимость вычислений (inference) может быть огромной, поэтому инженер играет ключевую роль в поиске баланса «accuracy / speed / cost». Cagan подчёркивает: AI-продукты сложнее, а не проще.
Как меняются требования к лидерам: от директив к стратегическому контексту
Многие лидеры говорят «вы теперь empowered», но это пустой звук. Нужно дать команде цель (outcome) и чёткое видение того, как их работа вписывается в стратегию компании. В противном случае команда либо теряется на огромном холсте, либо скатывается в under-management. Cagan советует: если лидер сам не может сформулировать product vision, используйте аналогии — например, Spotify. Никто не говорит, что любит Spotify из-за музыки (она везде одинаковая), все говорят о рекомендациях, плейлистах, кросс-девайсности. То же в банке: клиенты любят не «банковский счёт», а цифровой опыт. Покажите прототип нового опыта — и лидеры начнут понимать.
Советы начинающим PM: agency, работа, где можно, и наставник
Текущий рынок — сложный. Лучший путь — начать в своей текущей компании (если есть работа): заслужить доверие, затем попросить попробовать себя в продуктовой роли. Если вы новичок — искать internship или волонтёрскую позицию в хорошей компании, ориентируясь не на название продукта, а на лидера, у которого можно учиться. Cagan рекомендует стартовать в стартапе — там объём обучения колоссален. Ключевое качество — agency: не ждать идеальных условий, а брать на себя ответственность за конкретный outcome, даже в хаотичной среде. Пример Мальты: он попал в eBay Germany, когда нужно было запустить PayPal с нуля, и просто начал делать то, что нужно — «make it work». Это и есть путь.
Двойной трек: IC vs Leadership
Необязательно становиться менеджером, чтобы расти. Многие компании (Stripe, Google) предлагают dual career track — principal product manager, который остаётся индивидуальным contributor и решает самые сложные продуктовые проблемы. Если же вы идёте в лидерство, ваш продукт — это люди, а не сам софт. Нужно отдавать себе отчёт: инновации исходят от команд, а не от лидеров. Лидеры создают контекст и развивают людей.
Ответы на вопросы аудитории: копирование, моральные границы, этика AI
- Копирование фич: допустимо, если есть доказательства, что фича нужна, а не просто потому, что есть у конкурента. Слепое копирование (feature parity) ведёт к плохому продукту и наследству чужих ошибок.
- Product owner vs настоящий PM: Cagan прямо говорит — future не за product owner’ами, они должны upskill. Иначе их роль исчезнет.
- Ответственность PM за этику AI: этика — часть viability risk. Если вы первым замечаете этическую проблему, ваша задача — зафиксировать риск, поднять его до менеджера и предложить альтернативу. Не стоит идти с этим напрямую к CEO; лучше эскалировать своему руководителю. Если компания системно игнорирует этику — уходите.
- Совет молодой аудитории: не нужно «опыта в PM» — компании нанимают людей с высоким IQ, EQ, любопытством, технической грамотностью и ориентацией на клиента. Демонстрируйте эти качества в любом текущем проекте.
📜 Transcript
en · 17 126 слов · 231 сегментов · clean
Показать текст транскрипта
Thank you, guys. We won't talk much about things outside of products, because we think the product topic is more important. But yes, we met a long time ago, and that was fun at eBay, and we've stayed in touch since. We thought we'd just use the time and really jump right in. and have an in-depth conversation on a few topics that will probably be on your mind and we'll later on open up for questions so there'll be kind of some microphones we'll be throwing around and you know we'll want to talk about everything product today so I thought we may start with kind of how you feel the role of the product manager is really evolving what it is like kind of to be a product manager today and what you would tell people great and thanks for everybody to came and also Atlassian actually went way out of their way to make room. This is more people than they normally handle in this room. And so that was much appreciated. Yeah, what a wild time, really, for product. It's actually not a short answer even to that question. And I want to be careful because nothing, I don't want anybody to think what I'm about to talk about is like only in Australia, only in Sydney. It's really the same dynamics going on all over the world on this. As you know, it's these these trends are hitting everywhere. There are some cultural differences and hopefully we'll have a chance to talk about those. So I do think there's there's also there's always been something a little bit special about Sydney we should talk about. There's some very important similarities to New York City, actually, in terms of the product community site. that would be good to talk about too but in terms of in general you know we've kind of always had these three kinds of product manager types loosely speaking product managers we have a lot of product owners out there these are mostly people um and i i mean that sort of by the strict definition the way a pspo or a cspo class would define a product owner uh we're in atlassian these are people spend a lot of their day in JIRA, managing a backlog, they that is the heart of the job. That's a process role. So that is a role. Honestly, agile, scrum, Kanban, XP, these are delivery processes. As you might imagine, if you've been following the news, those are becoming a whole lot less relevant. So product owners um i have hundreds of friends that are product owners and i've been encouraging all of them to upskill as fast as they possibly can so i don't want to mislead anybody i am genuinely nervous about that role um i don't have a lot of i'm not gonna shed any tears about that role going away but i do have a lot of uh you know empathy for my friends that have to they're going to have they are having already, especially in Europe, their, their careers disrupted. So that's a big change. I think that's a big change. And of course, it doesn't hit it once. It's not like something tomorrow, but you want to get on the right side of that train. The second kind of product managers sort of always been out there is doesn't really have a great name. They're, they're usually called product manager, as opposed to product owner. But they're what we call feature team product managers. These are people who and these are very, very common, all over the world, a lot of them right here, because there's a lot of banks here, a lot of banks have these where it's very top down culturally. And you know, you have these very highly paid people that decide what goes on a roadmap, and it eventually trickles down. to a product team, and you have somebody called a product manager has to figure out what this thing is and get it on, get it designed, get it ready for sprint planning, get it built and get it out. It's actually is still important work, just like the product owner is often doing important work. But it's, it's, it's really not product management, it's much more project management. I don't mean that in a derogatory way. I'm just saying, if you know who gets to define what product management is anyway, I don't know. It's like there's all these definitions out there in the world. The Silicon Valley definition has been pretty clear that the product manager is not a project manager, they're a creator. And so the third kind of product manager and this is the one that is having a blast right now. This is the one, honestly, you could see their average salaries are going up while the other ones are losing their jobs. So because we have kind of a gold rush going on with, and I don't just mean around Gen AI, because there's AI products, which of course is a wild time right now. more generally we have pt every team even if you're building conventional products which is still more than 90 of them i don't know the actual number but i'd be shocked if it was you know more than 10 are actually ai products it's probably closer to one or two percent are ai products but if you're building any product including conventional deterministic products you're gonna be using ai tools and the What does that really mean? It means figuring out what to build, that figuring out the solution. And that's the role, that's the definition of product management that companies have realized it's everything. I don't know if you remember, but a couple of years ago, there was a lot of noise about, oh, are product managers even necessary? And that's because so many CEOs looked and saw these project managers and product owners and said, this is ridiculous. You can literally listen to CEOs saying, oh, we're increasing our percentage of product managers because we actually need a much higher percentage of product managers because the company is all about how fast we can discover a winning product. So that definition, I think the time has never been better. And I also would, I've always argued this, it's way more fun job, way more satisfying job. to actually take responsibility for delivering a solution, a real outcome product. It's all about product discovery, which is all about prototyping and testing those prototypes and getting evidence. You've got something worth building. If that's what you want to do. It doesn't even matter if you call it product manager. There's a lot of great engineers that are doing this. There's a lot of great designers that are doing this. I started adopting the general, more general term, product creator, which really applies to any of these people that take responsibility for this. And you've been very consistent in this. In fact, the book Inspired, kind of from 17 years ago when it was first published, had the subtitle, How to Create Products That People Love. So I think that notion of creating being the essence of what a product job actually contains has been very consistent. Now the shift of now having the technology infrastructure actually become more modern and kind of therefore in better companies it being easier to release. kind of frequently to actually kind of understand what impact the changes that you're making have on the business, kind of measure the outcomes, has actually become easier. So I think people who adopt this mindset and want to kind of really latch on to being a product creator probably now have at a better time than ever, while their business leaders also recognizing that that's important for the company. I'm seeing that kind of throughout industries, even in banks. some that i do some work with and you know there certainly is the ambition to kind of up level the product leaders and the product managers kind of to be able to do this so um do you want to talk a bit more about that more recent kind of shifts what do you tell the product owner kind of what do you tell the project manager type in a feature team how to actually kind of evolve and how to change to to use this momentum to their benefit yeah well i think the dynamic what's really going on and this this started a long time ago but it takes decades is that companies have been doing these feature-based roadmaps forever and um most of them would admit to you that that they know that a lot of what they're building is not actually delivering the business results they would have there's very few that argue that the only question to them is like how bad is it really and is there anything better And several years ago now, Harvard Business Review published this story that argued that 85% in general, even from good companies, they were using Microsoft as the data point for this, 85% of items on the roadmap are not delivering the business value. And that's terrible by anybody's definition, right? 15% is actually generating a useful return. There has been this ongoing awareness of working that way is not so great. So then the question is, well, what we really need are outcomes. And of course, in a product company, really, outcomes are really all that matters. We don't really get points for just releasing features to our customers. We get points when we actually solve problems, either for our customers or for our company. And so. there has been a growing awareness that what really matters is outcomes and that's the driver because the fundamental difference between a pro whatever you want to call it we call them empowered team product manager and a feature team project manager is a feature team can sign up for output but uh product manager can sign up for outcomes. So I think that's the dynamic that's actually driving this. And if you're so if your goal is an outcome or a business result, then the game is about getting evidence that you can do that. Before you build it, I got my partner Christian, who you know, well, has a great quote, I'd never heard it until I heard him give a talk that that used it, which is that everyone does product discovery. You either do it before you build or after. And his point is they're doing it after, right? They find out that wasn't such a good idea, but by now the executives have changed their mind anyway and so moved on. I mean, that though is kind of actually one of the points I emphasize with people even in feature teams, that you may not be in the perfect environment and you may say, well, it's going to be difficult for me as a product owner to actually change this whole company. you still are usually in a position to kind of at least kind of look at the outcomes of whatever you just released. And you may have not done a whole lot of discovery beforehand, but look of whether what you just kind of put life to the side has had any impact. I was working with a company, e-commerce company, you know, not rocket science. Obviously, you want to optimize the checkout flow. And the product manager, product owner proudly said, we built in Apple Pay. I'm like, great. And then I go, what did it do? and the person didn't know. I was like, I mean, that's like a very, like, they obviously have the instrumentation and it's like everybody would understand, like you look at checkout kind of completion rates and abandon rates. So I think at a very minimum, kind of, you look at what it did and then you actually have something to talk about in the company where you, I think you can slowly start the mindset, like changing the mindset bottom up. because next thing kind of well your boss or kind of whoever is kind of the lead in the organization may want you to do more things that have an impact if you've just talked about the impact that that last thing that you did and then i think you can work upstream in situations where you don't maybe have the top-down support so i do think there's things people can do you can one of the uh and i realize you asked specifically about that they uh our favorite thing to do even in the Even in a company where none of the leaders know about this stuff or maybe even care about any of this stuff, you can always go to your manager and just say, what if we were to just do an experiment? That's all. Not the whole company, not just our team. Do an experiment, which is to try to see if we can actually achieve an outcome. I don't know that I've ever seen a company say no to that. They're seeing some initiative. Maybe it works, maybe it doesn't. If it doesn't, fine, they just go back to doing what they always did. But if it does work, maybe there's some real upside here. And at a minimum, you can do that. There's a lot you can do. This is a whole, maybe it's a good excuse. One of the characteristics that is incredibly important in every real product manager is agency. This is realizing you can do a lot. much more than you probably think. We all suffer from the constraints of our companies and the personalities of the people involved, but high agency people are like, well, of course, there's always going to be these obstacles. What can we do? There's a lot we can do. And you can usually talk to customers. You can usually look at product data. You can usually just go and inform yourself of what the problems are that your customers are facing. And maybe if I can, Because this is something that you could always do in the past, but it's so much easier now. Politically, one of the very best things you can do is show and not tell. And why that I mean is create a prototype. You can do that. You could always do that in the past, but now you can do it with tools like Lovable in about a couple hours. You can create a prototype of something better and show it. especially good is before you show it to those leaders, test it on some users, test it on developers, you're testing to see that they could build this thing for real, and testing it on key stakeholders, like maybe the lawyer is concerned about this, or maybe sales is and and you get the make sure that you have a prototype of something that those all those people constituencies are can support. And then you go to the leader, I mean, is very possible that leaders that up until then have been saying no to everything say like let's build that so if that's all possible why do you think it is still so hard for companies to actually move to this model yeah um honestly there's uh i i was talking with sharif about one of my favorite product thinkers is shriash doshi Some of you may if you don't know that name, you should look it up. He's so thoughtful is one of my known him for 20 years and started as an engineer and became like one of the original product people at Stripe early at Google relatively and and at Twitter, just a very, very strong product guy. But he likes to say every product problem is a product leadership problem. It's kind of right on that. It is really true. And that's that's really what's going on. A lot of times that's the issue. We have to get our leaders on board. Now, there's a lot you can do from the bottom, but to really make change happen, there's never been a big secret. You know, the leaders have to really help. Not only do they have to to sort of bless it or sanction it, allow it, but there's a lot they actually need to do. The good news is that more of those leaders are aware of this than ever before. I mean, their boards are pressuring them. They're saying, what are you doing around AI? Do you even have the muscles internally to do this stuff? Do you know how these good companies that are turning out these products work? If not, why not? They're asking those questions. So we're seeing more demand than ever, more interest than ever from executive teams. Well, but let's maybe kind of follow down that thread and talk a bit about the expectations of leaders that people should rightfully have. So like, what are the two, three things that you think a leader needs to provide to actually fulfill their role in empowering teams? I've found leaders that they just say, you are now empowered. Right. And that's not a thing. I mean, if you're at least receiving a goal, that's a good start. there's still suddenly you've got like this kind of open canvas in front of you that could be too broad, right? So I think you rightfully kind of want some leadership direction. So I think let's talk a bit about what that looks like. Yeah, the two extremes are actually both not helpful. The one extreme, which we've already talked about is the micromanaging boss, right? That's like, I'll tell you what to do. Just do this, just ship this. We know that micromanaging is not, you know, that isn't you're never going to get any innovation that the real innovation is going to come from the engineers, but they're already being told what to do. So it's not going to happen. On the other hand, like Malta's pointing out the other end of the spectrum is, this is called under management, sort of micromanagement might be a form of over management, just delegating and say, Okay, I know that's not good. So I'm just going to let you run. I'm going to give you the space to do good work. That's the words they offer these. And under management is it's better than micromanagement, but not by much. Because for I mean, I like to tell leaders, I literally was with a senior leadership team at lunch, and I told them exactly this, that empowering teams don't require less leadership, they require better leadership. So Malta is asking, what does that really mean? It means two things. The first is that how are people supposed to know how to do good work? Where did they learn how to be a real product manager? Where did they learn how to be a real tech lead, a real designer, professional designer? Normally, from their manager. I can tell you that's how I learned that. So almost everybody that's learned the craft actually got to learn it. So the first order of business for a manager is to help them learn their craft. Now, the challenge there is what if that manager's never done this before? And that's unfortunately the case in a lot of developing, you know, microcosms. Like I would say Sydney, that's one of the challenges here. There's much more interest in working the way I'm talking about than there are managers that are skilled in working this way. So you kind of have this chicken and egg problem. which is for those that have been following, you know, what I talk about, the real answer to, I mean, one answer to that is the CEO brings in new leaders. And sometimes that is exactly what happens. They bring in leaders that have been there, done that. A more scalable answer, because, you know, usually these leaders that they have, have like 20 years of knowledge about that business. They'd be losing a lot. The other answer is to give those leaders a product leadership coach. So there are a bunch of product leadership coaches around the world. I was here about a year ago here in Sydney. And my main purpose of that trip was to find more coaches that we could recommend. And I did find more coaches. And we now have a set of coaches that we can recommend. No money involved. Just I want to, you know, when a leadership team asks me for somebody who can show them how to do this, I want to make sure they get a name from somebody who knows how to do it. It's not complicated. And so that's the other way to develop it. And that is a very scalable solution. That's the first responsibility, though, is developing your people. That's how that's how most people learn. The second responsibility, it's a little more. This is one where it's actually the bigger the company, the more critical. It is. If you're a startup, it's kind of a non-issue startup. Everybody knows what's going on. Basically, the team is the company. It's pretty easy for us all to know why we're doing things as you get large Atlassian. Look at how large Atlassian is. I think Sharif told me 400 product managers. Now, if you've got good managers, you can largely count on each of those 400 product managers to kind of know what they need. to do for their you're talking about the vision and the strategy for not yet but i'm getting there i'm talking about they know the purpose of their team but the key is how do they make good decisions if they don't understand the bigger picture now that's not so hard like i said if it's a few teams like early days my first visit to atlastian was uh there was less than 100 people today with this many that's hard And so the leaders have to spend a lot of time sharing the strategic context. That's product vision, that's product strategy, that's team topology, what all the different teams are working on so they know. So the point is every team needs to know how their part contributes to the larger whole so that when they make the hundreds of decisions they make every week in an empowered product team, they know they're making good decisions, not just for their team, but for, in this case, Atlassian. And I do think that's hard when that's not around you. I think that's where sometimes kind of in those in the product roles, you can probably probe your leaders to some extent, and you can kind of sketch certain directions, because sometimes I found it's easier for them to react to one than to discover this themselves if they don't have the benefit of someone who's kind of taught them. But I do think those kind of lacking product visions and lacking product strategies can be a problem. I've found sometimes companies haven't even really recognized kind of how they're competing on tech products and they still think of themselves as more traditional businesses. So this does happen in banks where kind of even the question of like what's your product is suddenly a very difficult question for someone to answer. And I think having some analogies at hand that helps people to discover this themselves can be useful. I often use the music analogy where when you just ask anyone what their favorite tech product is, if not the first, then the second or the third answer will be Spotify. And you can drill on that a bit because you can ask them why. And I've never had the answer that someone says because of the music. The music is the same in Spotify as it is in Apple Music or in Tidal or whatever else you want to use. Every answer comes back as like, well, it helps me find new music, discover new music that I like, or it's the playlist that I share with my kids, or that I can play the music on any device, on speaker, whatever it may be. So something you realize is a company here, and you'd say that the core product is music, but no one describes it as that of why they love it. That's true for a lot of other companies where in a bank it's not the underlying bank account a debit card a credit card that you actually care about why you rave about one bank and not another has to do with the digital experience they created and i if you kind of i found if you explain that to business leaders suddenly they realize that that kind of business strategy they have in mind or that re-platforming of like something that kind of powers uh the the technology is not actually the product and they start opening up to kind of some conversation on like what a vision could be that you may have in mind for where that product can go and again good opportunity prototype that new experience and show it don't tell them great um as we're starting to talk about prototyping kind of where do you see product discovery going well i don't know that it goes anywhere i mean it the job of discovery is to figure out what to build and delivery is to build it um but the tools and techniques are are on fire right now they're just they're all conceptually the same things but disruptive significant improvements in how those things are done for example product discovery has always been primarily about prototyping and there's always basically been these four major kinds of prototypes depending on the kinds of risks that you're working on Those all still exist with whether you're building an AI product or using AI technologies to build products. They still exist. The difference is some of them are way easier to create than they ever were before. And that changes the whole calculus. Because when these kinds of prototypes, especially what's referred to for those that don't know the... taxonomy of prototypes are referred to as live data prototypes. That is incredibly powerful and it used to be the most expensive kind. Now it's usually the cheapest depending on the situation. It might be one of the cheapest, but it's so cheap that you can do them now where it wasn't practical before. And especially because before these new generation of tools, you really needed to get developer time. And that was the bottleneck for teams. Now, most of these, including live data prototypes, you don't need developer time. And that's a game changer, to be honest. This is why it's the, I call it the era of the product creator. This is like perfect time for product creators. So AI builds the prototype and AI also just builds the whole code, like so engineering is taken care of also? Yeah. I mean, unfortunately, a lot of people believe that, you know, it's true. I, I've been struggling with this. I, you know, spending time on LinkedIn is something I treat like medicine, I have to do it, even though I hate doing it. Because you see all these things people believe. And there are a lot of people that believe that. So, but to Malta's point, there are Prototyping in discovery is very different than building a production quality product in delivery. One of the things I, there's a lot of questions there. Boy, I don't even know how much to go into this. This gets pretty technical pretty quick. But I want to be very clear. I love the new generation tools for prototyping. tools like lovable tools like bolt i love love really love the tools for delivery tools like cloud code tools like cursor they are not the same they're for very different use cases for very different people tools like lovable it's a feature that that any of us in the room because really almost anybody can use English to describe what they want. Any of you who've done that, I bet a lot of you have. Quick show of hands, how many of you created anything in any of the, yeah, so I figured. So you probably know, though, once you kind of get the basic flow, it's then it turns into like a game of whack-a-mole we call it where you know okay this is not working now and you change it now this is not working but you can't actually know why because you don't actually see the code and most people to try to look at the code don't understand the code and then so it's like I'm just guessing and I and you know you very quickly went from super fast to get this initial thing to like this is driving me nuts and what's going on is they're very you know English is not good for specifying in an unambiguous way and a repeatable way, a bunch of use cases. And in any product, there's, there's hundreds or 1000s of use cases. In many products, like I don't know what the latest is on JIRA, but I would bet it's 10s of 1000s of use cases. It's a massive product that does so many different things. It's essentially a platform that enables so many different kinds of solutions. That's a very powerful product. That has probably got, I don't even know if there's anybody left at Atlassian that understands all of those cases. It's really only in the code. So that's real product. You don't want to try to describe that in Lovable. I mean, you can try. Good luck. Good luck. It's not for that. But where I was going is, I do think each of those two classes of tools are going to continue to get way better. And we will be able to describe prototypes better than ever, because that's a lot of those issues are going to get better. But ultimately, I do not believe, and I might be wrong on this, because it's very hard to predict the future, especially with something that nobody really knows just how smart. The foundation models are going to become nobody knows everybody's guessing right now So I do believe that's gonna get a lot better, but for a product I think we're gonna indefinitely need senior engineers, engineers that understand architecture, that understand all the major. When you talk about a product, it's reliable, it's accurate, it's performant, it's scalable, it's fault tolerant. These are hard things. And there's a lot of knowledge that comes into making the choices in what way to build that. Most non-technical people wouldn't even know what the choices, they wouldn't even know these are choices. They just sort of take it for granted. But every senior engineer that's worked on products, real products, they do know this is their world. And so it's a different set of tools that those people will have. And that's I think that right now is the leader. I mean, everybody loves the cool factor of things like lovable. I do, too. But if you really want to be blown away, look at what great look at what serious engineers are doing with cloud code. Just watch them. And you can really see they're basically like an orchestra conductor with 50 agents doing their bidding. It's very, very impressive and scalable. So I see that going, I see both of these getting better over time, but I see them as distinct. So on the product side, our job is to actually discover something worth productizing. And the delivery is all about turning these into products. The other thing I'd mention is there's another layer to all this. As the cost of coming up with products drops and it's dropping, the number of players is going to go up. It is going up in every category. In some categories, it's really difficult to even track the main players, which means the bar gets higher for the product. not lower. In fact, now there's a new competitor in practice, which is people can roll your own and a lot of them for simple things, especially will and for more advanced things once the technology is further along. Yeah, so we really see lots of changes in discovery and delivery, but they strive for different goals. And so therefore there's different tools and different approaches. That's my theory. We'll see in a year. I'd be comfortable, I think. a year and three years from now that will be true so as this happens and there's now new tools being employed and and you can actually develop at a different velocity how is the composition of those teams changing yeah this has been a hot topic of course uh so again there are people that think all you need is any one person like a product manager could do it all i do not i think there will be outlier cases there always has been I call these people triple threats. They are skilled in product design and engineering. I know a handful of them. They're amazing, but they are true unicorns. I mean, those are truly rare combinations of talent. It is much more likely, I think, that we will have at least two. And those are the product. person that we're talking about that really understands the business dynamics, the data, the customers, the purchasing, all of the different constraints, that's a typical product manager that we've been talking about, and a senior engineer, tech lead, what we usually call a tech lead, which is essentially the AI engineer, if you're building an AI product, but the tech lead in general. I do think we're already seeing the average number of engineers. In other words, if today a team has a product manager, a tech lead, and five engineers, tomorrow they'll probably have three or four engineers. And I think that will continue to drop. But I do think that structure stays the same. And I also think that the best design is a trickier one. Because I think there are a number of products where the tools will do design just fine. As long as you have a serious design system at your company, which will become only more, I think, more valuable in companies. And we're doing pretty good on that front anyway, getting better. But for the, I think for a lot of the best products, they will have professional designers. Well, at the same time, I've seen... in the US, certainly not sure about Europe, as I really, that was a long time ago that I worked in Europe, but in the US I found this like distinction of like who does what and kind of what's the role of the product person, kind of the designer, the tech lead, when it comes to some of the core decision making is more fluid. You've got some companies where engineers are really ultimately usually the driver of the direction. You've got some companies where designers actually have an outsized influence. Airbnb is known for that. Google is known for the engineering culture. um instagram was always more of a product where designers were kind of really having more influence so that even can evolve and maybe as kind of now people get different tools and uh you know they they can kind of span more roles kind of you you see different people stepping up and really driving the future of the product yeah i what i would be careful of is though in different companies the risks are different And so certain things become super important, like at Apple design has always been incredibly valued, because look, look at how integral design is to their products. Absolutely. And so it's valued there, actually design and engineering are incredibly valued there. Instagram, another good example, Airbnb, the product that there is some complexities around the product side, but the design is very big and of course the scalability, the engineering is pretty big. So the point isn't that they don't have the skills, it's just the sort of the importance of those relative skills can vary. For most B2B companies, the most difficult skill is actually understanding all the different dimensions of the business, which is product management. For consumer companies, it's often design. because what we were talking about before the user experience. So it just depends. 100%. I've just not found that mindset necessarily, but often I found designers kind of not kind of seeing that opportunity for themselves that they would be allowed to kind of step into that role. So I think sometimes encouraging kind of people in design kind of to do more of that can really lead to great outcomes because the best designers understand customers very well and they can kind of visualize like actually where this product could evolve to better than others. more creativity and imagination, right? Stereotyping somewhat, but I therefore always encourage people that if they see kind of something that they don't think is quite right and it's not moving the right direction, step up and do something about it. I'm curious, most people will be working on what you I think call conventional deterministic products, but do you want to talk a bit about AI products and how those are different? Yeah, well, It's all very early right and I should have there's a big caveat here There's a lot of people who are working on air products are actually working on infrastructure right now And that's where the money is right now, too And of course totally but this but the the game of course is not there the game is to do something with that infrastructure so that's at the application level and that's That is early still very early then Everything conceptually is still a thing, of course. But for example, one of the hardest things in AI are probabilistic products, right? These are non-deterministic, meaning you can't always know what's going to come back and you have to make sure this thing is responsible, doesn't get anybody hurt. I think I've been encouraging people. I know, I don't think you have this here, but if... If any of you get a business trip to the US, to one of the cities where Waymo is, you should definitely get the app super easy and do a ride in a Waymo. A true self-driving car is a really mind-blowing experience. And you see a lot of tourists getting in them and they're taking pictures and they're just like, but it is a weird thing at first, but it's so good for product people to experience that. that's probably one of the most sophisticated intelligent products i know it still has a human in the loop but not everybody knows that but if the car encounters a situation that is way outside and by the way there's something along the lines of 10 million miles of automated tests running constantly on that it's just incredible the work they have done on that but if it encounters something weird like recently there was some vandalism happening. People would, would block these cars and sometimes try to damage them. When the car figures out that is actually somebody not letting them go forward. It will, it will basically send an image to an office over over, you know, the internet, so that they can decide like, should we call the police? Or what should we do? So there is still a human in the loop. But anyway, Why did I start telling that story? It's super interesting to see. And I think one of the most impressive examples anybody's done. There's some risk with probabilistic products as well. Absolutely. There's a lot of risk. In every product, we have something we often usually call acceptance testing. And that's usually on a product manager to make sure the thing of acceptance testing isn't full QA. It's just like, is this thing okay? That is way harder with a determinist with a probabilistic product. And it's something that you kind of have to you can't it's with with a deterministic product. Once you do that, as long as the product doesn't change, you can pretty much count on it's going to do the same thing tomorrow and this weekend and on Christmas. So you don't have to worry about it. It's not true. with a probabilistic product. So there is this whole process which is conceptually acceptance testing, but it is way harder than that. It's called eval. And it's how we set things up to be able to know if this system is consistently doing the right thing, or at least not a bad thing, right? Not a dangerous thing, not an incorrect thing. There are these guardrails we have to do that learning how to do that is a big part of the product job for AI products as an example. I mean, that's that gives you a taste. If you want to learn more, there's good resources now. And I would mention, I bet many of you know, one of our favorite product coaches, Teresa Torres. She wrote continuous discovery habits. Terrific coach does a bunch of courses. So she if you hadn't heard she uh she's such a badass she was actually playing hockey ice hockey and uh had a serious crash and and um and actually had to have surgery on her ankle it was a bad surgery and she said she was told she was basically had to be on a couch off you know no weight on the leg for more than three months and she's like I'm either going to go crazy or I'm going to do something useful. And she decided she was going to learn how to build an AI product. And she ended up doing, she picked something very useful for her business. One of the courses she does is teaches people how to interview, do a good user interview, right? Not job interview, to be clear. User interview, right? When we test our product, like I said, we take a prototype, we put it in front of customers. trying to see if it does what it needs to do. So she wanted to coach people on how to do that better. She does that. She wanted to a tool that could do that smart tool. And so that's what she picked. And she went through the whole process, which was primarily about this eval system. And, and then she ended up sharing all her learnings and she it's really an excellent job, both in terms of learning what's really involved in an AI product. And we've been telling people for a long time, it's harder, not easier to do these kinds of products. But also, and this is actually I told her I said, this is such a good thing she created, not just because of AI products, but because it showed the most important thing for product people is thinking. And how you don't want to, the most common mistake we see, I was talking with Sriyash about this because this is the thing that bothers both of us more than anything else. People delegate their thinking to a tool, right? I mean, you see people trust ChatGPT all the time. And some of the things are just ludicrous. You want... And what she did so well is she's not the type of person to trust some systems output. She wants to understand everything. And so you could see her using the tools as thought partners, never as delegation. And that was impressive. Her level of agency was so impressive. So well worth your time to watch that. That I reckon will be one of the pieces you'd recommend for people to do, kind of to really kind of start using tools, but maintain the thinking. We'll go to questions from you guys in a moment, but let's kind of keep going on that thread. What else would you advise people to do if they want to move into the product creator role? What do you advise people? Well, really, there are lots of techniques in discovery, for sure. Get really good at prototyping and get really good at testing those prototypes. Testing with users, testing with buyers, testing with stakeholders, the different kinds of stakeholders. They all have different concerns. And testing with your engineers. We're testing value, usability, feasibility, and viability. Or go to skills as a product creator. I would argue that's been the core skills for a good product manager. But as you know, there's all this other stuff. that people often do. And a lot of product managers spend all day doing non creator things. And that's, I've said for a long time that make sure you're spending at least four hours a day on the creator stuff. If you've got to do a bunch of other things, we you know that we all pay a tax, we all do stuff. Developers don't like spending time in JIRA either necessarily, right? But they do it. We all have to do it. It's part of the job. Will does not seem to be offended. As long as it's JIRA and not something else, I'm happy. Well, one thing I don't think you've mentioned is kind of talking to customers. Oh, I hope I talked to it. That's what I meant when I said you take that prototype, put it in front of users, put it in front of buyers. Yeah, I mean, that's... Has anybody seen... I published another article late last night. Anybody see it? Nobody. Yeah, it must have been different time zone. Every once in a while, I think my message is getting out, then there's a reality check. But no. So anyway, it's called forward deployed engineers. And it's talking about a technique that Palantir actually really popularized and actually did some amazing things with it. And the idea is when you're a product creator and you really need to learn because you're signing up i don't know how much to tell of the palantir story what they do is they do products for really hard environments i mean initially they started with military things and intelligence things and then they moved into health care which is very hard and sure you know but none of these they don't do to-do lists right they do very complicated systems And they don't just build what you tell them to build. That's what Accenture does. They build what they believe they need to build for you to accomplish the outcome you need. And they'll only work in the environment where they're given that ability, truly empowered. In order to do that, they send engineers and typically product managers into the customer environment, not just for an hour or a day but often for months to learn the users to learn the data to learn the stakeholder constraints look to learn the space just like we would as product and their goal is to discover a solution that will deliver the outcome they prototype like crazy now in order to make this reasonable when you're doing big complex systems, they don't just start from scratch, they start from a platform that they provide, not to the customers, but to their FDEs, Forward Deploy Engineers. So they start with this platform, they do the tailoring they need to do to make it work in the customer environment. And then the platform organization takes what they had to do and abstracts it into something that could improve the platform for all the future work. It's actually a very difficult but amazingly profitable model if you can do it well. And just so you know, Accenture is worth currently about $150 billion. It's been around forever. Palantir is worth $400 billion. And it's a relatively young company. And that's because this is such the difference between a feature team, which is, and I'm not criticizing. Accenture on this, that's their business model, right? The client tells them what to build, they negotiate a price, they build it. Palantir though is taking the product model to this and saying, no, it's all about achieving an outcome. But for us to do that, you need to let us figure out the solution, not you. So it's really quite unique and like a new way of how enterprise product gets built with more discovery at the customer done by kind of product people and engineers. It's quite interesting. But whereas in consumer businesses, you can just talk to your consumer customers kind of as the engineer, the designer, the product. Yeah, it's much easier for the consumer product. maybe before we open up, you initially mentioned kind of some of the similarities between New York City and Sydney, which I'm not intrigued by. I know you love Sydney. I know you come here a lot. I believe kind of some of the book transformed was was written here in Sydney. So do you want to talk a bit about those, those differences and the similarities that you find for for Australia and for Sydney specifically? Yeah. So first of all, this is really important that I For whatever reason, so many of the people I meet in Australia in general believe that they're somehow been left behind and it's just not true. It's just not true. And this belief that you go to San Francisco and they're all like doing this is I wish that was true. It's just not. It's the same issue there. It's the same issue in London. It's the same issue in Berlin. It's everywhere. There is a mix of companies that are really good at products and the rest. That has always been true. You have, we're at Atlassian, which is a great example of a product company. Just down the street is Canva, which is another great example of a product company. And those two companies hold their own against anybody in the world. And yes. you have a lot of other companies that are not nearly as far along. So that's the norm. It's not about Australia versus anywhere else. It's really important to understand. Now, that said, there is a dynamic in Sydney that I saw heavily in New York, which is that in both cities, the biggest employer are banks. both cities and that's kind of unusual I mean I'm sure there are other cities Singapore maybe I don't know other cities that have that kind of dynamic but that's a big thing in New York there was a lot of frustration in the product community for so many years because Boston was doing things Austin San Francisco Seattle but New York nothing what happened was a new and by the way there's no question New York has talent but they were employed by the banks. And the banks do pay well, right? They have a lot of money, kind of that's their advantage. But they don't really, you know, they don't use engineers like product companies use engineers. It's mercenary missionary thing, very different use. What happened in New York was the financial crisis. And then so many of the banks actually had to lay off a lot of people, which finally turned loose so many of these talented people. mostly engineers, that many of them went to do. Okay, I've been looking for an excuse to start a company or to do join Etsy or to join one of the cool, you know, younger product companies, non bank companies, and it took off the whole I mean, today, New York is really indistinguishable from San Francisco when it comes to the product community. I think you've got a lot of that dynamic going on right now. You have a lot of your talent sort of golden handcuffed, locked in to banks. And what I would love, what I expect to see is a lot more of these people over time deciding to take a chance on a company like Atlassian or a company like Canva or their own startup. That's. It's kind of how you see it really take off and spread. I think it's arguably already happening, but I don't know that there's been that event like the financial crisis caused in New York. But I do think that's kind of the dynamic here. I've met a lot of people in banks, a lot of banks. They're a primary employer here, and they drive a lot of what's going on. Well, maybe the banks will also change. I know Christian has had some impact on JP Morgan, and I know he's been doing some work with banks here. So we'll see if that works or otherwise. I have also noticed kind of people from banks, engineers, kind of actually become very successful as tech leaders in startups. So I think both can both can be beneficial. Look. Very happy to open it up to two questions. We've got mics roaming around. There's a question in the back there, and then I think we'll just, there's one in the front here, so we'll just keep running around. I think we've got multiple mics. Go for it. Maybe say who you are and fire away. Does it work? First of all, thank you, Marty. It's an absolute pleasure to have you. My name's Nat Simpson, startup founder. My question is, we've seen a bit of a proliferation of different product manager roles. You see the growth product manager, you see AI product manager come up everywhere. Into the future, do you see that rolling into just the normal product manager role, or do you see a further proliferation of different niches coming out of the product manager role? No, we have always seen that. The most recent one was probably mobile product manager, right? because we need it for our phone. I've had several discussions with other people in the AI community at OpenAI about exactly this. We all think AI product manager will just be product manager. Growth, that's kind of already, many teams are growth teams. In other words, is growth one of the outcomes your team cares about? The answer is very often yes. If that's the only thing your team cares about, that's called a growth PM. But that's been true for a long time. That's not really different. So I would argue a mobile product manager, there was more difference there. I mean, the growth guys sometimes have more of an online marketing knowledge and kind of knowledge kind of that extends it a bit beyond the company. But otherwise, I totally agree with you. I mean, and. that a good product manager needs to know that too how their product gets to the customers will do i know you've got some questions in the back you were first i'll just hand the mic hi i'm i'm an ex-alassian designer and an aspiring product manager as well and i wanted to ask like i'm really curious about what's the difference between an ai product manager versus a normal product manager and what skills you think makes the ai product manager Good. And by the way, there's an article I wrote with one of the sort of thought leaders in the AI space, Marilee Nika, called AI product management. And I would encourage you to take a look because we, one of the product leaders at Google, we both get this question all the time. And so we wanted to put this out. So first of all, it's important to realize, remember, I was saying with AI, oh, did I say this? I might not have. With AI, there are two side Bitcoin. One is, those using AI technologies to build any product, I did say this, and those that are building AI products. So I think you're really asking about those that build AI products. The last question I think was, you know, do you need to be an AI product, every product manager will be skilled in using AI tools and techniques. I believe that's pretty clear. It's like saying, do you need to be an internet product manager because you know how to use the internet for your product? Of course, we all do. So I think AI will be like that. That said, building an AI product, an intelligent product, a probabilistic product. In 10 years, probably all most of us. I don't know. This is a hard question about how many what percentage of products will really end up being probabilistic. I think it's amazing for a lot of things, but not for a lot of other things. So I don't know what the ultimate thing will be. But there will be many, many more people that are. skilled and capable of building an intelligent product. And yes, there are some different skills. The biggest one is what I was alluding to before that's referred to as a vowel. Answering that acceptance testing question is way harder. So you need to have the skills to be able to set that answer up. And it's a repeatable thing. Another thing I didn't mention is we have always emphasized that in a good product team, Discovery and delivery are continuous, right? You're always doing them. Discovery is not a phase. Delivery is not a phase, right? It's ongoing. You know, discovery is always a little ahead, but it's in parallel. That's especially true with an AI product. If you decide to get into probabilistic products, you're signing up for continuous improvement there. Great. Let's do a question in the back and then come back to the front. Hi. Good evening. Yes. My name is Amuiz Taha. I'm Sudanese. I just moved recently. Speak up a bit more. Sorry. Yeah. Yeah. I moved recently to Australia from Africa as a refugee because of the war in Sudan. I'm a business development expert. My question is about the implication of the product life cycle. on the outcome. For example, you've been more into the innovation side of the things but if you look at the sales and the marketing activities that has to be carried out afterwards because we have seen so many products died in the early stages of their development because they have been placed in the wrong hands. And I would like also to see how do you see the implication of the structure of the company on the product lifecycle and the outcome? Thank you. Okay, I think you're really asking about the old product lifecycle model. Honestly, for most, most products, it's not a relevant model anymore, because we're not building a product as a project. We're building it continuously. So we're continuously discovering, we're continuously building, delivering, and we're continuously delivering it to our customers, getting it out to the actual customers. That is nonstop. You sign up, you go for many, many years until you eventually decide to phase that product out maybe 10, 20 years later. So Part you're pointing out if I could reframe it. It's not really about the life cycle. It's about making sure you have good go to market with your product. That's a real thing. Because and that whether no matter what you use the old life cycle model or new if you don't understand and make sure you have a good go to market path for your products. Good luck because. Chances are you're not going to have distribution. You're not going to get it into the hands of the customers. They're not going to know what about it. They're not going to know how to use it. None of those things. So that is part of product management is understanding your go to market strategy. Now, usually that comes from actually product leadership. It's more tied to the product strategy than it is tied to each product work. So, for example, you might have. I'm just making this up and we're at Atlassian. So Jira, let's just pretend there's 25 squads or product teams that contribute to Jira. You don't want each of those teams to have their own go to market. That would be a mess. You want one go to market and it might have multiple channels like an enterprise direct sales channel and self-service. So it can be multiple channels, but you want one strategy and all the teams are working within that. But that's a key part of the job. When the alignment is about really it being in sync because you like we can say a great product sells itself well But it sells even better with great marketing and great sales on top of it So I think having that alignment where it's less so Certainly you wouldn't want the marketing of the salespeople kind of tell you kind of how to market it But if you have a great product vision product strategy and strong attributes for the product You align that into a great marketing strategy and sales strategy. You'll be more successful We'll do the third row here, then back, and then come back to the front here. Okay. And I'm being given signals, so we'll try to do... You're going to have a question as well. Great. So we're going to do brief questions and brief answers, which I don't do to get through more of them. Hi, Marty. My name is Kurt Young. I'm a senior PM. I used to work for Pivot Labs, so I know about... I'm a huge fan. The first question is, with the rise of that sort of a product creator or the emergence of those different sort of attack, design, product roles, do you see a potential issue with that kind of the current healthy attention balance between viability, desirability, feasibility? If you're merging that into one person, then how would you still having that balance being striked? Good question. So first of all, and you might have heard there was, there's two taxonomies for risk out there. that was just sort of the other one they're both fine one comes from uh the other the one you're referencing the one with desirability started with ideo which is one of my favorite companies but uh desirability combines uh value and usability um so as long as you if you combine it just know that those are the two things you need to look at so but um i'm sorry you were asking yeah just how how would you strike me oh yeah people doing their job this easy but if you're one person then how would you strike that balance so to be clear i was saying that i do not believe that in most cases it will be one person i was saying it will continue to be multiple i do think it will be often two instead of three but it will be more than one because of what you point out there's a lot in all those risks there's a lot of work and knowledge to do this. For example, most engineers have no knowledge of all the business viability issues. And most product managers have no knowledge of all the feasibility issues. So you really need multiple often. And it doesn't really matter who worries about them as long as someone worries about them and they actually know what to worry about and how to address them. That's the key. The second part is, I think you mentioned earlier around having competent product leaders, right? Whether it's replacing or giving that level of support they needed. Do you reckon for them to succeed, they also need at least one or more senior leadership support like the CEOs or like business side of the sponsors? Do you think that's important? Well, so yes. Short answer is for most companies to actually transform. Not just a team, but the company, the CEO's really got to provide some support there. They don't have to be experts in any of this, but there will be times when you have to realize moving to this way of working, moving to outcomes, implies that some power will move from a general manager, business unit leader that's used to dictating a roadmap. to a product leader who's there to deliver outcomes. And they're all going to say they want outcomes, but that's push comes to shove. There's some like you're losing a little, you're gaining a little, that's a little political. And so the CEO at times will need to say, we're going to try this. And that's so that the CEO does need to play a key role. That said, the real work is the product leaders. They are the ones. They are the ones that make all the difference for this. Great questions. But people want to say shorter questions? I didn't mean to. So you've got a mic and then we'll come to the front here. I've got the cube. Hello. Does this work? It does. Hopefully. Okay. Marty, hi. My name is Kosta. Up until recently, I led the product and design team at OptoSport, a sports streaming company here. My question is, so I'm intrigued by what you said about the tools for discovery and delivery improving so rapidly, which makes it so much easier now to discover and build features, right? So in that environment, do you think that changes how a company can create a lasting advantage now that it's quite easy to build and copy, presumably, features? Yeah. By the way, this has been an issue for a long time. It's always been easier to copy. Always. And because once it's actually defined, that's kind of the hard part, right? Now, lots of people can say, well, we can build the same thing. There's this is a strategy. I won't go into the Sandmore Brothers, but they this is a whole. There are businesses that are all about fast follower is the nice way to put it. Right. So that's always been true. And so what we're really talking about is making the moat. Right. And there are lots of always been different ways to build that moat, that defensible position. I would argue it becomes more important. The more competitors there are, the more important it is to do this, the more important it is to do a great product. One of the reasons that I was just telling you the story about Palantir. One of the reasons they've been successful is their moat is they know more about their customers than anybody else out there because they actually spent months inside those customers earning their trust that is more sticky than Almost anything you can imagine so deep knowledge of your customers the ability to deliver real outcomes and you know that the thing that I think is more and more people are realizing is that customers rarely leave us because of a competitor. They leave us because we stopped taking care of them. And that's when you realize that you've got to really, that's where your mode is. I would add I have no issue with copying things at all. Like, I mean, seriously, because if it makes your product better, like, go do it. Half the products on your phone today have a newsfeed. Well, there's one company that invented that and then lots of companies copied it. That same company that invented it copied lots of things from other companies. I think that's great. It won't be the only thing that you do if you're successful. I don't think there's a thing where all you've done is copying that that turns into a success. So that's not, I don't think that's true. Since you said that, I just want to, I always laugh when I know a company is copying something else. especially when I know that company they're copying and I know their data shows that's not even being used. They have no access to the data. It is amazing. This is a real product strategy with Malta's describing. It's called the feature parity strategy that says we just need to copy the features they have. They end up with a crappy product and what they've done is inherit all these things that aren't even working for that other company. So I, you know, this is Malta's phone, not mine, but it's an iPhone. First iPhone when it launched, didn't even have copy paste. Some of you aren't old enough to remember know that but it's true. Didn't even have copy paste because Apple, that is never a reason for them to do it. So to Malta's point though, sometimes a feature is just a no brainer. We know we need it. You don't have to like do a bunch of discovery, you just knock it out. But you should only do that if you have some evidence that that is necessary. Don't assume because a competitor has it. Definitely don't assume because some client or customer says they want it because a competitor has it. You need to be convinced. And there'll be something that you built that is your own kind of creation and ideation. Otherwise, it won't differentiate. Okay, you've had a question for some time. Thank you. Hi, Marty. Thank you. Love the conversation. I'm Nishant. I work for a consulting company. I work as a product owner, work in the Scrum, Agile methodologies. So you talked about prototyping and you see prototyping going ahead, becoming big and PMs wearing a hat of probably a designer. So where do you see the line drawn between a PM and a designer? And do you also see when you talked about Teresa doing AI and playing around with AI as a thought? partner. You see prompt engineering taking a big role in all these things and making the prototype and providing value to the client. Yeah, thank you. Yeah, well, you know, I just want to make sure you take away the message that product owners scrum time to upskill trying to upskill because that is just a sitting duck right there. They're very nervous about that. So the kinds of things we're talking about. Yeah, prompt engineering is one of those things like do you know how to use google yeah do you know how to do prompts yes you that will be a yes very soon for anybody in this space so absolutely um but you were asking something else too oh yeah so just because um just because a product manager creates a prototype or a designer creates that prototype or an engineer creates approach doesn't mean it's got a good design. It doesn't mean it's got the right functionality. It doesn't mean that it's compliant. You need the skills. So there's whole one whole question is who creates the prototype. The big breakthrough is anybody can create the prototype. That's the big breakthrough. It used to be certain prototypes were created by the designers in Figma, and certain prototypes were created by engineers in code. Now throw that all away and that most of the prototypes can be created using these new tools by anybody on that team. Then the question is not creating the prototype, it's evaluating the prototype, testing the prototype, assessing it. And that's where the different skills are necessary. A good product designer, if you've got a product that's got a very important user experience. That is critical. A good designer is amazing. If you've got a product that's got a lot of business viability issues, like go-to-market issues, like compliance or security issues, that's where product management skills are important. If you've got a product, let's talk about AI product. Another big difference for those is that the costs are crazy expensive for a lot of what we want to do. And so the engineer plays an outsized role in trying to figure out a way that is both accurate and fast and affordable. That is very hard trade-offs that we haven't had to do for most a long time. So you need the different skills to judge these things. We had some questions somewhere there in the middle. It's harder for me to see you at the end up first. I'm happy for you to go if we can get a mic to you. I'll come across. Does that work? Yes, I think so. Is that right? Yeah. Hi, my name is Bella. I'm a product manager at a media company. But this week I was just looking on LinkedIn and they released their article of the top 100 business schools in the world. And they listed alongside the most common job titles. And product manager, I want to say, was like... at like 80 of the 100 which really surprised me so i'm interested if you think that there is like is it a growth market and enough opportunity for that many product managers at the moment or like as i guess tech and industry continues to grow so they were saying that product manager is a popular job is that what you yes it's like out of like 80 of the top 100 business schools in the world um product manager is like the title of most of the graduate graduates i see There's a whole other topic about does a product manager need an MBA? And that's not really what you're asking. So what's the short answer? I never I never got around to it. Short answers. No. No, not men. There's some very strong opinions on this topic in Silicon Valley. My experience is that you can you can have some great product people that have an MBA. You can't it's not a blocker. It doesn't negatively. It's very diplomatic. Believe it or not, a lot of people disagree. Okay, we do a couple more quickly. I don't think I answered the question. Did I answer the question? No, sorry. The question was, is there enough like opportunity in the market for that many product managers? The truth is, I don't know. That is really, really a hard question. You know, because at a macro level, I'm pretty confident, and I say this reluctantly, we're not going to need as many engineers as we have in the world. There's still a strong argument to be made that it's still a very useful education because for the engineers that we do need, they really need some training. But that's a tougher, that's, an easier one because of the dynamics there uh for product managers i don't you know here's the part we haven't talked about yet we talked about the shape of a product team and i said you know you probably will have some percentage less number of engineers what i didn't talk about which i think is a more impactful difference is team topologies are changing what that means is For a given size product where everybody in the world knows Jira, so it's a good example to use. Let's just pretend I bet it's a lot bigger. I think what did I say 15 or 20 squads? I don't know how many a lot right? Yeah, but let's just pretend it's 25 just for just for a number. Sorry. Oh, let's go for it. All right. So yeah, I mean it is a big ecosystem product so I I'm not doubting. So let's say it's 100 product teams and they're all, you know, they have some average size. What I think will happen is not only was the average size decreasing, but the scope of each team will increase. And actually, that's a very good thing. Teams have wanted more scope for years. They wanted, you know, because nobody likes to feel like they're just a little cog in a giant wheel. Like the biggest complaint, I'm not saying this is a complaint for them, but in most of the world, even in good product companies, if you're one of 100 teams that contribute to a single, you know, skew like Jira, then you can easily feel like we can't do anything without 20 other teams helping us and we have no autonomy. This autonomy means empowerment means we get to figure out the solution. Most good teams have that, but they don't have autonomy, which means that and they don't depend on all these other teams to do what they want to do. they do depend on a lot of other teams and so they feel like this would be so much easier if we just had end-to-end responsibility i don't necessarily mean one you know the hundred goes to one but i do think it's very very likely that the hundred will go to 20. something like that over time and that will be a lot more satisfying for all the people on those teams because they'll have a lot more impact. They can make a lot more changes. They can take responsibility for whole flows, whatever it might be. So I think the topology issue will have even broader impact than the team size issue. Now on the product manager specifically and those that are true creator product managers, I'm very confident for the next few years, you'll see more and more demand. There's a lot of business leaders that I talk to and once they understand what actually true product management is and like why that's important, the next question they always ask is where do I find great product people? And so I do think kind of for those product creators, for those great product managers, kind of they'll be Ample work and so I'm I wouldn't be at all concerned for those people that kind of however They get there they become a great product person. They'll have great career opportunities I think you've been making the point that I even make more money now in the future. Yeah Here's the thing though that like I don't see a future for the product owners And I'm not trying to pick on this. I'm just trying to be honest with you Now it could be wrong, but I wouldn't bet on that with I were you I would not So what I'm suggesting is become one of these people that Malta just described. Question there in the middle with the mic. Go for it. Hey, guys. Thanks for the talk. It was great. Very simple question. Factually, for both of you, if you are a younger self today, what would be one piece of advice you'd give yourself as an aspiring product manager? You want to go first? Your I've got kids that are just in uni and going into uni and all of that Look the my oldest kind of did what I did. She does international business. I'm not sure that I would do that My second oldest is doing math and engineering mechanical engineering and I'm always like Livia can you like pick one of the two? They're both great like you really have to do both but that's like more mean Livia problem. I'm I'm I'm not sure that I would do much differently. Like when I was very lucky, I just landed in that kind of company that eBay had just acquired, Orlando and back in Berlin. And it was a time when there's just like lots of things that needed to get done. And there wasn't a lot of guidance, you know, I fell into product not even knowing that that's necessarily what I was doing. It's more like, hey, Malta, can you like, work with those kind of engineers and the side ops people? And by the way, we need to migrate the platform to the US platform. And then particularly since no one else around me kind of actually provided a lot of leadership, it was kind of that stepping up and thinking like figuring out stuff that needed to happen. And so I think that's what you talk about with agency. And I just did that because someone needed to kind of make some decisions and move some stuff forward. I would advise that kind of still to young people today and say there's so much opportunity and you may be in an environment that's a bit chaotic or it's like not perfect and doesn't do this and doesn't do that. okay make a suggestion figure something out and and ultimately create some some value some outcomes but even ebay and paypal at the time weren't the greatest i think in like delivering like striving for outcomes but there were some problems i was given where it was simply like make this work it's like it's probably the simplest way of framing kind of you're going to be measured by an outcome because make this work as like launch paypal in germany was not as in deliver this feature or do this localization no one cared and frankly no one knew how to do it if the market isn't using any credit cards the make it work was asking for an outcome and find situation like that where you can have given some space and you can demonstrate some outcomes i think it'll serve you really well i i mean i i was so lucky and i but i would say if i could i started my career with 10 years at a big sort of the Google of the day, it was HP labs, it was a good plate to learn the craft of engineering. I'm glad I did that. But if I was starting over, and I had the luxury of knowing sort of what I had learned, I would have started at a startup actually like the dead. I did startups after the big company thing. Can do a lot of great work at any but there is just the amount of learning in a startup is off the charts. And I'm really grateful I did that. I wish I had done it even earlier. Good question. Last question. Like how are we doing for time? Yeah, we're good. Okay, then maybe second to last question. Okay, there's a few more. So like you go quickly. Yeah. I did talk about team topology. I was thinking is product team is actually needed for all the different scenarios. For example, some business, they have a legacy system, they want to do a re-platform. The requirement is just predictability and trying to get like feature parity. Is that something like what you called high integrity commitment that actually not like product team is not? quite applicable? Or if yes, how that we can make a difference? Yeah. So everybody get that question? Because it's a pretty good one that there's, and the way I would actually frame it is, do you need a product team for something like replatforming? Yes. Do they need to do discovery? Maybe not. Right? Because if there's not a lot of risk. Now, I will tell you one of the most common first of all we platforms often turn into the re riskiest things you do one of the reasons that happens is because we're taking two difficult things re-platforming when that happens it's very often combined with a redesign because it's been like 10 years they've been waiting for all this stuff and they never let you just do what it used to do which is usually a lot of legacy stuff that's not really important anyway and So they want to combine a replatform with a redesign. That is very hard and risky. And that redesigns, you need a lot of discovery typically. So do you need a full, you know, discovery is the harder question. I think the more important question there. If it's a replatform, they often don't have a designer unless you are redesigning and then you would have a lot of design. But if it's just API level stuff, you wouldn't need it. Yeah. Kayla as an engineer, do you want to talk about high integrity commitments? Sure. I mean, if you don't know what that is, for the most part, we are doing outcomes. But every product company has situations where you need to also give a date. And it has to be a date that the organization can trust because the product model is all built on trust. And so what do you do? Well, you only give a date if you've done product discovery. And you do, and it's not anybody, it's the engineers that are going to have to deliver that thing. They do the discovery. And technically what that really means is a feasibility prototype, which are one of the four kinds of prototypes. If the engineers do a feasibility prototype, then they can give a date that we can trust. And that's what we do. There are some more questions over here. Hi, I'm Nick. I'm product manager for AFR app. I had a question about Korea. progress. Let's face it. We're all here at 8pm on a Thursday. It's a room full of ambitious people who want to make more money probably and be making better products. But as you progress in your career and you get more and more senior, do you get further and further away from that creative part? You said 40% of your week should be doing that creative work. Four hours a day. Oh, sorry. Four hours a day. Do you think the more senior you get, the more you get caught up with executives and and politics and away from the creative part of the work of actual product no that's a great point uh first of all oh i know some amazing product creators that well actually i mentioned shriash shriash the founders the collison brothers at stripe stripes one of the best product companies in the world uh and they've been they tried they kept trying to get him to move into leadership role he was like But I love building product. And like, well, I will just give you the hardest products. And so you can move up. In fact, there's a whole speaking career track, dual track, it's called, right? Where the principal, Sharif is a principal product manager. Where did he went? He disappeared. But that's an awesome job. Because you're normally you're a creator, but really high leverage creator. Now, because it is true, when you move into leadership, your product is no longer the product. Your product is the people. So it's a different kind of life and a different kind of, you want to make sure that the reason so many companies believe in the dual career track is because they do not want people to become a manager just because of money. They want, you should do manager if you want to develop other people. You want to look at the impact of product strategy, for example, product vision. But creator, I mean, a lot of the most successful people in our industry are individual contributors. And I think one of the things I love about our industry is that is so valued because look at it. Where do you think the innovations come from? They don't come from the leaders, really. They come from the teams. Yeah. I mean, the only thing I'd add maybe is sometimes the company culture is also very different. There'll be some company cultures where you become a manager and it's all about managing something. But there's some companies where you move up in your career and you just have more impact on more products. And if you think of Canva, I don't think Rob, the head of product, would be offended when we say, well, the real chief product officer at Canva is named Mel. and you just have a company culture where people, even in higher levels of management, care about the product very much and they just have more impact through the organization. And therefore, I think you've got some company cultures where leaders, I wouldn't say necessarily do IC work, but are very still connected throughout what gets built and why certain things evolve. So that's different from company to company. We'll go, Will. So engineer amongst the Product crew. I think a key takeaway for me is that my next career change is not going to be to a product owner. I think that that's a very important takeaway. I'm taking that one home. I'm interested because you drew some interesting parallels with mobile product managers, right? And you also talk about probabilistic product managers. And I'm trying to think about where AI fits into that space, right? Like people talk about agentic AI and like is it just another interface to engage with the product? Is it a product itself? I know that when mobile came out, people were looking at mobile as like mobile is the product rather than is it just another way for people to interact and get the value? I'm just curious to see, are these all independent categories that you see as successful? Like it will be an AI product as well as an interface that people use to engage with it? Or do you see like, yeah, I'm just interested to know how you see those categories kind of panning out. Well, I would draw a distinction between truly different kinds of products. For example, a hardware product versus a software product. There's some, and then there are people that love each for sure, but they're different. There are some differences as opposed to a characteristic of a product that like the best analogy I have is actually, because I remember I was at Netscape during the birth of the internet. It's kind of like open AI is today for AI. They were the epicenter of that. And initially it was like, wait, how many products do we need that actually are connected to the Internet? It's like all of them, really. And they're going to almost all be. And I think that that was true. When we talk about mobile product managers, it became more like, well, OK, yeah, initially we had one or two teams that would create the native apps and everybody else did the whole, you know, everything is normal now. For most of the stuff, we expect that everybody's pretty comfortable building things that will be part of that mobile experience. It's one of the major experiences. I was trying to cast AI or intelligence slash probabilistic products into that. Agentic is actually kind of another layer on this discussion because now we're also talking about how are those products designed to be accessed. As you know, there's a pretty big change going on. around, which I think is a wonderful change, right? I'm actually very optimistic about the MCP protocol along this because I think we've needed something like that. I've been told to lower my expectations. It's not going to be that great, but I'm very bullish on that. I think that's kind of been the missing piece for a long time, even way before AI. So, yeah, go ahead. Isn't then the analogy that kind of if you say like this, you can book a plane ticket on a website, on a desktop website or an app. Okay, fine. And more and more people now do it through the app. Great. But there are some products that only work on the phone. There is no Uber on desktop. So it's the characteristics of the phone that enabled that service. The fact that it is location aware of those things. So there'll be some products that only work through AI that don't work without AI. Isn't that more than the paradigm? I mean, that's what I mean by, oh, that's why AI is tricky. Like I said, I was speaking to, will everybody use AI to create products? I think yes. Will everybody create AI products? No. But there'll be some products created that only work because of AI and that technology. I think Waymo is a good example for that. Yeah. Last question? Yeah, we have questions on this slide. Okay. Hi, I already enjoyed today's talk and also really like you were saying how people and products promote each other and I agree that People don't just buy products people buy people people buy you and for people like me I don't have experience in product management at all. Do you have any experience to share like the top three? Say soft skills that you'd like to share to how to get into product management, how to get in the product. Okay, good. Good. It is actually right now is a tough time to get into product. Everybody kind of knows that is a tough time. If you're working currently at a company, then that's usually your best path is to do what you need to do so that they love you. And then share with your manager that I really want to learn product because that is usually the easiest most consistent path they will they are more likely to give you a chance because they already know and think you're like very smart very good you know teammate everything they're looking for and so they'll make a bet on you uh i learned product that way i i was an engineer but i really wanted to learn it and they were like okay we'll let you learn it but i had already kind of proven that I was maybe a good investment for them to spend some time training and developing. If you're not working at a company yet, so you're like right in university or something and getting to come out, that's the harder one. And a lot of people are and I'm I would do whatever you need to do to to get some sort of internship, even if you're volunteering your time. uh at a good place so if you're gonna join a company and help the most important thing is not the company it's not the kind of product they do it's who you're going to work for because you're looking for somebody that will develop you and show you what great looks like and you want to tell that person look i'm here because i want to learn from you i want to become great and and then that's the path It is a hard time right now, though, as everybody knows. Yeah. Well, and you say that because a lot of tech companies have let a lot of people go. Not sure that that's as true in Australia, actually, as it is in Silicon Valley, for example. I mean, it's we're seeing it sort of globally, and I think it's a softening thing. I think what's really going on is CEOs are they don't know what's going to happen. They don't know if they're going to. need to lay off a lot of people because their technology comes out that means they only need half the number of engineers, they don't know that all they know is there's a lot of uncertainty and CEOs hate uncertainty. Fair enough. No, fair enough. And I can see how the reaction so I didn't I didn't mean to negate that. Look, the only thing I'd add then in some optimism is there is no there's hardly people let's say that leave university as a product manager so it's it's like it's very common that out of some other function kind of you enter product management some of the larger companies have programs for that they call them associate product manager rotational product manager some sort of product manager to actually kind of learn how product management gets done in some of those larger companies There is kind of startups in younger companies who will just want someone who has kind of strong natural talent, strong IQ, EQ, kind of is curious, kind of is tech savvy and kind of is kind of customer oriented and wants to build stuff. So I do think those are the traits that I would kind of emphasize, kind of you demonstrate. Now the lights are going out. I don't know what that means. I was told we all need to be out of here by like 8.45. So. um we can keep going if that's okay um for like maybe a couple more questions um you won't have as much time to have a beer but you can do that outside and so someone's pointing we'll do a couple questions and then we'll wrap oh go for it um hi thank you so much for the conversation can you hear me okay very close um so yeah thank you for the conversation you know yeah Thank you. My name is Deanka and I'm currently a PM at Google Photos. So as PMs, we're often told to move fast and innovate. But like you mentioned, with AI's probabilistic and sometimes unpredictable nature, the stakes feel really high. So where do you think our responsibility as PMs begins and ends when it comes to embedding, I guess, ethical guardrails into products? Do you think it requires a new external role perhaps? And how do we kind of avoid slipping into ethical theater? Yeah, this is a tough one. And I'm saying the reason it's tough is because it's very politically sensitive inside a company. So technically, ethics is part of viability. It's always been part of viability risk. In other words, if you're going to be out there doing things that aren't great, that's a business risk. At the minimum, there's legal risk. So that's part of the product manager's responsibility. So that's not really the question. The question is, you have to realize that product is usually right on the bleeding edge because we're doing discovery on the new capabilities. If there is a new issue, an ethical issue being introduced, You're probably the first one to spot it right right there now then the question that's not the hard part the hard part is what do you do because This is sensitive, right? It's what you don't want to do is go to the CEO and say, you know You're trying to make me do an unethical thing. They're like, what are you talking about? I mean, yeah, there's probably brand new news to them So what they're looking for is and it is your job to point out that worry, point out that risk like this is what we uncovered. Your normal job with an empowered team is anytime you find something that's not viable, like it's not something we could cost effectively market, we take another approach to it. If we find something that maybe we worry about damaging children or, you know, it's accessed by a bad actor or something, we're like, we look for a way not to do that, have that vulnerability. So that's our normal thing. But sometimes, of course, it's like, what do we do? This is like exactly what the customer is saying, but we see this issue and, you know, we have this issue. Then it's your job really to escalate that to your manager. Just to take it. Don't take it to the CEO. Take it to your manager and say, I could really use some guidance here. Here's what we sound. Here's what we're nervous about. Tell me if you think we're over worried about it or maybe you should take it. You should take it to the leader or to a lawyer or something. But escalate it. Don't put your career at risk. Now, that said, there are some companies out there. that are really nasty companies and honestly i was shocked at what some of these ceos want to do uh and i would and i have advised people that work there just get out you know get out you don't want to be a part of that you don't want to be associated with that get out Once in a while you find a company that actually treats this like Airbnb was the main one with a chief ethics officer. He was actually the guy who was the legal counsel at eBay, Rob Chestnut. And and but not that's not that's very unusual. Normally, it's the general counsel, the lawyer for the company that would have this. It's not even official. It's just something they would help with. Yeah. Just be careful. All right. action of LLMs and how many of them will specialize versus general. And as you know, a lot of companies are a lot of companies are that's exactly what they're doing is they're making these intelligent products is their training to training enough that it's essentially a specialized on their topic. And I do think that's part of a vow. That's part of what we'll do. I think you'll see a lot more people get better at that. Thank you. Give a round of applause to Marty and Malti. And yeah, thank you all for coming here. It's been a great discussion. I think we all learned a lot from your thoughts and insights. And thank you for sharing these things with us. We really appreciate that. And now we're moving to more informal parts, the networking part. So please grab a drink, grab a snack. And also important note, we're closing at 9pm. The door closes at 9pm. So keep that in mind. And yeah, thank you for coming here and enjoy the rest of your night. Big thanks to Ryan and Milda. You guys are awesome. Thank you. Thank you for coming, everybody.
⚙️ Pipeline jobs
| Stage | Status | Att. | Updated | Error |
|---|---|---|---|---|
| download | done | 1/3 | 2026-07-20 14:52:20 | |
| transcribe | done | 1/3 | 2026-07-20 14:53:29 | |
| summarize | done | 1/3 | 2026-07-20 14:54:22 | |
| embed | done | 1/3 | 2026-07-20 14:54:24 |
📄 Описание YouTube
Показать
In this Fireside Chat at ProductTank Sydney, Marty Cagan, Author and Partner at SVPG, reflects on the evolving role of product managers, the decline of traditional “product owner” roles, and why the era of the product creator has never looked more promising. Speaking with Malte, he discusses the shift from feature roadmaps to outcome-driven product management, the rise of AI-powered discovery tools, and what leaders must do to empower their teams effectively. The conversation also tackles ethical guardrails in AI, the impact of banking culture on local product communities, and practical advice for those aspiring to build careers in product. Chapters 0:00 – Introduction and context 2:00 – The three types of product managers 6:00 – From product owner to product creator 9:00 – Outcomes over outputs 13:00 – Agency and prototyping as superpowers 16:00 – The role of leadership in empowering teams 22:00 – Product vision, strategy, and alignment 25:00 – Discovery, prototyping, and new AI tools 33:00 – Changing team composition in the AI era 38:00 – What makes AI products different 43:00 – Continuous discovery and ethical guardrails 47:00 – Forward deployed engineers and enterprise discovery 51:00 – The product community in Sydney (and parallels with New York) 56:00 – Audience Q&A: proliferation of PM roles 1:06:00 – Leadership support and transformation 1:08:00 – Competitive advantage in a world of fast followers 1:16:00 – Career paths, MBAs, and the future of product jobs 1:22:00 – Advice for aspiring product managers 1:28:00 – Replatforming, risk, and high-integrity commitments 1:38:00 – Breaking into product management today 1:40:00 – AI ethics, guardrails, and viability risks 1:44:00 – Closing remarks Key Takeaways — The product owner role is at risk. Managing backlogs and outputs is not enough; future-proofing your career requires moving into discovery and outcomes. — Empowered teams need strong leadership. Empowerment is not the absence of direction; leaders must invest in developing people, setting strategy, and providing context. — Agency is essential. High-agency PMs and creators prototype, test, and show solutions rather than wait for permission. — AI is changing both discovery and delivery. Tools make prototyping faster, but delivery still requires experienced engineers for scale, reliability, and performance. — Moats are built on customer understanding. Deep knowledge and trust with customers provide lasting advantage in a world where features are easily copied. — Careers in product are shifting. Demand for true product creators is rising, while feature-team PMs and backlog managers risk being replaced. — Ethics is part of product viability. PMs are often the first to spot ethical risks in AI and need to escalate them thoughtfully.