← все видео

Understanding Continuous Discovery with Teresa Torres

Product Thinking by Melissa Perri · 2024-02-14 · 44м 26с · 720 просмотров · YouTube ↗

Топики: product-discovery-loop

🎧 Аудио

📝 Summary

model=deepseek-v4-flash · prompt=summary-v7 · 12 709→2 595 tokens · 2026-07-20 14:29:45

🎯 Главная суть

Teresa Torres в книге «Continuous Discovery Habits» предлагает практический подход к продуктовой разработке, основанный на еженедельном общении с клиентами, визуализации гипотез через Opportunity Solution Tree и постоянном балансе между ценностью для клиента и бизнеса. Вместо разового исследования в начале проекта команды должны встроить discovery в каждодневную работу, чтобы непрерывно уточнять, какие проблемы решать и как это делать.

Как Тереза пришла к проблеме «отрыва от клиента»

Тереза начинала как дизайнер и frontend-разработчик в стартапах 90-х и 2000-х. Работая на разных ролях (вплоть до CEO стартапа), она повсюду видела одну и ту же проблему: продуктовые команды проводят слишком мало времени с пользователями. Для неё это было особенно удивительно, потому что ещё в колледже её учили, что обратную связь от клиента нужно интегрировать на всём протяжении разработки. В 2013 году Тереза решила целенаправленно заняться этой проблемой: начала консультировать, затем коучить и преподавать, а в итоге написала книгу и сейчас ведёт Product Talk Academy.

Ошибка с этикой: почему нужна вторая книга

Когда книга уже была почти готова, события 2020 года и движение за социальную справедливость заставили Терезу переосмыслить содержание. Она поняла, что упустила возможность глубже обсудить этические вопросы: продукты могут неосознанно воспроизводить неравенство (например, дозаторы для мыла, не реагирующие на тёмную кожу). В книге есть глава про «этические допущения» и их выявление, но Тереза считает, что этого недостаточно. Она планирует написать следующую книгу — практическое руководство по этике в продуктах, чтобы ответить на вопрос «как именно» разработчикам учитывать этические последствия своих решений. Она подчёркивает: «Мы должны создавать продукты вместе с людьми, а не для людей» — это ключевая идея continuous discovery, которая перекликается с книгой Design Justice.

Структура discovery: outcome → opportunities → solutions

Тереза выделяет три компонента любого процесса discovery, независимо от конкретного метода:

  1. Outcome (исход) — как компания создаёт ценность для бизнеса (например, рост прибыли, снижение затрат). Это целевая метрика.
  2. Opportunities (возможности) — потребности, боли, желания клиентов. Если их решить, они приведут к целевому outcome.
  3. Solutions (решения) — конкретные продукты или фичи, которые адресуют выбранные opportunities и двигают outcome.

Такая структура универсальна: Jobs To Be Done, Design Thinking, Lean Startup — все они работают с этими тремя элементами, но делают акцент на разных частях. Команда может выбирать любые методы для каждого этапа, главное — не пропускать ни один из них.

Opportunity Solution Tree: визуальный инструмент для выбора пути

Дерево возможностей и решений — это способ наглядно представить, как команда планирует достичь outcome. Начинается с одного outcome. От него расходятся opportunities (потребности клиентов). От каждой opportunity — возможные решения. Дерево помогает:

Используется на уровне команды, а не всей компании. Для верхнего уровня лучше подходит «карта клиентского опыта» (experience map), а дерево — для каждой команды, отвечающей за свой outcome.

Когда использовать Opportunity Solution Tree

Дерево нужно каждый раз, когда команда начинает работу над новым outcome. Даже если у вас ещё нет продукта (вы на стадии pre-startup), можно задать outcome — например, «помочь подкастерам увеличить аудиторию». Затем через интервью и наблюдения картируете opportunities (потребности, боли, желания подкастеров). Анализируете, какие opportunities уже закрывают существующие продукты, где есть пробел, и только потом переходите к решению. Если продукт уже есть — дерево помогает понять, что вы уже делаете, где пробелы и как дифференцироваться от конкурентов.

Две главные предпосылки для continuous discovery

Прежде чем внедрять непрерывное исследование, у команды должны быть:

  1. Устойчивое product trio — Product Manager, Designer, Engineer, которые работают вместе, отвечают за «что строить» и закреплены за одной частью продукта на долгий срок. Не должно быть, что trio разрывается на 17 проектов.
  2. Outcome-ориентация — руководство должно дать команде цель в виде измеримого результата, а не фиксированных фич. Если команде спускают список «что построить», внедрение discovery только создаст конфликт.

Эти условия могут быть выполнены не на всех командах сразу: многие компании начинают с 1–2 «песочниц», где создают правильные условия, чтобы потом масштабировать успех.

Ошибки при установке outcomes: урок Wells Fargo

Пример Wells Fargo (2016) — открытие счетов без ведома клиентов для выполнения планов по среднему количеству продуктов на клиента. Тереза использует этот случай, чтобы показать опасность привязки компенсации к метрикам и забвения клиентоцентричности. Если outcome формулируется как «увеличить среднее количество счетов на клиента» без учёта, как именно это достигается, команды начинают «читерить». Правильный подход: объединить outcome с глубоким пониманием клиента. Цитата Питера Друкера: «Цель бизнеса — найти и обслужить клиента; акционерная стоимость должна быть побочным эффектом».

Тереза отказывается от контрактов с компаниями, где компенсация привязана к KPI, потому что это убивает внутреннюю мотивацию (см. книгу Дэниела Пинка «Drive») и провоцирует плохое поведение.

Как представлять discovery на roadmaps

Традиционный roadmap — список фич с датами — это фантом, потому что инженерия неопределённа. Вместо этого Тереза предлагает формат Now-Next-Future с фокусом на opportunities:

