December 13, 2022

The JJ Rorie Hypothesis: The 5 Key Skills That Make a Product Manager Great Can Be Learned

We talk with JJ Rorie about what mistakes teams make around their assumptions, how product management is different across industries and company stages, and how to create an environment where product managers help each other.

The JJ Rorie Hypothesis: The 5 Key Skills That Make a Product Manager Great Can Be Learned

JJ Rorie is faculty at Johns Hopkins University, teaching undergraduate and graduate-level product management courses. She is the author of IMMUTABLE: 5 Truths of Great Product Managers, and is Chief Executive Officer of Great Product Management. JJ is a sought-after speaker, advisor, trainer, and coach, having worked with some of the world's largest companies, and also hosts the podcast Product Voices.

In this episode of the Product Science Podcast, we cover what mistakes teams make around their assumptions, how product management is different across industries and company stages, and how to create an environment where product managers help each other.

Subscribe for the full episode on Apple, Google Play, Spotify, Stitcher, YouTube and more. Love what you hear? Leave us a review, it means a lot.

Resource Links

Questions we explore in this episode

What was one of the biggest lessons she learned while working at First Data early in her product career and what does she do instead now?

  • You have to identify the assumptions early in the process and be willing to invalidate them
  • Now, when starting a new initiative instead of getting excited about all the ways something could go right, she flips it around and looks at the ways of could go wrong
  • She uses a hypothesis canvas to capture evidence both for and against a hypothesis

How does she create an environment where product managers help each other?

  • Make sure the product managers spend time together as a team, sharing learnings
  • Encourage product managers to bring peers into design studios and risk assessment exercises
  • Remember that product manager peers like to get out of their work and think about other product challenges for a while

What has she learned from working in a wide variety of industries and company types?

  • When she started working with providers of military solutions, she was surprised to learn that by contract they often cannot make any changes to the product over one or two years
  • Product managers in industries that cater to the government often have very few clients and lots of barriers to change, so they have to get creative about offering new products and services to solve new problems
  • There are situations where more heavy due diligence is needed even while trying to use concepts of agile and lean, such as in medical devices which require government approval
  • Big companies are more constrained by processes and approvals because they feel like they have more at stake with their existing businesses and brands
  • Early-stage startups are often difficult environments for product managers because they can be task oriented around delivering on the founder's vision

Can product managers improve their skills in the five immutable truths that JJ has found are foundational across all great product managers?

  • All of the skills are learnable, even those  that are commonly misunderstood to be only innate
  • The one that people most often misunderstand is that uncommonly good judgment can be learned
  • Experience and time build confidence and that builds the skills to learn the rest

Quotes from JJ Rorie in this episode

When we're looking at a new project or a new product, we're so excited about it, we think about all the ways it could go right. But if we flip that around and say, "Let's think of all of the things that could derail this project or could make this go wrong." That way, it opens our eyes a little bit to some of those things.
I think the one that jumps out that most people think is innate, you either have it or you don't, and it's not something that you can build upon is the good judgment. I don't agree with that. I think we absolutely can build upon that.
A product manager is not going to be in another product manager's entire work stream, but if they're having some upfront design sessions or they're having some upfront risk assumption sessions, pulling someone in and encouraging a product manager to ask another product manager to come in and sit and provide feedback, that's what I always did as a leader.

The Product Science Podcast Season 5 is brought to you by Productboard

Check out their eBook: Dangerous Animals of Product Management 2.0
Every organization has challenging stakeholders and situations that can get in the way of our product plans. Learn how to manage them using a mix of soft skills and hard frameworks.

Get Your Copy


Holly Hester-Reilly: Hi, and welcome to the Product Science Podcast where we're helping startup founders and product leaders build high growth products, teams, and companies through real conversations with people who've tried it and aren't afraid to share lessons learned from their failures along the way. I'm your host, Holly Hester-Reilly:, Founder and CEO of H2R Product Science.This week on the Product Science Podcast, I'm excited to share a conversation with JJ Rorie. JJ is faculty at Johns Hopkins University, teaching undergraduate and graduate level product management courses. She's the author of Immutable: 5 Truths of Great Product Managers and is Chief Executive Officer of Great Product Management. JJ is a sought-after speaker, advisor, trainer, and coach, having worked with some of the world's largest companies, and she also hosts the podcast, Product Voices. Welcome, JJ.

