Continuous Discovery Habits | Teresa Torres in conversation with Sohrab Salimi
Agile Academy · 2025-08-21 · 48м 57с · 519 просмотров · YouTube ↗
Топики: product-discovery-loop
🎧 Аудио
📝 Summary
model=deepseek-v4-flash · prompt=summary-v7 · 11 778→2 863 tokens · 2026-07-20 14:07:00
🎯 Главная суть
Тереза Торрес предлагает системный подход к continuous discovery — непрерывному процессу принятия решений о том, что строить, с фокусом на потребности клиентов. Ключевая идея: discovery — это не разовое исследование, а ежедневная привычка, которая формируется через маленькие шаги (например, еженедельные интервью с пользователями), а не через масштабные организационные преобразования. Основные инструменты — интервью для понимания контекста пользователя и тестирование предположений, а ключевые участники — кросс-функциональная команда (product trio), включающая инженеров.
Почему discovery — это моральная обязанность
Торрес считает, что индустрия тратит огромные человеческие ресурсы на продукты, которые никому не нужны. В цифровых продуктах легко иметь мнение о том, что строить, не основанное ни на чём. Это приводит к напрасной трате времени и энергии талантливых людей. «У нас есть моральная обязанность: раз уж мы так много работаем над созданием продуктов, пусть это будут вещи, которые действительно нужны людям». Помимо экономической неэффективности, discovery помогает избежать воспроизведения социального неравенства в продуктах — ещё один аргумент в пользу встраивания пользователя в процесс.
Основные отговорки и почему они не работают
Самая распространённая жалоба: «моя компания не даёт мне заниматься discovery», «у меня нет времени», «меня оценивают по поставкам (delivery)», «встречи забивают весь день». Торрес категорична: все эти препятствия реальны, но они не освобождают от ответственности. Discovery не требует одобрения начальства — достаточно найти один маленький способ начать. Например, если компания запрещает общаться с клиентами по регламенту, можно поговорить с другом, который пользуется таким же продуктом (банковской картой, больничным пропуском). «Нельзя принимать решения на основе нулевых разговоров. Если у вас нет идеального исследования, это не повод не делать ничего».
Discovery — это не research
Торрес чётко разделяет академическое/долгосрочное исследование (research) и быстрые ежедневные ответы, необходимые product-командам. Research требует повторяемости, валидности, десятилетий. В индустрии такого времени нет. Discovery — это два основных действия: интервью для понимания контекста пользователя и тестирование предположений для оценки решений. Ни то, ни другое не является «настоящим» research, но это не проблема, потому что product-команды могут быстро измерить, повлияли ли они на поведение пользователя. Это цикл обратной связи, которого нет в академической науке. При этом Торрес подчёркивает, что даже «быстрые и грязные» методы должны учитывать базовые принципы валидности и надёжности — формулировка вопросов, контроль предвзятости интервьюера.
Территориальные войны — это токсичный подход
Разговор о discovery вызывает сопротивление у UX-исследователей и дизайнеров, которые боятся, что их «специальные» навыки обесцениваются. Торрес считает это проявлением токсичной культуры «захвата территории». Она напоминает, что большинство навыков в индустрии осваиваются на практике, а не благодаря врождённой исключительности. Вместо того чтобы защищать функции, нужно сосредоточиться на том, как работать вместе. Внедрение discovery не сокращает потребность в UX-исследователях, а наоборот — создаёт спрос на долгосрочные исследования (например, diary studies), которые команды не успевают делать сами. «Работы хватит на всех».
Product trio: почему инженеры должны быть в discovery
Идея product trio — это не жёсткая ролевая модель (только PM, дизайнер и инженер), а призыв включить все ключевые кросс-функциональные роли в принятие решений о том, что строить. Если в команде есть штатный UX-исследователь, он должен быть в trio. Но обязательный участник — инженер, потому что именно он знает, что технически возможно. Исключать инженеров из discovery — значит принимать решения без учёта реалий. Торрес сравнивает это с тем, как дети на детской площадке собирают конструктор: они не выстраивают конвейер «ты дизайнер, ты инженер», а вместе придумывают и пробуют. Пример marshmallow challenge: MBA-студенты строят иерархию, а дети просто сотрудничают — и выигрывают. Product trio возвращает такое естественное сотрудничество.
Организационные изменения начинаются с одного человека
Торрес имеет магистерскую степень по организационным изменениям и утверждает: CEO не могут эффективно «провести» организацию через изменения. Каждый сотрудник проходит изменения в своём темпе, и настоящий сдвиг происходит только когда почти все меняются индивидуально. Поэтому бесполезно биться головой о стену, требуя, чтобы компания изменилась. Вместо этого нужно изменить свою собственную работу: говорить с пользователями, показывать результаты, делиться инсайтами внутри компании. Это вызовет любопытство у коллег, и только тогда у вас появится реальное влияние. Призыв: перестаньте ждать разрешения и начните действовать — это единственный путь.
Как начать с малого: первый шаг
Самый простой и первый шаг — поговорить с одним пользователем. Торрес сталкивалась с командами, которые годами не общались с клиентами. Пример: команда, разрабатывающая систему бейджей для входа в рабочие станции для врачей и медсестёр, не могла договориться о встрече с клиницистами внутри компании — у тех плотный график. Тогда Торрес спросила: «У кого-то из вас есть родственник-врач?» Оказалось, дядя PM — доктор. Возможно, у него есть такой бейдж. Разговор с дядей — не идеально репрезентативный, но значительно лучше, чем ноль. Второй шаг — делать это еженедельно, превращая в привычку. Даже если первые интервью предвзяты (друзья и семья), они всё равно дают информацию, которой раньше не было.
Интервью всей командой: почему это важно
Торрес рекомендует, чтобы trio (PM, дизайнер, инженер) проводили интервью вместе. Причина: мозг каждого человека фильтрует информацию через свой опыт. PM может услышать один сигнал, инженер — другой. Разные фильтры дают более богатое понимание потребностей. Совместное интервью не должно быть допросом: один человек ведёт беседу, остальные слушают, задают уточняющие вопросы. Если тема чувствительная (например, здоровье), можно записать интервью и дать посмотреть остальным, соблюдая анонимность. Главное — не полагаться на то, что один человек перескажет встречу: без личного присутствия теряются нюансы.
Opportunity Solution Tree — визуальный инструмент для избегания преждевременных решений
Торрес разработала дерево возможностей и решений (OST), чтобы команды не перескакивали от результата (outcome) напрямую к решению. В продакт-менеджменте распространена ошибка: услышали потребность — тут же предложили решение. OST заставляет сначала рассмотреть несколько возможностей (opportunities) — проблем, которые нужно решить, — и только потом несколько вариантов решений для каждой. Это повышает качество решений, как при поиске квартиры вы смотрите несколько вариантов, а не одну. Дерево визуализирует все альтернативы и помогает команде совместно выбрать, где играть (where to play) и как выиграть (how to win).
Ресурсы для дальнейшего развития
Книга «Continuous Discovery Habits» доступна в печатном, электронном и аудиоформатах (аудиоверсия выходила через пару недель после записи интервью). Для практической поддержки запущено платное Slack-сообщество members.producttalk.org: групповые коуч-сессии дважды в месяц, книжный клуб, еженедельные подборки материалов, ежемесячные челленджи для тренировки привычек. Также есть онлайн-курсы с живым инструктором (learn.producttalk.org): по интервьюированию, определению outcomes, выявлению скрытых предположений и тестированию гипотез. Расписание учитывает разные часовые пояса.
Финальное напутствие
Торрес призывает product-менеджеров, дизайнеров и инженеров не ждать, пока компания изменится. «У вас больше влияния (agency), чем вы думаете». Не нужно пытаться переделать всю организацию сразу. Достаточно найти маленькое место для старта — поговорить с одним клиентом, показать инсайт коллеге, повторить на следующей неделе. Итеративный подход к внедрению discovery сам по себе является проявлением «continuous improvement».
📜 Transcript
en · 8 603 слов · 107 сегментов · clean
Показать текст транскрипта
Hello, and welcome to our next edition of the Agile Insights Conversation Series. Today, I'm very fortunate to host Teresa Torres, who has wrote one of the best books, I think, on product management, on product ownership. And you'll know why I think this when we get into this conversation. But before we get started, I usually don't like to introduce our speakers, but because I want them to introduce themselves, they know themselves much better than I can. So I would want to start with giving Teresa a bit of time and space to quickly introduce herself to us, to our audience. And then based on that introduction, we will dive into the topic of the book, which is right behind her, Continuous Discovery Habits. teresa welcome to the show very delighted to have you and thank you already for donating your time to us and your wisdom and give us a quick introduction about yourself yeah thanks for having me so i'm teresa torres i work as a product discovery coach that means i help teams make better decisions about what to build and it really comes down to how do we do that in a customer-centric way through experimentation through interviewing And then I'm also the author of the book, Continuous Discovery Habits, and I blog at producttalk.org. Cool. And you're joining us today from where, Teresa? I'm seeing a comment that a little bit quiet, so I'm going to adjust my sound levels a little bit. I am joining from Bend, Oregon. So the West Coast of the US, smack dab in the middle of the state of Oregon. Okay, cool. West Coast of the US. So, Teresa, when I... when i found your book actually i got introduced to it by by a friend of mine oliver winter who i think also to some extent contributed to the book at least his name is in the in the end where you where you thank many people with whom you co-developed or who who acted as your sparrings partner i guess through this process of writing the book and when i saw the book all three words meant something to me the continuous piece obviously right when you think about agile product development or product development in general it's a continuous journey then the discovery piece and we dive into that much more and especially the habits piece but before i bring in my interpretation i would like to know why did you call this book the way you called it why what do these three words individually and collectively mean to you yeah so i think Discovery as a concept has become very helpful in the sense that I think it's easy to put a big emphasis on delivery and what we're shipping. And of course, that matters. That's how we get value to our customers. But I think it puts equal emphasis on are we building the right things? How are we making good decisions about what to build? I think across the industry, we're seeing a shift from a project mindset to a continuous mindset. I think that's really important, especially for digital products. Although I would argue this is bigger than digital products, but especially for digital products. And then the habits piece, one of the things that I look at is most product teams are working in organizations that are still output driven and project driven. And so how do we make it as easy as possible to shift to a more continuous mindset and to put more emphasis on discovery? And I know just we know from like behavioral psychology that if we just rely on willpower and motivation, we're not going to be successful, right? We really have to lay the foundation by building strong habits, just like when we're trying to adopt healthy habits in our own personal lives or good social habits or whatever the case may be. It's really just taking this lens of how do we make it easier to do this than to not do it. Yeah, I like the point that you mentioned at the end, right? How do we make this easier to do this? Because for many organizations and for many individuals, the process of discovery, let alone continuous discovery, is very hard to get started with. But once you build the habits, at least that was then my interpretation going through the book and your thinking was once you build the habits, it becomes the norm. and it then becomes very very easy to do right but initially you need a lot of discipline and and this is one of the areas where where i want to talk to you more today but let's start with um discovery itself and you start your book with a section about basically laying out why discovery matters can you share and you already did this to some extent but can you share with our with our listeners with our viewers Why does this topic of discovery matter so much to you and also to many of the clients that you work with? Yeah, I mean, here's the reality. We're really still in the early days of digital products and even forget the early days. Even if we look at physical products and mature products, we just have a lot of gaps between what we're trying to do and what actually happens in practice. And I view it almost as like we have a lot of really smart people spending all day, every day on products. That's like a lot of lives. That's a lot of hours of productivity and work that in a lot of ways we're wasting if we're not creating a close connection between the needs of our customers and the products that we're building. And in the product world in particular, it's so easy to have an opinion about what to build. And that opinion doesn't have to be based on anything. And there's a cost to that. Like if you just have an opinion about what to build and it's not grounded in any evidence, it's not centered in what your customers need. You're going to spend a lot of time and energy building something that may or may not be helpful to anybody. And so on some level, I feel like we have sort of this moral obligation of like, if we're going to work this hard to create things, let's make sure there are things that people want. And then there's this sort of second part of it of I just see all around me, like on my phone and on my computer and out in the world, just things, products that fall short. We really just... can get a lot better at this and then i think another realm is we're starting to see a lot more conversation around products that replicate the inequities we see in our communities in our products that's a whole nother area that i think discovery can help with um so i think i think it's it's really about we spend a lot of time building these products we could probably spend a little bit of time making sure that they're going to create value for somebody Yeah, absolutely. So you mentioned some of the reason why this matters to you and ideally should also matter to organizations because no organization wants to waste the energy, the talent and the money that goes into building stuff that nobody wants. Now, when you work with organizations, and I mean, most of them are not stupid, but when you work with them, what do you observe being the main reasons? for them, and I would include myself as well in that, right? What do you observe being the main reasons for them not doing discovery as you see it? What keeps them back from doing this? Yeah, I want to go back to something you started with. You mentioned that getting started with discovery is hard. I don't actually think it needs to be hard. I think we think it's hard. And the reason why we think it's hard is because it's so counter to how business has traditionally worked, right? So we have this sort of... we got to push back against our internal culture and that feels hard but it doesn't have to be hard i think what's hard organizational change is hard but i think for any individual in a company to start to adopt some of these habits it does not have to be hard i think the key is to find a teeny tiny place to start and then to iterate from there it's really embracing a continuous improvement mindset from the very beginning and i think every single one of us it doesn't matter where you work or how your organization works You know somebody who's like your customer. You know somebody who's talking to your customer. You have a way to get started. And I think it's that it's really easy for our brains to see all the reasons why we can't do this. And I think it's really about flipping the nuts on its head and looking for the smallest way you can get started and then just iterating. So what I see in many organizations that I work with is, and you already spoke about discovery versus delivery. And what I see a lot is all the metrics in an organization and all the incentives, at least in traditional organizations, are framed in a way that you're not incentivized to do discovery. that you're actually incentivized in many cases, if you look at the short-term metrics, to do primarily delivery, focus on like getting the things out. And then once the product is done, you basically, you're like, okay, we did our work to the best of our knowledge, but whether it now creates an impact for customers and ultimately based on that for your business becomes like secondary. Do you see that as well, that the metrics in an organization's don't incentivize to do good discovery work? I don't think a good product person needs to be incentivized to do discovery work. That may sound harsh, but if you want to be a product person, you got to find a way to do discovery. I don't care what your organizational context looks like. And here's the deal. Like I didn't work places where I had like a VP or a CEO be like, here's some space to do discovery. Like if you want to serve a customer, you have to understand who your customer is. Full stop. That's just the reality. That's the world we work in. And yes, it's true that most organizations, that's not how they think about it. Nobody's telling you to do this. Nobody's holding your feet to the fire saying, if you don't do this, something bad's going to go wrong. And I get that a lot of people are in meetings all day long and we already have way too much work on our plate. If you want to build something that people care about... you have to talk to your customers it's just that simple and i think everybody every single person without exception has the ability to do it has the ability to find a way and i'm sort of um frankly a little bit tired of this excuse of like my company won't let me i don't have time i'm incentivized i have these horrible delivery deadlines we all do every single one of us does and i feel like um frankly like we all the only way anything is going to change is if we each individually start making the change happen yeah so i don't i don't have a lot of uh i mean sure i have sympathy for it like i've been in that situation i know it can feel overwhelming i know it can be hard but you know what like that's why we get paid to do this we have like one of the best jobs in the world and i think that um it's our responsibility to go out and do it yeah No, I love that you're this frank and that you're basically saying there is no excuse to not do it. Now, when I listen to you, right, one of the things that we teach product people is you have to prioritize what you build. Now, maybe prioritization actually starts with your own time on where do you spend your time. Do you spend your time in meetings that are not going to add any value to your customers? Or are you going to prioritize the time to talk to your customers to get a better understanding? Maybe even have your team speak to customers as well so that you can speak to them like on the same eye level more or less. And based on your now deeper understanding of customers, you're going to build better stuff. You're going to probably have less debates in meetings where everyone is just talking based on their own assumptions. And no one is talking based on real knowledge and experience and observation. And through that kind of prioritization, you make the right call to actually move forward and drive customer success and through that business success. I think it's very important to point these things out. Now, getting to discovery itself, what is discovery exactly to you? You already mentioned like speaking to customers, et cetera. But what else is... part of what you define as discovery and probably many other people. I know you refer to Marty Kagan quite a lot, et cetera, but what is it to you? I mean, I think broadly discovery is just the work that we're doing when we're deciding what to build. It's that simple. I think good discovery includes the customer in the process. And I think it's when we talk about including the customer in the process, now we're getting into sort of research methods. Frankly, I don't love using the word research anymore in connection to discovery because I don't think anybody in industry is doing real research. I'm seeing a lot of user researchers get upset that they think that product teams are now doing their job. I don't think that's true. I think that what product teams do is not research. We're trying to get fast answers to our daily questions. We have really good feedback loops. We're trying to influence user behavior. I think from a discovery standpoint, there's two core activities. there's interviewing to understand your customer's context and there's assumption testing to evaluate solutions and the reason why i would say neither of those activities are true research is that if we think about the word research usually we associate it with academic research and we have this standard of research what makes research valid what makes research reliable and i i'm hearing more and more uh ux researchers complaining that discovery isn't good research neither is most user research it turns out industry doesn't have time for good research right good research takes decades where multiple people replicate studies before we learn anything nobody in industry has time for that so now it's shades of gray it's like how reliable how valid does our work have to be to be able to make decisions off of it and i think where user research is really valuable is that we do have longer horizon questions that user researchers should be answering things like where What's going to happen in our market? What's long term customer behavior? That's different from discovery questions. Discovery questions are, what do I need to be building next? That's a very short term sort of research question that we're answering. By the way, not with real research because we don't really have time for real research. And the reason why that's fine is because we're putting a stimulus out in the world and we're seeing how people react to it. That's a feedback loop we don't have in real research. And so I would argue that discovery is not research. Discovery is just the work we're doing to make better decisions about what to build. There's some research-like activities we can do as part of discovery, whether that's interviewing customers to uncover unmet needs, pain points, or desires. and assumption tests to evaluate potential solutions and the reason why those can be quick and dirty research methods i'm putting research in quotes because i don't think it's real research is because again we're just trying to influence behavior and we can quickly measure did we influence behavior yeah no i like i like the fact that you also mentioned that this is not like traditional research because i'm by background a medical doctor so i've been through this research process right working on phd stuff etc and if you if you compare these two i mean research in the scientific field is always looking backwards so you see something happen now we can look at covet right then you see a million people getting this and then you do your research and then you have it peer reviewed so you have a high end you have multiple people being involved and you have a long time horizon as you mentioned right now when we when we're building products we're not looking backwards we're trying to understand patterns of customer behavior and then build products that either support this behavior or help people or nudge people into a different type of behavior so i like the fact that you say this is not real research neither is ux research it's actually a different thing where we use similar things quick and dirty because you don't have the time but not having the time is not an excuse to skip it all completely because we cannot do it in a perfect way as academics do we can still do a lot to validate our assumptions and here's here's what i'm going to say about this it doesn't mean we shouldn't pay attention to reliability and validity so those are research concepts right how repeatable is our research how likely is what we're learning reflecting reality. Those are really important concepts that we should pay attention to and how we conduct an interview, the questions we ask, the way that we account for different biases in the process will have a big impact in the reliability of the feedback we collect. So it's not that we shouldn't be learning from research methods. It's that I'm starting to see this like territorial battle. Like user researchers are saying, product teams are now stepping on our territory with discovery. First of all, I don't think that's true. I think there's still a need for longer horizon user research. And there's a need for product teams to get fast answers to their daily questions. So I don't think there's a territory battle there at all. I think what's happening on the research side is exactly what we saw on the design side. that we still see on the design side, we deem designers as special and they have this unique ability that other humans don't have, which I think is baloney. I'm not saying designers don't have skill and there's not a skill of developing design skills, but it's something we learn and most of us learned it in industry practicing, right? The same is true on the user research side. There's skill there and there are people that are better at research than others but the vast majority of us learned it in industry and so then to turn around and say you other person in industry you can't do this because i have special skills you don't i don't buy it i just i don't buy it that's territory it's it's people being territorial it comes from i think really toxic business culture of like land grab territory space and i would much rather we have conversations about how can we work together and i'm recognizing that i clearly woke up on the wrong side of the bed this morning i'm not usually this early so i apologize no but honestly i like that so it's very to the point that's very frank and and similar to you i mean you mentioned that that you're tired of hearing excuses and in in the field that i work where it's mainly about organizational change organizational redesign right how do we set up our organ our whole organization not just one team but how do we set up our whole organization to be better at doing this work and to be honest i'm also tired at like the ceo of an organization telling me like he can't do anything about it i'm like if you can't do anything about it who can because this organization was ultimately designed by you or your predecessor or whoever now you also have the ability to change it and you mentioned this like territorial fights i think when we think about the organization of the future it's not about individual territories it's about us as an organization building great stuff for our customers and it doesn't really matter where these insights come from and honestly if you're a user researchers be happy that now the work that you do is getting to a much higher level of attention and more and more people are trying to do that because in the past you were fighting to get the customer's perspective into the product and no one was listening to you so i think i mean i think there's this fear right like i started with design if everybody on the product team is doing discovery does the designer lose some specialness of no longer being the voice of the customer and now we're seeing that with user research here's the deal like i get it people are feeling threatened but There's so much work. There's going to be enough work for everybody. User research is not going away. Design is not going away. If anything, putting more of an emphasis on discovery is going to elevate these roles. We're going to see more companies hire user researchers. Because when we get fast answers to our daily questions, we see that we actually have weekly questions and monthly questions that also need slower answers. And that's exactly what... user researchers excel at like no product team no product team doing discovery is going to do a diary study nobody has time for that user researchers have time for that and we need that that's a great um research method that inform that can inform our product work so it's not about i i really wish uh i could just give everybody a hug and say look Your job's not going away. You're not threatened by these ideas. It's really about how do we all get better at working together? And on the org change side, I went back and got a master's in organizational change. And my takeaway was this simple. We can't really influence organizational change in the way that we think. I get why CEOs say they can't influence organizational change. Here's what's required for an organization to change. Every single individual has to go through the change on their own timeline. Individuals change at different rates. And it's not until almost everybody in the organization goes through the change that the whole organization actually changes. Which means whenever an organization is trying to go through the change, it's utter chaos for a really long time. Okay, so what do we do as an individual contributor? We can bang our heads against the wall and like try to... influence that process that, by the way, your CEO is barely even influencing. That's crazy town. Like I wouldn't do that. What we can do is we can focus on our own work. We can change the way we individually work, which has two benefits. One, if everybody did that, the organization would change a lot faster. And two, when we do that, other people get curious about how we work. And that's when we have the ability to influence. But that's not what most people do. most people don't start with themselves they start talking about the right way to do things and they advocate without changing their own behavior and it just becomes my opinion versus your opinion and we get nowhere so this is a little bit why like i'm tired of the excuses like the only way organizations are going to change is if all of us individually i feel like i'm like a community organizer right now if all of us individually make a decision to like work this way and and to be customer centric that's really the only way this is going to happen that's another i've been hanging out on twitter too long which is why i'm kind of uh tired right now but like another thing that keeps coming up is like all these thought leaders are writing about this way of working and nobody's really working this way and they they take that as a criticism you know what 98 of people don't do discovery does that mean discovery is bad and that this model sucks and that it's all a sham Yeah, you're right. We shouldn't be customer centric and we shouldn't build things that customers want. Let's just go back to the old way. How is that an argument? I don't get it. This isn't meant to be this revolutionary new idea. It's meant to be, how do we better serve our customers? How do we get closer, even if we're just inching our way there? Because frankly, that's the only way anything's going to change. The norm is, the status quo is pretty depressing. right like it is so um i wrote you an email yesterday and in that email i wrote when i was reading your book i was constantly asking myself why hasn't anyone written this book yet and that i'm very happy that you ultimately went and and wrote it because the topic of discovery i mean i being one of the people that treat teach methods like scrum etc i've always considered scrum not only a pure delivery method Because one of the first teachers I had is Jeff Patton. And in one of his trainings, he said, like, what happens if you build shit faster? You just get more shit, right? And I never forgot that quote. And the rest of the training is like, all right, I talked to you about delivery. Now let's all focus about discovery because other people can teach you delivery. Very few people can teach you discovery. So I was aware of the importance of this topic. Now, another thing that happened when I was reading your book was, I'm not going to say your unique take, but I think very few people have written about it the way you did, is that discovery is not something that designers do or only designers do. Because you speak about this concept of a product trio. And we were just talking about this territorial grab. And I thought it would be interesting to bring this up because you believe, and correct me if I'm wrong. the discovery is done by this product trio consisting of product people design people and engineers is that correct did i get that right yep yep and why is it so important to you that discovery is not only done as it is traditionally by the designers but i mean the product person okay but then also the engineer is involved in this because that would just make the territorial grab much bigger right could result This is another topic that I didn't realize was going to be controversial when I put the book out. The product trio isn't limited to those rules. I think this is also where user researchers are feeling left out. If you have a user researcher on your team, they sure as hell better be on your product trio. I'm just going to say that. If you have a full-time user researcher on your team, include them in your trio. That should be a no-brainer. The idea of a product trio... is taking a cross-functional approach to the decisions that we're making. Period. That's it, right? So in most companies, on most teams, the cross-functional roles represented are product managers, designers, and software engineers. I was not trying to say, exclude your researchers, exclude your content marketers, exclude your journalists if you're a newspaper, whatever. I don't really care what the role is. It's for your team and the type of product that you're working on. What are the right cross-functional roles that need to be represented when making decisions about what to build? That's the idea. And the reason why we want engineers involved is because they're the ones that know what's possible. Why would we exclude them from our decisions about what to build? So like my goal here in all of this is how do we get back to building things like humans? and breaking these weird cultural norms we developed in an assembly line business culture. So much of our business is influenced by Taylorism in the industrial age where we are focused on efficiency and how do we crank more widgets off of an assembly line. Well, software doesn't work that way. It's too complex. There's too many open-ended problems. We actually need creative humans to work together. in a way that like i used to use this analogy of like if you were a bunch of kids on a playground and you decided to build something out of like building blocks you wouldn't create an assembly line you wouldn't be like you're the designer and you're the engineer you'd all put your heads together and create something together and people would just use their natural strengths and blur boundaries between roles and get something done in fact there's a really cool uh the marshmallow challenge is a great example of this where they took teams of business students mba students and like kindergartners and gave them like spaghetti and a marshmallow and they basically were told to build a structure and make the marshmallow as high as possible and what happened like kids just worked together and tried things mba students like tried to be experts inside right like and the kids outperformed the mba students We forget how to collaborate. We forget how to be human. We forget how to solve problems together. My goal is to get us back to that. How do we get back to working together as a team? Which is why when people push back on some of these ideas because they're worried they're being left out, I literally want to shout from the mountaintops, you're missing the point. We're not leaving you out. We're trying to bring everybody back together. to actually work together as humans not to get into this like my territory versus your territory so if i understand this correctly the same or the similar type of cross-functional team that we would want to have in delivery right we would want that that type of people also working in discovery because they know what the customers want they would know what is technically possible they would know like what is the product strategy where where do we want to take this as an organization and all of those things combined result in in better ideas on on what to actually build and better experiments to validate whether we're going to build this the second point you brought up is you brought up this analogy to the kids in the marshmallow challenge So when I talk about or when I read about the topic of discovery, what comes back to me is always like, we need to get back to being curious. Like kids, right? Kids are very curious. Kids do not pretend that they know stuff. They actually are very okay not knowing and asking and trying to understand. But when I look at most organizations that I work with, When I look at myself in many cases, we believe we're good if we know, because to some extent we've been trained this way. And I think aiming to know we don't spend enough time being curious and then doing discovery. How do you see that? I think curiosity is a big piece of it for sure. And I think this is where business culture gets in the way. Businesses reward us for being right. They don't reward us for being curious. So this is where I think it is. There is some. It does take a little bit of a leap of faith for all these individuals to create the space to be curious. But I think equally important to curiousness is we also just don't know how to collaborate cross-functionally. And we see this at the highest levels of our organization. Very few companies have well-functioning executive teams because we don't know how to collaborate cross-functionally, right? And so... Curiosity is a big piece of it, and I don't want to trivialize that, but I know a lot of curious people who are struggling in their organizations. And it's because we really do have to learn. It's like we're in kindergarten when it comes to collaborating. We don't know how to do it. We weren't taught how to do it. Think about all your school years. Maybe in a graduate program, you got to more robust group work. Right. But maybe not. A lot of people still don't even at that level. We just don't learn how to collaborate. And that's one of the things I really focused on in the book is teaching people how to collaborate visually, because I think it's one of the best ways to stay aligned and to really short circuit some of that like endless debate that we're so afraid of when collaborating. And so I think that's the other piece of this is you can individually cultivate your curiosity and you definitely should. but you also need to learn how to do it as a team and how to be curious about your teammates perspectives and how to slow down and not just be focused on my opinion is right but oh i think something different from you why is that let's explore our unique perspectives yeah i like that piece so curiosity and collaboration both of them are are tremendously important skills to to build up now you mentioned earlier when we talked about why is it so difficult, you said it doesn't have to take this giant leap. You can start out small. So what are a few small things that teams can do to get on this continuous discovery journey? The very first thing anybody listening should do is they should talk to a customer. It's really sad to me how many people work on product teams that have literally never talked to a customer. like never once and i i mean i met a product manager at a bank who had never talked to a customer and when i asked why they had all these reasons like i'm not allowed to talk to the customers there's all these regulations in place you know what i said do you have a friend who has a bank account like really you're looking at a bank and you can't talk to someone who's like your customer i worked with somebody else so i coached a product team they're Customers were clinicians, doctors and nurses. They worked on a badging system for like to badge into a workstation to be able to chart, right? Okay, that team really struggled to talk to clinicians because clinicians are busy and nobody at their company, they had no avenue to get to them. And they spent weeks like trying to get, they even had clinicians at the company. So first they spent weeks just trying to get meetings with those clinicians. And they failed because it was a company where they have a meeting culture and they were in meetings 14 hours a day and it was going to be three weeks before they could get on that person's calendar. So we're sitting on a coaching call. There's three of them on the call, the product manager, the designer and the engineer. I said, hey, do any of you know any clinicians in your personal network? The product manager's uncle was a doctor. And I was like, OK, do you think maybe your doctor has a badge he uses to badge into a workstation? Maybe you could just have a conversation with him. Now, is that perfect? Maybe it's easier to get on his calendar. Yeah, like, is that perfect? No. Is it better than zero? Yes. Right? Like, this product team is just speculating about what a doctor's life is like. And all they have to do is have a conversation. And then the pushback I get is like, is it really safe to make a decision off of one conversation? Is it really safe to make a decision off of zero conversations? Right? Like... This is where like we're letting perfect be the enemy of good. So no matter what, like I don't care what your organization is like, I don't care what regulations are in place. You have the ability to talk to somebody who's close to your customer profile. Without exception, every single product person, that's where you should start. Yeah. so you mentioned the clinicians i i recently had a similar experience with a team building a a new basically the chemical marker to diagnose sepsis right and i asked them have you talked to your customers they're like yeah we're not allowed to talk to patients yeah but the patient is not your customer who's your customer they're like yeah so the clinician and the lab doctor so are you allowed to talk to them they're like probably yes so have you done it no how can you also they are allowed to talk to patients they're not allowed to talk to patients going through the health channels because we have hipaa laws right they are allowed to talk to patients i've worked with teams that interview patients they recruit on the internet and screen for whatever condition they're looking for and by the way is they if that person opts in you don't have a hipaa violation anymore Because you're not going through the healthcare system, right? Like I can run an ad saying, do you have this condition? Will you talk to me for $100 Amazon gift card? There's no problem there. You don't even have to because there are so many like patient communities out there. You just get in, you just tell them what you're planning to do. If they realize that you're working on something that will improve their lives, their quality of life, many of them speak to you for free. And I'm going to tell you. Especially with healthcare, people push back. They're like, people aren't going to be willing to talk to us about their health concerns. Here's what I'm going to tell you. I've worked with teams at Planned Parenthood that interviewed women about really emotional decisions to have an abortion. They were willing to talk about it. I worked with a company in the UK that treated erectile dysfunction. Those men were willing to talk about it. I don't care what your realm is. You can find a way to talk to your customers. Okay, so number one, start talking to your customers. Now, what is the next thing you would recommend? The next small thing, remember, right? We're trying to make small habit change, not take the big move. I think after you've talked to your first customer, you want to start looking at how do we make this a habit? So I really want to see teams talking to customers every week. You don't have to get there tomorrow, right? If you're literally hustling to find your first conversation, find your second conversation. Once you start to get into this groove of like, oh, I do have people in my network like my customer. Here's what happens. Okay, let's say you work at a bank and your bank has regulations about who you're allowed to talk to and you don't know how to get through them and you're being told the product team is not allowed to talk to people. Great. Talk to your friends and family that bank. Is there going to be bias there? Yes. Are they going to be like you and you're going to not have a representative sample? Yes. Is it better than zero? Absolutely. Talk to those people. In those conversations, pay a little bit attention, like read a few articles on the internet about how to ask good questions, right? So you're working to make those conversations a little bit better. Share internally with the rest of your company what you're learning and how it's influencing the decisions that you're making. What does that do? It cracks the door open to, oh, there's value in these customer conversations. Even though we have all these weird regulations we got to jump through, maybe we need to find a way to make this happen, right? So we're showing, we're showing the value of doing this. rather than waiting and asking for permission and now you got to use your judgment don't get fired don't like ignore your company policies right like you're no company is going to tell this person they can't talk to their uncle about their work right that's safe so look for those safe ways to talk to people like your customer and then show the value of having done that to other people at your company that's what starts to bring change in your organization now when you mentioned talk to like your relatives friends etc is that is that you the product manager or would that be everyone that's on that product discovery or team or on that team in general i want to see trios interviewing together there's a reason for this we um filter our brains filter everything that we hear based on our prior knowledge and experience right so we've all had this experience you're sitting in a meeting you leave the meeting you walk away with a takeaway and your colleague in the same meeting walks away with a different takeaway why does that happen we don't perceive the world objectively we all think we do but we don't right everything that we're hearing and seeing is being filtered by our brains because we don't have the cognitive ability to process everything in front of us so our brain We have a whole bunch of cognitive biases that are basically shortcuts that usually work in our favor that's helping us perceive the world around us. The problem is those filters are tuned and they're tuned based on our previous knowledge and experience. So if we have a product manager, a designer, and an engineer, by the way, three different people with very different knowledge and experience, watching the same conversation, they're gonna hear very different things. We want that. that's how we get that more value from that conversation so to the degree that you can i want trios interviewing together now some people think like oh am i going to overwhelm the participant i mean if you're running your interview where if i pepper you with 100 questions and there's seven people watching you're going to feel interrogated right but if there's three of us and i just say hey here's what we're trying to learn by the way, tell us about a time when this happened and you tell us your story, it's going to feel like a conversation. You're not going to care that there's three people there. And if you're really concerned, like when we interview on sensitive topics like these health topics, I actually had those teams have one person conduct the interview. They recorded them and had the others watch them. And because it was a sensitive topic, they had to record them and then destroy the recording, right? So they had to follow some procedures to make the patient feel safe. to anonymize the data so like in really specific environments there's some extra things we might have to do but there are ways even in these really sensitive topics to allow everybody on the team to either participate in the interview or watch the interview after the fact and the benefit of that is you're leveraging everybody's knowledge and experience you're going to pull a lot more value out of that interview Yeah, I mean, even with the recording, people can get different interpretations of what that customer is saying. But being involved in the live interview, you can also ask questions from the technology perspective, from the product perspective, etc. Now, in your book, very early on, you introduce a tool called the Opportunity Solution Tree, OST, correct? Yep. So what I liked a lot is that tool helps us, is also part of the discovery work. Because what I took away from it is it helps us specifically look for multiple ways to solve a problem. Because I see in myself, but also in many others that, okay, they realize what the problem is, they immediately come up with an answer and that's it, right? Case closed. But with the opportunity solution tree, you force yourself to come up with multiple things. Was that the intention, the main intention to create such a tool? That's a part of it. So the opportunity solution tree definitely helps you visually see when you're only considering one option. And that's really important. A lot of this comes from decision-making research. We actually don't even need the research. We already intuitively know this. When you're looking for a job, you don't talk to one company. When you're looking for a place to live, you don't look at one apartment or one house. We know we make better decisions when we compare and contrast options. The reason why we forget to do this on product teams, one, is because of time pressure. And two is actually it comes from a good place, right? We hear a customer need. We actually want to solve it as quickly as possible. We're trying to serve the customer, so we jump to a fast solution. We know, though, we'll generate better solutions if we just suspend that a little bit and consider multiple options. This is especially true in the opportunity space. A lot of teams jump straight from outcome to solution, and they forget what are the most important problems to solve. Which is a really important strategic question to ask. Where are we going to play? What are the boundaries of the opportunity space that we're going to tackle as a team? And what are we going to leave for somebody else? So it ties in really well. I recently spoke to Roger Martin and he has this strategy development framework, like where to play and how to win. So that ties in really well. Now, what I liked a lot. similar to the topics that you already shared with us like speaking to customers interviewing them how to find those early customers to speak to but also the opportunity solution tree as a as a visual way to to a ask questions to make transparent how many solutions we are seeing to do that in a collaborative manner because visuals help us collaborate much better the book is full of these like tools tips and tricks on how to advance and ultimately build this habit You didn't ask me to do that, but I also wanted to spend a few minutes before we close this interview to ask you, where can people learn more from you? One is the book. And I think that's clear to everyone listening to this. But you also have a few programs out there where I hope or I guess you build individuals and teams over a period of time, build these habits. Is that correct? Yeah. So the first thing I'll share is the book is available. um worldwide it's called continuous discovery habits it's currently out in kindle epub and paperback the audible version is literally days if not maybe a week or two away actually this afternoon i'm going to record my final pickups so it's very close i know a lot of people have been waiting for that um and then one of the things that we did when we launched the book is we know that it's not enough to read a book people really need support as they're putting the habits into practice So we also launched a membership community alongside the book. The heart of it is a Slack community where we support each other as we're putting the habits into practice. We do community calls. So think of them as like group coaching calls where twice a month we just get people together and talk about their challenges, what they're facing. We do a book club. We share worthy reads every day. We run monthly challenges, just easy ways to invest in your habits. That's a really low-cost, easy way to get involved and to connect with other people who are trying to adopt these habits. You can learn about that at members.producttalk.org. And then we also have... Yeah, perfect. Thank you. And then we also have a variety of online courses that are designed to help you develop skill in each of the habits. So we have a class on how to interview well. We have a class on how to define outcomes. We just launched two new classes on identifying hidden assumptions and assumption testing. You can find all those options at learn.producttalk.org. And those classes are live instructor-led courses? They are live instructor-led courses. They're online, so you can participate from around the world. We try to offer them at different time zones to accommodate different time zones. Yeah, and you can find the upcoming schedule for all of those at learn.producttalk.org. Cool, cool. So Teresa, is there a final word you would want to share with product people, designers, and or engineers in order to get started with discovery habits, continuous discovery habits? Yeah, I'll just, I'll leave you with, I realize that most companies don't work this way. It can feel really overwhelming as an individual, but I want to really encourage you that you have more agency than you think. So look for small places to start and iterate from there. And I think you'll be pleasantly surprised by how much progress you make. Cool. We'll close with that. Teresa, nice hosting you. Thank you so much for being here. Thank you so much for having me. This was great. Sorry I was a little surly. All good. I loved it. I loved it.
⚙️ Pipeline jobs
| Stage | Status | Att. | Updated | Error |
|---|---|---|---|---|
| download | done | 1/3 | 2026-07-20 14:05:53 | |
| transcribe | done | 1/3 | 2026-07-20 14:06:24 | |
| summarize | done | 1/3 | 2026-07-20 14:07:00 | |
| embed | done | 1/3 | 2026-07-20 14:07:02 |
📄 Описание YouTube
Показать
Unlock the power of Continuous Discovery with Teresa Torres and Sohrab Salimi in this Agile Insights Conversation. In this exclusive interview, product discovery expert Teresa Torres (author of “Continuous Discovery Habits”) sits down with Sohrab Salimi, Founder & CEO of Agile Academy, to share actionable strategies for building better products through ongoing customer insights. Learn how discovery, development, and delivery fit together in successful product teams, why organizational redesign is necessary for effective product management, and how cultivating the right mindset and curiosity drives product innovation and team collaboration. Whether you’re a product manager, designer, or agile coach, this episode is packed with practical wisdom to help you lead teams that continuously learn, adapt, and create real customer value. If you want to master continuous discovery habits and empower your teams for sustainable success, don’t miss this conversation. 📌 Key Topics Covered: • The importance of product discovery and continuous learning • How organizations can redesign for better discovery practices • The difference between discovery and delivery • Why curiosity and customer interviews are crucial for innovation • Using the Opportunity Solution Tree for decision-making • Trios interviewing: unlocking team collaboration in customer research 💡 Key Takeaways: • Continuous discovery is a mindset, not a process • Customer insights should drive product decisions, not assumptions • Teams succeed when discovery, development, and delivery happen together • Organizational redesign enables sustainable product success 🌟 About Teresa Torres Teresa Torres is a renowned product discovery coach and author, specializing in helping teams embed continuous discovery habits into their daily work. Her practical frameworks have empowered organizations worldwide to build products customers love. 👉 Like, comment, and subscribe for more insights on Product Discovery and Agile Leadership! 🔗 Resources: • Agile Insights website: https://www.agile-academy.com/en/agile-insights/ • Online Agile courses: https://www.agile-academy.com/en/ #ContinuousDiscovery #ProductDiscovery #TeresaTorres #AgileInsights #ProductManagement #ProductLeadership #OpportunitySolutionTree #Sohrabsalimi #AgileAcademy