При таком подходе у маркетинга и продаж нет конкретных дат, но они могут опираться на customer evidence (отзывы, истории успеха), полученные в процессе discovery. Маркетинг готовит материалы на основе ценности для клиента, а не просто запускает фичу.

Оценки и роль discovery в точности прогнозов

Когда инженеров просят оценить истории в двухнедельных спринтах без предварительного исследования, это чистый гадание. Тереза настаивает: в процессе discovery команда выявляет допущения, в том числе о реализуемости. Инженеры проверяют feasibility assumptions и по мере приближения к готовности получают всё более точные оценки. Чем ближе к моменту постройки, тем точнее можно сказать «3 недели», «6 недель» или «3 месяца». То есть точная оценка — результат хорошего discovery, а не отдельное упражнение.

Почему стоит отказаться от ежегодного планирования

Тереза сравнивает традиционное составление roadmap с «голым королём»: все знают, что планы иллюзорны, но продолжают тратить месяцы на их создание. После COVID многие компании поняли, что шестимесячный roadmap можно выбросить за день. Если бы команды работали непрерывно, единственным изменением в кризис стала бы смена следующей opportunity, а не переписывание всего плана. Тереза призывает: «как только вы замечаете, что останавливаетесь, чтобы сделать что-то (синтезировать интервью, создать roadmap), — вы уже делаете это неправильно».

Баланс customer value и business value

Тереза подчёркивает: цель discovery — создавать продукты, которые приносят ценность как клиенту, так и бизнесу. Если команда фокусируется только на клиенте, она рискует остаться без бизнес-модели (пример Google Reader — у сервиса были преданные пользователи, но не было бизнес-ценности, и его закрыли). Если только на бизнесе — забывает про пользователя. Правильный подход: строить дерево метрик (KPI tree), начиная с «увеличить прибыль» (или «усилить влияние на миссию» для некоммерческих), и через него связывать работу команд с итоговой стратегией.

Аудитория книги и где её купить

Книга ориентирована на product trios — PM, дизайнеров и инженеров, которые хотят получить конкретные практические методы. Она подходит и для лидеров, которые управляют такими командами, но не работали в continuous discovery сами. Купить можно на Amazon (paperback, Kindle), аудиоверсия ожидается к концу года. Также доступна через независимые книжные магазины по запросу. Ресурсы и сервисы для внедрения — на producttalk.org.

📜 Transcript

en · 9 067 слов · 97 сегментов · clean