JJ Rorie: Thank you, Holly. Great to be here.

Holly Hester-Reilly:Yeah, I'm so excited to finally have this conversation with you.

JJ Rorie: Yes, absolutely.

Holly Hester-Reilly:Tell me a bit about how you got into product.

JJ Rorie: Yeah. My first foray into product management's kind of funny. Like a lot of people, I just happened into it, found myself into it. I was working, gosh, this has been close to 15, 16, 17 years ago, a long time, at a law firm in Fort Lauderdale, Florida in marketing. Totally random, right? And so, I was doing marketing for this law firm and the main partner had an idea for a software product. He was a very eccentric, brilliant man, but way out there and he had this idea for a software product for law firms, for healthcare clients. It was a firm that did malpractice insurance cases and that sort of thing, and so they worked with hospitals healthcare systems. So, software product was going to manage legal cases. Okay, great. He comes to me, 20-something-year-old in marketing, and says, "Hey, you want to build a product with me?"I'm like, "Yeah, let's do it." Know-nothing me and then know-nothing-in-terms-of-product-management partner build a product together. We found someone to write the code and do all that kind of stuff, and it was fun. We actually did it. When looking back on it, I realized how ridiculous some of the things we did were. Then I also did some things right. I got voice of customer. I didn't call it that, but went out and talked to people. It was fun. So from there, I realized that, "Hey, this is cool." I didn't even at the point know there was this profession called product management, but after that, got into formal product manager roles, learned the craft, and took it from there. But yeah, it was fun to realize that you could build something and have fun at it.

Holly Hester-Reilly: What were some of the mistakes that you made that you're now like, "Gosh, I would tell myself not to do that?"

JJ Rorie: Yeah. First of all, we tried to define everything up front, and so it took us a year-

Holly Hester-Reilly:Oh, gosh.

JJ Rorie: To just, again, write requirements. I didn't call it that, because I didn't know it was that or user stories or whatever. We tried to do the most ridiculous things. It was so old-school and wrong. So, we did that. We didn't get enough feedback. We talked to customers, but then we would go try to build something and then didn't go back and validate anything. We had no idea what we were doing there. We didn't have a clue about competitive research and market research and pricing and how we did all of that. So, we just threw things at the wall. The fun part was we built something which wasn't that great, because of all of those reasons I just mentioned, but then we would jump on his private plane and go talk to hospitals all over the country. So-

Holly Hester-Reilly:Oh, wow.

JJ Rorie:Again, for a 20-something-year-old marketing person who had no clue what she was doing, it was a fun experience.

Holly Hester-Reilly:Yeah, sounds fun.

JJ Rorie:It just wasn't the best product, but it was fun to look back on it and think it was interesting to do it that way because we had the beginner's mind and then you can point out all of the silly things that we did too. So, it's cool to look back at that.

Holly Hester-Reilly:Absolutely. That's interesting, I had a similar, I guess, first experience with my first startup that I was a part of, where there was a lot of things that it's like, gosh, nowadays, I would just be like, "You need a coach."

JJ Rorie:Yeah. What were you doing?

Holly Hester-Reilly:Well, we were building a lot without putting it in front of customers and same sort of deal. We talked to people and we were inspired by people, but then we would build and we thought we needed to be in stealth mode. So, we didn't actually show what we built to anybody for over a year. In retrospect, I'm like, "What were we thinking?" I remember I went to an event at my alma mater for founders and entrepreneurs and I met somebody there who was an early adopter of Lean startup and was basically like, "You're doing it all wrong. You need to be talking to customers every day. Put it right in front of them." I remember just being like, "Oh my God, I've been doing it all wrong."

JJ Rorie:Right, I still do that. I've been doing it 20 years now, and I still wake up and say, "Oh my God, I think I'm doing it wrong." So...

Holly Hester-Reilly:Yeah, exactly. What were some of the highlights since then? What are some of your favorite companies that you've worked at?

