Jim Morris on Exponential Growth with Product Management

On this episode of Where Product Meets Design, Alex chats with Jim Morris, Founder, Product Discovery Group, about the importance of talking directly to users, fitting product into user lives, and the balance between collaboration and decision making.

Alex Smith: We're product design is brought to you by way go UX, UX research strategy and design consultancy. Hey, Jim, thanks so much for coming on the series today.

Jim Morris: Great to be here. Thanks, Alex. 

Alex Smith: Yeah. And as we get started, can you give the audience a bit of insight in your journey in product?

Jim Morris: Yeah, I started out as a software engineer hands on keyboard programming. And really was that I was that business oriented engineer that the folks would come over and ask the engineering group, like, how could we solve this problem? What can we do here and so I kind of poked my head up. And fast forward many years later, still kind of really passionate about that bridge between tech and business. And as product management has grown, I've really pivoted over and chosen that as, like, where I've made my career at this point. And I've been through two startups where we were creating whole companies and inside of those companies, we were creating whole products. And so I've had a chance to really start many things from scratch, and then also grow the company, I co founded to 1200 clients, and so had had a chance to do it in that growth mode. And you know, the last eight years I've been on my own. So helping out companies, a variety of sizes, kind of do that kind of thing, grow. start something new, and then grow.

Alex Smith: Nice. I love it. We'll dive into that after the lightning round. Are you ready? I'm ready. All right, let's keep these two a few sentence answers. So what's a common myth about product management?

Jim Morris: That you need to be a computer science major to do the job? Really, you need to be detail oriented. But you don't need it. You don't need to know how to program.

Alex Smith: What's the most important lesson you've learned? 

Jim Morris: Talk to users sooner than you think. Each time I felt rushed to talk to users. I'm like, Ah, I'm glad I did it now versus two weeks from now.

Alex Smith: What's the one thing about product that no one agrees with you about?

Jim Morris: I don't feel this alone in product honestly. Struggling here, I would say that a thought that is rare out there as a product is now a lot of behavioral science, and that everybody has really filled most of their 24 hours with something sleeping, eating, talking to people staring at their phone. And so really, we are in a competition with some behavior. And if product people get a little bit more paranoid, and they think about, well, what are people doing with their time? And how can I be a valuable part of it? You know, it's just not enough to make a great product, you have to fit it into people's life.

Alex Smith: What's an underrated or indispensable tool for products?

Jim Morris: It's  indispensable. And that's MIRO. It's fantastic for teams that are remote. It's fantastic. Each time I have teams do that, it's pretty quick for them to learn. And it really allows me to do a lot of the exercise that I did before with more agility.

Alex Smith: And what's one piece of advice you'd give to someone starting out in product,

Jim Morris: I find the balance between collaboration and decision making. Most new product folks are scared to make decisions, and they overdo it in the collaboration. And that often leads to lack of direction. And a product manager does need to provide direction. And I think if they can admit that they may not be right. That if you can commit to reflection and analysis, then that decision doesn't seem as important because you're going to revisit it.

Alex Smith: Love that. Thanks for diving in on those. Let's switch gears here. I mean, Jim, you've had a long history of product management and have worked with so many teams, I'm wondering what are the themes you see across, you know, good performing product teams?

Jim Morris: The good performing product teams, the high performing product teams that I see, have found a way to talk to their users on a regular basis. And not not wait for the user research, folks. because there just aren't enough user research books. User researchers are great. But in the 150 Plus teams I've worked with, they're pretty rare. And when they are there, there aren't necessarily enough of them for all the teams I work with. And so I think the high performing teams can lean on their user researchers when they have questions, when they need some coaching, when they need help finding the right person with the questions. But my goal has been really kind of a thought a little bit of like a no excuses approach. I don't have a designer, so let's try these tools. I'm having you XR Well, let me teach you how to do some customary interviewing without introducing bias. It's not about, you don't necessarily need that. PhD and you know, the various subjects that could lead you into qualitative research like it can make you fantastic at it, but a lot of the time we need to be moving fast and being just really good at it. 

Alex Smith: I think That's great advice. So you're suggesting, like kind of the whole product team, go directly to customers, and interview them and run tests with them and all those fun things?