Показать текст транскрипта
Creating great products isn't just about product managers and their day-to-day interactions with developers. It's about how an organization supports products as a whole, the systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary-pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader. This is the Product Thinking Podcast. Here's your host, Melissa Perry. Hello, everyone, and welcome to the Product Thinking Podcast. Today, our guest is Teresa Torres, who just wrote the book, Continuous Discovery Habits. Teresa is a product coach and a product teacher. She's done a lot of really cool stuff. So, Teresa, how did you get into product management? And can you explain to our audience a little bit about what you're doing now with your clients? Yeah, so I started actually as a designer. And really not even a designer because I learned design in college. I sort of got introduced to a human centered design program in college. But that was like the 90s and nobody was really hiring full time designers. So my very first job was actually as a front end developer where I did design work, which is kind of a funny entry point into things. And then over the course of a couple different jobs at early stage startups, I realized I'd actually always been doing product work. I just hadn't worked at organizations that knew what product was or what product work was. And so I always like to tell product trios, which is usually who I coach, that I've actually dabbled in all three roles at various points in my career, which is a lot of fun. And then I did a lot of my background was early stage startups where I got to play lots of different roles, which was super fun. I got introduced to the business side really early on. By 32, I was a startup CEO of somebody else's company, which if you're being offered a CEO job of somebody else's companies, not sure that I would take it again. I mean, if I had to do it over again, I learned it's fun. It was great. But I'd rather be a founder and be the CEO of my own company. And then I really just saw the same problem everywhere. Like no matter where I worked, product teams did not spend enough time with their customers. And this was really foreign to me because I was introduced to human centered design and integrate feedback throughout the development process, like as a 20 year old in college. And so in 2013, I just sort of got fed up of seeing the same problem everywhere and decided I really want to tackle this problem in particular. And so I started consulting. Consulting gradually led to coaching. Coaching gradually led to teaching. And so now I mostly focus on course design and teaching courses through the Product Talk Academy. I occasionally take on some coaching teams, although Hope Gurionna has mostly takes on our coaching. And then I wrote a book and I teach at Northwestern. I'm already thinking about what the next book is going to be. Oh, it's so soon. It's crazy. I'm not trying hard not to write a next book. I really think about myself these days as a teacher and a writer and I still do a little bit of coaching for past clients. Cool. You're glad for punishment. You're right into this book. When I finished Escaping the Bill Trap, I was like, I'm never writing again. It's just taken me until this year, three years later to be like, okay, fine. Maybe I'll write another one. You know what? I really thought I was going to write one book. In fact, people ask me, do you want to write more books? And I was like, no, like it was hard enough. I just wanted to write one book. And I poured everything I knew into this book. And I was like, and in a way, part of me was like, I want to write this book and then figure out my next career. Like, I kind of want to be done and move on to my next thing. Like, that's what I'm feeling. And then 2020 happened. 2020 is when I wrote the book, but probably towards the end of 2020, when it was too late to kind of change course on the book, because most of it had been written. I'd already started the review process. I was committed. People have been waiting for this book for a long time. I was not going to pull the plug on it that late and start over. But I was really influenced by what happened in Minnesota with George Floyd and just all the social unrest around the world. I started reading about all these products that replicate social inequities in the products themselves, biases like hand soap dispensers that don't detect darker skin, things like that. I realized that I missed the boat. I had an opportunity. to infuse more of those ethical questions throughout the book. I do talk about ethical assumptions and how to surface ethical assumptions, and there's a big part of that in my identifying assumptions chapter. But I really feel like a lot of people are talking about the ethics of the products that we're building. But it's the same problem I see everywhere. There's lots of people that write product management books. There aren't very many people that write really good how-to product management books. And so I feel like my superpower as a communicator is to get to the how-to. This is what the day-to-day looks like. I really want to do that on the ethical side of products because I feel like so many of us right now reacted to 2020 with we care, we want to be part of the solution, but we don't know how. I don't think I have a choice. I think I have to write that book. That's amazing. We should talk more because Cathy Pham was just on the podcast a couple of weeks ago too, and she's teaching all about product ethics. product management in governments at Harvard. She talks a lot about it. We should all talk about that because I've been in our class into that too. That would be awesome because I think my next career, whenever that ends up being, is I really want to figure out how to bring this stuff to the public sector. I think that's awesome. In the same way that product people should co-create with their customers, I think politicians and policymakers should co-create with their constituents. I have no idea how to make that happen, but I really want to. Oh, I love it. We have, okay, I've got so many people to tell you after this. This is gonna be really fun. I feel like this is a really hot topic right now to something that has been kind of burning with me to get more people to think through and to really think about. So we have a lot to dive into. And I think what you've been talking about too, with your continuous discovery habits, right? Like that's the first step to really thinking about product ethics is understanding your users, understanding what you're going after as well. And without good discovery, we can't really get into how do we make good products? Yeah, so I recently read Design Justice, which is this phenomenal book, and they talk about this idea of if you want to create ethical products that you should design with people, not for people. And I read that and I got goosebumps because that to me is the heart of continuous discovery. Like, let's not shove products onto people, let's co-create products with them. And I've gotten pushback from big thought leaders about this co-creation language. Really? Because people think that like, oh, it means I'm going to go ask my customers, what should I build? We have to recognize that customers are experts in themselves, in their world, in their needs, and that they should have a say in which problems we're solving and how we solve those problems. It does not mean we're going to say, hey, tell me what I should build. Right? And I think one of my goals with continuous discovery happens with all of the work that I've been doing for the last. eight to 10 years, depending on how we draw a boundary of when I started it, is really just how do we bring the customer into that process and how do we include them? How do we make sure it's working for them? That language in the Design Justice book, it felt like, oh, that's what I've been trying to teach people to do for a really long time. I just didn't go far. I didn't look at the question of who are we including when we define the customer and who are we? implicitly leaving out because we all know, all product people know, we can't design a product for everybody, right? You have to have a target customer. But we can be a lot more thoughtful and deliberate about how we define that, where we draw the boundaries, who we include. As a result, like, are we being explicit about we're designing for these people and not these people? And it's not just about race and gender and ethnicity. It's things like, do you assume your customers have a broadband connection? And are you leaving out everybody that lives in a rural area? Or are you a B2B company that is focused only on the big ticket enterprise clients? And then what does that mean? Like, are we just not going to serve our mom and pop businesses? I don't want to live in a world where mom and pop businesses are around. So it really opened my eyes to that. And I think I started to layer those ideas onto the continuous discovery habits framework. And I was like, wow, this is like a hand in the glove. Like it's so compatible. Because continuous discovery habits is all about learn about your customer, integrate with your customer, bring your customer into the process. I love that. Yeah. When I was talking to Cassie about this too, we got into a little bit about how I think a lot of companies just stop at MVP. When you have to start, figure out where do I start and how do I build it? Of course, you want to narrow it down and think about your target audience you want to first go after. But then especially when you scale and you're a huge company, there's really no excuse for not. taking into account accessibility and other people and all the different types of customers that you would serve. At that point, you almost become like a commodity. Sure, you can pick and choose, but how does that reflect on you if you want to be a commodity like Airbnb? You want everybody to use you. You can't just say, oh, well, we designed for this target market over here. It's like, no, you've been around for so long. You're huge. You've got tens of thousands of people working for you. It's a cop-out at that point. It feels like, We're just not doing good product management. Yeah, I would argue even before you're big, you're making really early decisions that are going to have long-term downstream effects. It doesn't take a lot to just, one of those is a major theme in the book, make your thinking explicit, externally visualize it so that as a team you can examine it. Yes, you might still decide we're a teeny tiny startup, we need money, we have to go after the big enterprise clients. But at least you're being deliberate about that rather than what a lot of us do is we just chase the next contract and we're not explicitly saying we're focusing on this segment and not this segment. And later down the road, because you were explicit about it, you're going to remember to revisit it. You're going to be more aware that you actually made the decision. And I even did this in my own business. I know we actually, you and I are on similar kind of trajectories where we just went with our businesses. But like I used to spend 80% of my time coaching and 20% on my courses. So what does that mean? I'm serving companies where the head of product is already sold on working this way. They have a ton of budget and they're willing to invest in their teams. That's a teeny tiny percentage of the market. Who am I leaving out? Everybody else. And so I decided this year that I'm going to focus on the everybody else. And I might make less money as a result because most of the money isn't consulting. Although frankly, the course business is not a bad business to be in and I'm doing fine. Nobody needs to feel sorry for me. Right. But like, I really want to serve the individuals. who don't have the luxury of working for those leaders because those are the people that need the most help. That's also where we're going to find the underrepresented folks that aren't even getting jobs at the companies that are willing to make these investments. Yeah. That's where the interesting opportunities arise too, and the people who are not really being served. This gets us into your continuous discovery habits because I assume you're going to be doing some of that for figuring out where to go there. Can you tell us a little bit about what is the framework for continuous discovery habits? How would you describe it? Why should people do it? I'm going to describe this in two different ways. First is just what are we doing in discovery? I think the first is I tried to come up with regardless of the framework or the tools or your favorite methods, what's the underlying structure to the work that we do? This is what led to the opportunity solution tree because I think that underlying structure is as simple as we start with an outcome, common trend right now. Hopefully people are familiar with what that is. Then we have to discover the opportunities, which is jargon, but it just means customer needs, pain points, and desires. Then we have to just, that if we address them would drive that outcome. Then we need to discover the solutions that would address those opportunities in a way that would drive the outcome. With that structure, what I was looking for is some people, I teach story-based interviewing to discover opportunities. The jobs to be done folks teach job to be done interviewing, but they're discovering. what I would call opportunities. Design thinkers say, go observe your customers in person in their environment. That's a way to discover opportunities. I don't think the way matters so much as long as that's a part of your process. Just like we have a million ways to discover solutions, design thinkers will tell you to prototype and get qualitative feedback. Lean startup folks will tell you to test your assumptions and get quantitative feedback. They're all good, right? But I feel like there's these three components. Understand what the end looks like, what does success look like, define that outcome. That's usually your business value, right? Your outcome usually represents how you're going to create value for your business. Then define the opportunity space, that's how you're going to create value for your customer. Then make sure that your solution ladders up to both. Then the methods can be swapped in and out based on a team's preference. That's one part of what I would say is the set of discovery activities. Then I think for continuous discovery, I want to see teams engaging with customers every week and that it's the team that's building the product that's doing that and that what they're doing during those customer engagements is that they're conducting small research activities to figure out what are the right solutions, what are the right opportunities to ensure they're driving that outcome. I think you just hit on something that has been a major source of frustration for me and I love how you put it on here because I get asked the question all the time, I'm sure you do too. How is this process different than design thinking? how is the escaping the bill trap process different than Teresa Torres' continuous discovery habits? I'm like, escaping the bill trap is not a process. It's just product. I love what you said. It's not so much about what method you're using to get into the interviews or discover the opportunities. It's just about figuring out what the right opportunity is, however you actually want to define that. Yeah, I get asked all the time, what's the difference between the opportunity solution tree and impact mapping? Okay, great. They're both ways of visually externalizing your thinking, you should do that. If you have your own made up way of visualizing or externalizing your thinking, do that. I think the key is not very many people do the work to understand the underlying principle behind the method, and then they don't know what to do when. So by coming up with this, whether you use the opportunity solution tree or not, understanding that you should be outcome focused. you need to find the right problems to solve and then you need to find the solutions that fit both that problem and drives that outcome is enough. Now you can look at any tool framework method and say, which part does this help me with? OKRs help me with setting an outcome. Jobs to be done helps me with discovering opportunities. David Bland's work is going to help me discover solutions. I can literally pick any thought leader in the space and think of their big idea and tell you where it fits in that structure. I think that's a big missing piece that teams just need help with that translation. Yeah. It's just figuring out what's fit for purpose at that time. But some of them do exactly the same thing. Other ones are fit for purpose for different types of things you're looking at. For the people who don't know about your opportunity solution trait, what is it? How do you describe it? When is the right time to use it? When would you turn to it? Yeah. It was designed to help a team figure out how to find the best path to their outcome. Anytime you're starting with a new outcome, I would start a new opportunity solution tree. Now, if you're not outcome-focused yet and you're like, how do I even get to an outcome? It's this simple. If you have a target customer segment and you have a theory of the value proposition for them, you can set an outcome. The example I give is, I may not even have a product. I might be pre-startup phase. I just want to start a company. I'm passionate about podcasters. and I know I want to help them grow their audience. I don't have to know what my product is. I can set an outcome. Like in that realm, I would set an outcome of how much did I help Melissa grow her audience, right? And then do that collectively across all the podcasters I'm serving. So I don't have to know what my product is yet. With that in place, I can go interview people. I can go observe people. I can start looking for what are the needs, pain points, and desires that are related to trying to grow a podcast audience, right? And I can map out that opportunity space. And once I have an understanding of the opportunity space, I can start to evaluate what are other products and solutions doing in this space? Where are their gaps? Where can I have a differentiated product? If I already have a product, I can start to evaluate what do we already serve in this opportunity space? Where are our own gaps? Where can we differentiate from our competitors? And then that sets me up really nicely to make the good strategic decision of where do I want to play? And then that's where I can start to get into discovering solutions and working my way across that opportunity space. Is there a specific level that you find works really well for the opportunity solution tree or is it high level for a company? Is it more team-based? Yeah, I usually use it at the team level. A team is responsible for an outcome and they're trying to figure out what in the world should we build. I have worked with leadership teams at companies that try to do a cross-company opportunity solution tree. I don't think it works. What I think works better at that stage is the cross-company experience map. How do we across the organization build a rich understanding who our customer is, what their opportunity space looks like in an experienced way? Whereas the opportunity solution tree is really designed to help you reach an outcome. Doing that across the company, it gets really messy because there's lots of competing outcomes within a company. Yeah, that makes a lot of sense. I feel like in theory, you need the same thing at the company. You were just mentioning it before. I think one of the biggest issues I've seen for companies is not that deliberate, who are we going after right now and the prioritization, as you were talking about with your business. That leads to so many other problems like people not knowing how to roadmap and not knowing how to prioritize and getting into that. I love the idea of the whole experience mapping at the top to set that strategy, understand where the opportunities are, and then basically we'll dive into the opportunity solution trees to figure out what we're actually going to build. Yeah, so I think at the leadership level, there's let's across the company co-create this experience map and that the leaders need to do it's almost like a KPI tree, right? Like every company trying to grow profits, we need to increase revenue, reduce costs. Based on this experience map and our theory of the products and services and our vision of the future, what are the metrics that matter most to our business? And then the outcomes that the teams work on are going to roll up to that. I think that's a lot of that strategic context that Marty Kagan talks about that is just missing in an organization. We're cherry picking outcomes. We don't see how they relate to each other. We don't see how they ladder up to business outcomes. Then we find teams in these situations where they're running hard after a metric and they're moving the metric and it looks like they're having success, but they're not creating any business value because it's just a sham outcome. I do think there's an equivalent to the tree. That is a tree structure, it's just how do you branch out? These are the outcomes that matter to our business, and it's really closely tied that this is how our business model works. Yeah, that makes a ton of sense. I always say, when I talk about my product strategy canvas, I always look at things called, I call them strategic intents, but they're always the business-focused piece. Then we need something like the opportunity solution tree to do the product initiatives and the solutions over on the team level. Yeah. Cool. Did you know I have a course for product managers that you could take? It's called Product Institute. Over the past seven years, I've been working with individuals, teams, and companies to upscale their product chops through my fully online school. We have an ever-growing list of courses to help you work through your current product dilemma. Visit productinstitute.com and learn to think like a great product manager. Use code thinking to save $200 at checkout on our premier course, Product Management Foundations. So one of the things too that we were just talking about was being able to roadmap getting into this. So if you're going into work with a company and they're like, Teresa, we want continuous discovery habits, come fix it. What do you try to set up? What needs to be there? What are the prerequisites that are needed so that this can actually be successful? This is a really good question because this is like my sales process. This is what I vet in the sales process. I want to see durable product trios already in place. So what do I mean by that? A product manager, a designer, and an engineer working together jointly responsible for what to build. They may have never done that before, but like from a team topology standpoint, that needs to be in place. And they need to be on one part of the product for the long term. So not like, yeah, we're a trio, but we have 17 projects. Because... The work to discover the opportunity space, the work to truly discover solutions and to do this continuously is a full-time job. So that's the first thing I'm looking for is, do we have a stable team that's in place that owns a part of the product that they're going to own over time? And then the second piece is, do they have an outcome? And I'm less concerned about, is it a well-formed outcome? Is it the right outcome? I just want to see from leadership that they've made some move away from build these fixed outputs. Because if the team is being told to build fixed fixed outputs and I come in and say, interview customers to discover the opportunity space. They're going to be like, we got to get started on these outputs and I will cause more problems than I'll help. Those are the two primary prerequisites that I look for. Thankfully, that's also where the industry is going. I don't need a company to have those in place across all of their teams. I just need the team that I'm coaching to have that in place. For a lot of companies, they're in the middle of their digital transformation and they just identify two front teams that they're trying to create bright spots. They figure out outcomes, they give them, create durable teams, give them some focus. It's like they're creating a little sandbox for how we're going to learn to work this way. One of the things you mentioned in the book too about outcomes gone wrong is the story with Wells Fargo, how you can chase that. Can you tell us a little bit about where can this structure sometimes be misinterpreted? What are bad practices when setting the outcomes and unleashing your team to go get them? Yeah. So first I'll clarify, I've never worked with Wells Fargo. That story came from reading the news and reading Wikipedia. But here was the gist of it. People might remember this because it was all over the news. In 2016, there was this huge firestorm throughout the media that Wells Fargo was opening checking accounts, savings accounts, and mortgage accounts under people's names without their permission. And I started to think about, why does this happen? And this is the classic example of sales teams going off the rails. And it's because we incentivize. outcomes, which is a lot of why in the product world we talk about don't tie compensation to outcomes because it leads to all these sort of misbehaviors. And I inferred that like, well, some of the news articles started to dig in and found that maybe Wells Fargo leadership was putting like setting unreasonable goals and then attaching it with these outsized incentives. So what does that do? You're incentivizing people to cheat. Probably not explicitly. I don't think any leader at Wells Fargo said, go cheat. But you're creating a system in place where it's not surprising that cheating might occur. I got to be careful because I don't want to slander Wells Fargo here. I really do think Wells Fargo is a good company and I've talked to many people that work there. I think they are a very customer-centric company, but you have to be customer-centric in how you set your outcomes and especially how you frame them. For example, if you just set your outcome as increase the average number of accounts per customer. which it sounds like is what they might have done. Again, I don't have any firsthand knowledge of this story. You run the risk of, okay, are we doing that at all costs? Whereas you can actually frame that outcome a little better and say, let's learn about our customers and figure out what makes them want to open more accounts. It's really important that you combine this outcome mindset with a really strong customer-centric mindset. I think that chapter opens with a Peter Drucker quote that's along the lines of the purpose of a business is to find and serve a customer. In today's business climate, we're losing sight of that. We think the purpose of a business is to create shareholder value. Shareholder value should be the side effect of finding and serving a customer. I wanted to include that story even though I feel like it does expose me a little bit because it scares me a little bit. I wanted to include it because I see teams go too far with outcomes and they forget the customer centricity piece. Yeah. In the case of Wells Fargo and other places too, sometimes really good companies get caught up in something like that. It's something that you don't even catch until it's too late. I think it's a good lesson for everybody. It doesn't mean that. the entirety of Wells Fargo is corrupt or anything. It's just like, hey, we thought we were actually motivating people. I think a lot of people in management do think this. Hey, set a really lofty goal, motivate people to go get it and we're going to see progress. That's just like a natural business management methodology. But I think it's such a great warning on where it could go wrong. I've seen it happen to other companies too and in big ways and small ways, tons of them when you just think like, hey, I'm going to set this really ambitious goal and then I'm going to compensate people for trying to hit it. As soon as you do that, man, I have seen some really wild stuff. I had one company when I came in to do an assessment on them, I asked them about their roadmaps and the stuff they were building and they were like, well, all our bonuses are tied to what we deliver on our roadmaps. In December, we basically just do whatever the hell we can to ship everything out and meet those roadmaps so we get our bonus. and then we spend all of January undoing it because it was a bunch of broken code that didn't really make any sense. It's so easy to get into that trap. You know what? This is what's hard. I have turned down work with companies that compensate their teams based on whether they hit their KRs or their outcomes. I feel like if you really want to do discovery well, that is the wrong model. We need to treat our employees like the adults that they are and trust that they work at your company because they care about their customer. and that they're genuinely doing the right thing, and that they're going to show up at work and do the best they can given what's available to them each day. And that their compensation does not need to be tied to their outcome. And I don't even think it needs to be tied to their outcome. Most people, especially knowledge workers, do what they do because they care and they're intrinsically motivated. And Daniel Pink's book, Mastery, does a great job, I mean Drive, does a great job of summarizing their psychology behind this. You put an extrinsic reward like compensation on this. and you just killed people's natural intrinsic motivation. Not only do I think it leads to these really messed up incentive systems that encourage wrong behavior, I just don't think you need it at all. I think you're going to get more from your people if you just make it all about your customer. Our goal is to serve our customer. I think most people genuinely want to do that. Organizations do more to get in the way of that than they do to help support that. I could not agree more. I just think we have a sometimes outdated perception on management of like, it's not about beating people with a stick, giving them some leeway to go out there and learn. I feel like people love doing discovery stuff. They love learning about their customers. Every time I've seen teams go do it well, they're like, man, I feel like I made a difference here. That's exactly what it is, is that every human, they hear a customer problem. They genuinely want to solve it. It's like going to a bar with a friend and hearing about their problem. What the friend wants is empathy and what you want to do is solve the problem. It's like a natural human thing. We hear about a need, we want to address it. I think if we just create the environment where it's easy for teams to talk to customers, it's easy for teams to have the freedom to figure out how to solve those problems, they'll do the right things. But you can't have only half the equation. What I was trying to get out with that Wells Fargo story, and I don't know if this is true Wells Fargo, but from the news reports, it sounds like they only had half the story. They said, how come they forgot the customer-centric piece? That's an important part. When teams are trying to build up their continuous discovery habits, make space for this in the companies, there's two things I want to dive into a little bit that I've seen be an issue. One, I get this question all the time and I'm sure you do too, which is, How do we communicate the discovery work we're doing on roadmaps in a way where we can talk about it at the company, but nobody's trying to sell it out there? Yeah. Roadmaps are tough, right? So a traditional roadmap, here's a list of features, here's when you're going to get them. Companies like that because then marketing can plan and customer success can plan and your sales team can plan. When I say your sales team can plan, they can start selling those features. Here's what's wrong with that. We're assuming that we can predict the future. We know when things are going to release. We don't. Engineering is uncertain. There's uncertain problems. We can't forecast uncertain problems. So that's the first thing. That's just a fantasy. We don't know when things are going to release. And frankly, it's about time we just acknowledge that, right? How many hours a week do engineers waste trying to estimate things that are impossible to estimate? So I wish we would just acknowledge it'll release when it's ready because quality matters. So that's the first part of it. The second part of it is I actually think it's this output mindset. We're doing our marketing launches around output. We're doing our sales strategy around output. Whereas I think instead, if we fully switch to outcomes, instead of talking about a list of features on our roadmap, we could talk about this quarter, we're focused on this outcome. We have this target in mind, which means we're going to work on this outcome until we hit this target. And when we do, we'll move to this next outcome. Under this outcome, we've identified these customer opportunities. We're currently working on this one and because we're currently working on it, we can tell you what solutions we're experimenting with. We think this next opportunity is the most important one after that. In the future, we know this whole other branch of opportunities is going to be relevant and we're going to have to get to them. What I like about that, so that's just the now next future roadmap format combined with opportunities and then only solutions in the now. What I like about that is that we have near-term certainty. We know what we're building right now. We may not know when we're releasing it, but we know what we're building right now. We know what we're learning right now. As we go a little further in the future, in the next category, we should, based on our interviewing and our understanding of the opportunity space, have some guess it was what's next. And then we all have an infinite list of things for the future. So that seems like it matches better the ambiguity and uncertainty in our work. But now we have to solve the problem of sales needs to know what to sell and marketing needs to know what to market. And that's that final piece of the output to outcome shift is that if we're doing good discovery in the now stage, even before it releases, we should have customer testimonials. We should have impact. We should know not just that our marketing releases should not be, we launched this feature. Our marketing releases should be, This feature is now available to you and here's what Melissa had to say about it. Here's how it impacted Melissa's business. So if you're doing discovery and you're getting feedback throughout the process from your customers, even if the date's unknown, your marketing team can work on that because they're pulling from your discovery work to get the value proposition and the benefit and the impact and they can have it ready for whatever day it launches. Or they could decide to do it two months after it launches when they have even more customers. What's hard about this is that it's not just a product change, it's a whole company output to outcome change. Yeah, that's a big shift mentally. I think one of the big pieces of pushback that I hear from CEOs and from executives when we think about it in that way, and maybe you have a good solution for this, is how can I tell what's in my now thing? Is it going to be a year from now or are you going to release that thing two years from now or is it going to be next week? Think about just general swag estimates of this is a quarter versus a year project or anything like that. Yeah. Part of your discovery should be testing feasibility assumptions. The problem with the way we estimate right now is we give engineers, if you're working in Scrum, which is what most people are doing, here's a two-week sprint, estimate these stories. The engineers have done nothing to look into what it's going to take to build those stories. They are swags, but we don't treat them like swags. We treat them like truth. and the whole rest of the organization starts planning as if they're going to release, which is why everybody thinks that engineering isn't doing their job and why engineering gets mad at the rest of the company and there's always this tension. It doesn't have to be that way, right? Like if in your discovery process, you're taking a solution and you're breaking it down into its underlying assumptions, a whole set of which are feasibility assumptions. As engineers test those feasibility assumptions, they're getting the data they need to make better estimates. The closer you get to being ready to build something, the better your estimate should get. You're going to be able to say, this looks like a three-week project. This looks like a six-week project. This looks like a three-month project. You still get that data. You just get it after you've actually collected. You still get the estimate. You just get it after you've collected data about the complete unknown. Teresa, are you telling me that if an executive wants better estimates, they have to do discovery work? Pretty much. I think that's amazing. Oh my God, I hope everybody's listening to that. And now the next time you say, hey, we don't have time to do discovery. Well, you don't have time to get a roadmap that's accurate either. So here's the thing, like, I work with so many teams that are like, but Teresa, I have to give a roadmap and they're stressed out about it. And they're trying to figure out the perfect things to put on their roadmap. And they're hammering their engineers to give perfect estimates. I just asked one question. Did you hit your last roadmap? Nope. Were there negative consequences? Nope. You felt a little bit bad and you moved on. So why are we stressing about this ridiculous charade that everybody knows is not true and nobody expects us to meet it, but we just play along. You're going to hit your roadmap. You're going to hit your roadmap. You're going to hit your roadmap. Oh, you didn't hit your roadmap. Okay, what's your next roadmap? It's kind of crazy town. Yeah, it's just like a back and forth always where we're like, next time you better put better estimates on it. It's like we don't change anything. We just keep doing exactly what we were doing. There's more and more pressure to just make stuff up and shove it into a roadmap. In a lot of ways, it feels like that story of the emperor's new clothes. Nobody wants to acknowledge this piece of paper means absolutely nothing. Some companies spend months. companies that start in July working on their January for the next year roadmap. That kills me. That kills me so much. Let's just spend all that time talking to our customers and doing discovery. And you won't have to have a roadmap. You'll have had shipped five months of value instead of having a piece of paper you're going to ignore on your... Yeah. You can't even come up with what to put on the roadmap if you're not doing the discovery work. You're just making it up. I just see so many people go through this process for... setting the strategy for the next year where they're like, oh, we'll just lock ourselves in a room and everybody bring a list of the stuff you want to build and we'll figure out where it fits in. No metrics, no outcomes that it's tied to, no business value calculations, just like let's shove it in there. Pre-COVID, I get why business works this way. We're coming from a business culture where we're still rooted in industrial age. Everything is predictable. It's all about efficiency. It's all about planning. I mean, honestly, in the 50s and 60s, we started talking about real strategy and Porter and Mintzberg and positioning and markets. We should have stepped away from it. It's not just about efficiency. We're still trying to do that. Then I think the internet added this whole other layer of pace at which markets change. the type of feedback loops we can build into our businesses. And so we're seeing rapid change in what wins in business, but we're seeing really slow change in how businesses operate. Here's what I'm hopeful of. The entire world got a really heavy dose of what it really means to live in an uncertain, ambiguous world. The entire world. Like, if that's the lesson we get from 2020, I'm going to be thrilled, right? I mean, it was a very expensive lesson and trust me, I wish we'd never had to go through COVID. But if the teeny tiny silver lining is that all these companies recognize that that road map they spent six months creating literally had to be thrown away overnight, maybe, just maybe, a small percentage of them will start to question why in the world are we doing this? Yeah, that's such a good point. I saw so many companies scrambling last year to change course and figure out what to do. Even before that though, the companies I've seen be the most successful. They're not ignoring business value, they're not ignoring their investors. They've still got an eye. If they're public, they still worry about Wall Street all the time, but they're still so concretely focused on the problems that they're solving. They're not like, oh my God, what can I do to just check this box for Wall Street? It's like, all right, I know Wall Street's beating down our door, but the only way we're going to win is for me as an executive, right, to block out that noise for a little bit and just focus on what we do well, how we double down, and then what more problems can we solve? I think that's so key. It's so important to just come back to the opportunities that you're talking about and figure it out as we go. I see those things emerge as we do discovery. Your roadmaps will just be living documents like we like to talk about, but if you're doing the continuous discovery habits that you talk about, you'll always have the next thing on the roadmap. You don't have to stop and build one every July. It's just like the next opportunity will naturally be on there because you've been discovering it. Yeah. I love that you just said we don't have to stop because I actually tell every team that I work with, no matter what the context, if you find yourself stopping to do something, you're already doing it wrong. People ask me, when do I stop to synthesize my interviews? No, you're interviewing continuously. You synthesize as you go. When am I stopping to do my roadmap? No. You're working your way across the opportunity space. This is what you're doing now. This is what you're doing next. That is continuous. And that is what unlocks true agility. The whole world can change. And if you were doing continuous discovery habits, the only thing that changed in a COVID world for you was you started working from home, which I realized is a big change. And maybe your next opportunity changed. But that's it. You didn't have to throw away a whole roadmap. You didn't have to redo a whole five-month planning process. You just... said, you know what, this new opportunity is coming in that seems a lot more important. Let's do that next. It seems like such a smarter way to work to me. And then to go back to your Wall Street comment, I think that a lot of product teams don't spend enough time on business value. And the subtitle of my book is Discover Products That Create Customer Value and Business Value. And I think I meet some teams that only focus on business value. I meet some teams that only focus on customer value. We're not doing our jobs if we're not doing both. And that's where I think that KPI tree where we're literally starting with grow profit. And if you're a nonprofit, it's increased impact on your mission. It's still the same. Instead of increased revenue, it's increased donation dollars. The underlying formula is the same for all organizations. You need to keep your costs in control and you need to increase the way that you create value. And there has to be a theory of how your products and services are going to create that value. And then that's what gives you that metrics tree and gives your teams the context they need. for not just how are they going to serve the customer, but how are they going to serve the customer in a way that creates value for the business. I completely agree. I completely agree. I've seen this big shift too with Agile, Lean and everything that was coming out where people just start realizing business value, where they stop talking about it. I actually got yelled at a couple of times from people where they're like, You're talking about business value, but we need to be focused on the customer value. I'm like, well, you don't work for a company out of the good of your own heart. We all want to get paid and the company wants to do well as well and serve a customer through it. If we don't make money, we can't serve our customers as well. But I'm hoping with the practices that you're talking about and us moving on a little bit from those lean startup days, we're coming back to a nice balance between the business side and the customer side, which is exactly where we should be. Yeah, in some ways, the pendulum just swung too far the other direction. We saw in the 90s and the early 2000s, this rise of the voice of the customer and UX, and it was all about the customer. That's awesome because that was completely missing from a lot of organizations. But then with time, we swung too far and we started to forget about business value. What happens when we forget about business value, the way that I like to frame it for teams, especially ones that really believe their job is just to serve the customer, is if you don't create business value, you're not going to serve the customer at all because you're going to go out of business. your product will get cut, right? Because no business leadership team is going to say, yeah, let's keep this product that doesn't make us any money. And we see this, like the best example of this is Google Reader, because Google has a bajillion dollars. Like they're not hurting for revenue. They're still not going to keep a product that didn't create enough business value. And customers loved Google Reader. I see regularly Google Reader used as the example of the product that was killed that everybody misses the most. but it had no business model. That's what happened. That team didn't earn the right to serve their customers over time. I think if you really want to be customer-centric, you have to create business value. That's such a good lesson for product managers. Your book, Continuous Discovery Habits, Everybody Can Buy It Now, who should be reading this? Who's your target audience for this and where can they find the book? I'll tell you my primary audience are people working in product trios or people who want to start working in product trios. So product managers, designers, and engineers, it's really written to be a hands-on guide for literally what do I do day out? How do I put some practical methods to these pie in the sky, trendy ideas? I have heard from leaders though, that there's the secondary audience, which is we have a lot of product leaders who are managing teams and they want their teams to do discovery, but they feel in this awkward position because they're the leader of the team, but they've never worked this way themselves. What the book can do for those leaders is give them a really clear picture of this is what your team should be doing, this is what it looks like. That's so important for leaders to understand too. Where can people pick it up? Yeah, so it's widely available around the world. The easiest place is on Amazon. It's in paperback and Kindle. An audible version is coming eventually as soon as I find a month of my life to narrate it. Hoping by the end of the year, but that's like a roadmap with an output on a deadline. I'm not committing to that. But my goal is to have the audible version by the end of the year. If you're anti-Amazon, I get it. It's available on print via print on demand, which means you literally can walk into your favorite independent book retailer. And even if they don't carry it. they can order it for you and you can buy it from wherever you want. That's awesome. I didn't even know that existed. Definitely want to do that. Thank you so much for being on the show, Teresa. Where can people connect with you as well to learn more about what you do? The best place to go is producttalk.org. In addition to the book, we have a whole bunch of services to help you put the book into practice because we know reading a book is often not enough. You can learn more about those there. Then I'm also on Twitter, I'm on LinkedIn, some t-tourists on Twitter. you can just search for Teresa Torres on LinkedIn, you'll probably find me there. I love to connect about this stuff, so feel free to reach out. Great. Well, thank you so much for being here. Make sure that you go pick up Teresa's book. If you're enjoying the Product Thinking Podcast, we would really appreciate you leaving a review wherever you're listening to it so other people can find us too. We will see you next Wednesday.