JJ Rorie:Yeah. From there, I went into a real product manager role, as I said, and that was at a company called First Data, which is a big global payment processor, now called Fiserv because they merged with Fiserv, I don't know, several years ago and so now, they're under the Fiserv brand. But I really learned the craft there. Again, this was in the early 2000s-ish, 2006, 2007, 2008, something like that. In tech years, that was a hundred years ago. It was still a little bureaucratic and the processes we used were what we would call now out-of-date. But at the time, it was a great place to learn the craft. You've got some really smart people. You've got passionate people. The payment space at that point was a really interesting, evolving space, and so we had some really innovative things. Mobile payments was not a thing back then. We were working on that and doing some really fun stuff.That's where I learned the craft and moved up and ended up leading a global product team there. From there, had a startup for a while, moved around, did some consulting. Then went and led product at the American Hospital Association, which was a totally different environment. So, services-based and membership-based organization. We had some data products. We had some media products. And so, really got to learn a lot about different types of products and different types of industries, if you will, and user bases in that role. And then, been consulting and advising for now, gosh, five or six years at least. That's been amazing because I've gotten to see numerous industries, everything from logistics and travel to pure software to military equipment and everything in between. And so, it's been interesting to see the various cultures of product teams, depending on the product and the industry, and also some of the processes, some of the ways that they focus in different ways depending on what they're building.

Holly Hester-Reilly:Yeah, I'm sure there's a lot of gems in there. I'd love to go back to one of the earlier things you said there was about a global product team at First Data. Tell me more about that. What was that team structure like?

JJ Rorie:Yeah. We were the product team, building data and analytics products for the financial services side of the business. If you think of a consumer payment, you've got the retail, or wherever you're buying something, and then the bank, or whoever owns your card or issued your card. We were in the business unit on financial services. So, we worked with banks a lot. The products that we built were basically a byproduct of all of that payment data, all that consumer behavior data. We would build loyalty and marketing products. We would build fraud products and risk products to make sure that whoever was using that payment vehicle was actually the person who was supposed to be. So, really cool products that we built. We were structured somewhat traditionally. We had North America. We actually had Latin America as well. We had folks in APAC, of course.And so, we had folks all over the world, and again, not quite the same as it is today because there weren't all the technologies of the remote world. Now, of course, they existed and we all obviously had lots of virtual meetings, but we had meetings at times where the folks were calling in literally on a conference call. Then we would have some video meetings as well, but those weren't the same as today. You didn't just click a button and jump on a video call. Now, again, I'm not a thousand years old, so it wasn't that bad, but it was not today. We had to do a lot of things of team building and making sure that everybody understood that we were one team, even though you were working literally in different parts of the world and often never met your team in-person, never worked on projects with them. And so as a leader, that was the hardest part. Frankly, the most fun part to me was to think of ways that we could all bond and get together and work towards one mission.

Holly Hester-Reilly:That sends me back. It reminds me of that same first startup, buying webcams for everybody and buying them all headsets and shipping them to them and being like, "We're globally distributed."

JJ Rorie:Yeah. "We're so cool. Look at us."

Holly Hester-Reilly:Yeah, exactly. "Look at us. We're getting on video calls."

JJ Rorie:"Sorcery."

Holly Hester-Reilly:Exactly. "It's like magic." Were there any things that you did back then that you would look back on and say, "Wow, what a mistake?"

JJ Rorie:Yeah. There was one big project we were working on, and again, it was under my team, but because it was such a big, visible product, I was actually leading it. So, I was the product manager on this project in addition to being the leader of the team. It was this idea to take all of the data from all of these payments that we processed. Again, we at that time processed a trillion dollars a year of transactions. I mean, just a ton, literally billions of payment transactions. As you can imagine, there's a lot of interesting data there. There's a lot of interesting consumer behavior data.The idea was to take all of that data and combine it and use it for things to show certain behaviors and to help banks and others understand how they could better serve their customers. Well, it's a great idea and we ran with it. It was the quintessential, "Hey, this is awesome, light bulb moment. Let's just start building, or at least start organizing." And so, we built decks and we did research and we did all of the stuff. We literally resourced a team and I mean, just did a ton of internal work and talked to some clients, which on the very surface they thought it was an interesting idea. But when it came right down to it, here was the problem. Each bank owns their data. First data did not own the data. It was the bank's data. It was the customer's data.And so, they had to agree legally to combine their data with other banks' data. Well, no way they're just going to do that for legal reasons, for competitive reasons. That's a big hurdle. It ended the whole project basically. And so, it's like you look back on that and you're like, "How did you not ask that first or figure that out first, before you start jumping in on this exciting shiny object?" Looking back, that's one of the learnings that I've taken is that, "Okay look, yes, you don't have to be a negative Nelly and always look at the things that can go wrong." That's one of the problems that we do is we always jump in, or at least some people jump in, and say, "No, that can't work. Let's move to something else."

