Teams that skip real customer contact are building faster and failing faster

Product teams are moving fast on AI, but speed without discovery is a trap. Teresa Torres, author of Continuous Discovery Habits and one of the most trusted voices in modern product thinking, reveals why teams that skip real customer contact are building faster and failing faster. But as long as we're building products for humans, I think the human we're building for needs to be in the process. In this episode, you'll learn how to avoid the AI discovery trap. Don't fall for synthetic users, fake insights, and discovery theater. Teresa shows how to ground AI-assisted research in real human context so your data actually leads to defensible products. How to use AI to think deeper, not cheaper. Learn the high leverage ways AI can supercharge synthesis, spot patterns across thousands of signals, and accelerate prototyping without replacing the empathy and nuance that only humans can see. and how to turn discovery into your moat. Discover why first-hand customer contact is still the ultimate competitive edge. How teams using AI to augment discovery, not outsource it, are finding opportunities their competitors miss. A lot of AI products, they over-promise and they don't adequately solve the underlying problem. And so maybe it gets us to try it, but we aren't going to subscribe because it actually creates more work for us. This is episode 44 of the Design of AI podcast. If this conversation helps you build smarter, rate the podcast and leave a comment. Your feedback shapes the next topics we explore. Want to go deeper? Subscribe to our subsect newsletter for AI strategy and research insights. Welcome. Thank you for joining us. Thanks for having me. Let's talk about the fact that AI can now generate personas, insights, even fake users. So what concerns you the most about how product teams may mistake this for real discovery? First of all, these tools are new enough that I'm not sure we know yet how and when and where they can help. I'm not in the camp that they're useless and we should ignore them and we should pretend like they don't exist. I think the reality is there's lots of product teams out there that have no time and their organizations don't prioritize discovery. And it is possible these tools are better than nothing. Again, there was a lot of caveats in that statement. I can't confidently say they're better than nothing, but I want to stay open to the fact that it is possible. My primary concern is when a product team is looking for ways to avoid talking to their customers. I think every product team, regardless of what tools they have, regardless of how much AI-driven discovery they're doing, they still need firsthand exposure to their customers. There's a lot of real humans that are their customers. Mostly because this is what helps us build empathy. We've already gone through the experience of outsourcing our discovery efforts to centralize research teams, whether that's business intelligence or market research or user research teams. And what we see is teams don't act on that research. This is a huge problem because they weren't part of developing the research. If we outsource everything to AI, we're going to have the exact same problem. The difference is we don't even know if what we're getting from AI is reliable. At least we knew. Our researchers were giving us reliable feedback. That's their expertise. But we don't know yet if what we're getting from AI is reliable. If you're doing nothing, maybe that's better than nothing. But if you are doing discovery, I would be reluctant if you were replacing your discovery efforts with these AI efforts. You know, you mentioned about it. It's better not to try and replace talking to real users. In your experience, are you seeing more product teams choosing to? take less time with real users? I mean, I think the thing we have to first be clear about is that there's still a large percentage of product teams that have zero contact with customers. So is AI changing that? I'm not sure. I don't know of a single team that was regularly talking to customers and said, you know what, we're going to stop talking to our customers and we're going to use something like synthetic users instead. What I see more often is teams are starting to experiment with some of these new tools as a way to augment what they're doing. And I like that. I like that as an additive approach. I don't like it as a replacement approach. Okay, so let's talk about discovery research. Can you give us a bit of a snapshot of what research looked like, let's say 10 years ago, five years ago, and how we got to today and what you're seeing as happening around the industry? These ideas, the ideas that are core to discovery have been around for much longer than people think. In the 90s, I was doing a degree program in human-computer interaction, and a lot of the things we talk about in Discovery was being advocated for. A lot of that dates back even to the 60s and the 70s. We've had human factors research in physical products for a long, long time. I think what's changed is with the rise of the internet, we actually have much faster feedback loops. So when we make decisions about what to build, we can... get feedback on whether or not those are the right decisions a lot faster than we used to be able to. We don't have to wait for a product to be on a store shelf before we can get feedback on whether anybody wants to buy it. We don't have to spend $30,000 to rent a two-way mirror facility for two days to run usability tests. We can do that on the internet in just an hour or two. So I think the internet has accelerated the pace of our feedback loops, which means it makes it more accessible for more teams. So I think more teams are doing customer-centric discovery. It's not that I think these ideas are new. It's that the tooling around it has gotten better, that we can do it faster. We need less expertise. We need less budget. And almost everybody in any organizational context has the ability to do some of it. Our next AI product strategy workshop is on October 30th. In this three-hour online session, you'll learn our framework for discovering and pressure testing disruptive AI product ideas. Get details at designof.com. AI slash workshop. So I want to think about discovery research because just generally research has really changed a lot over the last 20 years. It was a complex endeavor and it was something that was very rarely done. But we're seeing all the barriers to entry to research dropping. We started doing more remote research. The participants became more comfortable and familiar with this. It is so plentiful the amount of research that can be done. So then it shocks me when you said a couple of minutes ago that there still are organizations that don't do discovery research. So what will it take to bring these people on side? Is it that they will never do the research and that is just fundamentally how the organization is structured for them? Or is it that they're going to move more to this discovery theater kind of realm where they're just going to do micro activities without much yield? Tough question because I'm not sure everybody needs to be doing this stuff and that may surprise you as an answer. I think every product team could benefit from more exposure to their customers, but not every product team works in an organizational context where that's even remotely feasible. There are some people that will tell you if you're not doing discovery well, you're not doing your job well. I don't agree with that. There's plenty of organizations that don't support this way of working. They're going to cause more problems than goodwill by trying to do some of this stuff. The reality is a lot of companies Leaders are still dictating exactly what product teams should build and their job is literally framed as build these features. Could those teams benefit from talking to customers more? Absolutely. I think they would build better versions of those features. Could those individuals advance more in their career if they learned how to be outcome focused, even if their organizations aren't? Yes, absolutely. I'm a big advocate that every individual can work on their own discovery habits. But I don't think that means that every single team is in an organizational context that's going to support this way of working or even encourage them to do that. We have to look at this as three different levels. There's the individual level. I want to build my own toolbox. I want to build my own skills. I think everybody could benefit from learning these skills. Then there's the team level. Am I even set up to work with a cross-functional team? Are my teammates even interested or excited to work this way? And then there's the organizational level and there's plenty of organizations that don't support this. And if you're an individual, there isn't a lot that you can do to influence the way that your organization works. There's a lot that you can do to influence the way that you individually work. And this is why like Marty Kagan recently wrote transformed. I think this is our next like step function is how do we get more organizations on board with working this way? And I think it's a really important distinction because right now everybody's trying to be an expert on LinkedIn and on social media. And what they're doing is they're telling people you're doing your job wrong. And I don't think people are doing their jobs wrong. I think they're doing exactly what their companies are asking them to do. You bring up an interesting perspective because. The people who are listening will come from different backgrounds. Some are designers, some are researchers, some are product people, right? And so rarely does everyone get the exposure to what's happening on product teams. But again, from the same lenses, product owners will do well by learning more on discovery research. Strategists and researchers and people from the other side will do really well to know what's happening from a product team perspective as well. You mentioned about how there's different types of organizations and different types of product teams that should work differently, right? So let's take that apart a little bit more. In your experience or what you've seen, what are the type of product teams or organizations who should be using more automated discovery research? If we're going to get into like how generative AI can impact discovery, one use case I really like is this kind of stuff that Gong is doing. the kind of stuff that we're seeing more vendors get into the space of every organization has a million inputs from customers and how do we start to synthesize what that is and what that looks like i think it would be really great if genitive ai helped us kind of keep a pulse of what's happening across the organization i think the mistake teams make is they look at that data and they go oh our biggest pain point from our customers is x let's build something to solve for that and they don't really understand that need yet they've got a signal that there might be a pain point here but they still need to go and talk to customers directly and learn from customers directly to understand the context in which that pain point occurs, who it occurs for, how it's affected. Every kind of customer need or pain point occurs in the ecosystem. It occurs in a specific context. There's usually more than one user involved, especially in our B2B businesses. And so I really love AI for this first step of our organization is getting a lot of signals across the organization. How do we use that to understand and prioritize what's most important? But I don't think it replaces any of the discovery habits. I think we still have to go and interview customers and learn about where and how does that pain point show up. Another area I really like is I've been starting to experiment with using generative AI to help me synthesize my interviews. Now, I don't like this as an outsourced activity. I still find opportunities that neither Claude or ChatGPT can find. But they also, both those tools, find things that I don't find. And so I really like using generative AI, just like it's another teammate on my team. So if I'm on a cross-functional product trio, I want my team individually identifying what they heard in an interview. And then we're aggregating across our individual perspectives to develop a team perspective. And I think it's great to use generative AI as an additional perspective on our team. I know a lot of teams are time-limited. And so they really are just outsourcing this. I think the challenge with that is you will miss some really important stuff. I personally believe that discovery can be a really strong competitive differentiator. The more time you spend with customers and the more time you put into this synthesis work and high quality synthesis work, the more likely you're going to find opportunities that your competitors don't. And so I'm not ready to outsource that, but I do like using generative AI as a teammate. For myself, because I do a lot of discovery research and testing and things like that, and I've found that one hack that I have is if you have more touch points throughout the interview process to say, okay, well, here's what we're hearing right now. And obviously this is not going to be everything that you're hearing, but to date, these are sort of the trends or the signals that we're seeing. and having more of those touch points throughout that interview process allows you to then hold yourselves a little bit more accountable to what you then end up seeing at the back end with the Claude or the ChatGPT synthesis. Do you have any hacks or tips that you found really help to hold your team accountable as you're going through that process so you're not just purely outsourcing? I think the big thing is you have to individually do the work first. I think if you start with Claude or ChatGPT, you're not going to do the individual work. The output's going to look good enough. You're going to have no idea what's a hallucination. You're going to have no idea what's real. There's always nuance to what we learn from an interview and LLMs aren't super great at nuance. Whereas if we do the synthesis ourselves first, and then we look at the LLM output, we're in a much better position to judge the quality and to really ask like, oh, I didn't even cover this. Is this real? Can I see where in the interview this came from? I wholeheartedly agree. These LMs are really terrible at nuance, but I have to admit I'm constantly in awe how quickly they're getting better, how quickly they're able to pull in contacts and insights. But let's talk about the non-insights realm. So let's talk about data. Data is such a critical part to any product infrastructure and the amount of platforms now that can pull in experimentation data or contextual appended data. They can access different silos of information and we can start merging these things together. We spoke to the CEO of TheyDo and they're an example on what happens when you start looking at insights as a dynamic element. It's really powerful. I guess what I'm trying to understand is are we entering a unique period where the benefits and power of qual are going to start merging with the benefits and power of quant? in a way that can really transcend how product teams have typically looked at products themselves, strategy and their customers? There's a lot in there that I want to react to. So like the first one is, I don't think there's a battle between quant and qual. I think anybody with a good research mind knows that both are critically important. And if we're relying on just one or the other, we're not really doing our jobs. I think that's a really important thing to keep in mind. I think one thing that LLMs really unlock is they're really good at qualitative summary and analysis. LLMs are really good at sentiment analysis, so we can look at a lot of qualitative data and get pretty reliable sentiment. If you're using LLMs for more than that, though, that's where I think we're going to find ourselves in trouble because they do still hallucinate. They do miss nuance. For anybody who's done high quality qualitative synthesis, a lot of the magic happens from being in the data and in the data for a long time. and really playing with is this opportunity the same as this other opportunity I'm hearing over here. And I think one of the challenges with just outsourcing this is that we're going to miss those connections. Now, don't get me wrong. We're still in the early days of LLMs and it's very possible even maybe in a year or two, we're going to find that they're better at this than we are. It's important to be open to the fact that these tools are going to be better and to not have these dogmatic rules. This is why I'm not willing to say that synthetic users will be a bad idea forever. I think the landscape is just changing way too quickly. If you're a product team right now, I think what's being unlocked right now is we can find patterns and themes across these high volume signals that we didn't know what to do with beforehand. So your sales teams are having hundreds of conversations. No product team can possibly keep up with that. You're getting at large companies, you're getting thousands of support tickets. And we had to come up with really crude ways to look at what are the biggest pain points coming in through support. Whereas I think LLMs help us make sense of that mess. And I think that's something everybody should be looking at. How do we get something in place to help us with that? Because I think that is the area where LLMs already shine. Can you share a story of where a product team looked efficient, but ended up wasting years on the wrong problem? Let's talk about discovery debt. Yeah. One of the things I see a lot of teams make the mistake of, obviously can't share a specific team story, but I can share some trends that I see is. They do all the right things. I see two big trends. One is they do all the right things, but it doesn't change what they build. And it's actually not the team's fault. It's actually because somewhere in the organization, the leadership above them is still committed to their original idea and they're not learning from the team's research. This is sometimes because they're only sharing their conclusions. They're not sharing their research and their learnings along the way. And so the leader isn't seeing the ideas evolve and the... understanding of the problem space that evolved. They're just seeing the conclusion and they don't change their mind. Sometimes this is because our leaders just don't have time to be that involved and they really are just stubborn about their idea and they just tell the teams to build what they want anyway. And unfortunately, I still see this quite a bit. And I think coming out of COVID and coming out of being in a world where there's a lot of geopolitical and economic instability, we're seeing more leaders move towards a command and control. structure where they're dictating more what teams should build. I think this is cyclical. We go through these cycles all the time. I think as soon as money starts flowing again, we'll go right back to the empowered product team model. I don't think it's one or the other. I think it's like how many degrees of freedom are you giving your teams? But I do see a lot of teams like work really good discovery habits, but their organizational context isn't letting them do good work. So that's one thing. The second thing I see a lot is what people are starting to call discovery theater. I kind of hate this term because I think a lot of these teams are genuinely trying, but they're not getting the support they need, even at the individual level of like, we have to develop intellectual curiosity and intellectual honesty when we're doing good discovery. So we have to be willing to let go of our favorite ideas. We have to be willing to take some risks. Failure has to be okay. We have to learn that we're building the wrong thing and be willing to abandon it. And so I think a lot of teams, They're not getting the training they need. They don't know how to conduct effective customer interviews. They don't know how to run an effective assumption tests. And so they're not getting reliable feedback. And so they're building what they were always going to build, even though they're doing all the right discovery activities. They're just not doing those activities effectively. And I see this a lot. Like I recently built an AI interview coach. And the reason why I built this is because almost every product team you talk to thinks they know how to conduct effective customer interview. And I would say the vast majority don't even understand the mistakes that they're making. You can do all the right activities, but if you're not doing those activities effectively, you're not necessarily going to learn what you need to learn. And just to provide context for anyone who's listening, there are two kinds of discovery theater that I would also call attention to. So one being, look at us, we did the discovery work, we talked to users, it just doesn't get used, but they can point to it and say, we did it, right? And number two is it's already biased. It's trying to say, we think we made the right choice. Let's prove or validate that we did. I would add a third one there, and that's that it's not directed. So I'll tell a story of a team. They were really good researchers. They weren't in a research role, but as a team, they were really good researchers. And they had a room where across the walls was everything they were learning. And it was really fascinating. They learned a lot of really great stuff, but I was looking across the walls and I realized what wasn't clear was who their ideal customer profile was. And when I asked them, their answer was anybody who uses our product. Well, their product was a consumer product that literally everybody on the planet uses or something like it. So I was like, okay, so everybody is your customer. That means you did a lot of research, but you didn't really learn anything because nobody serves everybody. And you learned a lot about a lot of different people. your research wasn't guided. And I think this is a really common mistake. It can feel good to just learn about people and people's needs. And it feels very customer centric, but we actually can't meet the needs of everybody ever. No product is going to meet the needs of everybody. And so unless we're starting with a business outcome, then looking at a product outcome, choosing a target customer segment, and then going to learn about that. I'm not going to call it discovery theater. I feel like this team in particular that I have in mind had a lot of good intentions and they did a lot of really good research. The challenge is businesses aren't interested in research for research sake. We're interested in research so that we can build the right product so that we can drive business outcomes. And if that research isn't helping us find the right product to build, we might as well just be a research agency and hope somebody is willing to pay for that project. Yeah. And to add to that is if you don't have enough clarity on how to replicate who those people were or how to find them or have trends in it, you also don't know how to then sell it to them or market it back to them. So mistakes is a word that keeps coming up in this conversation. I'd like to discuss what that means. Are we entering a period where mistakes are going to become more valuable? I mean, my answer is biased by what I do as a company. I think the two biggest problems I see on product teams is their research methods are terrible. So I think in discovery, we have two primary research activities that we do. The first is we're discovering unmet customer needs, pain points, and desires. I like to do that through story-based interviewing. I think most teams are not using their interviews to discover the opportunity space. They're using their interviews to get feedback on their solutions. I don't think that's a reliable way to get feedback on your solutions, especially if you're asking things like, what do you think about this? Would you use this? feels like a shortcut like you're telling me you would use this great i can check the box i did my discovery but we know through decades of research and human behavior that we don't actually know what we would do and that's just not a reliable way to get feedback on our solutions and then the way that i do recommend that people get feedback on their solutions is through assumption tests and i think there's a lot of misunderstanding there people think i mean a b testing like you're going to build the whole thing and then you're going to see if it worked that is not what i mean it's really about deconstructing an idea into the underlying particulars that need to be true for the idea to succeed. This can be teeny tiny things like your customers have a Facebook login. Your product may have nothing to do with Facebook, but you're planning to let them log in on Facebook. So you have an assumption that they actually have a Facebook login. You have an assumption that they trust you enough to use their Facebook login on your site, right? These are things that we can test in isolation that don't require that we build the whole solution. And a good assumption test is designed so that you can observe behavior. You're not asking, do you trust us enough? You're creating a simulated experience where they have to trust you so you can evaluate by observing their behavior, did they trust you or not? And I think one of the challenges is that it's easy to throw these terms around, both interviewing and assumption testing. They've been around for decades, but I think most teams fundamentally misunderstand them and use them poorly. And this is why I run a training business in these spaces. Because I think all teams can get better interviewing around assumption testing. And it's one thing to go through and do these activities. It's another thing to get reliable feedback from those activities. And I think both product leaders and product teams underestimate what's required to get reliable feedback. Now, if I were thinking about a small startup, and let's remember, there's so many small startups now, more than ever, but they might have a very small budget associated to research. They may or may not have an FTE or someone on contract. When in the process should a smaller startup, let's define it as 30 people or less, when should they start doing research? Should they do it at the initial conceptualization of the business, identifying their unique selling proposition, their customers and such, or when they're closer to market, or when they're at the end of this commercialization process and really trying to refine their product offering and optimize for value creation and monetization. Research doesn't require budget. You can do discovery research with zero dollars. I did that for most of my full-time employee experience. I worked at early stage startups. I was often in the first 10 employees. I never had a research budget. The things you might need budget for is obviously if you have better tools, you can go faster. But even without those tools, you can still do perfectly good discovery. I do believe we need to compensate our participants, but it doesn't always have to be cash. It can be the service our company offers. I don't think budget has to be a limiting factor. And then when should you start doing discovery? I think we should start doing discovery as soon as we have a theory of our target customer and our value proposition. That's often long before we even have a product. If we're a startup and we have a very founder-led vision and that vision is a specific solution, then I think it's even more important. that we're testing that value proposition before we even jump to testing the solution. If AI keeps making discovery faster and deeper, what do you see disappearing in five years? Right? What new practices will help teams thrive instead of wasting time? I think today AI makes delivery faster. I'm not sure it necessarily makes discovery faster. I think if you take shortcuts and you're asking ChatGPT for your ideal customer profile instead of talking to your customers. It does make discovery faster, but I wouldn't call that discovery. At least not yet. You mentioned note-taking. So I do think that it's nice that we can now have an AI note-taker. Honestly, I was always recording my interviews. I'm not sure that makes it faster. Even with AI note-taking, I'm still re-watching those interviews. I'm still doing the synthesis myself. I think what AI does is it gives us an additional perspective. And there's something that's unique about that perspective. It's a perspective that has access. to a very broad set of data. And I don't want to trivialize that, especially if you have access to LLM that's been trained on your company data. That's a really important perspective to bring in. I guess AI can help us with writing our recruiting emails. But fundamentally, I'm still designing and running my assumption test the same way I always have. I'm still conducting my interviews the same way I always have. I kind of hope that AI touches discovery last. Because I just think most of the value from discovery, and I don't mean that because I'm trying to defend my career. I could happily retire and just be done with all of this. I would love for there to no longer be a need for teams to do discovery. That would be amazing. I would love to have a magic wand and have every team just make exactly the right decision about what to build. But I don't think we're there. I think it's going to take a long time for AI to get us there, if it ever does get us there. What's more likely to happen is that AI is going to accelerate delivery. Companies are going to go through this really uncomfortable phase where they deliver way too much, and we are going to end up with really mediocre products. And I think it's going to put a really big emphasis on discovery. We're going to see the teams that still have firsthand exposure to customers build better products, whether they're using AI or not. Simplify things a little bit for the audience here. We've been talking a lot about how AI may not function as effectively as it could. What are some of the... discovery and research and product tasks where you believe and highly encourage them to augment themselves with AI tools? And what are some of the ones where you explicitly want to say that it should be a real person through and through? I want to see real people interviewing real people. I can't imagine a future where that changes. I know that Reforged now has a tool that will interview your customers for you. And like, if that replaces surveys, I'm all for it. I don't think it replaces. me talking to someone in depth about their context and their needs. So notice I didn't say my product. I said their context, their needs, what they're trying to do. I really hope that never goes away. Technology needs more humanity, not less. I do really love AI prototyping tools. The lovable, the bolts, the B0s, the replets. I've used them. I use multiple of them. They're really great for assumption testing. So I know a lot of teams get stuck on assumption testing because they need real interactive prototypes with real customer data. And these AI prototyping tools now make that much easier and a lot faster. That's already something where AI has helped to improve discovery. And Brittany, going back to your question, that is an area where I think discovery has gotten faster. And I overlooked that earlier. I frame discovery, like we're trying to make good decisions about what to build. As long as we're building products for humans, which I realize even that might change. But as long as we're building products for humans, I think the human we're building for needs to be in the process. That's like core to my philosophy about discovery is we have to have fast feedback loops with those humans. And those feedback loops are likely to get faster, but I hope we don't replace the human in those loops. Now it is possible we're also going to start building software for agents and that changes everything. Like if you're building for agents, then you probably can rely a lot more on AI for your testing. But I would hope as long as we're building for humans, humans are involved in the feedback loops. If we look back at that period, 2023, 2024, it was just about getting product out, getting some users in there, getting some data. The 2025 onwards, we're actually starting to have entrepreneurs and founders and VCs trying to collect some of these debts from the investments they made into AI. Those platforms that have been collecting large user bases now need to monetize and pay the bills. What are some of the methods that you suggest to the listeners to help them identify a path to monetizing these AI tools that are quite expensive and perhaps that they're unsure users are actually paying for? What is an appropriate discovery method to enable that? The challenge is sometimes people don't see the value yet and it's hard to know if they're willing to pay. They might say it in an interview. They might say in a survey, but quite often once you're out in market, you're starting to make leaps of faith and it's hard to attribute things perfectly. The key is to not focus on your solution, but to find a problem that customers are willing to pay for to have solved. So if I think about, I know we're recording on Descript right now. Descript has a couple of really magical AI features, even though in the early days, their video editor kind of sucked and still drives me nuts to this day. But I use it. I'm a customer. And why am I a customer? Because they have a number of AI features that were impossible that used to take a ton of time. So the big one that comes to mind is the eye contact piece that can fix eye contact in a video. Particularly relevant if it's just a single person talking head video. They do stereo studio. They do studio sound improvements. So for people that know nothing about audio quality, you literally hit a button and then they just do it for you. I know a big one for podcasts is it removes all the ums and all the like filler words. And again, it's doing this with a click of a button. And my personal favorite one is I can edit a video by editing the transcript. And the reason why I brought up these specific features, none of them were possible before LLMs. And what Descript did an amazingly good job of was they found customer problems that were previously impossible or ridiculously hard to solve. And they found solutions. And they found solutions that they could do with the click of a button. So they removed hours and hours and hours of video editing work. Now, did a script have to go and do research and figure out, would you pay for this? They didn't need to do that because they were talking to customers and they could see they were spending hours on these things. The first part about willingness to pay is, are you finding an important enough customer problem? that if it went away, they would be willing to pay for that. And some good signals of that are how painful is it? How much of the time is it taking? How much quality does it overall improve? And then from there, we have to look at, does our solution actually adequately solve it? Right? A lot of AI products, they over promise and they don't adequately solve the underlying problem. And so maybe it gets us to try it, but we aren't going to subscribe because it actually creates more work for us. It halfway solves it. And then we spend more time. fixing the AI output than we would have spent actually doing the task itself. And I call that Descript, not just because we're recording on Descript, but also because I think they are one of the few companies where their AI features are really good. We have a lot of companies where their AI features are very mediocre. And of course, you're going to run into willingness to pay issues. So I think the key to a willingness to pay, you have to find the right problems to solve. You have to make sure you're... solutions actually can solve those problems. And both of those are our core discovery activities. We're going to interview to find the right problems. We're going to assumption test and make sure our solution actually solves those problems. And then when we really get into how much are you willing to pay? Is the credit card actually coming out of the wallet? I don't think we're going to learn that through interviews. We have to learn that through demand tests. That's a wonderful answer. So right now is a really unique period. It's easier never to get product out, but it also means that there might be a ton of clones happening at the same time. You don't know who's building in parallel to you because it's faster, it's quicker than it's been before. What it means is that a lot of ideas, a lot of concepts, a lot of businesses are not as defensible as they used to be. I'd like to know what are some methods and some techniques that you suggest to your clients. When they are trying to make a decision, should we rent a model, build on top of it, or build our own specialized tooling on? Because these things can be a big, heady investment. It's a big deal to go out and spend five years building a specialized model because you might not be able to monetize it for years. Thinking specifically competitively, what are some methods that you would suggest to ensure that I am collecting the research I need to continue developing some competitive advantage? I actually don't think anything has changed in the landscape of how people can compete. I think it is true that a clone, probably a half-assed clone, could pop up overnight. But people grossly underestimate. Like I listened to a podcast, I think it was probably a Lenny podcast, where somebody asked, anybody could build Salesforce? Or anybody could build Ramp? I forget what it was. And what's misunderstood in that question is not literally like... What you see on the surface of the product, it's the 4 billion business rules that have been built into place over time as they learn their customers and all the nuances. And it's so easy to think, oh, I could build that. And then you start building it and you realize this works for me, but it doesn't work for anybody else. And for me to get it to work for somebody else, I have to add all these caveats. And then I want to get it to work for the next one. And suddenly your little teeny tiny easy to build product turns into a nightmare product. What a lot of companies have accumulated over these years is the ability to serve a market. Is it easy to build a product that serves a customer? Yes. And I think what we might see, and I think we're already seeing this is a lot of people are building individual tools. I'm actually really excited for this because I think it is a level setter for individuals. Like I'm really enamored with this idea of mom and pop technology. So we have mom and pop stores. And I think we're entering an age where we have mom and pop technology. So I can build something. I've actually built individual apps just for me. I built an app to track my dog's food and exercise and medicine and nobody else on the planet is going to use it. But it works perfectly for me. And I didn't have to go look for an off-the-shelf software. And I did it in two hours using Lovable. Amazing. I think we're going to see a lot more of that. I don't think we're going to see that in the B2B space. I think with regulations and laws and businesses. Maybe for like our little internal pet projects of like, I need help to just automate this little workflow thing. Sure. I don't think it's the end of SaaS. I don't think it's the end of B2B software. I think people grossly underestimate what's required to build good solutions in those spaces. I'd like to flip it a little though. Because, you know, I think the conversation has been being had for a while of, you know, can you replace Salesforce? And, you know, sure, that's an interesting conversation. But I think the more interesting thing is the other side of if you are one of these mom and pop technologists. How do you create your defensible moat? How do you monetize or price your AI products? We're still at this point where we're seeing more failures in that or more struggle in that where people aren't really understanding what to do. So I'd love to hear what are some mistakes that teams or people trying to create that defensible moat with the opportunities they see. What are the biggest mistakes they're making when trying to monetize or price AI products? And how can discovery prevent those wasted launches or that wasted time? Yeah, this is the area where I think absolutely nothing has changed. I think it's the same mistakes we've always made. We're starting with a solution that we love, but we don't know if there's a market for it. We haven't taken the time to identify our ideal customer profile. We haven't gotten clear about what the value proposition is. We haven't tested that value proposition with the ideal customer profile. I mean, what I'm describing is right out of the business model canvas and that book came out a long time ago, right? So it's really starting with, if our goal is to build a product that is gonna be used by people other than us, right? So if I'm building something for myself, who cares? I don't have to do any discovery. I'm gonna build it for me. If I wanna build a product that's gonna be used by anybody else, I have to get clear about who I'm building for, what value proposition I'm delivering for them. I have to understand their needs. I have to understand their pain points. I have to map out the opportunity space. I have to choose where I want to play. I have to then test if what I'm thinking of building is going to actually address that opportunity space. This is the area where I actually don't think anything has changed. AI is making it more accessible for more people to build software. But I think the discovery side of things has not changed. We are still making the exact same mistakes we've always made. We like to think that AI is this new technology and therefore it's in this totally different space. But I think we're just putting a difficulty wrapper on something that doesn't really need it. For you personally, which AI products are you seeing that you believe are truly pushing the boundaries right now? So the ones that you'd recommend without hesitation or the ones that you think are going to stand the test of time? I would say the number one. product that I use the most like all day every day is cloud code. I'm using it for coding. I'm using it for writing. I'm using it for strategy. I literally use it for everything. I don't use a lot of the tool specific AI products. Like I just, I keep trying them. I've tried a lot of things, but I don't, they don't fit my workflow. I actually, we talked about Descript. I recently started a new podcast called Just Now Possible where we interview people about how they're building AI products. And because of that, like I have a podcast, All Things Product, that I do with Petrovilla. That podcast is like unfiltered and mostly unedited. So we do very little editing. It's just us like riffing on a topic. But this new podcast, they're hour plus long interviews. There's a lot more editing. There's a lot more sort of post recording stuff that I have to do. And I started using Descript just in the last couple of weeks. And I love it. Like I just am blown away by what it allows me to do. I use chat GPT and Claude both in the browser window quite a bit. I use both their APIs quite a bit, but I would say Claude code is my go-to. Like I'm in it all day, every day. So for my own curiosity, why do you prefer Claude code for like your content writing and things like that versus just regular Claude? Because I don't have to copy and paste. I mean, in the browser, you're constantly copying and pasting back and forth where Claude code has access to all my files. And so. Like when I'm writing a blog post, I'll write an outline in one markdown file and then I'll write my draft in another markdown file. Cloud Code can access both. And as I write, Cloud Code reviews each section and gives me feedback and helps me understand where I'm deviating from my outcome or my outline. And then I've also like set up sub-agents on Cloud Code that's reviewing my writing from different perspectives. So like I have a sub-agent that's my technical reviewer. It's looking for... have I made any technical mistakes in the blog post? And by technical mistakes, I mean like regarding technology, like have I claimed something that's true that's not true? And I have another sub-agent that's reviewing it for, am I writing equally for product managers, designers, and software engineers, or am I favoring one role over another? And so Claude Code allows me to kind of define these task-specific, like almost lenses by which to review my writing. I guess I literally could do that in Claude. dot AI, but I would have to cut and paste a lot of prompts. People really needed to hear this conversation. It's challenging times right now and research is more important than ever. Can you help our listeners know where they can go to learn more about your methodology, about your writing, and also where they might be able to find your podcast? Thanks. So I write producttalk.org. Historically, I've written about product discovery. I'll still be writing about product discovery. but I'm also building my own AI products, mostly to facilitate teaching and building discovery skills. And so I've been writing a lot about what it takes to build good AI products. And so if folks are interested in that, that's all at producttalk.org. And then I do have two podcasts, All Things Product with Teresa and Petra. That's with Petra Villa. She's also a big discovery advocate based out of Germany. That's... We do like 15 to 20 minute episodes. The idea is that we're sitting in a coffee shop riffing on a topic and you get to eavesdrop. It's a lot of fun. And then the new podcast is just now possible. And that is I'm interviewing product teams about the AI features that they're building. So our first episode was with Ellen Brandenberger at Stack Overflow. That was a super fun conversation because Stack Overflow's business really got hit hard when ChatGPT came out. And they managed to turn it around and find a way to work with all the LLM labs. And then we're just about to release an episode with a team from eSpark where they built a teaching assistant. And they got into all the like intricacies of how do you build AI for teachers that aren't necessarily technologists and super busy, like K through five teachers. So that's a really fun story as well. You can find both podcasts and all my writing at producttalk.org. This episode was hosted by R.B. Dragfiguero. and Brittany Hobbs. It is brought to you by PH1 Research, a research and strategy consultancy helping teams map the future of their products and businesses. Learn more at ph1.ca.

