The Paul Gebel Hypothesis: Products Succeed or Fail Based on the Trust They Build

Paul Gebel is the Director of Product Innovation at ITX Corp, where he leads a team of 15 product managers working on enterprise client accounts overseeing 7 Agile teams. He’s also an adjunct professor at the Rochester Institute of Technology and the host of Product Momentum, a Product Development Strategy podcast.

In this episode of the Product Science Podcast, we talk about why product leaders are the next business leaders, and how to step into owning that role.

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


Questions We Explore in This Episode

The Paul Gebel Hypothesis: Products Succeed or Fail Based on the Trust They BuildHow did Paul go from serving in the Navy to a career in product? What did he pick up from his major in graphic design? Why is taking the time to train your team such an important component of good leadership? What lessons carried over from Paul’s time in the Navy, and why is product ultimately a people business? How can you free your team from distractions so they can focus on their job?

What unique perspectives does Paul have coming from industry into a product management agency? Why are we seeing more and more product managers responsible for things like PnL and hiring and firing? Why are some products coming across tonedeaf to people in industry? What external demands are coming into play? How do you look beyond products to see the people who use them?

How does Paul manage to serve both his clients and his client’s customers, and what are the challenges in accomplishing that effectively? How do you balance your job as a consultant with your job serving the end-user? How does this differ from the relationship an in-house person has with their key stakeholder or project sponsor? How does Paul differentiate between implied trust and earned trust?

How do you prioritize trust at the beginning of an initiative? Why are the things that are most experience perspective different than the things that are important from a trust perspective? How do you challenge assumptions at the start of a project, and why is it harder to do that later on? How is an innovation workshop different than a design sprint?

What does Paul mean when he says that software develops, it is not developed? Why is the vision you have the outset not the same thing you have at the end? Why do we need to shift our perspective as product leaders in understanding the function we’re serving? How do you keep your vision over a series of sprints? What do most product managers lose sight of and how do you keep your focus? How do you avoid getting stuck in the output instead of focusing on the outcomes?

Quotes From This Episode

Product management is a people business. There’s a lot of leadership that goes into product management that’s not just about making cool products. – Paul Gebel

Earning trust is not a binary. It’s not a have it or don’t have it. It’s definitely one interaction at a time.- Paul Gebel

I think the thing that matters most, and that companies are going to live or die by, is whether or not they’re resilient enough to trust their people.- Paul Gebel


