Loading summary
Transcript16 lines
- [00:00]
A
Creating great products isn't just about features or roadmaps. It's about how organizations think, decide and operate around products. Product Thinking explores the systems, leadership and culture behind successful product organizations. We're bringing together insights from multiple product leaders pulled from past conversations to explore one shared topic offering different perspectives and lessons from real world experience. I'm Melissa Perry and you're listening to the Product Thinking podcast Podcast by Product Institute. We're starting with Teresa Torres, author of Continuous Discovery Habits. Her episode is one of our earlier ones, but the fundamentals she lays down are still the clearest articulation of what continuous discovery actually means. And we were not going to put this topic together without going back to the source. Teresa breaks down the three part structure underneath all discovery, work, outcome, opportunity and solution and makes the case for why teams at Discover Right never have to stop after that. We'll hear from Christina Wotke, lecturer at Stanford, on what a real weekly testing rhythm looks like when it's embedded in the culture from day one and how you scaffold feedback from yourself all the way to strangers. And we'll close with Julia Austin, senior lecturer at Harvard Business School at the time, who pushes back on the temptation to skip discovery in the age of AI and and makes the case for why going slow on foundation work is actually the fastest path to shipping something that works. Let's start with Teresa. So 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?
- [01:37]
B
So I'm going to describe this in two different ways. So first is just what are we doing in discovery? And I think the first is it's 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, which is a 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. And then we have to just that if we address them would drive that outcome. And then we need to discover the solutions that would address those opportunities in a way that would drive the outcome. And so 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, we can 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. Like, 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? To find that outcome. That's usually your business value. Right? Your outcome usually represents how you're going to create value for your business. And then define the opportunity space. That's how you're going to create value for your customer. And then make sure that your solution ladders up to both. And then the methods can, can be swapped in and out based on a team's preference. So that's one part of what I would say is like the set of discovery activities. And 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.
- [03:41]
A
And I think that's so key. It's so important to just, like, come back to, you know, the opportunities that you're talking about and, and, you know, figure it out as we go. And I see those things, like, emerge as we do discovery. Right. Like your roadmaps will just be be living documents like we like to talk about. But if you're doing the continuous discovery habits that you talk about, like, 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.
- [04:10]
B
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. Right. Like 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 realize is a big change. And maybe your next opportunity changed, but that's it. You have to throw away a whole roadmap. You don't have to do 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.
- [05:01]
A
What Teresa described is the scaffolding underneath every discovery method. The specific method matters less than the structure, outcome, opportunity, solution. And the rhythm is non negotiable. Teams engaging with customers every single week, synthesizing as they go, never stopping long enough to lose the thread. That is what unlocks real agility. When the world changes, you don't throw away a roadmap. You just shift to the next most important opportunity. Christina Watka built that same rhythm inside Zynga and now embeds it deliberately in her students at Stanford. Here's what it looks like when it's truly part of the culture. I don't recommend tools unless I actually use them. So when I tell you granola has become a daily essential for me and most my team, that means something. We're all in a lot of meetings. Granola is an AI notepad that quietly enhances your notes in the background. No bots joining your call, no awkward recordings, just cleaner thinking after every meeting. It's the rare tool that gives you time back instead of asking for more of it. You can try it yourself with 3 months free on any paid plan at granola. AI productinstitute. I do see this trap in product management where if we go after these business goals at all costs, we forget about that user value. What do you think game design does as well too to make sure that you remember the user value. Like how do you teach your people when they're designing it to understand their users better, empathize with them, make sure there's really like a goal for them on that side?
- [06:29]
C
Well, one of the unique things with my class is we have play tests every single week period. And we just, I, I got that from Zynga where we would always have user research every single week. I don't know if all game studios do it at that pace, but that pace was mind blowing. You just always had people coming. And I know Teresa Torres talks a lot about that as well about that just every week somebody's scheduled you're going to work with them, period. And so I build up the habit where I almost get them addicted to play testing. Because if you play test really early and they're like always embarrassed, you know, they got these crappy paper prototypes, but I try to show them crappy paper prototypes to know what they should expect to be play testing. And they play test with each other and then they debrief and talk about what worked, what didn't work, what else could they do? And then it gets even more intense towards the end of the quarter when they're pay testing every single class, every single section. And that rhythm, it's really right, if you remember, right. Methodology, rapid iteration, testing and evaluation, something like that. It's that idea that you test with, you know, three people, maybe make some changes, test with two or three more, et cetera, et cetera. But that really connects you to the customer. It's really easy to drift off into like this sort of auteur mindset where you're so busy making the thing perfect and you don't feel like it's ready to be shown to anybody. Especially with games. The thing about games is like music or movies, they are both the commercial product and art. And so the students will get very emotionally attached to the thing that they're working on. And you really have to push them to show that work to other people.
- [08:09]
A
That's really cool. And I get a lot of parallels in there about rapid testing for products too. And I see a lot of companies disappear or not want to show anybody what they're working on because they're afraid they can't make this splashy launch. And if we show it to people, they're going to expect it right away and all of that stuff. And that's where they get stuck building so many things that really don't matter at the end of the day and end up in the build trap.
- [08:32]
C
When I think about the projects I worked on when I was in industry and we do a tiny bit of need finding and then maybe a usability test at the end. I can never go back from this rhythm of testing once you've experienced it and it's just so powerful and so useful, you can't do anything else.
- [08:48]
A
A lot of places they're not even testing internally with people in their company that might not be working on anything into like how they're building it. And that's an opportunity for like usability testing or helping there. Not that you should stop there, but I see those like baby steps not even being taken sometimes. And I also think we paint this vision of this rapid iteration, rapid testing that we expect everybody to get to at the end of the day. And I like what you're introducing because it's not like you have to be there today. Right. It's like I introduce you to all that scaffolding before you actually get there. And I think that can apply for teams that are getting used to getting feedback, showing things that are half baked, like, how do we show it internally, maybe how do we show it to one customer or like friendlies? And then how do we take it somewhere else? And how do we keep building on this practice?
- [09:33]
C
And there's a lot of dogfooding. You're constantly playing your own game. The idea of doing kind of solo testing, as a starting point, just ask yourself, how does this feel? Is this working? Does this matching my vision, but then immediately turning around and going to colleagues and we talk about the path, which is, first you test with yourself, which means building something so you can actually evaluate it. Then you test with other designers as a way of having someone who's very thoughtful and hopefully has some knowledge to give you advice. And then you start moving out to friends and family that could be admins in a company or other coworkers who work in something that's not in your area, and then that's a little easier. And then eventually you move to stranger testing, where you're actually just giving them the game and letting them play by themselves without you there to tell any rules or anything. And it's just a nice staggering up that gets you a really good final product. Because if you think about it that way, you're not exposing strangers or playtesters to a really shitty thing. You start intimate, you start safe with people who understands that crappy is okay, and then you move your way out.
- [10:38]
A
Christina's model answers one of the most common blockers directly the feeling that what you're building isn't ready to be seen. Her answer is to start where it's safe, to be wrong and earn your way outward from there. But even the most disciplined discovery practice can face pressure to shortcut, especially when AI promises to replace the need for real customer conversations. For our last perspective, here's Julia Austin on why slow discovery is still the fastest path even now. What does it mean to go slow, to move fast?
- [11:07]
C
Yeah.
- [11:08]
D
So my philosophy is, if you put 80% of your time in laying the foundation and doing solid discovery work, really understanding the problem you're trying to solve, for whom, and have some of those foundational Questions answered, or at least you've thought about them, right? What kind of company are we building? What kind of legal things might we have to worry about? Those types of things, then you're not going to be spinning your wheels later and wasting a ton of time because you did the wrong thing right now you can't do everything perfectly and certainly again, with great tools out there now you can whip up a quick MVP and do a lot of prototyping and other things pretty easily and experiment. But what often happens is this temptation to build something and put it out there and then no one understands. Everyone says it must be a marketing issue. I don't understand why nobody's adopting this. And then you start unpacking. You realize we don't really understand our customer. We don't really understand the pain point. Or guess what, there's a user and there's a buyer and our user, it lands for them beautifully. But they're not the ones that are going to swipe your credit card to buy this thing. So we haven't really fully understood the pain point of the people who are going to spend the money to actually give it to them to use if they it's B2B. So that's what I mean by slowing down, is take the time, do the ethnographic research, do some experiments, really spend time with your target audience. And that's going to inform you, not only get you closer to, we should build that for these particular groups of people, but then the other thing it does is it helps you understand and learn whether this is something you want to do.
- [12:36]
A
When we were talking to you about how we have to slow down and understand our customers to really figure out what the solution should be, it made me think of AI too. And I'm sure you have a lot of opinions on this, right? With all these prototyping tools that are out there, your lovables, everything. I see so many people go, oh, we don't really have to do discovery. It's cheaper to just build it, put it in front of somebody and see if it works and tweak it from there. What do you say to people who say that?
- [13:01]
D
Yeah, I have such a visceral reaction to this because it's so funny, right? Because I'm an innovator. I've always worked on like cutting edge technology. But also AI is not new, right? So I just, it makes me laugh. Also it's this false sense of security that an AI will give you all the answers so you don't have to actually talk to Real people. And this, I think, is a big struggle for founders is talking to strangers and actually getting out there and understanding human dynamics. If human beings are going to use your product, you need to interact with human beings. And AI is definitely great and does a lot of really cool things, but humans will do things that you don't expect. And you and I have been building products for decades. And even when we think we've done all the user research and all the focus groups and all the things and then we put our product out there, I don't know about you, but I've had plenty of times where then we put it in front of the customer and you're like, oh, they're doing that. Like, I hadn't thought about that. Or they developed some workaround because we didn't think about some natural thing in their environment that some tab they opened on their computer they never told us about in an interview. Or like back in the day, it was like opening a drawer and looking at a sticky note because there was some code they needed to do a thing, but they never bothered to tell us that. So I think that AI can be helpful to get some efficiency going. I'm going to go run an experiment. What am I missing? Or what would be a great place to go find these people that I want to go run this test with? Or. So I think it can be a great thought partner and maybe a first pass in certain simulations you might want to do before you get out there. But I don't know, I don't know how you feel about this, but I feel like at the end of the day, you got to get it in front of real people and you got to see what the real environment is to really know if you're building the right thing.
- [14:33]
A
That's all for today. I hope you're leaving with a sharper sense of what continuous discovery actually looks like when a team is doing it well. And at least one thing you can bring back to yours. If you want to hear the full conversations with Teresa, Christina and Julia, check out episodes 30, 226 and 231. If you want to build stronger product management skills and learn practical approaches that you can use day to day, head over to Product Institute to learn more. And one more thing. For a productivity boost, I encourage you to try out Granola, a tool I use every day. It's an AI powered notepad for meetings that helps capture notes and decisions automatically without interrupting your flow. You can get 3 months free on any paid plan at granola AI productinstitute thank you so much for listening to the Product Thinking podcast. We'll be back with another episode bringing you practical perspectives from across the product community. We'll see you then.