⚙️ Pipeline jobs

StageStatusAtt.UpdatedError
download done 2/3 2026-07-20 14:28:44
transcribe done 1/3 2026-07-20 14:29:16
summarize done 1/3 2026-07-20 14:29:45
embed done 1/3 2026-07-20 14:29:47

📄 Описание YouTube

Показать
Teresa Torres is a Product Discovery Coach, author, and keynote speaker. She is also the founder of The Product Talk Academy where she helps product teams adopt continuous product discovery practices. Teresa joins Melissa to discuss how product managers can implement strong continuous discovery habits into their product practices and how to communicate that work via roadmaps. 

Here are some key points you’ll hear Melissa and Teresa talk about in this episode:

How Teresa first got involved in product management. [1:12]

The heart of continuous discovery is not about shoving products on our team, but about creating products with them. It’s also about bringing the customer into the building process and figuring out how we make our products work for them. [6:28]

We need to be always careful of who we are including when we define the customer and who we are leaving out. We can’t design a product for everybody but we can be more thoughtful and deliberate about boundaries. [7:26]

Teresa says product leaders need to be deliberate about their ideas, as this will help them make more strategic decisions. [9:41]

Teresa explains the framework of continuous discovery. [11:26]

There are three components of discovering opportunities: understanding what success looks like to us in our organizations, defining the opportunity space, and making sure our solutions align with the other two components. [12:40]

It doesn’t matter what method we use to discover opportunities. What matters is that we need to be outcome-focused, we need to find the right problems to solve, and then we need to find solutions that fit both the problem and the outcome. [14:15]

A big issue with many companies is that they aren’t being deliberate about their target market. They miss out on opportunities because of this. [17:50]

We have to be customer-centric in how we set and frame our outcomes. [22:20]

We need trust that our employees work at our companies because they care about the customer. We need to trust that they’re going to do the right thing and do their best at work every day with what they’re given. When we do that, their compensation does not need to be tied to their outcome. [25:59]

Teresa talks through how to communicate discovery work on roadmaps without getting tied to a fixed timeline. [28:35]

We don’t have to be constantly looking for the next task because if we are following continuous discovery practices, we will always have the next opportunity there. [37:15]

We need to focus on both business value and customer value. We have to serve our customers in ways that will create value for the business. [39:04]

Teresa talks about the target audience for her book. [41:45]


Resources
Teresa Torres | LinkedIn | Twitter
Product Talk
Continuous Discovery Habits