Holly Hester-Reilly:Right.

JJ Rorie:But you should look at the realistic hurdles.

Holly Hester-Reilly:Yes.

JJ Rorie:"Is this feasible or not? Probably not. Let's move on to something else." It's funny now, but it's like, "How? How did you not do this?" Because there were a lot of leaders and a lot of smart people thinking, "This is a great idea. Let's do it." Yeah, didn't work so well.

Holly Hester-Reilly:That's interesting because I came across a Twitter thread recently, where someone was talking about being involved in several public failures and talked exactly about that, about there being a core assumption that is wrong and that becomes the elephant in the room, that everyone just somehow thinks that it's going to be overcome but it never is, and then at the end of the day, that not being right means the whole product can't succeed. I guess I'm curious, having been through that, what tactics or strategies have you come up with since then to try to keep that from happening again.

JJ Rorie:Yeah, you're exactly right. It's the assumptions that we're making, and we work on assumptions in product management. That's just how it is. We make predictions and there are very few things that are absolutely set in stone and black-and-white true. It's all about mapping your assumptions and naming those assumptions and not taking anything for granted. And so, that example is huge assumption is that each of the banks are going to share their payment data in a way that allows this to happen. The fact that we just brushed over that assumption and didn't talk about it and didn't dig into it was the death of that project. So, every assumption, big and small, map those out from the beginning.I've got something that I call a hypothesis cannabis that I use that allows us to name those hypothesis or assumptions, and then as we're going through our research, literally document what proves it and disproves it, because we so often have confirmation bias that, "Oh, I heard this. It proves it." Well, guess what? We're interpreting that a certain way. And so, to actively try to disprove your assumption or disprove your hypothesis is actually a good practice to avoid some of those mistakes. That's what I try to do is just be as open as possible about the assumptions and hypotheses, use that canvas to try and disprove things, and then just go through an exercise and try to name out everything that could go wrong. When we're looking at a new project or a new product, we're so excited about it, we think about all the ways it could go right. But if we flip that around and say, "Let's think of all of the things that could derail this project or could make this go wrong." That way, it opens our eyes a little bit to some of those things.

Holly Hester-Reilly:Yeah, I love that. A practice that I do as well. I think it's so valuable to open up that conversation. What experiences have you had with teams engaging in that conversation? How willing to talk about all the ways that could go wrong have the teams you've worked with been?

JJ Rorie:Yeah, it depends on the culture. I look back on it and it seems very negative and I don't think that it necessarily was, but the culture was to very much look at what could go wrong and how we couldn't do it. It was almost like we were trying to talk ourselves out of doing something. Always. That was our default, which is totally different than a lot of cultures, which is always talking our way into something or always confirming that we want to do something. And so, it depends on the culture of the organization like, "This will never work," or, "This could never possibly fail." Probably somewhere in between there. The teams that are more on the, "This could never work," actually ended up identifying some of those risks earlier in the process. And so, yes, sometimes as a product manager, product leader, you had to use your influence skills and your communication skills to get them over the negative hump once we decided that it was something to go forward with, because then you've got to excite them, people who are naturally negative and are looking at the bad side.But from a risk perspective, it actually really helped to identify some of those. And then, I've worked with teams both on my own teams and then as an advisor that they have a really hard time identifying what could go wrong. I find that very interesting, because again, they're just so positive, which is a great thing in theory, but you really have to force them to think of all of the things that could go wrong. And so, the best way that I've found is to have a cross-functional team. Don't just have a few product managers, or don't just have you as a product manager and a few engineers. Have marketing folks and finance folks and sales, if you've got a sales group, and engineers in various parts of the engineering group if possible, and even a few product managers that aren't necessarily working on this product, but they have adjacent roles and they can see perspectives or they have perspectives that may bring something in. So, cross-functional teams are usually the way that regardless of the culture of the organization, you can actually bring some things to light if you've got different perspectives.