Product teams are moving fast on AI—but speed without discovery is a trap. Teresa Torres—author of Continuous Discovery Habits and one of the most trusted voices in modern product thinking—reveals why teams that skip real customer contact are building faster and failing faster.

In this episode, you’ll learn how to:

1. Avoid the AI discovery trap: Don’t fall for synthetic users, fake insights, and “discovery theater.” Teresa shows how to ground AI-assisted research in real human context so your data actually leads to defensible products.

2. Use AI to think deeper, not cheaper: Learn the high-leverage ways AI can supercharge synthesis, spot patterns across thousands of signals, and accelerate prototyping—without replacing the empathy and nuance only humans can see.

3. Turn discovery into your moat: Discover why first-hand customer contact is still the ultimate competitive edge—and how teams using AI to augment discovery (not outsource it) are finding opportunities their competitors miss.


—-------
This is episode 44 of the Design of AI Podcast.
If this conversation helps you build smarter, rate the podcast and leave a comment—your feedback shapes the next topics we explore.

Want to go deeper? Subscribe to our Substack newsletter for AI strategy & research insights.


Our next AI Product Strategy Workshop is on October 30. In this 3-hour online session, you’ll learn our framework for discovering and pressure-testing disruptive AI product ideas. Get details at https://designof.ai/workshop.