Holly Hester-Reilly: Hi, and welcome to the Product Science podcast, where we’re helping startup founders and products leaders build high-growth products, teams, and companies through real conversations with people who have tried it and aren’t afraid to share lessons learned from their failures along the way. I’m your host Holly Hester-Reiley, founder and CEO of H2R Product Science.
Hi, this week on the Product Science podcast, I’m excited to share an interview with Paul Gable. Paul is the director of product innovation at ITX Corp, where he leads a team of 15 product managers and they work on enterprise client accounts. Paul, welcome to the Product Science podcast.
Paul Gable: Hey Holly, I’m so excited to be here. Thanks for having me.
Holly Hester-Reilly: I’m excited to have you too. I always love to get started by hearing a bit about how a person got into product in the first place. What’s your origin story?
Paul Gable: It’s been a roller coaster, like most product managers will say. I am a veteran, started out in the navy, moved on to management consulting with some time at Booz Allen. And then I spent a bit of time in finance before finally going back to technology as a graphic design major. I’ve always had a passion for UI and building really inspiring experiences for people, so it’s always been my first love, so to speak. Got back in through some traditional waterfall project management, found my way into some account management and engagement management, but when the opportunity presented itself to dive deep into product management, that’s really where I found my passion. I think it’s been a meandering course to get here, but it’s been a real joy. I think I’ve found my people in this community.
Holly Hester-Reilly: Yes. I so empathize with that feeling of I found my people in this community.
Paul Gable: Sure.
Holly Hester-Reilly: I’m glad that you found the community. What a long and winding path. What parts of that do you find yourself leaning on the most when you’re in your day-to-day work? What parts of it are you saying, “Oh yeah, this touches on this thing I used to do?”
Paul Gable: Well, it’s funny you should ask because I think the conversation that I’ve had even as recently as today in terms of team management, as director of product management, I’m overseeing the product managers on our teams at ITX, and I think the place that I default to is a lot of navy training. A lot of the things that we neglect is how do we build rigor into making our product managers more, I think, responsible to growing ourselves autonomously. A lot of times we’re working alone together with our teams. I think Christina Woodkies coined the phrase, it may have been someone else, but I hear it from her, we have all the influence, but none of the authority. So as a product manager, it really behooves us to take time to train our people, and I think that that’s something that I view as my mission.
I think one of the things that I rely on too is just being in industry. I was in finance as a financial advisor working for a bank and an insurance company, and that speaks to the types of clients that I can help support. So I think everything relies on everything. There’s not an easy answer to that question. I think the thing that I rely on the most though goes back to probably the graphic design training at college.
I think in 2003, when I graduated, it was really just the beginning of what the web would become, and I think having seen it from the start and where it is now, looking ahead another 20 years, it’s thrilling to imagine what technologies are going to be possible. So I think everything ties together. I think that the way that I look at my day-to-day is more along the lines of taking care of the people though, that’s really what it comes back to.
Holly Hester-Reilly: Yeah. That’s awesome. I’m curious with what you said. What did you learn in the navy that helped you in your day-to-day now with managing teams and leading?
Paul Gable: Product management is a people business. UX and technology get a lot of the attention because it’s cool and it’s easy to understand on the surface, but when you think about it, we’ve got teams of developers and designers drawing ideas out of human beings to express them in ways that can be used by other human beings. So I think a lot of the things that get forgotten in a lot of the product management talks and keynotes that you hear is just there’s a lot of leadership that goes into product management that’s not just about making cool products. And I think there’s quite a few voices that have begun talking about product leadership. There’s a whole book on it.
I think the thing that I rely on with my navy background is just there are teams of designers and developers, where I led in the Navy teams of sailors, specifically sonar men and torpedo men in my division. And the way that I approach my day-to-day was this room painted to standard. It was what’s going on in people’s lives. How is what’s going on in the world around you affecting you and affecting your job?
And the way that I tried to approach leadership from that perspective and apply it to my teams today is just when teams are motivated and they feel like they’re able to rely on leaders to clear the way, to inspire them, to give them the right tools at the right time, the teams will never cease to amaze me in terms of the creativity that they will unleash. That’s what I learned in the navy, when you free people up from distractions, and I know that you’ve recently spoken to Nia about traction versus distraction, and I think I totally agree. I think that when you free people up to do the job that they’re intrinsically motivated to do, they’ll never cease to amaze you in terms of what they can unleash.
The thing is that’s where I would speak to any of the senior leaders who are in startups or companies now, the TPS report syndrome and the endless PowerPoint updates that teams find themselves in is not what they’re intrinsically motivated to do. It’s important to report, no doubt, but people got into this business to design beautiful interfaces and release cool products to the world, and that’s what I want to enable them to do with most of their time.
Holly Hester-Reilly: Yeah. That’s awesome. You’re absolutely right that it’s a people job, whether we’re talking about the people we’re working with day-to-day or the people who we’re building software for, people are at the heart of what product management is.
Paul Gable: Absolutely.
Holly Hester-Reilly: What about in your time in industry, I mean, are there parts of working in finance that you wish you could tell product managers, you should learn this, product managers who are in other industries and are coming without a finance background?
Paul Gable: For sure. And I think that it speaks to a more meta conversation about product managers who are in-house versus product managers like myself, who are in agency. I think what I would say from coming from industry into the product management community, you do have a sense of the GM, the general management, having a product manager responsible for P&L of their silos, having a product manager responsible for even hiring and firing and training, I think these skills are traditionally associated with what we’d call product management, but I think more and more I’m seeing product managers are going to be the future business leaders because you’re closest to the market, the supply chain, the development of the thing that’s being shipped, as well as the people who are doing the building. I think product managers are in a place …
Coming to it from my industry background, I think the way that you approach end users could be looked at differently. We look at user testing as this thing we do at the front and then maybe check in a little bit down the line. The products that we’re building for aren’t going to be successful unless people use them. If we build the coolest product in the world and nobody uses it, it’s not going to be a successful product.
So I think coming from industry, we see a lot of enterprise entrance, a lot of CRM, a lot of email killers, a lot of how to do this thing disruptively, and I think what ends up coming across as tone deaf is the folks in industry have external demands. There’s compliance, there’s legal, there’s marketing, there’s branding, there’s all the positioning that goes into how you develop and deliver experiences to end users.
But I think the thing that matters most and the thing that companies are going to live or die by frankly in the next decade is whether or not they’re resilient enough to trust their people. I think that’s where it comes back to. When you look at the companies that are thriving, it’s those who are empowering their teams. I think Marty Cagan has been preaching this for years and I think he’s spot on. I think the way that you make products that are going to change the world aren’t by finding this ivory tower mountaintop moment and bringing it down to the teams for them to build, it’s freeing the teams up to do what they do best.
I think that product managers who maybe fall prey to the imposter syndrome, I must be the expert, I must know all the information are going to fail. I think the product managers who have the humility to realize it’s a big world and I’m playing a role, and the fact that I have influence in it is an honor, I think that’s the way that I approach my job every day, and I think that the way that you see product managers start to shape the conversation in bigger issues than just cool products and helpful interfaces is when you start to see it’s people that were helping. If we shave five seconds off of a workflow, yeah, we optimize that KPI, that’s a good thing. But that five seconds aggregated over time means I get to go to my kid’s soccer game. And those two things aren’t often mentioned in the same sentence, but that’s what happens when you do your job.
Holly Hester-Reilly: Yeah. It sounds like you’re interested in sort of the differences between product managers who work in a place where the role of product is already sort of, I mean, I almost want to say put on a pedestal, but where people are like, this is what it means to be a product manager.
And then on the other hand, product managers who are working somewhere where the whole system is so complex and it’s one role within this complex ecosystem in the enterprise, and the product manager has to develop partnerships and relationships and human-centered understanding with all these other departments and with not just their user, but all of these other functions that are important to the products being viable.
Paul Gable: Yeah. I love that. And I think if I were to plant my flag in the conversation and say, I want to represent this thing, it’s not being talked about, I would say the underrepresented voice in product management at the moment, and I’m coming with a personal bias, and I fully admit that, but I think the agency product manager faces a different set of challenges than the in-house product manager. If you’re working for a company that’s got a product and you’re either a startup and bringing it to market and finding product market fit for the first time, you’ve got a set of responsibilities.
If you’re in a mature organization and you’ve got a platform and you’re in maintenance mode, and you’re iterating and innovating features to enhance what you already have, you’ve got a set of responsibilities, but I think there’s this third role that as an agency product manager, I’m working with UX designers and developers to build and ship products for my clients, and the end users who I’m serving are my clients’ customers.
In solving the problem there, there’s this meta narrative that I need to both be a consultant and help explain the problem and define the problem and work through design sprints and innovation workshops, and work through with architectural analysis to find tech stacks that fit the solution in the most optimized way, but also convince the clients who I serve that the solutions that I’m presenting aren’t just a contract that I’m fulfilling, that I am also worried about their position to their competitors and their offerings to their users.
I think what I would like to see more conversation around is in high end UX agencies, and I think there is a lot of data to support the UX conversation in agencies is alive and thriving. I don’t often see conversation about the product managers who help shape the ideas in the form of actual usable interfaces at the end of the discovery and UX process. That’s where my passion lies because that’s what I do every day, but I also look around for literature from those who I consider product management heroes and I don’t see much. I think it should be talked about more because I think there are more than a few of us in this role, and I think there is unique opportunity to help make this conversation more helpful.
Holly Hester-Reilly: Interesting. I guess one question that I have for you, and I am thinking about this as a person who’s both been in-house and who currently consults is how do you see this as being different from the relationship that an in-house person has with their key stakeholder or project sponsor? What are the things that we’re missing in the conversation that makes sense for the agency?
Paul Gable: I’m going to go on a limb and possibly coin a phrase, and I think what I’d call it is implied trust versus earned trust. If I’m in-house, I am an employee, I’m part of an organization, I have implied trust that when I talk to an end user, I have the voice of the company on my business card. If I’m an agency product manager and I’m trying to talk to end users, not only do I have to convince the end user that the questions and discovery that I’m trying to do supports their courses and helps their needs and addresses their pain points.
I also have to make sure that my client knows that I’m not going to go talk to their customers outside of the fold or speak outside of class. And I think that that implied trust versus earned trust is hard because I’m managing relationships at levels that I think an in-house product manager doesn’t need to think about.
Holly Hester-Reilly: Yeah. I think the earned trust is a really interesting concept. I guess as a devil’s advocate, I would say that the in-house product manager also has to earn trust that I’ve certainly seen places where it’s not given just because you have the job. But I think you’re absolutely right that there’s another level of earning the trust that’s required when you’re the consultant or the agency person. And I’m curious to hear from you because this is what you do every day, how do you do it? How do you earn that trust?
Paul Gable: Yeah. I mean trust is often talked about as a thing that you have. You either have trust or you don’t. But I think trust is better expressed as in its verb form. I think you do trust, you express trust, you don’t have trust. If I have trust, how do you know? If I have trust, I express it by giving you my email to sign up for your newsletter. If I have trust, I express it by going through a workflow to get some information back from you. I’m sharing data, I’m sharing information. Even just my engagement with you is an expression of trust.
I think when I say implied versus earned, I think I probably went too far out on the limb because it’s true nobody has implied trust. I guess what I meant when I said that is more along the lines of, if I’m coming from a team whose sole mission is to build this thing, then there’s a bankroll of trust that I can sort of rely on because you already know who I am, you know my brand, you know my product, and at some level there’s tacit understanding.
The earned trust that I have to do every day comes in the form of thoughtful communication, it comes in the form of consistent messaging, it comes in the form of under promising and over delivering. And I think as a consultant, you appreciate you can’t just get by doing the bare minimum, and I think that’s where agency product managers need to have their voice heard. When I’m looking at the kinds of communication that I do, it can’t just be the bare minimum. It has to be the best email that you receive all day.
I think the kind of updates that I do can’t just check the box. It needs to convey that not only have I heard the task that needs to be done, but I’ve thought about it, synthesized it, and now I can share something new that you haven’t thought of before or haven’t had the time to think about before. I think that the earning comes in the day-to-day. It comes one email, one phone call, one Zoom call at a time. Earning trust is not a binary. It’s not a have it or don’t have it. It’s definitely one interaction at a time.
I think that what we bake into all of our products, the way that we train our product managers is that products succeed or fail based on the trust that they build. If I give you the opportunity to sign up for a newsletter, just to use that example, and I say, give me your email and I will send you a newsletter, I have no idea what you’re going to do with that email, I have no idea what this newsletter is.
If I say instead, I’m going to give you the opportunity to sign up for this newsletter. I’m going to send it every second Friday, and in it you’ll find the most recent conversations and best tips and practices for an agency product manager to improve their practice, and by the way, here’s our most recent example of what you can expect in the future, it’s just a totally different conversation than, here’s a field, input your email and click submit. It’s demonstrating that I’m going to do what I said I was going to do.
Holly Hester-Reilly: I think you’re right. It’s so critical to be demonstrating trust every step along the way. I’m curious how you handle the client relationship side, if there’s something about being a product manager who has to manage a client relationship as well. Have you ever been in a situation, for example, where the client didn’t believe the thing that you wanted to do was going to be best for them? And how did you handle that?
Paul Gable: It’s usually never a single conversation where there’s a major breakdown, that the thing that you propose is not received or declined. I think what ends up happening over time is product management is an iterative process. You go through discovery, you go through release prep and regression with the development team. You go through market fit and positioning, and I think there’s never one point where a position is taken where there’s one side dogmatically arguing against another side. It’s always organic. It’s always a conversation.
But I do think that there are from time to time opportunities to find a problem that just does not have a solution that’s immediately available. One of the things that I’ve sharpened up on, I think, can rephrase that. That’s not the … It’s a weird word. One of the tools that I’ve developed in my toolkit is practicing the Google venture style of design sprint. Jake Knapp and team have put together a playbook that I think is scalable. We’ve taken teams through two-day all the way up to the full five-day. And I think that design sprints often avail themselves of a way to get people thinking about problems that are really hard to solve and develop hypotheses around, is this worth it now that we know?
Design sprints are, I think a tool that are often, I would say dismissed, but often assumed to be a UX thing, oh, our designers do design sprint. But I think product managers should embrace them wholeheartedly
I think the other thing that we have developed is our own style of innovation workshop, and what that helps do is create clarity and commitment around what the problem is and how the roadmap will look at the kickoff of a product. When a problem is presented and there’s not a clear scope, there’s not a clear design, there’s not a clear even tech stack, you can set aside, I would say a two-day to three-day period of time to be able to get each of the key stakeholders in the room, really sit down in a disarming way and have an honest conversation.
And I think that when you go through an innovation … Our workshop, it’s rarely about scope and budget. It really starts to strip that part of the conversation away and get into what I need to do is build trust. And the features that start to look like trust building features get prioritized at the top, and they might not be the right ones or the ones you perceive to be the right ones at the beginning of the conversation. And I think that managing client expectations, it helps when you have all voices present and it helps when you have a clear outcome in mind. If the outcome is alignment and commitment to the plan, then I’m going to give it a little, but I know you’re going to give it a little and we can find a solution.
Holly Hester-Reilly: There’s something you said that I really want to actually expand on a little bit, which is the idea that when you’re doing an innovation workshop at the beginning of a new initiative, that you might prioritize things that are high trust. Tell me more, what do you mean by that?
Paul Gable: Yeah. I think one of the things that you often hear about is our users are complaining about this feature or our designers are prioritizing this workflow. And what we often find is that the things that are either the most important from an experience perspective aren’t often, I won’t say often. The things that are most important from an experience perspective sometimes don’t align to the things that are most important from a trust perspective.
Just to go back to, I’m trying to move money from my checking account to my savings account. I’m trying to do something benign. It’s a feature that everybody has done on some app or website before, but if I think about it in a way that’s going to enable me to get the bills paid, to get the parents to their kid’s soccer games on time, I think the thing that we’re trying to prioritize isn’t how to do this thing in the most efficient for the feature, we’re trying to do it in the way that’s most trusting for the user.
And I think that when you start to prioritize the backlog in terms of trust building, you start to open up opportunities, like, sign up for this newsletter and I’ll show you an example of what I’ve done in the past. You’ll also see ways to improve security and compliance. And I think that some of the things that we often prioritize, if we’re being honest, come from the highest paid person in the room. It’s a way to just assume that there’s a truth that is going to be realized in the backlog. And I think that when you go through the innovation workshop, you have a way to challenge these assumptions in ways that you don’t often see in a day-to-day scrum ceremony.
Once the feature is in the backlog, it is the feature, but in the disarming sense of the innovation workshop, you’ve got an opportunity to really dig into why is this thing even being proposed, and is there another way to solve the problem?
Holly Hester-Reilly: In the work that you do, how is the innovation workshop different from a design sprint?
Paul Gable: In terms of, I would say chronology, a design sprint is for what’s happening now. It’s for a problem that I know, and you’re asking how might we solve this problem? In a design sprint, you’re setting two to five days aside to say, I think that there is a better way to present analytics in a customizable dashboard for a user, and you do a rapid prototyping session and validate your hypothesis, and you have instant feedback on whether or not it’s desired and whether or not you should go ahead with it.
The innovation workshop starts before that. I think it starts with a more strategic lens to say, is this the right vision? Do we have motivation? Does the team even have the capability to do the job we’re asking them to? And what does the next three to six months of roadmap look like if we were to set them loose? I would say a design sprint and an innovation workshop are sort of two sides of the same coin. Often a design sprint will come out of a workshop. We have this problem now, how do we solve it? But I think that when you present an opportunity for one or the other, I don’t think that they’re mutually exclusive. I think it’s both end.
Holly Hester-Reilly: Yeah. It sounds like the innovation workshop is used to really dive into the problem and to dive into the strategy where you’re deciding which problem is even worth attacking. That is a super critical piece of any kind of innovation process that … I do see teams that do the design sprint without having that answered first and it’s kind of a mess. That’s really interesting the way that you guys are developing those, the approach that you use.
One of the things, if I could change gears for a second, that you mentioned in our chat before this that I’d love to talk about is that software develops, it is not developed.
Paul Gable: Yeah.
Holly Hester-Reilly: Tell us more about what you mean when you say that, and why it’s important to you.
Paul Gable: Yeah. I think that the way that anyone who’s been in the software development life cycle has observed teams behaving in the past, you’ve seen the vision that you have at the outset is not often the reality at the end. We saw it painfully in the days of waterfall, you saw it when teams would take 300-page PRDs to the dark office in the back and crank out for three to six months and come back with something and find out all the changes that you needed to make at the end.
In agile practices, we started to see a different way of doing things, and most frequently, I think in my experience, you see it in the scrum framework, but I think they’re starting to show some cracks in the armor. I think what the base camp folks have done in shape up is getting closer to the more organic way that teams work.
I think that software develops, it is not developed, means to me that there is always ambiguity, there’s always uncertainty. And I think we often present … As product managers, we have this mission to drive clarity. We have this mission to make things that are in our imagination, real. That’s our, I think our core function in life. But what we experience along the way is that this idea that we’re starting out with has lots of external influences on it. It has lots of people that are going to have a voice in it. It is not our thing.
I think that when we realize that the function that we’re serving is in helping to embrace the organic nature and not force everything into a framework, it’s almost liberating. You start to see some of the anxiety just visibly fall off people’s shoulders because you have a sprint burnup, you’ve got a backlog refinement session, you’ve got UX reviews and all these boxes that do need to be checked. Things do need to be moved through a process.
But I think the framework that we’ve started to see be more successful is there’s probably a bigger cycle than two-week sprints that things happen on. Two-week sprints is enough to get some tasks accomplished, but it’s not enough to keep the vision at the top of mind. And I think the vision is really the product managers core value. If the product manager is using Jira all day writing user stories, that’s a necessary job, it’s part of the job, but I think that the thing that we lose sight of often as product management community is that the vision is what we’re making real, and that doesn’t happen in two weeks. We can start to break it out into three to six week chunks and say, this is part of what’s in my imagination that I’m going to make real, and I think that that’s where I’d like to drive the conversation. I think that that’s where complying with a road framework will just create anxiety in teams, it won’t reduce anxiety in teams.
Holly Hester-Reilly: Yeah. In many ways, I feel like you just described what happens when you have an agile product team that has no vision. They keep doing little things that are not moving anything forward because there isn’t a vision or a strategy in the first place to moving forward on, and everyone just gets a little stuck in the output instead of the outcomes.
Paul Gable: Yeah. I mean, scrum was developed in response to waterfall and I think it did do a great job. It does do a great job of helping teams move faster, but helping teams move faster in the right direction is the job of the product manager.
Holly Hester-Reilly: Absolutely. This has been really fun. Is there anything that you really want to communicate that we haven’t covered?
Paul Gable: No. I think what I’d offer to the community, what I’d say to startup founders or corporate execs who are dealing with product managers and looking for ways to help, I would say product managers are the stealth general business asset in companies. I think that product managers have more influence over a broader reach of products than any other single function. Obviously, it’s in the title as a product manager, but I think what’s often overlooked is there’s also a business sense, there’s also a technology and design sense that comes with being a product manager, and I think that expecting product managers to stay in a scaled agile framework box or stay in a framework that drives process over people, I think is you’re not utilizing your teams as optimally as you can.
So I would say for anyone who’s managing product managers, freeing them up to do their best work means removing those roadblocks and tapping into the knowledge and the insight and the market research and the design function that they have just by nature of their job. So I would say product managers are both the most underappreciated and probably underutilized business asset that leaders can rely on for driving the business to the next level.
Holly Hester-Reilly: I guess I do want to ask, how do you make that case to people that are looking to bring one of your team members on in their company? Because I imagine you must see that in the enterprises that you work in. They may have a specific vision of what product managers do and you’re trying to tell them, well, actually, you’re under utilizing them. How do you do that?
Paul Gable: Yeah. These people are probably overworked and asking me to stop talking right now. But I think that what I mean when I say underutilized isn’t that they aren’t working hard, it’s that there is capacity in the business sense of the term to inform the conversation in ways that you don’t often think of a product manager doing. And I think that one of the cases that I would make is that when you’re in say, an innovation workshop, just to go back to that theme, I think that in an innovation workshop, you’ve got a product manager leading it. Prior to the day or days of an innovation workshop, that product manager is getting so smart on the industry and doing competitive benchmarking and heuristic analysis.
And I think that the thing that you have going for you when you’re bringing a product manager into the conversation at a business level is that there’s a level of maturity there that’s out of the realm of just shipping a product and more into the realm of, I understand my market and I know that the P&L is going to be affected by the decisions that I make, and that I have that responsibility. It’s not sales job. It’s my job. And I think the product managers are ready to own that. I think that there’s a core function of the product management heart that speaks directly to what’s going to be the business leader of the future. I think the best business leaders come from product, in my opinion.
Holly Hester-Reilly: Yeah. Hear. Hear. This has been really fantastic. Where can people find you if they want to learn more about you or ITX?
Paul Gable: You can always find me on LinkedIn. is where I work, and you can hit me up on either of those channels, and I’d love to continue the conversation there.
Holly Hester-Reilly: Wonderful. Thank you so much for your time today, Paul.
Paul Gable: Thanks Holly. It’s been a pleasure.
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 methods to discover the strongest product opportunities and lay the foundations for high growth products, teams and businesses. Learn more at Enjoying 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 love the show, a rating or a review would be greatly appreciated. Thank you.