Jim Morris: Yeah. I mean, there's this balance between the perceived, like high quality of a user researcher, and then the speed and then positiveness that a product team has.

Alex Smith: I'm wondering about models you've seen across these top performing teams, are they all agile? Like what about their ways of working? I'm not convinced that agile means the same thing in most product teams, but like, how are they? How are they like high performing and you know, iterating, so quickly, and crashing the product roadmap and all that fun stuff? 

Jim Morris: Yeah I think in smaller companies where there are fewer dependencies and the required roles reside on the team, you know, front end engineer, maybe somebody builds the API's, maybe somebody who helps with the back end, when you can vertically integrate, those teams do move fast in larger companies, they will break these out into these horizontal layers. And that creates a lot of dependencies. And so I think teams can reduce their dependencies, and they can start to introduce differential launching. So I can launch. I don't have to wait for you, right. And then there seems to get this continuous launching, you know, ci CD type pipelines where they can launch every other day, and they've got automated testing. So do you have a corporate client who can launch every two weeks to customers wants to customers not just launched dark? So high performing teams launch? And the reason you do that, in recent high performing, is that when we do discovery, we don't really know. We get evidence, not proof. This to me is that ability to calibrate your discovery. So your discovery gets better when your post discovery metrics get better. And so but you only do post discovery metrics that you've launched, the high performing teams get that launch out there, even though it's not perfect. Right. They agree to decide, let's just do this. They agree to reflect iterate? Yeah. So high performing teams reflected iterate, and they and they don't have to know the answer this find the answer.

Alex Smith: One of the things you touched on is kind of like co creation, at least with research. So I'm wondering kind of another question I like to ask is, how do you think product teams and design teams or research teams should be collaborating more efficiently, or working better together?

Jim Morris: If we can all agree that talking to more users more often is important, then that user researcher role partly becomes a role of a coach, and the design and the product team? When they have questions? Maybe they've got a user research that they can use as an internal resource that's better than Google. And I think that's that part where this collaboration where there are some forms of research that are delegated to the product teams.

Alex Smith: That that's okay. I hear this a lot like collaborating. Let's collaborate, right? Like we were both at ux dx. I think that was the number one takeaway teams collaborate, but it doesn't happen. Why do you think that is?

Jim Morris: Well, in this remote world, we don't encounter each other physically, we don't necessarily sit next to each other. And so it takes an element of work to get on the screen together, right in the meeting. And now they're huddled, and they're more lightweight to do this now. But I think that's one reason friction logistics. The other is, it's easier to kind of do something on your own rather than work through team dynamics to great create something. The reason I liked my teams to do working sessions, where we're all together for a certain period of time each week, is that it teaches them that they can accelerate the product in these big jumps, rather than these little steps. If I take a little step as a PM, I hand it to my designer, they take a little step, and they get to the engineer engineers, like well, I can't really do that. And the engineer thinks that that's the only way it can be done to the engineer gives a long estimate. And then it goes back to the designer back the product manager like, Oh, two hours, I gotta rethink this. If they're in the room together, they start to mesh these gears in this three dimensional or Quadra dimensional engine, whoever is in the group that maybe I'm a data scientist, and when my teams have doctors on them, if you get that right group of people together in the room at the same time, not all day, but certain times a week. And you talk about a hard problem, like the workflow, you talked about, what's the main success metric? What's the main problem? We're literally going after, hey, let's all sketch solutions together. Let's do that thing in this sprint book where we work alone, but together, I call it real time collaboration. Everybody when I say collaboration thinks they're collaborating. And so real time is when we're all together for working sessions. You know, 90 minutes, maybe a couple times a week.

Alex Smith: Yeah, that's I mean, it's a very practical, tangible, built in way to collaborate like, hey, we have these facilitated workshops that are consistent and And by definition that is collaboration. So I love that answer. And Jim one question as we wrap up where can people go to find you? 

Jim Morris: Go to product discovery group.com That's my website and you can read about me and, and that's a great place to contact me.

Alex Smith: Jim, thanks so much for coming on the show today.

Jim Morris: This is great. Alex. I love hanging out with you