—----------

This episode was hosted by:
Arpy Dragffy Guerrero (Founder & Principal Strategist PH1 Research) ⁠https://www.linkedin.com/in/adragffy/⁠ 
Brittany Hobbs https://www.linkedin.com/in/brittanyhobbs/ 


And if you want more AI strategy & research content, subscribe to our substack newsletter at ⁠https://designofai.substack.com/⁠ 

This episode is brought to you by PH1 Research, a research & strategy consultancy specialized in mapping the future of your business & product. Get more info at ⁠PH1.ca⁠ 

Follow us here:
⁠⁠Spotify⁠ https://open.spotify.com/show/3O11vQKPpKI5ZlJhdRGwnf
⁠⁠⁠Apple Podcasts⁠⁠ ⁠https://podcasts.apple.com/us/podcast/design-of-ai-product-strategy-innovation-career-growth/id1734499859⁠  ⁠
YouTube⁠⁠ ⁠https://www.youtube.com/@ProductImpactPod


------

Teresa Torres is a globally recognized product discovery coach and author of Continuous Discovery Habits. Through her company, Product Talk, she’s helped thousands of teams build the habits that make products succeed: weekly customer conversations, continuous assumption testing, and opportunity mapping that ties directly to outcomes.

She also hosts two podcasts—All Things Product (with Petra Wille) and Just Now Possible, where she interviews product teams building the next generation of AI-driven experiences.

Links:
Blog: ⁠ProductTalk.org⁠
Community: ⁠Members.ProductTalk.org⁠
Product Talk Academy: ⁠Learn.ProductTalk.org⁠
Twitter: ⁠https://twitter.com/ttorres⁠
Linkedin: ⁠http://linkedin.com/in/teresatorres/⁠
YouTube: ⁠https://www.youtube.com/c/ProductTalkVideos⁠