Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. It’s true that discovery takes time. Interviewing customers, building opportunity solution trees, running assumption tests—these are all activities that take your attention away from delivery.
But I’m also a firm believer that discovery doesn’t come at the expense of delivery. Both activities should happen in tandem to achieve the best results.
Discovery doesn’t come at the expense of delivery. Both activities should happen in tandem to achieve the best results. – Tweet This
Still, in our Product Talk courses and webinars, we often hear the complaint that teams don’t have time for discovery.
I get it—I know how packed the average product person’s calendar can be. Yet even the busiest people can manage to make time for discovery.
I sat down with fellow Product Talk Academy instructor Hope Gurion to discuss the top seven reasons we hear for why people don’t have time for discovery and to share our tips for overcoming them.
You can watch the video or read a lightly edited transcript below.
Teresa Torres: Hi, everyone. I’m Teresa Torres with Product Talk, and I’m joined today by fellow Product Talk coach Hope Gurion. Hope, thanks for joining me today.
Hope Gurion: Of course, happy to chat about this
Teresa: Today, we are going to talk about, by far, the number one reason why people think they can’t do continuous discovery.
Just for some context, in all of our classes, we start by asking people what’s their biggest obstacle to working this way, and the number one response, by a long shot, is: I don’t have time.
What we’re going to do today is dig into what that really means, because it’s rare that time is actually the factor, or there’s maybe many reasons why time is the factor, so before you can address this, we’ve got to get into why time is the biggest obstacle, and so we’re just going to go through the seven most common reasons why a team might not have time, and give you some tips on how to address them. Hope, do you want to dive into the first one?
Reason #1: Product Teams Spend All Their Time on Delivery-Related Activities
Hope: Sure. The first one is they’re spending all of their time managing delivery-related activities, so they’ve got full backlogs, they’ve got tons of tickets to be created, to be checked, they’re doing acceptance criteria, they’re doing the stand-ups, they’re managing the overall product development, and so there is no time to do discovery, because they’re completely full managing delivery.
Teresa: Yes, very common. What’s your primary tip in this situation?
Hope: In this case, we’re very solution-oriented. The easiest place to start, I think, is to start doing some solution-related discovery. If you still have something in the backlog that hasn’t been released yet, you could do some assumption generation and see if you can identify your riskiest assumptions and at least see if you can run a couple of experiments to de-risk those riskiest assumptions.
If you’re spending all your time on delivery, the easiest way to introduce discovery is to start doing some solution-related discovery. – Tweet This
Teresa: Yes, I definitely agree, for teams that are very delivery-focused, to start with solution discovery. I think the challenge is: How are they making time for that? One of the things I like to look at is how can we push delivery management to the engineering team itself? Does the product manager really have to be involved in every stand-up, writing every user story, doing all of that sort of scrum management or can the engineers take on some of that load?
I think that’s where I would start. If I was the product manager, I would look at: What’s on my calendar that I can stop doing and have somebody else take some responsibility, and even if I can just find one hour of my week that I can get back? Then I can start doing some of those things like story mapping a solution, generating assumptions, and starting to think about, can I question or test some of those assumptions?
Hope: Makes sense.
Teresa: All right. What’s our second one?
Reason #2: Product Teams Are Spending Most of Their Time on Stakeholder Management
Hope: The second one is that they’re spending all of their time or a lot of their time doing stakeholder management, which is different from managing the delivery, right? It’s usually the communications to interested parties about what is being worked on at this point in time.
These can take the form of project status reports or meetings or Gantt chart creation or intake of new ideas. Often these teams feel like they either have a lot of stakeholders or there’s a lot of worry and fear about not being available to stakeholders, and so that’s why they prioritize any free time that they have to making sure that they are in sync with their stakeholders.
Teresa: Yes, also very common, especially at larger companies where there’s lots of stakeholders to keep in sync. What’s your tip here?
Hope: For teams that have a lot of visuals that they are already working on, one of the things that I recommend is to try to see if you can shift some of those meeting-related stakeholder updates to sharing of artifacts. You may need to send out links to them in email or screenshots of them in email or in Slack but try to leverage existing artifacts to explain what is happening now or next instead of using meetings, which always tend to run long and not be very focused.
Teresa: Yes, and I’m a big fan of using the same artifacts that you’re creating to do the work, to share the work. In a discovery context, that could be your experience maps, your opportunity solution trees, your story maps as a way to communicate with your stakeholders what you’re doing.
I’m a big fan of using the same artifacts that you’re creating to do the work, to share the work. In a discovery context, that could be experience maps, opportunity solution trees, or story maps. – Tweet This
I think also most companies now are using something like Slack and MS Teams, so is there a way to kind of pair this where you’re asynchronously communicating your updates visually, so it’s easy for your stakeholders to understand. Then maybe if it doesn’t eliminate the meeting, at least it reduces the amount of time you have to spend in the meeting.
All right, let’s move on to our third one.
Reason #3: Product Teams Spend a Lot of Time in Cross-Team Coordination
Hope: Third is spending a lot of time in cross-team coordination, and this could be for what we’re going to build next or it could be in the managing dependencies for things that are already in delivery, and this happens a lot of time for teams because there are challenges in the way their teams are organized. They may be organized around tech stacks as opposed to managing individual products or along the customer journey, and so their org design is creating a lot of interdependencies and collisions that need to be identified or rectified, and that can consume a lot of time for teams.
Teresa: Yes, I’ve definitely observed like 100-person meetings where companies are trying to reconcile dependencies across teams on a quarterly basis. It’s a nightmare. What’s your tip for a team in this situation?
Hope: I think this is a tricky one both at the team level and the leader level. The first comes with a recognition—and maybe it does come from the teams. But really when we’re talking about org design-related changes, often this is really for the leader to recognize this—if it’s the product leader, engineering leader, or both—and see if there’s a team or two they can start to decouple and maybe change how their teams are structured. I think that’s the first step to take. You don’t have to completely reorganize your entire team, but look for these opportunities where you can make some changes in the way teams are organized to reduce these interdependencies.
Teresa: Yes, I think this is key. I think we tend, especially with org design, to rip everything up and reorganize everybody. It’s a very big, disruptive change. Whereas what you’re suggesting is, can we just identify one or two teams? We can create them in a way that they’re self-sufficient, they don’t have these dependencies, create an example of what good looks like, and maybe test out org design before we restructure everything.
I think that’s great if I’m a leader, but if I’m an individual, I’ve got to think about, like, “I’m on a team, my work is dependent on seven other teams.” This is where I think the tip is really similar to managing stakeholders, right?
Hope: Yes.
Teresa: It’s how do you visualize your work? How do you use those visuals to negotiate the boundaries between your neighboring teams? Maybe my team has an opportunity solution tree, your team has an opportunity solution tree, we’re looking for overlap, we’re looking at how we align our dependencies that way.
Maybe it’s an experience map, maybe it’s just a story map for a single solution, and we’re looking at, I’m going to do this first and then you’re going to do that and then it’s going to come back to me. But I would look at how I can visualize these dependencies so it’s really clear who is doing what when so that we’re not constantly spending all day, every day in meetings reconciling dependencies.
I would look at how I can visualize dependencies so it’s really clear who is doing what when so that we’re not constantly spending all day, every day in meetings reconciling dependencies. – Tweet This
Hope: Yes, and those visuals can also help the leaders and the teams identify maybe where to start with decoupling some of these teams or changing their outcomes in a way that gives them more total ownership of their progress towards that goal.
Reason #4: Product Teams Spend “100%” of Their Time on Product Support-Related Activities
Teresa: All right, I think we’re on our fourth.
Hope: We are.
Teresa: Fourth one? All right. Good.
Hope: The fourth one is, I’m spending 100% of my time—maybe that’s an exaggeration—on product support-related activities. This is a situation where a team is having to respond to the sales team, the support team, maybe even the marketing team. There’s tons of questions about the product, how it works, is this a bug, is this a feature? Maybe there’s instability issues or triaging of bugs or user experience debt issues that have come up. They’re spending a lot of their time really helping educate or react to questions from other customer-facing teams.
Teresa: Yes, I know in sales, this is why we have sales enablement roles now, and I know in support, it can be even a bigger burden because if you have lots of customers, you have lots of support tickets ideally—not ideally, most likely. All right, what’s your tip here?
Hope: Also I think it gets exacerbated if you have high turnover in your organization in the support or sales role, because there’s a lot of new people who need a lot of information, so I think it’s important to piece out, is the reason for this level of time being spent on support, is it because your product is buggy, unstable, has a lot of debt, or is it that there’s actually not really sufficient sales or support enablement associated with your product?
The tip I would have would vary based on whether or not it’s an unstable product or buggy product versus whether there’s just insufficient sales and support enablement.
Teresa: Okay. Let’s get into those two tips.
Hope: If it’s an unstable product, I think as much as teams want to be driving incremental value for their companies, driving towards some sort of outcome that’s going to drive business value, it’s really hard to do that on a shaky foundation. Most product teams are not doing 100% outcome-driving work. They usually have a mix of keep the lights on, stability work, but you may need to have more of your time being spent on that until your product is in a place where it is more stable, can be evolved in a way that drives value for your customers, because no customer is going to be excited about using a product that is unreliable or difficult to use.
If you have an unstable product, driving towards some sort of outcome that’s going to drive business value, is really hard to do on a shaky foundation. – Tweet This
That’s where I might say you might move away from some outcome-driving work so that you can shore up the foundation of your product experience.
Teresa: Yes, I would think maybe that is your outcome, like if this really is the biggest pain point and it’s taking all of your time, you could set an outcome of: let’s reduce support tickets that require a product person. What I like about that is that you can use the same discovery process instead of trying to fix all bugs—which is probably not possible if you’re finding yourself in this state—but just start to look at: What are the most common support tickets that we get pulled into? How do we reduce those? You could even drive that outcome alongside some other customer-facing outcome where you devote 25% time to that.
Now, usually I don’t want you working on multiple outcomes, but if this is the situation you’re in, it might be a way to kind of continuously chip away sort of the biggest, hardest pieces rather than stopping everything and trying to fix it all at once.
Hope: Yes, and there are great examples of companies that will take a bunch of bugs and UX debt-type issues and bundle them together in sort of, like a pain-relieving release for their customers, which is a great way to do it and tells the story.
The second one, if it’s really about the fact that people just don’t understand what this product is, how it works, why it does this way and that way, I think it is looking at what is our process for sales enablement of our product. If we’re continuously evolving our product, how is it that we’re creating shared understanding with the teams that most need to understand how our product works and why, and why it’s better than their customers’ alternatives? That really does come down to sales or support enablement, and I think there’s different ways that you can structure it.
It may not be a we’re on call answering your questions every time you’ve got one, you may need to dedicate some blocks of time or some documentation or some videos or some specialists within your organization who can help make sure your other customer-facing teams know how the product is working and why so that it is more scalable than the on-call support approach.
Teresa: Definitely, and this I think you could take the exact same approach of, what are the most common situations? How do we design a solution that doesn’t involve the product team, but our support and sales team still get what they need? Great. What’s our fifth one?
Reason #5: Product Teams Are in Meetings All Day Long
Hope: Fifth is the classic, “I’m in meetings all day long,” which is certainly true of a lot of people. For many, many product teams, there are many, many stakeholders, partners in the organization, and it’s very, very easy to get pulled into a lot of meetings.
It could be because they’re invited. It could also be within the team their sort of fear of not being seen as the centerpiece of the product, and they want to make sure they’re there in every meeting.
It could also be exacerbated by lack of clear agendas or clear ownership of what decision are we trying to make. I think there’s a number of root causes for overload of meetings, but I see that as frequently why the teams don’t have time to be practicing discovery as much as they’d like.
Teresa: Yes, I’ve definitely seen product managers’ calendars where they’re double-booked all day long. If I’m in that situation, what do you recommend I do?
Hope: For me, the first thing to do is just take an audit, see really what is driving your reason to be meeting. Is it that you’re invited to all of them and you feel an obligation, like you’ll be seen as not helpful or not doing your job if you don’t attend all of them? Really look to see if that’s real or something that you’ve imagined for yourselves. Then when you do that audit and you think about is there another way that this information can be relayed to the person who’s requesting the meeting.
Maybe it’s a visual artifact or a link to something. Maybe we could do this in an email or a Slack or Teams exchange instead of a meeting. I’d be looking at the audit and seeing where I can cut back on participating in person when it really doesn’t justify the amount of time required.
To reduce meetings, think about if there’s another way to relay this information. Maybe it’s a visual artifact, a link. Maybe we could do this in an email or a Slack or Teams exchange instead. – Tweet This
Teresa: Yes, I would definitely run experiments with this. I think the challenge with meetings, it’s like a little dopamine hit, right? We like being needed, we want to be in the room, we want a seat at the table, throw whatever platitudes you want at that, but the reality is we have other work we need to do, and so we really need to be there. I think what I would experiment with is what happens if I just don’t go to this meeting? Am I missed? Are they still able to make progress? If they need my contribution, can I give it in another way?
Some common ones that I see is product managers want to be in every bug prioritization meeting, whereas usually engineers can handle that. Even if you have one or two bugs that you definitely need to get prioritized, can you just tell an engineer that and then not go to the meeting?
Hope: Right.
Teresa: I think this is true for a lot of scrum rituals. I think there’s a lot of meetings where we could take a more critical look to ask, am I contributing? Am I needed? If I don’t go, am I going to hold something up?
Hope: Right.
Teresa: It’s a hard one, though, because it hits our ego a little bit.
Hope: It does. It does, yes.
Teresa: What’s our sixth one?
Reason #6: Time Spent in Discovery Isn’t Valued in an Organization
Hope: The sixth one is, this is more of a culture issue, let’s say. That is it’s not that I don’t have time. It’s that time spent in discovery isn’t valued within my organization. It’s questioned: “Why are you doing that? We already know everything we need to know,” and it’s really seen as a delay to the inevitable, which is, of course, building that output that everybody thought was a good idea. These are some of the underlying causes of why that time doesn’t feel as valuable as a delivery-related time spent.
Teresa: Yes, we see this especially with engineers, right? An engineer provides value by writing code, and if they’re doing anything else, then their velocity is going down and their value is going down. What do you recommend if you’re working in an environment like this?
Hope: I think, again, it’s a little bit we need to unpack the root cause. Is it that only delivery-related activity is what is being recognized, rewarded, valued? I think, again, that’s where leadership, if a leader recognizes that, they need to take a hard look at what’s celebrated in emails and team meetings and really start to put an emphasis on, “We learned quickly, we avoided something that would have been a huge amount of time without likely creating any value.” That’s the first tip that I have.
The second is if it’s like we already know everything, we’d be wasting time towards the inevitable. I think that’s where doing the assumption mapping and assumption testing for at least a couple of those risky assumptions, even if it’s for the one solution that everybody feels is inevitable, I think that is a way to make sure that we check our confirmation biases, that we know everything we need to know.
Then the third is, a lot of people are spending time creating sort of artifacts for the people who weren’t in the room when the discovery was being done because they didn’t consider it a good use of their time. I think that’s where you have to really question, like, are you providing a Band-Aid to the rest of the organization to keep a distance from the discovery when you could simply share artifacts that your team has already produced—could be an opportunity solution tree, could be an interview snapshot, something where you don’t have to recreate a new artifact to explain to the people who weren’t there and use up more of your time.
Teresa: Yes, one thing I really love about continuous discovery in particular is that you don’t need a lot of time to get started, right? Like if you’re trying to do the whole framework end to end, that’s going to take a lot of time, there’s going to be a huge learning task if you’ve never done it before, but if you take this continuous mindset of I’m just going to pick one habit, so if I’m in a really solution-oriented context, the one habit I’m going to start with is story mapping and generating assumptions.
One thing I really love about continuous discovery is that you don’t need a lot of time to get started. The key is to work one habit at a time, rather than trying to adopt the whole framework at once. – Tweet This
Even just that habit alone, you can do it by yourself, you don’t need access to customers. You can maybe spend 30 minutes to an hour, depending on how familiar you are with it. What that exercise can do is it can start to show the need for discovery, because you can start to surface, “Hey, some of these assumptions feel really risky. Maybe we should just take a day or two to de-risk them.”
If you’re in an environment that’s a little bit more open-ended and you have a wider remit, you might just start with, “I’m just going to do an interview this week.” I think one thing that can really tackle this, like discovery is not valued and therefore I don’t have time, is don’t try to sell it and just find the easiest habit for you to just start doing and just start being the bright spot in your organization.
Hope: Yes, I love that you point that out, because I do find it tends to not be as effective when people try to sell the value of discovery, the process, it’s going to change your life, like that, like it’s much better to start with something tangible and real that’s related to your business, your customers, and I think your suggestions are perfect for that.
Teresa: Yes, we see this all the time. I know right now in our community, we have a member who didn’t ask permission, she didn’t wait for somebody to tell her she should do it. She just started interviewing customers every week. She didn’t worry about the rest of her organization. She didn’t try to sell the process. She’s five or six weeks in, and guess what’s happening? Other teams are starting to get interested. “Hey, what is it that you’re doing over there? You keep having these great insights.” Now suddenly they’re coming to her to learn about the change as opposed to her getting embattled in this ideological war, trying to shove the change onto other people. I think people underestimate how impactful they can be by just starting.
Hope: Great example.
Reason #7: Discovery Itself Takes Too Much Time
Teresa: I think we’re on our sixth.
Hope: We’re on our seventh.
Teresa: We’re on our seventh. See, I can’t really count.
Hope: We’re taking it home.
Teresa: All right.
Hope: The seventh, I’m sure this is not an exhaustive list, but these are the ones that I’ve seen. Maybe people will have others that they notice, but this is that the discovery itself takes too much time. Maybe there are teams that are like, we are interviewing every week, or we’re not learning anything new, or it takes too long to get everybody in the same room, in the same shared space to really synthesize what we’ve learned recently, or maybe we’re running assumption tests and they’re taking too long, so discovery itself is taking too long, and that is becoming a deterrent to doing more discovery in their decision-making.
Teresa: Yes, another common one, especially when teams are new to discovery. What’s your tip here?
Hope: I think what happens is people get like, “Oh, I’m supposed to do these things,” and they kind of lose sight of what really are we trying to do, and if we’re trying to expedite progress on our outcome, then really we should be spending our discovery on the thing that we least know but is most important for us to learn next.
It could be that if you’re hearing the same thing in customer interviews, maybe it’s time to change up your question and learn about something that your team doesn’t really understand, or talk to different types of people than your team has historically spoken to.
Maybe it’s lost customers or companies or people who are using a competitor’s product and not your product. They’re not your customers; they’re competitors’ customers. Or if you’re running an experiment that takes too long, maybe it’s time to switch up your experiment. Maybe you don’t always have to do an A/B test. You could do another type of assumption test that takes less time and really challenge yourselves to see if there’s ways that we could be faster, more effective in what we’re learning.
Teresa: Yes, I think this is really related to the maturity of a team. I think if I’m brand-new to discovery, everything is going to feel slow and take a long time because there’s a learning tax, or that we don’t have the right tools yet, or we’re not aligned on how we do this yet, but if I’m on a mature team and I have access to a one-question survey tool and good data analytics tools and an unmoderated testing platform and I’ve automated my interviewing recruiting process, then I can do all this stuff really quickly, and discovery doesn’t have to take a lot of time.
If I’m brand-new to discovery, everything is going to feel slow and take a long time because there’s a learning tax, but if I’m on a mature team, discovery doesn’t have to take a lot of time. – Tweet This
I think the mistake teams make is they confuse the learning tax or that setup tax with the amount of time it’s going to take to do this forever. I think one of the things that I look for is, week over week as you run assumption tests, are your tests getting faster? If they’re not getting faster, it’s because we’re not investing in tools, we’re not investing in process, we’re just making it up every week as we go.
Same with interviewing. If we’re just hustling to recruit someone every week, that time is never going to go down, we’re going to have to hustle every week, but if we take a week or two to automate our recruiting process and maybe another week or two to refine it, till we have a really good candidate flow, that problem goes away entirely.
Hope: Yes.
Teresa: I think a lot of this is the early days, when you’re new to discovery, it can feel really slow, and we often give up before we get to that point where it gets faster.
Hope: Yes, and if that’s what the rest of your company is using as sort of their taste test of what discovery looks like, it can feel that that’s like a risk. I think you’re absolutely right that this is something for the teams to be cognizant of and for the leaders to be cognizant of so that we can help teams find faster ways to enable their learning and decision-making so that it’s sustainable for them and their stakeholders and partners.
Teresa: Yes, perfect. Okay, we just ran through seven of the most common reasons behind “I don’t have time to do discovery.” What I want to leave people with is if you individually feel like you don’t have time to do discovery—which I know is many of you, because we hear it every day in our classes—think about these seven reasons. Can you dig in and understand what’s keeping you from just getting started on that very first habit? Hopefully we’ve provided some tips that you can put into practice. Thanks Hope, this has been a great conversation.
Hope: Yes, thank you.
If you’re looking for help picking up one of the continuous discovery habits, come join us in a Product Talk Deep Dive course. You’ll build a foundation of knowledge while deliberately practicing a specific skill in a safe setting and connecting with like-minded peers. Explore what’s starting soon here.
