Listen Here
The Benefits of Squad-Led Discovery
"Squad-Led Discovery" is where cross-functional Product teams collect customer feedback on their own. They don't depend on a user researcher to be assigned to them.
These Product teams recruit and interview customers, create prototype solutions and make decisions based on qualitative evidence (rather than hunches).
Most squads have an outcome goal to reach when building technology. By having the squad also do the user research, a Product organization is aligning the everyday work of solving customer needs with the end goals of the company.
If you're in a Product team, you can become a squad that does Discovery regularly.
Listen to Lily, Randy, and I discuss how to make this happen.
Lily Smith
You know, Randy, I always wanted an excuse to do less work, and now I have one.
Randy Silver
Why? What's happened? Has the singularity suddenly occurred? You know, the nerd rapture?
Lily Smith
No. I should be so lucky. Instead, we talked to Jim Morris, product discovery coach, about how the team should be doing more discovery and not just leaving it all to UX and research.
Randy Silver
But you, you run product and growth. You're not a UXer or a researcher.
Lily Smith
That is true, but then I tend to work in startups where a researcher is a luxury we don't get to have. So the idea of sharing the customer research is music to my ears.
Randy Silver
I tend to work in larger companies, and a researcher dedicated teach team is a luxury there, too, most of the time. That sounds great, but it also sounds really challenging. So let's hear all about it from.
Lily Smith
Jimmy the product experience is brought to you by Mind the Product.
Randy Silver
Every week, we talk to the best product people from around the globe about how we can improve our practice and build products that people love.
Lily Smith
Visit Mindtheproduct.com to catch up on past episodes and to discover an extensive library of great content and videos.
Randy Silver
Browse for free or become a Mind the Product member to unlock premium articles, unseen videos, AMAs roundtables discounts to our conferences around the world, training opportunities, and more.
Lily Smith
Mind the Product also offers free product tank meetups in more than 200 cities, and there's probably one near you. Hey, Jim Morris. Really lovely to be speaking to you today. So we're going to be talking all about discovery, but before we get stuck into our topic, it'd be really great if you could give our listeners a quick intro to who you are and just a potted history on your background and yeah, what you're doing today.
Jim Morris
Sure. So I'm a product discovery coach, and I work with product teams and product leaders at Fortune 100 companies, all the way to tech startups, to entrepreneurs, and I help them work through their ideas. So my background is as a software engineer turned into a product person. I did product management as the business minded engineer, and then as that field developed, I ended up managing a team of product managers and then helping build the product of Power reviews. And then we ended up selling to a different company. And then after about ten years in that business, I started out on my own as a coach. The last six years, I've been working with a variety of companies to help them work through their ideas and get smarter before they work harder.
Randy Silver
We always talk about discovery and say, give advice to people about get your developers really involved, help have them fall in love with discovery and participate in it. But you're the first person I've ever met who's gone from being involved on the dev side and managing dev organizations to make discovery your primary purpose in life. How did you fall in love with it? What happened?
Jim Morris
Yeah. When I was looking to see what I would do next, it became really clear that building something has gotten easier. With Amazon Web services and frameworks to really consolidate a lot of functionality, you don't have to build anymore. But what we build was still super immature, mainly because the people who were making decisions were super immature about their decision process, basically relying on educated guesses, even all the way up until today. And engineers wouldn't be doing that in their respective careers and professions. And so at that time, I really thought, this is a place where I can add value, where I can help people develop their ideas. And to me, having engineers involved is crucial. Some of the most important companies in the world used by billions, whether we like them or not, were started by engineers. And nowadays, with Agile or any form of development, we often see engineers as implementing our vision. And this is super dangerous. It's also a lot of stress for product teams or product managers or designers to put all of the burden of finding the next idea on themselves. And if we share it with our engineering counterparts, it's super great for morale, and it gives us that spark of innovation when we least expect it.
Lily Smith
So one of the things we chatted about before, when we were talking about doing the interview was the difference between Squad led research and UX led research. You kind of intimated this before, so tell me what you mean by this. I mean, I'm assuming it's got something to do with those engineers getting more involved in research.
Jim Morris
Yeah. One of my clients kind of nicknamed it Squad led Research, and I just jumped right on it because people ask me, well, do we need a professional user experience person on our discovery squad? And the answer is no. It can help quite a bit, but sometimes it's an excuse not to do discovery. So I say a no excuses approach is this Squad led research. And the expectation for all of my squads, and I think just for squads in general, is from a product manager, a designer, that discovery engineer, whoever else is on that core team, that you will recruit and interview people, users, yourselves, and that you can learn this. There are great resources out there. I teach people all the time. And with practice, you learn to ask good questions. You make really good solution tests so that you have a good experiment to ask questions about. And so the UXR led research would be a user research person kind of leading the research and setting the hypotheses. The issue, of course, is that we don't believe the things that other people say or do if we're not there. It's just like a human nature thing.
Jim Morris
And so you could have the greatest UXR in the world, but if they create research, make a great document present it, it won't have the impact, as would these three or four folks actually interviewing the users directly. And of course it takes more time, but the insights stick more deeply and they stick over time. So six months later, after interviewing three users a week, these folks on your Discovery team are going to be incredibly knowledgeable about your customers and they have direct control over which solution is technically feasible and viable. There's a lot of pressures that the product team have in order to make a great product. Often the Uxrs don't have that pressure. And so with that pressure comes the crucible that makes a really good product, where you balance everybody's needs. From the UXR point of view, are they really going towards an OKR, a key success metric the same as yours? And so being aligned is difficult with fear in different silos and organization. So I think with Squad Led, it's really about the team doing it themselves, believing they can do it. And if the company's perspective should be that, where I'm aligning all of my success metrics and expectations is where they should also be talking to users.
Jim Morris
It doesn't need to be split out. And I would say the same for data and analytics, honestly.
Lily Smith
So as a UX person in that, or the person in charge of research in that sort of dynamic, in that sort of situation, do you become more of a coach for the rest of the squad on how to do good research or just upskilling the rest of the team?
Jim Morris
Yeah, I would say definitely a coach. Definitely somebody who can provide some centralized services such as maybe user recruiting, helping generate a panel from all the customers you have, or helping them actually recruit and find users, making sure incentives are paid. There are some logistics to recruiting that can be friction and blockers for teams. So I would say reducing that friction and impediments, certainly coaching people, listening into interviews, helping them improve what questions they're asking, what hypotheses they're making. And if you can, you could allocate user researchers to a team to be on that team again. If they're doing the research together, interviewing folks, creating the prototypes, if the user researcher has the same priorities, then that would be almost a form of squad led research with a UX researcher on.
Lily Smith
It and I guess kind of aligned with that. How do we measure how good we are at Discovery as a squad led team? If you're not used to regularly doing research, then you're going to start off at a particular level of expertise and then hopefully improve. But how do you measure kind of like where you're starting from and then see the improvements over the time and kind of measure well, hopefully the improvements over time?
Jim Morris
Yeah, I would say this is what they ask on Twitter, wrong answers only. And it's number of people I talk to and number of prototypes I made and it's like sort of counting stuff, right? That's sort of the wrong answer. I do want to see that there is activity. There is no substitute for talking to folks. So you do need to have something like, are you talking to two folks a week? Three folks a week. The evidence would be that teams are rejecting some ideas with some evidence. So teams that validate every idea honestly shouldn't really bother with discovery. Right. What are they learning if they're only getting usability feedback? Meaning the person was a little bit confused? So I'm going to tweak the content, the location, the calls to action. Okay. But I want to see value oriented changes, whole flows reorganized, whole concepts tried and then failed. And I want to see the teams exploring the edges. So if you're managing a team and you see them having all this great success, you might think, well, my team is so great, I would just get skeptical of that greatness and say, look, I want you to actually push this, because in design, there's very low risk.
Jim Morris
I don't want you to be unethical or legal, but you should be able to push all these push people down, sort of the spectrum of ideas without having to build it, without all the engineering. So I would say failing. I want Freshness to be insights. So maybe we don't have to count how many people we're talking to. But if it's about that user test that was three months ago, and you keep talking about it, I'm going to get the sense that you're not doing any more of it. So freshness, and you slowly move away from customer anecdotes to, I found a consensus. You're not going to get every user to agree, but if I'm using one customer and you're using one customer and you're using one customer, we're just battling over anecdotes. Right. This is sort of another wrong answer in discovery. So when I did consensus, well, five out of six people, six out of eight, seven out of eight. Like, these don't sound amazing to statisticians. Right? But it it actually these are meaningful insights. If you do enough user testing, you'll know that there are ideas that people don't find consensus in, and there are ideas that are worth it.
Jim Morris
So I think that's sort of the consensus concept, the freshness, the rejection, it all ends up leading to humility, which is something I learned very late in my career. Teams that basically say, maybe I don't know this, but I have the tools to find it out.
Randy Silver
I like that. I'm not sure if Lily will get this. It might be too American a reference, but it sounds like the Trident principle. Four out of five dentists and seven.
Jim Morris
Out of I like that. The Trident principle. I've just published an article on this, and I was trying to name it, and consensus is the only word I came up with. And I'm sure there are lots of people who won't like it, but we don't have a lot of great names for stuff and product, so we'll take a time. There we go.
Randy Silver
Let's see where we go with it. You heard it here first, folks. Jim, what's stopping most teams from working this way? Why aren't they doing it already?
Jim Morris
I think there's a natural well, there's a natural aversion to taking your ideas and sort of being vulnerable, giving them to other people to actually let them click through it. I'll see a lot of teams just show it on screen and they'll narrate it like a sales presentation. Don't you like my prototype? Don't you like my idea? This is just indicative of and of course, it takes about five minutes to make this thing clickable. So this is not a matter of time or energy to do this. It's a matter of understanding one. It's a radically different concept to let somebody else go through your prototype. I also think just in terms of reading app store reviews, quantitative surveys, sitting in on call center conversations, having one on one conversations with users, there might be an aversion for folks that are just used to working in their office environment, right? And I think really there's that just general aversion for office workers to talk to outside folks. There's finding users. Sometimes people think, well, I have to get them to sign these documents, and they're really complicated. But there are lots of great online services in various countries in the world to find users.
Jim Morris
So I can find users in about 48 to 72 hours with one of these services. So I think block, some of the blockers are just not knowing what these services are and having exposure to them. Some of it's just the simple part about budget. We're more than willing to spend the time and energy of ten people on something, but when it comes to finding $500 to talk to ten users, it's not there. It's just mind blowing. So budget previous experience sort of an unwillingness or a fear. And then in some BDB companies, there's a cultural aversion. Cultural aversion meaning the salespeople don't want you talking to their customers. They think that customers believe in a perfect world where everything is one way. And most customers, especially now in B, two B software, really understand that if somebody's interested in my opinion, that's probably a good thing. Not just sort of listening to me dictate features, but working through ideas. So there's some internal headwinds that block folks, and the biggest one is just managers who fill the team's time and their backlog by just dictating features. There's just no wiggle room. I've given you something to do, please go do it.
Jim Morris
Why are you telling me this may not be a good idea? I gave you a deadline. And so roadmaps with deadlines are inherently incompatible with this bottoms up information finding journey that might make you pivot either a little or a lot.
Randy Silver
When you say managers, are you talking about stakeholders, product managers, delivery managers, or is it even possibly engineering managers who are also working on refactoring or tech debt and things like that?
Jim Morris
Yeah, I mean, it's rare that I find engineering managers who want 100% of backlog. I give it about 20% to 40%. So if I work backward through your list, good engineering managers will make the case to keep 20% to 40% of time fixing stuff as we go. But then outside of that, you're looking at direct managers, say group product managers, or heads of product, heads of lines of businesses, CEOs who maybe might be managing in a more traditional sense, like they don't really understand software. So here's the thing, here's the deadline. Let's put it together. And that's their management style. Whereas the other style of generating a good success metric or two takes time, could take ten or 15 hours to figure out what a good metric is. It could take another month or two to measure a baseline. And then of course, you got to wait for the team to make some progress against that baseline. That just sounds really unromantic the way I put it. But this is building a long term, scalable way to increase your probability of success. Otherwise you're looking for hero culture where there's someone in the organization who's going to constantly be dictating and hoping, dictate and hope, dictate and hope.
Jim Morris
Whereas if you can stand up to that at any of those levels, engineering manager, group product manager, head of line of business, CEO, head of product, and say, look, in this 60 minutes, let's talk ten or 15 about success metrics. Instead of all 60 arm solutions, let's talk ten or 15 minutes about problems. And I try to create this little conversational virus of data and problems and opportunities that my team members can talk to their bosses and their bosses and their bosses. So the design lead talks to design manager, engineering lead talks to engineering leader because design leader says, what about this great idea? Design folks are all full of ideas, right? But do they have the context of what the problem is and what the metric is? Usually? No. So the team, as they develop context, gets confident that they are going to get to the right place. They just need a way to represent that to the rest of the business. I don't know if we got off track there, but yeah, I get it. Kind of excited.
Lily Smith
No, I think it's a really good point and I love that idea of the team being able to kind of influence upwards by sort of being more aligned in how they're working together. I guess kind of on that topic as well. Sort of a couple of questions like just bringing it back to discovery again and the kind of the teams working through taking more ownership of the discovery process. How do you kind of build that culture of discovery within the business so that that becomes acceptable. And sort of as part of that, like, one of the things I've done in teams that I've worked in before is included some business metrics or some success metrics around discovery activities in order to ensure that we get it done, because managers love to see numbers and data and, oh, yes, we've agreed to do this discovery activity, and you've done it. Well done. Tick the box kind of thing. So is there something in that that enables and empowers the teams to take ownership of that discovery and kind of make it part of the outputs so that management teams who are slightly more output driven can see some progress there, or can kind of feel something tangible that's going on?
Jim Morris
Yeah, I think that I could see something about customer touch points. I talk a lot about solution testing. So talking to real people live is important for discovery to be meaningful. No matter how much I read about surveys and give surveys. Right. So there's going to be a balance to the input. So my first thought about metrics on discovery would be to my metric for my teams, honestly, was two customers or prospects a week. So I was in a B, two B business and we had 1200 clients, and it felt very overwhelming. And I said to my product managers, designers, heads of engineering, my directors of engineering, you will just like I will meet two customers or prospects a week from now until forever. And I worked very tightly with my counterpart who ran customer success. I said, anytime you're having meetings, I'd like to include these people. And what we did was kind of pair people up. So one of my director of engineering was paired up with one of our particular customer success manager. So then that person could just schedule the director of engineering in and there was no asking, everybody had access to each other's calendars and you just got on it.
Jim Morris
So to me, that was something I held them accountable to and I held the other parts of the organization accountable to. I like that one. That's a long term play. I don't know what the result of that is, right? But I know that I'm not going to have these only educated guesses coming out of my team. And if I get them to talk to more than a couple people, I'm going to get beyond the anecdote. So I got two problems. I've got anecdotes and educated guesses that I've got to really overcome then any particular discovery activity, whether it's making user experience map or finding problems or making prototypes. These get harder to count because they're very lumpy. I might do a prototype one week and I might just tweak it 20 times. I think Marty Kicken talks about making 20 changes a week. Absolutely. You can do stuff like this. Some of the changes are just me talking to you. Some of them are us talking to customers. Right. So the process of change, I don't know if you can measure it in discrete things, but I do have at the end of each cycle of five or six users, my teams do a readout.
Jim Morris
And what did you discard? I want a non zero number of discards, so there's something you can count. If you're not discarding anything, then you're not exploring enough. I don't think you're going to find innovation that way. So you may not be my innovative team, and if you only discard things, you slowly have a decision making problem. Yeah, we have to make decisions with imperfect information. Right. We're not going to get perfect information, and once we get it, it can often be too late. So I would say those are two starting points. I want to see some failure, and I want to see that you're really talking to folks in different ways or shapes or forms. And maybe there's some way you can summarize all the non live interactions, actual reviews, online surveys once a month, just so I know that you've gone through them and that we've covered, because some people will communicate to your company and that'll raise some red flags and someone's got to listen. And the product team is a primary listener in any company.
Randy Silver
Jim, a lot of what you're talking about makes sense, but I'm curious about the best structure of a team for all this. Now, you've got certainly your engineering, your UX, and your product leads all meeting with customers. Hopefully the rest of your engineers are doing on a regular basis as well. But should you have a dedicated user researcher on every team, or is there an agency model? Do teams get to the level of competency and expertise themselves doing this? What's good look like for you?
Jim Morris
Yeah, a dedicated user researcher is not required. I would say 85% of my teams do not have one. And what I need on each team, though, is somebody to take responsibility for loving humanity and that and bringing that humility. People expect this to be the designer always. And I find this to be unfair, but if I have a set of personalities that I've associated, brought together in a core Discovery team, and I find that they're all a little bit hesitant about users, I might just need to break that up and take this team that's got three folks that love users and start to intermix them. And you're thinking, well, what if this person doesn't know about this technology? What about this person doesn't know about this domain? Honestly, if no one really cares about users, it just won't happen. We are people, and as leaders, we cannot create every desirable trait in every employee. So if we can start with things that lead us in the right direction, whether it's the PM or the designer, sometimes it's the engineer who says, look, I really want us to do our homework before we generate this work for the engineering team.
Jim Morris
So I'm looking for at least one person to be really strong in terms of getting out there and making sure they do the discovery activities, talking to users. Another aspect is often people talk about engineering leads, and I might just back it off to be an engineer. In fact, I sort of prefer hands on keyboard engineers, mainly because their facility with the technology is direct. They know it so well. This is especially the case in app and app engineers, iOS and Android, because they often deal in the UI at the same time they're programming. And then I think one of the issues with lead engineers or solution architects is they can get called into a lot of meetings when things happen. So in terms of attendance and time, someone who has purview over lots of engineering systems tends to be less available. So they may be the most knowledgeable person. We think, oh, we have to have the most knowledgeable person on the team. In actuality, engineers are fantastic at asking their colleagues about stuff they don't know. Engineers are constantly googling everything. This is sort of the joke on engineers, right? Like, well, what do they really know?
Jim Morris
Well, it's because we don't want to memorize all this stuff and we're more than happy to not know something. Business people don't necessarily get that luxury. You often walk into a room and saying, I don't know can be incredibly vulnerable. Engineers typically don't have this problem, and so I would prefer to have a hands on keyboard engineer who doesn't know every part of the system, but who knows somebody that they can ask. Yeah, that would be sort of some team formation concepts.
Lily Smith
I'm just thinking about if you have multiple different squads doing their research within their own kind of squad teams and this might be an issue already, actually, with the way that research is done by the research team, assuming that that's the other way that it happens. But what's the best way for larger organizations to share their discovery learnings? Because I imagine that there's lots of people if you end up in that great situation where you have lots of people across the business talking to customers, you're getting lots of insights, but how do you share them across the whole business? Or is that even necessary?
Jim Morris
I think how you reach decisions as a culture is incredibly important. And if you have folks that are using a discovery based approach where they're trying to get external information, to me, being an advocate or evangelist for customer feedback is great. And so large organizations that want discovery to take hold, that want this external feedback engine to keep going, they will make sure there's time for teams to report back about their findings. Now, let's say that we have a decision we've made about a particular concept, and we show the before and the after. But we don't talk about the process. We might just think that it was an enlightened set of tech workers that made this decision, right? And so what I want folks to add to this readout process, the sharing is a little bit of how you got to this decision, right? And that means that for the PM or the UX designer, it might be something like, well, I thought it was this, and it turned out to be that. That's super vulnerable, like, whoa, you didn't come up with this. Maybe I shouldn't have you as my employee. I mean, these are people's jobs and they want to come across as confident.
Jim Morris
We need a culture that says, hey, you don't have to have the answer, but you need to have the mechanism to find the answer. And if celebrating the mechanism, the process. When I say process, I don't mean overdoing it, right? I just mean that I found in non intuitive learning because I gave three solutions to the user and I had them compare and contrast them, as opposed to I told my designer to come up with one. And then we all kind of argued in meetings about where to put everything on this one design. And we showed one solution to a customer. That's a very common process, but it's not going to lead to the insights that coming up with three solutions would, because you've got three different ideas, because you've stretched yourself and your teammates. And it could be that this engineer's idea beats the PM and the designer's idea. And this happens all the time. And this is actually what drives long term humility, is when you allow your idea to be baked off against other ideas in your team. And so I often tell the designer in discovery, we will get into your business quite far.
Jim Morris
It should mean less stress for you because we're not expecting you to solve the world's problems, but we also expect you to incorporate other ideas later in the process than you normally would.
Lily Smith
I love that. And so one of the other things that you mentioned before as well was that people pay far too much attention to what customers are saying rather than what customers are doing. So what are your top tips for kind of understanding what customers are doing rather than what they're saying?
Jim Morris
In addition to getting a strong signal of demand in a situation where the user believes they're actually giving you something of value, we can make sure that we're going beyond just having a conversation about something, right? So we can talk about things that user feels really confident about. Like we were talking about Creaky chairs and how it affects audio and you were describing the situations and the stories about Creaky chairs to me, one with Randy, one with you just now. Those stories are 100% believable. In fact, we could almost hear the Creaks in the audio. Then what users. Or stakeholders typically do is, look, I want you to get the Air on chair. The Air on chair is like the number one chair, right? And it has this cool mesh and all the other startups have the Air on chair, and I'm dating myself. But this was what happened. And people, we would literally go to failed startups and we would auction and buy the Air On chairs. And if anybody's ever had an Air on chair, you realize it's impossible to configure to your body. The levers are impossible to use. It's baffling. It's the most expensive Baffling chair that everybody wanted.
Jim Morris
So that particular solution wasn't that great. So what do you need? Well, here's a foam chair. Here's the chair where you have your knees forward. Here's the aeron chair. Let's get a couple of solutions. Now, those are perhaps expensive ways because I have to make all those chairs. But in software, we don't have the hardware physics limitations. We can make multiple versions. And as you experience the multiple versions, or just like you were sitting on different chairs, you're going to be able to give me feedback about the foam chair, the Air on chair, the one where you're leaning on your knees. I'm going to believe that feedback more than you just hypothesizing about these chairs without sitting in them, just like user interfaces without experiencing them. We try to get as close to that reality as possible. And the do portion of that is them experiencing that prototype rather than you just talking to them about a solution or honestly, my clients just talk to folks about the problem, go into the hole of development and come out with a solution. I call that the product Discovery Valley of Death because they do some discovery talking to people, open ended conversations, but they don't get that do phase where someone gets to experience their solution.
Jim Morris
Why? Because it's really vulnerable and they say they don't have time. Right?
Lily Smith
Yeah.
Jim Morris
Well, you're going to build something. It's super risky to build something that you never showed to folks or you show them at the last minute where it's just usability and you're not going to like to make any major changes. So that was my say versus do.
Lily Smith
Jim, it's been so great talking to you today. Unfortunately, we have run out of time, but thank you so much for joining us and imparting some of your Discovery knowledge. I love the idea of Squad led discovery and I'm sure lots of other people will as well. So yeah, thank you very much.
Jim Morris
Oh, thank you. It's been fantastic to hang out with you, too.
Lily Smith
The Product Experience is the first and the best podcast from Mind the Product. Our hosts are me Lily Smith and me Randy Silver. Lewon Pratt is our producer and Luke Smith is our editor.
Randy Silver
Our theme music is from Humberg based band POW. That's Pau. Thanks to Arnie Kittler, who curates both product tank and MTP engage in Humberg and who also plays bass in the band for letting us use their music. You can connect with your local product community via Product Tank. Regular free meetups in over 200 cities worldwide.
Lily Smith
If there's not one near you, maybe you should think about starting one. To find out more, go to mindtheproduct.com product Tank.