Holly Hester-Reilly:Yeah, it's so important to have those different perspectives in the room. In particular, one thing that struck me with what you just said is about bringing in other product managers who might be in adjacent areas. I've seen a lot of organizations where product managers themselves end up pretty siloed from each other, and everyone's running really hard and they barely have time to stop and help each other. I guess I'm curious to hear from you about, is that something you've encountered as well and how have you gotten over that? How did you get those product managers to come and be a part of those risk discussions?

JJ Rorie:Yeah. Again, every product manager, like you said, is just running their own show. They don't often have the time to take their heads up out of that to do something. And so, it depends or it helps a lot if the leadership is setting the stage for that. A couple things that I did as a leader, I don't think I really had the foresight to do it as a product manager, but once I became a leader and realized that these things were important, number one, I always made sure that we as a team spent time together, whether it was weekly product team meetings or what have you, where we all talked about what we were doing because again, literally, some projects and some work streams are completely blind to other product managers.During those meetings, we would talk about the projects, the work that we were doing, and very intentionally try to find ways that they mapped to each other, or there were learnings from one product manager to the other. "Oh, that happened to you? Yeah, that happened to me on my last release, and this is what we did about it." And so, very intentionally set up those cross product manager conversations. But in terms of actually being involved in other projects, again, as a leader, I try to encourage that. A product manager is not going to be in another product manager's entire work stream, but if they're having some upfront design sessions or they're having some upfront risk assumption sessions, pulling someone in and encouraging a product manager to ask another product manager to come in and sit and provide feedback, that's what I always did as a leader.What I would suggest is, I mean, even if you're not a leader, you're listening and you're a product manager, just ask if somebody can do that and try to set that up. You can amend the culture of your team by literally just asking someone to do something differently. They'll show that it works and they'll frankly enjoy it, because as a product manager, they like getting out of their day-to-day world for a minute and having the ability to just think about other things and provide perspectives. So, even if you're not a leader that can do it from the top down, as a product manager, you can always just ask your peers and create that environment on your own.

Holly Hester-Reilly:Yeah, absolutely. I think that's a really valuable point that as a product manager, you don't have to wait for your product leader to make things happen. You can go out and make things happen even where you're at.

JJ Rorie:Exactly. One of the things I encourage all the teams that I work with is to create this community of product managers. Even if it's not something formal, if the 20 product managers that work in that company want to set up a monthly lunch-and-learn or a coffee or whatever it is, just do it. Just talk about a book or talk about a podcast or talk about your projects or whatever and just do it. I mean, those product managers in your community are bevy of wisdom and we all should learn from each other.

Holly Hester-Reilly:Yeah, absolutely. You had a long list of different industries and types of companies that you've worked with. Did you have any experiences where you got in somewhere and you thought, not necessarily that you had seen it all, but you knew what you were getting into and then it turned out that something about this company or this industry was just really surprising and different?

JJ Rorie:Well, it's interesting. I mean, even though I had seen a lot of longer span product development cycles and physical products and that sort of thing, when I started working in industries like the military or providers for military equipment or services or what have you, especially physical or digital products, I was really surprised... I don't know why I was surprised, but I was that they, by contract, often can't change the product that they sell to a government entity for years and years and years. They literally can't even do different releases in some cases.Think about that for a second. You launch a product, let's say, it's a physical product, a piece of equipment or something, and you can't do a new version over the next two years. You've signed a contract with a government entity and they can't change anything about it, which is so fascinating. Now, this of course is not for every product out there, but a lot of products are that way. What that means is, number one, you probably as a product manager got about six to 10 clients. Period. Ever. You're never going to have more than that, because those are the governments, those are the military, those are your markets, which is really interesting and totally different than some consumer software product for example.The other thing is, what does that mean for innovation and what we think about as improving our products? It's always finding services around it or it's finding net new products. And so, that was a very interesting dynamic. Of course, it's just one niche market, but it's very interesting to think about that because we, as product managers, don't think about putting something out and not touching it for 10 years and literally not being able to touch it for 10 years. That one was a really interesting learning for me. And so, what we had to do as product teams when coaching them was to think about all the other ways that we could add value to that customer in addition to that. They had to be really good at understanding customer problems and all of the nuances around the problem, because you obviously could get complacent if you were in that environment. We tried to avoid that. So, that one was a really interesting eye-opening experience.

