Hello and welcome into another episode of Lessons in Product Management. I'm your host John Fontenot and on today's episode I have Paul Turow on to talk about his journey into product management and we riff on a number of topics in research. Paul's a longtime PM, having held a variety of senior IC and director of product management roles in healthcare.
Some of the topics we cover on today's episode include the tension between research and shipping products, what's the MVP of research, changing the culture and perception of research inside of organizations, and so much more. This episode is longer than normal, but it's entirely worth it. So listen to the end, hit that subscriber follow button and enjoy the episode. Hey, Paul, welcome to the podcast. Hey, nice to be here, John. Thanks for taking the time.
Yeah, absolutely, man. I'm so excited about this conversation. We started this on LinkedIn. Just for listener background, I posted a survey not that long ago. that was asking, can product management be done well without research or discovery? And the majority of people said it's not possible, but there were some experienced...
product people that I respect who said maybe, and I love digging into the nuance. And Paul was one of those maybes. And we had a nice back and forth on LinkedIn and really excited to continue the conversation, man. So thanks again for coming on. Yeah, no, absolutely. It's my pleasure to be here. I think it's a great topic.
I'll start off by saying something I would like to get out there, which is I think product research and discovery is critical. It's vital. And when done right, and there's my little asterisk with the whole maybe conversation. it can benefit everybody. But I think, right, I would love to explore that a little bit more and talk a little bit more nuance there. Yeah. A hundred percent. So before we dive in,
I am curious. I was looking at your background, saw you had a political science degree, got a law degree, and then I saw you went into web dev and then now you've done product management for several years in healthcare. So how would, how'd your journey go? Talk us through that. Super interesting. Thanks. The macro of it is right.
I think it took me a little bit of time probably coming out of undergrad, still wasn't sure. But what really kind of makes me tick, what makes me happy in the professional space, right, or as happy as anybody can be, is... getting into the details and understanding how things work right um i i enjoy just asking why i
i like sort of spending a lot of time figuring out people and i really like the psychology behind how decisions are made um so i tend to like whether i'm in a meeting or a casual like conversation in a coffee shop Sometimes people have told me like I'll start looking at them with my head tilted. And it's like I'm trying to get in their brain and I know I can't. And I don't know why I just naturally sort of go there. I did graduate. I went to law school again.
I wanted to know more about the world. I think it was a natural extension of political science in my undergraduate studies. Hadn't a chance to practice law, you know, during doing some clerkships. Found out quickly it wasn't for me.
I had a chance to work in a startup. We were a small group. I was mainly concerned with doing strategy, which when you're less than 10 people means you're doing everything, as you can imagine. What I was really doing back then was... product work i was working with the developers very closely working with our out of house designer and working very closely with people trying to either sell them our product or build a product that they wanted to use right in the
two things go hand in hand. And so I was, I did that for a couple of years, fell in love with it, did some other things and then decided i needed to get back into technology which is why i went to do web development um i knew i wanted to get back into product i now knew about that career path i knew what it was i knew what it meant i was 100 all in um
Started learning web dev, got closer to it, did that for a little bit to make sure I could like basically speak to engineers and I could ramp up my technical chops. And then I moved into sort of the product management world and I haven't looked back. I absolutely love it. And I'm... I'm actually like one of those people who most days looks forward to going to work. So I consider myself, you know, very, very fortunate to be here. I'm right there with you, man. And so I want to call out.
We're going to get to research, but I want to call out a myth. I think it's a myth, but I'd love to hear your perspective. As a web developer who's been trained in web dev, how critical is the actual component of coding to your job now as a PM? Coding? Actually hands-on coding, John? Oh, I don't do it. I don't do it. Nobody probably wants me doing it. I think I like to sort of stay up to date because it does interest me how the engineers are working and what tech they're using.
I know, for example, when I was learning React, Angular, a lot of those frameworks are still around today. There's some new stuff folks are using, but the MVC sort of framework is still in existence.
When I'm talking to my engineers about, you know, models versus front-end versus, right, back-end logic and methods and things like that, we can talk fairly closely. But as far as touching the code, you know, my personal opinion is... it's like sort of the same like when designers open up their figmas like i want to be respectful and i wouldn't go into like uh an engineer's code to to mess with anything i think the conversation is is pretty much where i like to keep it at but the background
context so that they don't have to worry about me either misunderstanding perhaps the level of effort complexity or why we found this critical bug that needs fixing right i think um it builds the relationship and it just It helps me sort of do my job. I was going to say, what's the myth though? What was the...
So I work with a lot of aspiring PMs. I have this platform called Path to Product. And one of the myths that I think still exists because probably 10 plus years ago, maybe a shorter time frame ago. I think you saw more engineers moving into product management. And I think even some companies in their job rec still post like for, for PM's experience with certain like.
development languages and stuff. And it's like, you don't have to know how to code, but I think to your point, understanding the difference between front end, back end, how the internet works, how APIs work and understanding like frameworks and concepts. is super beneficial. And like when I started to learn more about technical concepts, I became a better partner to my engineers, but that's, that's probably a whole nother debate around like, is it critical or necessary to do?
a PM job well and at what level of seniority of a PM role, right? I love it. I can already see right where your head was going because that, like the kernel. of that topic is very similar to the kernel of the topic that we were going back and forth with the research, right? Is how much of it do you really need to do it quote unquote well?
or good uh but yeah i would agree with you right i think i've worked with um ems who had no technical background they never had the title of developer junior developer anything like that and they could read API documentation better than I, right? Like, so no, I would agree. It's not a prerequisite. It can help, I think, right? And I think there is some baseline level, like you said, that's very good for PMs these days, but it's...
It's not a hard requisite. And for the listener, you said EM, engineering manager, right? Oh, sorry. I worked with some PMs. Oh, PMs. Okay. Yes, some PMs. And they sort of just pick up and like... they can skim over API documentation in a fraction of the time sometimes it takes me and they get it. They know what they have to connect and they can spit out a very good mapping. We can do that too, but I guess my point is they never worked as a developer. And it's something you can definitely learn.
Yeah, I think of it as building your skill set over time. And like there's an infinite number of things you can learn as a PM, whether it's directly related to design or development or the PM like core skill set and functions. or even cross-functionally, right? Like you have a law degree and you work in a very highly regulated industry of healthcare. So I'm sure there's gotta be some level of that background in law.
that helps being in that regulated space where maybe you can get into some documents and understand things better. I don't know, anything you want to speak to on that front? Yeah, I mean, oh man, that could be a whole other series if you allow me. i loved law school john um it really honed my ability to read right and that's what you're picking up on and um and dissect from a certain point of view uh just a very critical way of of understanding language and the written word and so
It helps. There's a very, I'm not going to say fine line, there's a very thick line barring me from doing anything that resembles legal advice. And I know that line and you can see it a mile away. but you're exactly right like if we're looking over and understanding right like baa's or contractual obligations right i can offer a
slightly perhaps more nuanced opinion when it comes to how we need to maybe either structure an argument, or excuse me, an agreement, or build a product to make a relationship work. And that background has suited me, I think, in that regard. I always tell my wife that if I had a...
If I had a different career path, law would have been fascinating for me as well. One of my favorite classes in college was a business law class that I took as an elective. And in my first PM role, I actually had to work on a... It was in an HR company. We were doing time and attendance management. We had biometric clocks and there's biometric laws around how long you can store biometric data. Can you get the actual scans or do you have to hash it? And the laws vary by state.
So I had to go through like three or four different states legislation who had like most strict legislation around biometric laws, read through all the documents, put together an acceptance criteria based on.
some of the laws that were out there trying to lean towards the most stringent side and then bring that to lawyers to get them to sign off on it to be like okay where does this need to be changed what needs to be fixed and that was one of the most fun things that I've ever done So, yeah, no, like I, I really think like law could have been a fun career path for me if I had went a different route, but, but here we are.
Yeah, no, I think, yeah, it's, again, separate podcast topic, but the practice can be different, especially when you get into, I don't know how many lawyers are doing this anymore, but like. the billable hours man um they just they they can suck the the fun out of a lot of stuff um but you bring up right i'm just again we're not kind of getting to research which is okay with me but what i think we're circling around as well is
I think another one of those core sort of fundamental pieces that makes, I think, a good PM, a great PM. And I think I'm taking this from somebody else who you've probably seen around on LinkedIn and other places, Shreyas Doshi. he he does right he does this thing where he talks the difference between good and great pms and things like that and like it's having that subject matter expertise to paraphrase right and it's like what you did with that project like you made yourself that
which i can just i would bet almost anything just contributed such tremendous value right to what you were doing because you went into the documents you learned the difference um you weren't necessarily relying on somebody else so yeah i mean kudos to you but i think That's a very, very critical skill. Agreed. Agreed. And just the willingness to do whatever it takes, right, to get to the outcomes you're looking for.
which I think could segue nicely into research. So we're like halfway through the episode. We're finally going to get to research. But I think that conversation was really good. So thanks for going on a winding path with me to get here. Yeah, of course. All right. So when we were, when we were talking, I'm, I'm very biased towards research and I feel like I overcompensate sometimes because as much as books like.
Outcomes over outputs have done good philosophical work in making executives think we should be more outcome oriented, not just shipping products. It feels like we. You know, we put arbitrary deadlines, we have goals that the board is pushing on us when we get into these quarterly cycles of we got to show some type of return. And I think the.
The assumption that still lies out there is that outputs will still equal outcomes. And in a sense, there's truth to that where you need to have outputs to get outcomes. I think there's also a reason why like the Pindo data or whoever put this data out there, that 60 to 70% of features that get shipped don't get adopted. And you have to fundamentally ask, why is that the case? And I think it's because there's not a lot of, there's not enough.
upfront vetting or testing or like assumption testing on our parts as PMs, partly due to pressure, partly due to maybe the competency of research. I know I'm kind of monologuing here, but what's been your experience with that push and pull tension of we need to ship stuff, but are we actually shipping the right stuff? Yeah. So no, I mean...
There's a lot there. My head is going in a few different directions. I think what you just said, though, is one thing as I was thinking about our conversation and how I would try to encapsulate it in my head. Not only on LinkedIn, but the one that we're having right now is that word tension. To me, I think that research shines an execution, right? Let's call execution what we do when we actually ship and release, right? These things.
Those two are like they shine when there's this really good tension. Right. And I'm sure not the first person saying this, but that's where I think it works the best when both are keeping each other in check. when execution is pushing back on the research process and the people involved in it if they're not one in the same and then research is pushing back on the people trying to push releases etc.
When there's this beautiful tension, I think that's when the two shine. I think my experience, I've seen both sort of, I've seen it done well, and then I've seen it done, I guess... in my opinion not so well the not so well and i think where i was going with you when i think the poll question said like can you can you do good pm without research and discovery or something um
Can PM be done well without this thing? And I think that it can. It's to what degree and sort of what context you're finding yourself. you know ian um going back to the where research kind of i think may not be done well is when for again really just being very general when you're having too much sort of pontification And there's no clear vision or strategy from leadership. You need clear vision and strategy so you don't spin your wheels and don't go chasing. We've all heard the problem.
And I think this is another Shreyas thing, right, to call him out. But I think, right, the whole solution he came up with, with asking customers to rank.
right these problems so that you're actually not falling into the psychological trap of just because you're talking about a problem suddenly you're uh incorrectly elevating it to be the most important when you could be completely completely missing the target there so i think um i think those are some of the indicators where i think research is not necessarily done the way it should be and i think when
if you don't have those sort of guardrails to do research well that's when you know someone like me comes in and says listen let's probably we'll probably get more value out of executing right because we don't have those guardrails we don't have the things we need in place to get the value from research that we need to have that tension. Of course, I can say like, if you have someone like me who's saying, okay, let's go execute, let's ship and learn and iterate.
I think under certain circumstances, there's value, a good value that can be derived there. But at least, right, you're not perhaps...
chasing the wrong thing and just spending an inordinate amount of time. Yeah. No, I agree. I think without the guardrails, you make assumptions about what's important and you're... assumptions about what's important of like what should you be researching based on nothing but a guess because there isn't that executive level guardrail in place lead you to maybe asking the wrong questions or
biasing what you're looking into. And maybe the track you're going down is to your point of stack ranking, maybe priority number 10 on the market and the customer's list of things that are important.
um but i think that that goes back to like even the earliest days of founding right of like understanding the market what what are the most important things as a as a business to go after to really win in a market And I just think it's fascinating that like the companies that start out going after a certain pain point that grow, but somewhere along the way, like there's almost like a loss of touch with the market.
or an assumption that you still know it just as well 10 years later when you haven't really engaged with it on a deep level. And I think that's where some of that tension and friction comes in is.
a good PM will challenge assumptions unless there's really good data, like relevant current data showing that, oh, okay, this is validating what the hypothesis is, if we don't have that data, I think it's natural for us to want to challenge the assumption and make sure that we're not just blindly being order takers from an executive who is maybe...
you know, pontificating their own opinions about what's important. Absolutely. 100%. I came across, and you know, it's like you're also touching on something that I think also I need to speak to is... It's like, sometimes I found, again, thinking back on my experience where I don't think research and discovery was done necessarily well, it's almost a problem on...
and I kind of tried to engage you on this is like, what is, what is the point where you reach in the research and discovery process where like something needs to happen? And so. I think thinking back on this example swinging in my head, it's like time is being spent either pouring over right like the the quantitative like data or.
you know, conducting user interviews, screening, you know, potential users, writing scripts. There's a lot of good and valuable time spent there. But then what sort of comes out at the end, I think, is where the mark was missed. And I think it's almost like it's not that I'm at all criticizing the role of research and discovery. Right. Again, I'll sort of say, I think it's critical. I think it enhances.
every organization that wants to actually invest in doing it. But to execute research and discovery is a different thing than just saying you're doing research and discovery, right? Yeah. And so I think that it's, for me, it's everything from organization of thought and learning, right? It's even starting at that basic level of thinking, okay, this is what we got out of it. This was our input. this was our output, and now you need people to connect the dots, right?
Because at the end of the day, if you have someone on the other side of the coin who, like an engineering manager, right, they have a metric. Their action item at the end of the day is very clear, right? They want to release and ship more frequently. And they're sitting there waiting.
of like we can see that progress it's a it's sort of um you're leaning into into action whereas research i think you can get stuck a little bit right because then it's like how do you interpret this okay if you have
five different interpretations of, you know, 50 different interviews. Where do you go from there? And I think, right, again, going back to the whole need for vision and strategy, I think perhaps, you know, maybe... um as i'm talking to you about this john maybe my example swimming in my head around organizations that haven't done product research very well maybe it's actually the root cause of that is the fact that we didn't have a good vision and we didn't have a good strategy i don't know
I guess what I'm trying to say is, right, it's one thing to spend time doing research and discovery. It's another thing to actually get something out of it and keep that great knowledge moving the organization forward. Yeah, I completely agree, right? And there's my head's on me now with a bunch of directions where I could take from what you said. But I think fundamentally as a PM, and I've debated product people and research folks about this.
But I think like you have to start from the place of a goal. Like if you can't filter the questions you're asking in research based on. Like, what do I need to learn to help us achieve this outcome or reach this goal? If it's not rooted in like...
that question of what do I need to learn to get there, then you can go a bunch of different directions, right? And then who do I need to learn it from? So I think some of those fundamental questions of what do I need to learn? Who do I need to learn it from is like the most relevant. customer segment, your ICP, whatever you want to call it, and then be able to learn just enough to get on what I call the research dartboard. So when you actually ship, you're not shooting over.
the dartboard by a hundred yards and you're like, Oh, well, how do I adjust from here? Cause I'm way off the mark. But if you can get on the dartboard, even if you were off the mark by a little bit, the course correction. and the amount of reputational risk and the amount of technical debt that you didn't accumulate from being way off the mark, right? To me, like that's...
That's the cost equation or the opportunity cost in it is by doing no research, you're going to accumulate some of those things of reputational risk. Like how do they think this was valuable? or technical debt because you're having to refactor massively versus incrementally shifting the direction that you were going based on what you learned after shipping. And so that's where I get stuck is like...
There has to be some, but based on the level of risk and the amount of knowns versus unknowns and the assumptions that you're making or the hypothesis that you have, how can you de-risk it enough to at least get on the dark board? So your iterations are more incremental than fundamental. Yeah, I like that. I like that approach. I think the example of the dartboard to me is... is an apt one it's a very good one and something i would definitely hook into because what you're saying is um
There isn't a perfect answer, right? You're not going to do research and discovery and come up with, ah, there's the answer, right? That's what we need to do 100% of the time. It's a guarantee, right? Because I've done this.
i've seen number one people are enigmas right if we're talking about end user facing products um and not something where very hard requirements right enterprise business to business kind of thing end users they're enigmas they're gonna right we've seen the memes like thousands of them right like what you think you know your customer wants what they actually want kind of thing um
But the fact that you're talking about a DARP word, right, and honing in and increasing the probability, but never saying guarantee, I like that. I take that with me as well, right? Because that's the world we live in. It's squishy and there's little black holes that we never knew existed. But to increase the chances and increase the probability that we decrease the risk of all those other things, like you said, technical debt, waste of time and money. I completely agree with you.
I think there was another point that I'm kind of losing my track on right now, but I think it does bring up the question of... Do you have a sense, John, of what could be sort of like the MVP of research, right? If you think about like, okay, let's picture an organization that just...
They're running so quickly or they're so small. They're so bootstrapped. Right. But they say, you know, we want a product, but we believe in the power of product. We know we need someone sort of stewarding, maintaining and helping us grow.
we're going to hire a product person right pick small small startup company like do you think that there's some best practice or some guide rails that this PM should take with them when they don't have the time, perhaps, and the flexibility and the resources to do research that they could implement just at minimum.
Yeah, it's a great question. I'm glad you circled back to it because this was the question that you asked on LinkedIn that prompted me to suggest we get on a call. Like everything else in product, it depends. It depends on the situation. Do you have customers? Are you going zero to one? I can go in different directions here. I'll speak from personal experience on zero to one stuff and then we can get into existing product stuff. But in zero to one, like if I know.
where the potential audience that I want to build for, right? I think they have a problem. I want to solve this problem, but I need to validate that I'm not the only one that has this problem or that my in of one. observation is representative of an entire market. If I know where that audience lives, right? LinkedIn, Twitter, Reddit, wherever, I'll just post like a question or a survey.
and see what kind of response i get back and sometimes it's like wow that that yeah that's pretty validating and sometimes it you know it falls on deaf ears and it's like okay well maybe this isn't very important And so I think that's a good place to start if you're looking at kind of macro, like, is this actually a problem that resonates with a bunch of people? So whether that's an online survey or you could use a survey tool, just depends on how scrappy and cost effective you want to be.
I'm pretty frugal, so I like to be scrappy and cost-effective. Now, if you do have an existing customer base, I think it depends, again, on what you're trying to learn. Surveys are great for macro stuff, but I think what I would like to do from a survey is... If I can capture contact information, I might follow up with folks who maybe look like the ICP that I think is within my desired...
segment within that market. And I'll reach out and be like, hey, I really appreciate you responding to my survey. We'd love to get on a call and discuss this further with you. Looking to solve this problem and like your feedback would be invaluable. Something very short and sweet and do like five customer conversations.
And try to figure out from that five, if it's in the same ICP, be able to say, okay, are there commonalities within this five? Or is it still kind of all over the place? Do I need to hone in on that survey even more? It really just depends. But if in an ideal world, one survey and five follow-up customer calls gives me enough insight to feel pretty confident about a concept I can put together to put back in front of them.
Because after those initial calls, I'll always ask, hey, I really appreciate your information, what you shared with me. I'm going to be putting together some concepts, how we could potentially solve this problem. And I'd love to get your feedback and see if we're hitting the mark. So you kind of set the expectation for the next call.
And then you can put like a wireframe or a mock-up in front of them and just get their, get their thoughts on it and saying like, here's how I understood the problem. Here's how we're thinking about solving it. What am I missing? Right. So that's kind of the scrappy mix of quant and qual that I like to combine for most things that I'm trying to learn. Yeah, I love that. I think what I'm taking away and I think what's what's great.
about what you said is that it's it's to me it's what i hear you say it's a mindset right and so whereas i was asking you for very explicit sort of like what could you offer you know a junior pm or someone who's been thrown in and has very little time and resources and is
trying to find the best possible avenue out of this box that they were placed in or whatever. And so what you're... you're you're telling me it's a very good mindset you have right you don't need a dedicated research person necessarily right you can reach out your own sort of social networks you there's free things out there that you can start taking temperatures on and it's that mindset to want to learn more i think that's key here and i would agree like
it's it boils down right what makes a great pm right it's having what you just described that mindset to want to learn and not fall back on well you know i I talk to these folks. I'm in the same industry. I'm just going to take what I learned there and apply it here. Right. Things change. You might not have known anything, everything, and you will not know everything kind of thing.
I did have one follow-up question. I know we're kind of a little over time, but do you have any sort of perspective on how you present the research and the findings?
because i think right just like sort of analyzing data there's a little bit of an art and a science to the storytelling piece of this um any thoughts on like again kind of sticking with that example of you have limited resources limited time and you're just you're doing your best to get your temperature and your bearings yeah how do you go about like sort of encapsulating and presenting on you know your findings when you know
the work that you've done is very sort of limited. Yeah, it's a great question. And I'm going to put a selfish plug for the product that I'm building, Research Repo here, because I've seen this happen where... a research like a dedicated researcher i've worked in a company that's had them i i was one that was actually my first product role at a company was a uxr and and you do research you put together
Some customer quotes, you put together a slide deck or a doc and then you present it. But what I think is often missed is why does this matter? Right. You see like the make your research matter thing. Like I'm really big on that is why does research matter? And I, my unfortunate hot take here is I think the reason why, and it's not even a hot take. I think most people would agree with this.
I think the role of research is still immature across the world. It may be Silicon Valley and other places it's more respected, but like to be able to tie. why am I as an, as a executive team or as a board of directors, why am I giving approval to this budget for a dedicated function or to even give time for a PM or a UX designer to go out and do research? You should be making things pretty.
you should be writing stories, right? Like that's still a lot of the concept. And so how do you actually tie the research back to your goals? That's what executives want to know. They want to know like, okay, fine, you did this research, but how is it going to help me make money?
Like at the end of the day, that's what it boils down to. And so when you're doing those readouts, there needs to be kind of that step-by-step process of like, okay, here's our goal. Here's what we were trying to learn to help us get. to that goal here's what we learned and who we learned it from and this is what we're doing about it and if you can make that clear connection into
Like this is basically like what is helping us shape our roadmap is the fact that we thought we knew this. We found out that we didn't actually know it. But this is what we've learned and this is what we're doing about it. I think that goes a lot further than just saying, hey, we interviewed 10 customers. Sitting Sally over here likes to sit on these kind of cushions and like having these like weird persona names and focusing like on pretty slide decks. Just make it very clear of.
we this is what our hypothesis was this is what we were trying to learn this is what we actually learned and this is what we're doing about it connecting the dots right what you're talking about is what i think i was trying to get at also earlier which is
You did the research, whether it's a little, a lot, medium, and then you're connecting the dots for people. And I couldn't agree more, right? If you have that readout, if you show me the output and you... right don't just show me like stats and charts and um just all narrative right and interesting quotes um and things like that that you actually tie those into what we're all trying to achieve like you said um i think then it's much much harder to doubt the value of the time spent yeah um agreed
Agreed. That's a great point. And I think when that starts to be done well, I think that's when the mindset will shift from why are we investing in this to we should invest more in this. Right. 100%. And I think... um it could also right maybe now i'm being the little bit of uh of an idealist here although by the way i was never john referencing or thinking like that you were an idealist um i think though
right if you if you start you're you're educating right leadership and so you could actually um positively affect the culture right into that direction of just perhaps um right because we all known we all worked with leaders who like many Steve Jobses, and they have every right to be, but they revert to, okay, I don't see the results I need or someone's not connecting the dots for me. I'm just going to make a decision.
And if you start connecting the dots for them, you might start retraining and changing the whole culture of an organization to stop, pause, question, rethink, and adjust as needed. Yeah. I would love nothing more than that to be what happens and like across.
the broader industry of product work that to be become a reality so i am a little bit of an idealist but it's okay so call a spade a spade i'm fine no it is it's a good thing um yeah but i i think that's it's a great point and it's it it beautifully sort of ties into my natural mindset i don't know if this is idealism or not but it's just i do right
I've noticed I do personally lean into action. And I think when placed in leadership roles, that's something that I need to be very weary of and mindful because that could get us into that dangerous spot. So I try to... I try to think on that a lot and recognize. when it's time to pause. And I think that's why I loved your question, because it sort of forced me to think about that tension going back to like execution versus sort of, you know, research, if you wanted to.
bucket them in those categories? And sort of how do you find that really nice, I think, middle spot that optimizes for both? Yeah, no, I love ending on that note, because I think that's such an important takeaway for the listener, where like research is important but you can't get stuck spinning your wheels to where you don't do anything it's that that old you know what is it the um
But yeah, it's that old analysis by paralysis thing that everyone talks about that you have to at some point find that mesh point where it's like, okay, I've learned enough to take action. Versus thinking you have to know everything and be perfect because that's not a reality and it never will be. Yep. Agreed. Agreed. 100%. Well, Paul, man, thanks for coming on. This was such a fun conversation. I truly love all the ways that we...
We went into it and all the different angles that we looked at kind of product and eventually got to research and spent a good bit of time there. So thanks for sharing your thoughts, man. Thanks for the engagement back and forth on LinkedIn. And thanks for coming on the podcast. Yeah, John, it was my pleasure. I had a lot of fun too. And yeah, please keep it up. I love, I love what you're doing for the product community. I think it's great. So yeah, anytime I'd love to engage and thanks again.
Yeah, appreciate it. If you enjoyed this episode, make sure to hit that subscribe or follow button, leave the podcast a rating and a review, and we'll see you next time for another lesson in product management.