Teresa Torres | Implementing continuous discovery | ep.10

you can still adopt a lot of these discovery habits, even if your organization never changes. Right? So you can work on your own outcome mindset. You can start to map out what are the outcomes my leaders care about, even if they're not thinking about it that way. And then for your product, you can look at what are the product outcomes that drive those business outcomes. And then same with, you can still talk to customers. You can still story map and identify assumptions. You can still test those assumptions. Like most of these habits you can adopt without any buy-in from your organization. And the value of doing that is the quality of your work should go up. And what's great is when the quality of our work goes up, that tends to be when people get interested in the way that we're working. Hello and welcome to the Product People podcast. Here we learn from the most amazing people in the product space for 30 minutes at a time. At Product People, our mission is to help companies discover and deliver great products faster. We do that by doing hands-on product management work at companies of all sizes and also by sharing knowledge generously with our community of more than 20,000 product enthusiasts. My name is João Moita and today we have Teresa Torres with us. Teresa is one of the most recognized names in the product space, being the author of the book Continuous Discovery Habits and the creator of the Opportunity Solution Tree framework, used by product managers in all types of companies worldwide. She is also a product coach and educator. I hope you enjoy this conversation. Most people have probably read or heard about it, but for the ones who didn't read it, can you describe your book, Continuous Discovery Habits, in a couple of bullet points? Yeah, my goal with the book was to give teams a really actionable guide for how to adopt a continuous cadence to their discovery. So how do we build continuous feedback loops with our customers? to make sure we're building the right thing and i really wanted to bridge just sort of theory have it really grounded in evidence from what we know from research but not at the cost of making it really actionable so i wanted to make sure that i gave teams things they could do or start changing about the way they work that very same day definitely the one that most people are familiar with is the opportunity solution tree other than that what are some some of the areas that you focus on the methods that you suggest? Yeah. So one of the things I learned from coaching teams is that one of the easiest ways to think about continuous discovery is as a collection of habits and then to work on one habit at a time. So the book identifies several different habits from things like starting with a clear outcome to interviewing your customers on a regular basis, running assumption tests to evaluate solutions. Those are probably the three primary habits. And then The opportunity solution tree is a way to visualize that work. And then there's a handful of supporting habits. So there's a habit about visualizing what you know, which helps with team alignment. It helps with finding the right structure for your opportunity solution tree. There's a habit around kind of identifying the right assumptions so that you know which assumptions you should be testing. There's a habit around generating a lot of solutions. So how do we generate a lot of ideas quickly so that we quickly find the best ones? But fundamentally, the way that I've looked at it, it's really easy to get overwhelmed. Like, this is so different from the way I work today. And so I think one of the things that's really nice about it is you can really look at it as one habit at a time, but work on building one habit at a time. Yeah, that's super cool. Yeah, that's definitely the easiest way to implement changes little by little. What are some of the biggest misconceptions that you've seen around product discovery? Yeah, the big one I think is some companies split it as two teams. Like you have a discovery team and then a delivery team. So you have one team that's sort of market facing and working with customers and trying to figure out what to build. And then they write up requirements and hand that off to a delivery team. I think the challenge with that is that anybody who's ever built anything has experience. Lots of questions come up in delivery and the delivery team needs fast feedback loops with the customer to get those questions answered. And then also it's just the same challenges we saw with what drove the change from waterfall to agile. It's impossible to do a handoff where all the context and knowledge is transferred adequately. And so a lot of the context gets lost in translation. So the way to fix that is to have the same team doing discovery and delivery. That's a big one. I think another one that's really pervasive is that engineer should just code. that they don't have time to be part of discovery, that there's not value in having them part of discovery. And I think that's really short-sighted. I think a lot of engineers, even if they're initially reluctant, get a ton of value from engaging with customers and we end up building much better solutions and actually a lot faster if we have engineers involved in discovery. So I think that's a really common one. And then I think that probably the third most prevalent one is related to the product and design roles and it kind of varies by organization but some companies think product owns discovery other organizations think design own discovery whereas i really think the best model is when we take a cross-functional approach and having all three of those roles run discovery together definitely those three roles that you're mentioning you also call them the product trio so the product manager designer and the engineer working together What have been some contexts where you've seen working well? Yeah, so the first thing I'll say is that the product trio concept is really misunderstood. People think it's very rigid and that it's absolutely just those three roles and everybody else is left out. That's not the intent. The intent is that based on the roles available to you, you're looking at how do you take a cross-functional approach to discovery. And most organizations, that's going to be a product manager, a designer, a software engineer. But if you work somewhere where you have a lot of user researchers, you probably have a user researcher involved. There's a lot of variations on this. But the key is how do we work together when we're making decisions about what to build in contrast with what we used to do, which is kind of hand off from silo to silo. How does it work in practice? I think a really well-functioning trio, regardless of what those roles are, they're spending a lot of time together. I mean, there's a lot of... but this time working together interviewing together building out their opportunity solution tree together generating solutions together generating assumptions together running and evaluating assumption tests together and i think this is part of the reason why there's some resistance to this idea is it feels inefficient like why would we all spend this time doing the same stuff when we could divide and conquer but it's a little bit counterintuitive that up front together time saves us time downstream. When we don't do that, we get a lot of misalignment. We get a lot of disagreement on what we should build. We get a lot of back and forth, rewriting of requirements, rebuilding of stuff. We end up building a lot of the wrong things. So I think a well-functioning trio is spending a lot of time together. Now, some people push back and say, well, when does the designer do design work? And when does the engineer write code? And when does the product manager go deal with stakeholders and the other things that they do? And I think practically like we're not talking about trios spending all day every day together but i do think they are touching base every day and they might be spending an hour or two together every day and they still have plenty of time to do their other parts of their job but i think the best product trios it's just becomes the way they work they spend a lot of time together yeah that makes a lot of sense and how do you see that balance of having this three person core group versus involving the whole team. So a team that has obviously multiple engineers and probably multiple designers, who do you pull into what conversations? Yeah, so I often talk about it as the trio leads discovery. That doesn't mean they're the only ones involved in discovery. So I want to see everybody on the team have some exposure to customers and to the discovery work. So there's a lot of ways to keep the rest of the team involved. You can have other people join in on interviews periodically. The whole team, different people are going to be involved in running assumption tests. I think everybody needs to follow along whether they're involved or not. So there's ways to share what you're learning every day, whether that's asynchronously in something like a Slack or MS Teams channel, or if it's part of your standup. It could be as simple as like we interviewed a customer and these were the highlights we learned yesterday. It could be different people getting involved at different times. So some people, some of your engineers. might be better with helping with different types of assumption tests and other tests. They might rotate in and out based on what you're working on. I think the key is that we, like the bulk of our engineers, we need writing code and being focused on delivery. Same with design. Like there's a lot of design delivery work, but we want everybody to be able to follow discovery as it's happening. So what we want to avoid is like we went away into discovery and then at the very end, we're going to communicate our conclusions. Right? I think the challenge with that is it's really easy to disagree with conclusions. Whereas if you communicate the whole journey, people are part of that journey and they come to the same conclusions. Yeah. That's super good insight and very specific. So one of the things that a lot of teams go through is struggling from moving from this ad hoc or project based research into a continuous. habit that they can stick with. And what this leads to is that sometimes they have a bunch of insights that they've gathered in a specific period of time, and then they will only use those insights in some weeks or even months from that time. Do you have any rule of thumb for expiry date on research insights? Any way that you assess if an insight that was gathered is still valid at a certain point later in time? Yeah, I don't have a rule of thumb because it's really going to depend on the insight. I mean, some things are pretty stable, right? One way I think about it is that our behavior that's driven by technology changes all the time. Our behavior that's driven by our sort of core psychology is pretty stable. So I'll give an example. Like humans are always going to need social connection, right? Like that's a core human need that's not going to change. Now, how we connect with others. is often mediated by technology. And so that might change regularly. So it's a little bit tough. Like we can look at when we're learning about our customers, we can look at is this sort of grounded in psychology or is it grounded in behavior of being influenced by technology? But I think really it's not about when does our research expire? I think this is like one of the key nuggets of a continuous cadence that people misunderstand. In a project world, we would do like half a dozen to a dozen interviews, like synthesize that into a report and we would end up with some insights that then this question of when do they expire becomes really important. But with continuous interviewing, we're always talking to customers and we're making decisions based on all of our conversations up until that point. And so if you're regularly talking to customers, you're going to catch when their behavior starts to change. Right? So it's less about like this one specific insight, has it expired or not? It's more about what are we hearing across our interviews? What trends have changed recently? How have what we built and released impacted those conversations? And so it's more about like this continuous stream that helps us just have a broader context. Yeah. Cool. That's a cool one. I would like to also talk a little bit more specifically about the opportunity solution tree. before getting into the details? What is it? So an opportunity solution tree is a visual that I designed to help teams chart the best path to their desired outcome. So one of the challenges that I see is that a lot of us in our career, we've worked in organizations where we've basically been given a strategy and told what to build. Right? So this quarter you need to build features A, B, C and D. So we're shifting, that's an output mindset, we're shifting to an outcome mindset. So now we're being asked Hey, here's this metric. Can you make it go up? Or can you improve whatever desired outcome we're looking for here? So the challenge with that is that's a very different type of problem. It's very open-ended. It's what academic researchers call an ill-structured problem. And that type of problem solving is very different. And so teams need a way to give structure to that problem. So the opportunity solution tree is a visual that helps us externalize the structure we're implicitly giving to the problem. So it starts with your outcome at the top, and then there's space to map out what are we hearing from customers, what are their unmet needs, their unmet pain points, and their unmet desires, which we collectively call opportunities. And then below that, we can start to map what solutions we might build. And it ensures that we're designing solutions that actually address specific customer needs while also driving our outcome. So it's a way to stay aligned, that we're definitely going to create value for the business by driving our outcome. But we're also going to satisfy our customer by making sure our solutions are tightly aligned. And then because it's a visual, it helps our team stay aligned on what we're learning and our context. And it helps sort of give structure to this open-ended, how in the world are we going to move this metric? Yeah. And you've also mentioned in the past that one of the frustrations you felt about seeing other people use this framework is... the way they frame opportunities, sometimes it's still tied to the old ways of working where you just come up with feature ideas and you start solutionizing right away. So they frame opportunities still as solutions. How do you recommend people frame their opportunities in a way that it's, that it avoids having the solution directly within the opportunity? Yeah. So this, it's not too surprising, but Really understanding the difference between an opportunity and a solution is very challenging for people. We're product people, right? So we think about solutions all day, every day. And so it actually takes a concerted effort to step back and say, wait, hold on a second. What's the underlying need, the underlying pain point, or the underlying desire? And it's not always obvious. Like I'll use an example from Slack. So a lot of us use Slack all day at work. And a really common pain point is I get too many notifications. Right? Like most people that use Slack, that's like really resonates. Well, I get too many notifications is a pain point, but it's a pain point that was created by the product. Right? And so I would argue even that framing of the opportunity is too grounded in the solution space. Because it's not like any of us wants notifications. That's not our need. Our need is not, I want more notifications. Right? Or I want no notifications. The need is something along the lines of, I need to know which conversations need my attention. Right? And maybe there's a pain point of, I don't want to be interrupted for a conversation that doesn't need my attention. So those two framings have nothing to do with the product. They have to do with our work and what we're trying to accomplish and how we're collaborating with our customers. So it's a very subtle difference, but what it does is it opens up more of the solution space. So in the first framing, I get too many notifications. the only way to solve that is to work on notifications where the other framings of like i want to know about the important conversations or i don't want to get interrupted by stuff that doesn't matter to me now i have a lot of potential solutions that can explore that may or may not impact notifications right it's a great example i think it illustrates perfectly the the problem of framing opportunities properly and going to the solutions so one of the but still visualization is that from the solutions you draw or you create some experiments to validate your assumptions what is the role of experimentation in the opportunity solution tree framing and how can teams design and run effective experiments yeah i've moved away from the experiment language i'm not i mean you could probably still find it on my blog because i haven't updated all my old stuff but With the book, I made a deliberate decision to start referring to them as assumption tests. And that's because experiments really, like, some people hear that word and they think about, like, randomized, double-blind, controlled experiments. And that, we just don't have time for that, right? Like, that's not what we're doing in the product world. And then also, with experiments, we tend to think about, like, I need to run an experiment for this whole idea. And that tends to lead people. to building the idea and A-B testing it. And that's like the least efficient way to test an idea because we did all the work up front before we learned if it was the right thing to build. So I now use the language assumption testing because that reminds us that like first of all, we're testing our assumptions, not our ideas. It allows us to move quicker. It allows us to compare and contrast solutions against each other. And then an assumption test is something that is designed specifically to test an assumption. And I think that helps with helping teams move quicker, staying focused on a really tight test. I do think language matters and it sort of frames the way we work. And I think assumption tests have helped teams move a lot quicker. And what are some specific tactics that you usually implement or that you recommend implementing when it comes to assumption mapping and validation? Yeah. So the first piece is that teams have to do the work to see their own assumptions. So if I just say, hey, what assumptions do your idea depend on? it's really hard to answer and you might be able to come up with a couple of things but they're going to be probably too high level and you're going to have a lot of blind spots so one of the things i teach in the book is to story map your ideas that forces you to get really specific about how your idea might work and then you can use each step in the story map to help you generate very specific assumptions about what you're assuming the customer is willing to do about the usability of each of those steps that you're assuming they're willing to do It helps. There's a couple other exercises in the book to help you generate sort of viability assumptions. Why will it be good for your business? And then there's a whole section on ethical assumptions. How do we make sure we're not introducing harm? And then one of the exercises that helps you generate a lot of assumptions. And I think about identifying assumptions as a divergent activity. So it's like brainstorming. We want to generate as many as we can, but we're not going to test all of them. Like we don't have time for that. So then David Bland has a really great exercise called assumption mapping, where we quickly prioritize the assumptions that are the riskiest. And so that's where we're going to identify a handful of assumptions from each of our ideas to quickly test. And that's what allows us to work with multiple solutions to compare and contrast them against each other and to really sort of have a little bit more intellectual honesty. What a lot of teams do, they work with one idea, they're testing their assumptions and they're looking for them to work, right? they are trying to validate their idea and the challenge with that is that we sort of slip into these areas where we're going to fall prey to variety of cognitive biases whereas if we set up a good compare and contrast decision we're more likely to be more honest in our work and and get more value out of our assumption that yeah let's maybe dive a little bit into your experience as a consultant and coach what has been the most challenging company environment you found to implement discovery? I think the key is that in order, there's a few different elements of this. So any organizational change, you're going to have to see the change take hold at different levels of the organization. Right? So a lot of leaders, they think, oh, this is the skills gap of our product teams. So we can just get our product teams training and then they'll magically work this way. That tends to fall short. Most teams do need training because they haven't worked this way before. But that change can't just happen at the individual team level. It also has to happen at the middle management level and the senior management level. Because if it doesn't, like I worked at one organization where the senior leadership thought they were bought in and thought this was the way they wanted their teams to work. They got training for their individual teams, but they didn't do any work at the middle management level. And so what happened was the teams were hearing from their senior leaders. go do this work but then when they would go bring the results back their middle managers would say yeah but i want you to build this thing anyway right and then i've seen it happen the other way where maybe a head of products is driving the change and even the middle managers on the product team and the engineering team are bought in but the rest of the executive team isn't brought in bought in so they do all the work and then the ceo comes in and says yeah but we're going to just build this thing so what's hard about change in an organization is that everybody has to change and the change doesn't really take hold until everybody has sort of changed at a similar rate and to a similar degree and that change happens at different rates and so while the change is happening unevenly across the organization it's really frustrating because the old way works to some degree and now it's not working anymore right because everybody's in the middle of this change and you're not yet getting the benefit of the new way of working and it's just chaotic and messy And I think a lot of organizations aren't prepared for that and they don't tackle the change at all of those levels at the same time. And so that chaotic period goes on for longer than it should. Right. Yeah. Organizational change, it's always a very difficult topic. And on that, how do you recommend product managers, so individual contributors, even if in a more senior level, but still as a IC, how do you recommend that they go about implementing or fostering this continuous discovery culture in a company without such culture where like feature requests usually originated from sales or even directly from the CEO or the founder, as you were saying. How do you think PM should act? Yeah, one of the things I tried to do in the book is to give people habits they can adopt regardless of their organizational context. So one thing I often say is if you're an individual contributor in a company and like you're literally being given a roadmap, build these features, you can still adopt a lot of these discovery habits, even if your organization never changes. Right? So you can work on your own outcome mindset, you can start to map out what are the outcomes my leaders care about, even if they're not thinking about it that way. Right? So our business outcomes tend to be derived from our business model, which means that anybody can take the time to start to map that out and look at these are the business outcomes my team cares about. And then for your product, you can look at what are the product outcomes that drive those business outcomes. And then same with, you can still talk to customers. You can still story map and identify assumptions. You can still test those assumptions. Like most of these habits you can adopt without any buy-in from your organization. And the value of doing that is the quality of your work should go up. And what's great is when the quality of our work goes up, that tends to be when people get interested in the way that we're working. And so by improving the way that we work, we get people interested in the way that we work. And then that's what gives us some influence to start to change the organization. So I really recommend that individual contributors just work on their own habits. Don't worry about what's outside of their control and just work on one habit at a time and be patient. Right. Just show how it works in practice before trying to change everything. That's super useful advice. And you were mentioning that... this change needs to happen on several different levels. On the organizational level, how do you think this change can take place? Like, what are the steps or the phases of change that need to happen for an organization to go from a project mindset or even a non-discovery mindset to a continuous discovery culture? Yeah, there's a lot of pieces to this. I don't know that I have a step-by-step process, but the things that I would think about are... First of all, at the leadership level, there's a mindset shift. So there's a commitment to this way of working and the mindsets around it. So for a lot of leaders, they're used to being able to dictate outputs. And that's really hard to let go of, especially because they're ultimately on the line for the success of their teams. So oftentimes under duress or under stress, we revert back to our old habits. And that's when we see leaders, even if they are committed to this way of working. they're going to fall back to what they used to know, which is to dictate outputs. So there's a lot of work that has to happen and commitment that has to happen at the leadership level and buy-in at that leadership level. There's also sort of organizational structure stuff that has to happen. So most teams are not structured where they're working in trios, where they're collaborating cross-functionally. We still see a lot of engineering teams set up like IT departments where they're just taking orders and filling tickets and the rest of the company doesn't interact with them at all. So there's definitely some team structure stuff that has to happen. As part of that team structure stuff, most companies aren't resourced to fully resource product trios across their teams. Typically, they have more engineers than they have product managers for teams or designers for teams. So that's a challenge that has to be fixed. So that really takes a huge budget commitment to working this way. And that's just at the team level. You also have this sort of middle management level and getting everybody bought in there and making sure that from the top all the way down. people are changing the way they're working and their expectations and their mindsets. And then I think at the team level, there is a lot of skill building. Individual contributors that have never worked this way are not going to do a great job interviewing customers the first time they talk to them. They're going to have to learn how to interview Will. They're going to learn how to identify assumptions. They're going to have to learn how to assumption test Will. They're going to have to learn how to deal with this messy open-ended challenge of how do I reach this outcome. So it's a big hairy problem. I am excited to see that Marty Kagan and his partners are writing a book about this because they do a pretty good job. And I think organizations need a roadmap to this. I think Melissa Perry's Escaping the Build Trap is a really great book for giving organizations a blueprint of like how much is involved in making this change. I think most companies underestimate it and don't commit enough to it. Yeah, at least I think there are some good examples of companies trying to make a change, especially I'm seeing now in Europe that's still lagging a bit on product innovation compared to the US. But I see a lot of good efforts happening. I actually disagree with the statement that Europe is lagging in the US. What's your take on that? In my experience, teams in Europe feel like they're behind, which is funny to me because they seem, in my experience, coaching teams and teaching our courses. I think Europeans are much more eager to learn. And maybe it's because there is this feeling that you're behind. I would say like in 2013, I was in Switzerland for a conference. And at that time, I felt like Europe was behind. I felt like people were just starting to talk about agile. They were still a very prevalent waterfall model. But 10 years later, I think it's completely flipped. I think a lot more teams in Europe are moving towards trios and cross-functional collaboration. and are eager to learn and are investing in training. Whereas I think in the US, we have this really prevalent culture of we're doing it right. And then I think that comes at the cost. I think that comes at the cost of learning. And I don't think we're doing it right. Like I think a lot of startups think because they're in the startup ecosystem, they must be doing it right. But if you look at their week over week practices, they're not adopting the behaviors. And then same with we have a lot of big name, like the Fang companies. Obviously there's a lot of parts about their culture that are good and having a big impact. But I think a lot of companies take one element of that culture and then copy it wholesale. And then they use that as an excuse, like as a reason for why they're doing things right. And then they don't keep investing in their learning. Now that's a broad statement. There's plenty of companies in the U S that are doing great work and are investing in this, but I would say as an overall trend, Europe right now in this moment in time feels way more eager to learn nice that's actually super interesting and comforting from a european perspective um so yeah thanks a lot for sharing your insights there just to wrap it up a quick questions about your career how did the change from individual contributor from product leader to more consultant and coaching happen Yeah, early in my career, I played a number of individual contributor roles. I've actually been in all the trio roles. I did some front-end development early in my career. I was an interaction designer early in my career. I always worked at really early stage startups. I think at my second company, I had a product tell me he thought I was doing product work. And that sort of, I was doing front-end development and design work. And then I shifted at that company from doing design work and product work. And then at the next company, I came in at the director level. So I came in as a director of product in UX and then sort of moved up through the ranks as a, I think I became the VP of product and then the VP of operations. Then I became the CEO of that startup. And then really that change happened because I've always had like a really high level of agency and I never, I really was never very good about just staying in my lane. I really wanted to like understand the whole business and and be part of helping the whole business in all different areas. And I've found that's often rare from individual contributors. They struggle to understand the perspectives of other roles in the organization. So like a good product manager needs to understand the sales goals and what the purpose of the sales team is. And I see a lot of product managers butt heads with sales instead of trying to look at like, yes, we need to serve the whole market. That's true. And this sales rep needs to close this deal. Right. And so I think the more you can hold both those things in your head at the same time and navigate those, and that applies everywhere, right? Like with marketing, with sales, with finance. And I think that I always just did that naturally because I like the sort of complexity of what a business is. And then after that company, I went on to another startup as the head of product and design. And I had a really hard, at that point, I had a really hard time. For a lot of reasons, but I made a decision when I left that company that I wanted to focus on coaching. I really, what I loved about my roles as an executive was developing my team. What I didn't love was sort of the political, the politics of executive alignment. And I was just sort of done with that. And so that's what motivated my shift. And then I've been coaching and training ever since. Cool. Just before we wrap up, what are some ways that people can still learn from you after? this show? Yeah. So the book, Continuous Discovery Habits is available worldwide. And then I also blog at producttalk.org. So there's a whole bunch of free resources there. And then for folks that have read the book, if you want help putting the habits into practice, we do have a community for practitioners putting the habits into practice. That's at members.producttalk.org. And then we have a wide variety of online courses to help you build skill in the different habits. And you can find those at learn.producttalk.org. Cool. Amazing. plenty of resources for everyone to learn more. All right, Teresa, thank you so much. It was a pleasure talking with you. Great. Thanks for having me. Thank you for listening to this product people podcast episode. Make sure to follow our show on your favorite podcast app so that you don't miss the upcoming conversations with inspiring product leaders. We'd be really happy if you can rate our show on Spotify or Apple podcasts, or if you share it with someone who might find it interesting. To find out more about us and access our community, check our website, getproductpeople.com, or head over to our YouTube, LinkedIn, or YouTube pages. You can find all the links in the episode description. See you next time.