Holly Hester-Reilly:Yeah. That makes me think back to one of my own early experiences was I studied chemical engineering and I worked as an environmental engineer. I worked for the city of New York and we had a big software project. Just watching that whole process of how the government contracts a private company to build software and how the format of government contracting dictated essentially a waterfall process and it was shit. I just remember being like, "Oh, this is really a crash course in what not to do."

JJ Rorie:Right, but like you said, it was dictated that way. If you're going to do business with that entity, you have to do it that way or some model that looks like that. It's just interesting and it's not what we tend to think about modern product management today, but there's still a lot of those pockets out there.

Holly Hester-Reilly:Yeah, absolutely. There's a lot of organizations that have those kinds of constraints. I think I have occasionally come across someone from the agile or lean community who's working with governments and trying to innovate in the process of the contract itself so that there can be lean and agile. That's a whole area that I think a lot of us just don't pay attention to.

JJ Rorie:Yeah, absolutely. To give another example, I have I'm sure the same conversations that you have with folks, which is, a lot of product managers and a lot of people who want to be better in their products, like executives, et cetera, they think agile's the only way to go. First of all, agile is huge and convoluted and we all need to improve it in our own organization. But the truth is, there are some situations where a more heavy due diligence is needed. It doesn't mean that the whole process has to be old-school waterfall, but medical devices, for example, have to be approved. The design has to be approved by the FDA in the US or other regulatory body, depending on the country you're in.Once that design is finalized and approved, the team's not going to go back and iterate on that because if they do, they've got to go back into the approval process which can take years. Depending on the risk of the situation and what you're building, there's a point where true, iterative, ongoing changes of a product, it's just not feasible. And so, I try to get people to understand that, "Sure, if you're building just a purely software product, go for it. Do your thing." But a lot of folks aren't building those types of products, and there's still a world out there that needs a little bit more due diligence and a little bit more de-risking even while trying to use some of the concepts of agile, lean, et cetera.

Holly Hester-Reilly:Yeah, absolutely. What about, I guess, within different company types? Have you found there were times where, I don't know, if it went to a really big company from being in small ones or vice versa, but where the structure of the companies itself was surprising and constraining?

JJ Rorie:I think the big companies tend to be more constrained by processes and approvals and that sort of thing. Of course, that's a generalization, but I think it generally holds true. There's just more at stake. Ironically, there's really less at stake if you look at product line versus their entire company, whereas a startup, literally the entire company is at stake. But in their minds, there's more at stake. They think they have to be more buttoned-up and they have to have more diligence around their processes, even if it's agile. I think that a lot of times, I'll do training or advising with big company and there's hundreds of product managers, and that's awesome that they've got that infrastructure, but it makes it harder for everybody to have consistency around their thought process and the consistency around the way they're doing things. One product manager, one product team does things one way and another does a completely different way.Now, there's nothing wrong with that on its surface, if the inconsistencies are the elements you're vetting ideas against, prioritizing against, making decisions on, and sometimes you get convoluted. And so, the complexities of big organizations I think still impacts product management the way that they can succeed. On the other end, I work with startups and their issue, again generalizing, but a lot of times, is that you've got a CEO or founder group who have a vision and there's not really a need or the desire to have product folks then create their own vision. And so, the disconnect there or the difficulty there is having product folks who by nature are problem solvers, are critical thinkers, curious beings, just be executors and taskmasters of somebody else's vision.You tend to have a more free flowing culture in startups, which is helpful, but at the end of the day, the work often is very task-driven and just executing on somebody else's vision. That's not always the best environment for our product managers. So, it's just interesting to be able to go into both sizes of companies and see the difference and I think both of them can learn from each other, big companies and small companies, but it's hard to make yourself embed those learnings in an environment that doesn't look like a giant company, for example, or a startup. You hear lots of big companies say, "We're going to carve off this little group and they're going to be a startup within our big company." Well, that's a start, but it doesn't always work that way.

Holly Hester-Reilly:Yeah, absolutely. That's a whole nother topic I think, but one thing that I'm thinking about as I'm talking to you is I can see behind you your book and I want to know more about how you came to write a book.

