Jim Morris on Exponential Growth with Product Management
My latest podcast is with Alex Smith discussing Where Product Meets Design. He cuts it down to 10 minutes which I love.
We talk about how to work with UX Researchers when you're doing squad-led user research and other topics.
Episode Transcript
Alex Smith:
Where product meets design is brought to you by Fuego UX, a UX research strategy and design consultancy. Hey, Jim, thanks so much for coming on the series today.
Jim Morris:
Hey, great to be here. Thanks, Alex. Yeah.
Alex Smith:
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 business-oriented engineer that the folks would come over and ask the engineering group how we could solve this problem. And so I kind of poked my head up and fast forward. Many years later, I'm 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 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 a chance to do in that growth mode. And the last eight years, I've been on my own. So helping out companies of variety of sizes, kind of do that kind of thing, grow, start something new, and then grow.
Jim Morris:
Nice.
Alex Smith:
I love it. We'll dive into that after the lightning round. Are you ready?
Jim Morris:
I'm ready.
Alex Smith:
All right, let's keep these to 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 do not need a hotter 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, 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, if I struggled here, I would say that a thought that is rare out there is that 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? 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 product?
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 use it, it's pretty quick for them to learn. And it really allows me to do a lot of the exercises 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 they often lead 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 have a long history of product management, have worked with so many teams. I'm wondering what are the themes you see across 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 wait for the user research folks because there just aren't enough user research folks. 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 I call it a little bit of like a no excuses approach. Oh, I don't have a designer. Well, let's try these tools. I don't have a UXR. Well, let me teach you how to do some customer interviewing without introducing bias. You don't necessarily need that PhD and the various subjects that can lead you into qualitative research. It can make you fantastic at it. But a lot of the times we need to be moving fast and being just really good at it.
Alex Smith:
Yeah, I think that's great advice. So you're suggesting 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 high quality of a user researcher and then the speed and then targetedness that a product team has.
Alex Smith:
I'm wondering about models you've seen across these top performing teams. Are they all agile? What about their ways of working? I'm not convinced that agile means the same thing in most product teams, but how are they high performing and iterating so quickly and crushing 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, a front-end engineer, maybe somebody who builds the APIs, maybe somebody who helps with the back end when you can vertically integrate those teams, they 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 if teams can reduce their dependencies and they can start to introduce some differential launching so I can launch, I don't have to wait for you, right? And then there are teams that get this continuous launching CI/CD-type pipelines where they can launch every other day and they've got automated testing. So I do have a corporate client who can launch every two weeks to customers. Launch to customers, not just launch Dark. So high-performing teams can launch. And the reason you do that, the reason it's 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. But you only do post discovery metrics if you've launched. So 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 and iterate. Yeah. So high-performing teams reflect and iterate and they don't have to know the answer. They 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 researcher 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, that's okay, I hear.
Alex Smith:
This a lot like collaborating. Let's collaborate, right? Like we were both at UXDX, 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 a meeting. Now there are huddles and there are more light ways 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 create something. The reason I like 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 their product in these big jumps rather than these little steps. If I take a little step as a PM, hand it to my designer, they take a little step and they get to the engineer. Engineer is like, well, we can't really do that. And the engineer thinks that's the only way it can be done. So the engineer gives a long estimate. And then it goes back to the designer, back to the product manager, like, oh, dude, I got to rethink this. If they're in the room together, they start to mesh these gears in this three-dimensional or quadridimensional engine. Whoever is in the group there, maybe you have data scientists. Some of 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 talk 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 the Sprint book where we work alone, but together. I call it real-time collaboration because everybody, when I say collaboration, thinks they're collaborating. And so real-time is where we're all together for working sessions, 90 minutes, maybe a couple of times a week.
Alex Smith:
Yeah, I mean, it's a very practical, tangible, built-in way to collaborate. Like, hey, we have these facilitated workshops. They're consistent, 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 productdiscoverygroup.com. That's my website, and you can read about me, and that's a great place to contact me.
Alex Smith:
Jim, thanks so much for coming on the show today.
Jim Morris:
Yeah, this is great.
Jim Morris:
Alex, I love hanging out with you.