In this episode of the Product People Podcast, hosted by Joao Moita, Teresa Torres dives into the concept of continuous discovery habits. She highlights the challenges that arise when separating discovery and delivery in product development, emphasizes the importance of involving the entire team in the discovery process and shares insights on stable vs unstable research findings. Organizational change and the role of ICs in implementing continuous discovery in an organization is also discussed. Furthermore, she explores the opportunity solution tree framework and how it connects to assumption testing. The podcast concludes with Teresa reflecting on her career path and the differences between the US and European Product scene.



About us:



Product Management community and Interim Product Management services. Our mission is to help companies discover and deliver great products faster. We empower Europe's Product Management community to share knowledge generously for free. We earn money with Interim product management services for parent leaves or when hiring is slow. We manage the unglamorous hands-on work of a Product Manager/Owner, Product Ops, or Product Leader on an interim basis (3+ months). We onboard fast, align teams, and deliver outcomes.



Join us here too:



🤩 Community Chat on Telegram https://t.me/getproductpeople



📆 Upcoming events on MeetUp https://www.meetup.com/productpeople/



🎥 Talk Recordings on YouTube https://www.youtube.com/c/ProductPeopleManagement



📌 Updates and Product Opportunities LinkedIn https://www.linkedin.com/company/getproductpeople



📝 Blog articles on Medium https://medium.com/getproductpeople



🎏 Alternative locations:



Facebook https://www.facebook.com/getproductpeople



Twitch https://www.twitch.tv/productpeople



Discord https://discord.gg/e4xkuwMPbK



Timestamps:



(1:31) Continuous Discovery Habits



(3:45) Problems with splitting discovery and delivery



(5:31) Setup of the product trio



(7:53) Involving the whole team in discovery



(10:10) Stable research insights



(12:09) Opportunity solution tree



(16:46) Assumption testing



(20:24) Implementing continuous discovery at an organization



(22:47) Developing discovery habits as an IC



(24:46) Organizational change



(27:28) European eagerness to learn



(29:45) Teresa's career path
 

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit getproductpeople.substack.com (https://getproductpeople.substack.com?utm_medium=podcast&utm_campaign=CTA_1)