JJ Rorie:Awesome. Yeah, thank you. The book's called Immutable: 5 Truths of Great Product Managers. I actually went through several iterations of what the book was going to end up being about. At first, I thought it would be about all front-end customer discovery, and then I realized that there are a lot of people that do that and do it really well and have some amazing content out there. Honestly, that problem didn't need to be solved, in my opinion, and I didn't think I was the person to solve it, which I think is a good product lesson. Does your customer problem exist? Are there alternatives out there that are better than what you could position yourself at? And so then, actually interesting talking about the different industries, one of the ideas for a book was to differentiate software versus non-software product.I still think there's a gap in content there, but what ended up piquing my interest mostly, it also stemmed from working across different industries and companies, was that I saw what looked like successful, happy frankly, just the folks who navigated the product manager role well and tended to not be the folks who got overwhelmed... Of course, we all get overwhelmed at times, but the folks who just seemed to navigate the role more easily and more efficiently. Ended up calling them great product managers, and I defined that in a specific way, but the folks who seemed to succeed in the role. I wanted to do some research and find, "Okay, what is it? What is it across those?" Because again, it looked like someone could be successful building military equipment or building software.And so, I wanted to see if there were commonalities across those folks and that was my hypothesis going in was that there were a set of skills that any great product manager had, regardless of industry, regardless of anything in their background, et cetera. That's how the book came about. Ultimately, I define these five immutable truths of great product managers, and they're things that we all know about, but working together, they form this foundation or anchor that everything else is built upon for a product manager. So, the five things are customer intelligence, just really digging deep and having a high level of customer intelligence; building relationships, great product managers just do that well; they're master communicators; they have uncommonly good judgment; and they're fanatical about prioritization.Again, I'm not the first person to say any of those things, but they're so foundational to what we do. I yet have seen a great product manager who doesn't have a fairly high skill level on those five things. And so, I wanted to take it back to the basics and make it simple and say, "Yes, there are other things we've got to learn to be good at product management. We've got to have a technical acumen, financial acumen, et cetera, frameworks and how to do certain things, but at the end of the day, this is our foundation. If you don't do these things, it's going to be really hard to navigate the role."

Holly Hester-Reilly:Yeah. Do you believe that those are all things that can be learned and developed?

JJ Rorie:I do. In fact, I strongly believe that. I think they're not necessarily easy to develop and they take persistence and consistency and literally your entire career you'll be working on them, but I absolutely agree with that. I think the one that jumps out that most people think is innate, you either have it or you don't, and it's not something that you can build upon is the good judgment. I don't agree with that. I think we absolutely can build upon that. Now, some people just, again, have a talent for certain things and you start at a place further along than some other folks, and that's okay, but I think you can build all of these things.In the book, I've tried to distill it down to a couple of things that if we focus on within the context of product management, we can build relationship building skills. We can build communication skills. We can build judgment. Again, we don't have to try to boil the ocean and be a keynote speaker. That is not necessarily what good communication means in product management. It means adapting to your audience. It means being clear in your message. It means connecting with people, and that's it. There are a few things that we can do and get better at it and absolutely, I'm a big believer that we can all improve in these areas.

Holly Hester-Reilly:Yeah, I am too. I'm curious to hear if that has an impact on your teaching and where your students are at. Especially, I also teach graduate students, but I don't yet teach undergrads and I'm curious if you see a difference in some of these skills between the two groups.

JJ Rorie:Yeah, this semester is the first time we've opened it up to undergrads. But what's interesting about the product management course that I teach at Johns Hopkins is that it's one class for both. So, I don't teach a grad class and a separate class for undergrads. I've got undergrad students and grad students in the class together and they're working on real-life projects with real companies. Of course, I'm lecturing and doing all of the educating that way, but they're also getting the experience to work with a real company on a project. So, they're learning that practical thing.The difference I've seen, and honestly it's interesting, some of the undergrads are tremendously confident and communicate well and that sort of thing. Each individual is different, regardless if they're graduate or undergrad. I think confidence is the real thing that is the difference between graduate students and undergrad students. Again, a couple of students who are undergrads that just seem to be more confident and I think that's what I was talking about earlier. Some people just start at a different level, and there's nothing good or bad about that, but I think confidence is what folks learn over time and through experience.The grad students are obviously a little bit older. They've been through an entire undergrad program. Some of them have done internships and worked on real teams. Some of them have even done some actual work experience, where the undergrads haven't. Maybe, they've done an internship, but they just don't have that experience yet. And so, I think it's actually a good examination of how experience, time, builds confidence and confidence actually gives you more ability to build all of these things.It's very interesting to see that and I try to instill in them that, "These five things are things you need to build in addition to all of the other stuff I'm teaching you, but keep working on it. Don't beat yourself up if you don't feel like you're a good communicator right now. You'll get it. Just work on one thing at a time, and you'll get to that point." It's a great question because I think at the end of the day, it just boils down to confidence and I think that's probably true for professionals out there as well.

Holly Hester-Reilly:Yeah, definitely. That's also a skill that grows with usage.

JJ Rorie:Yeah, absolutely.

Holly Hester-Reilly:Tell me more about your own podcast. What is the mission of your podcast?

JJ Rorie:Yeah, the podcast is called Product Voices and you've been on it. So, thank you. This is the first year. It started in 2022, and so now we're almost at the end of 2022. We've got I think 40 episodes out there. It's a fairly new podcast, but wanted to create just a forum for people to come talk about product, but more specifically, share resources. At the end of virtually every episode, I'll ask the guest what resources they've used to learn product management and or the specific topic we're talking about, and then we'll share those resources on, in show notes and that sort of thing. Again, it's just one more vehicle for our folks to learn from others because I think product management is such an ongoing learning thing. We never stop that education. And so, I really just wanted to create a forum where we could have casual conversations about some topic and then share resources with each other that can maybe help along the way.

Holly Hester-Reilly:Yeah, I love that very much and it was great fun being on your podcast.

JJ Rorie:Well, you're an inspiration. So, I was excited to have you on because I've always loved your work and your content. I loved having you on and I'm really pumped about being here.

Holly Hester-Reilly:Yay, I'm really glad. What did you spend most of your time doing today? Is it mostly teaching, or are you doing other stuff as well?

JJ Rorie:It's mostly corporate work. I teach a couple of classes and they're virtual classes now. I don't go to Baltimore, which is where Johns Hopkins is. I don't live in Baltimore. Last semester, I went to Baltimore and had in-person classes every week, and that was a little difficult logistically, just being a part-time professor. Now, I do all my classes virtually. Usually corporate work, I'm spending more time on that. It's again, going in and doing advising, facilitation, and some training and that sort of thing. I spend quite a bit of time teaching and then mentoring the students. I'm the faculty advisor on the product management club at Johns Hopkins. So, I spend a lot of time with students there. I think if you really boiled it down, a lot of my time is coaching and mentoring, whether it's someone already in the corporate world or students trying to get into the corporate world.

Holly Hester-Reilly:Yeah, that's awesome. I mean, I love doing those things as well. So, I'm happy for you that you get to spend a lot of time doing that.

JJ Rorie:It's very cool, and I love that you do it as well. We share that because I don't think there are a lot of programs out there right now that have product management courses. So, I love that we both have the opportunity to teach folks that way.

Holly Hester-Reilly:Yeah, and it's exciting to see more and more of them popping up around the country.

JJ Rorie:Yes, definitely.

Holly Hester-Reilly:Where can people find you if they want to follow you?

JJ Rorie:The best way is to go to That's On there, you can find my website, great product management. You can find all my social links. You can find the podcast. You can find out about Johns Hopkins, all kinds of stuff. So, is the best way.

Holly Hester-Reilly:Awesome, all right, and we'll put that in the show notes. So, if anybody wants to just browse to the link, that's an option too.

JJ Rorie:Cool.

Holly Hester-Reilly:Awesome. Well, JJ, thank you so much for your time today. It was really fun.

JJ Rorie:Yes, it was, Holly. Thank you so much. I loved the conversation.

Holly Hester-Reilly:The Product Science Podcast is brought to you by H2R Product Science. We teach startup founders and product leaders how to use the Product Science method to discover the strongest product opportunities and lay the foundations for high growth products, teams, and businesses. Learn more at this episode? Don't forget to subscribe, so you don't miss next week's episode. I also encourage you to visit us at to sign up for more information and resources from me and our guests. If you liked the show, a rating and review would be greatly appreciated. Thank you.

More Posts