Podcast: Play in new window | Download

Sean [00:00:18] Hi, welcome to the Product Momentum Podcast, a podcast about how to use technology to solve challenging technology problems for your organization.

Paul [00:00:28] Well hey, Sean, how’s it going?

Sean [00:00:29] It’s going good, Paul, I’m excited to have Ken Sandy on.

Paul [00:00:33] Ken is a brilliant thinker. I think he’s captured a really great snapshot of where we’re at in the community today and how product managers can improve.

Sean [00:00:43] Until we heard about him for the pod here, I hadn’t heard much about him, but then I went out and did my homework and read his book. His book is incredible and we really have this opportunity to dig deep on it and I’m excited to share it with the audience.

Paul [00:00:56] Yep, put your thinking caps on.

Sean [00:00:57] Here we go.

Paul [00:01:02] Well hello, product people, welcome to the podcast. Today, we are excited to be joined by Ken Sandy. Ken is a senior technology product management exec from the San Francisco Bay Area, including online education companies, Masterclass, and Lynda.com. He’s pioneered the first product management course offered in the engineering school at UC Berkeley, which has over 400 alumni practicing in the industry. And most recently, he’s released The Influential Product Manager: How to Lead and Launch Successful Technology Products, a guide to navigating the challenging collaborative aspects of the product manager’s role. Ken, we’re so excited to have you.

Ken [00:01:39] I’m very excited to be here. Thanks for having me.

Paul [00:01:41] Yeah. To get things started, I’d like to start with an overview of some of the foundational aspects of the book. When you describe the book, you’ve often talked about how there was a lack of literature when you started looking around for how to be a product manager. And even though the book is a lot of practical tips on how to begin your journey as a product manager, I found it seems to be almost a written history of the practice over the past 15 or 20 years. So, can you tell us, what are some of the things that you learned as you were writing this labor of love?

Ken [00:02:18] Yeah. Yeah, absolutely. Well, to start with, look, there are plenty of books on product management and there’s lots of really amazing blogs and lots of great thought leaders out there. What I noticed, though, was that we talked a lot about influence as a key skill that product managers have. And when I was really trying to dig into that, I was interested in exploring, like, how do I actually teach that? How do I coach that, or how do I apply that? If I’m a more junior product manager, how would I actually think about where to start? And so what I realized was that there was an opportunity to kind of codify what it means to approach being an influential product manager in very, very practical terms. How do I go about building relationships, thinking about my role in the organization, who I should be collaborating with, and throughout the product lifecycle, what are the specific activities that I could undertake? And so what the book ended up being is sort of a fairly rich guide on tips and tricks and areas to sort of think about when you are going through to hopefully avoid some of the mistakes that I made being a homegrown product manager before anybody was teaching me anything.

Ken [00:03:32] Some of the things I really learned about that was, coming in I was a little concerned that maybe my experience would be very unique and not very applicable to the many different varieties of product management out there. Different companies have different types of flavors of product management. Obviously, enterprise, consumer, platform, hardware, are all very different types of product management. And while definitely there are processes or parts of the lifecycle that aren’t necessarily applicable in all those cases, what I did notice in talking to the various people that I talked to to research this, to gather ideas, is that consistency at which the underlying need of how a product manager operates within an organization through influence and not authority, and how they guide their organization forward primarily by setting clarity in context and collaborating well, was just a common thing that just came out over and over again. I was a little surprised by that, but in hindsight not, and I’m glad that the resulting work has broad applicability.

Paul [00:04:42] Yeah, you know, there’s one specific topic, it’s been blogged on several platforms where you shared it about the four mindsets and the axes and the way that we look at how a product manager can almost be a chameleon throughout the day. I’ve actually taken your concept and applied it as recently as yesterday. As a director, I’m leading a team of product managers and there can be a real identity crisis at times. “Am I doing the right thing? Am I focusing on the right areas and switching from imaginative to inspector roles?”.

Sean [00:05:14] You have to be able to zoom way out and zoom way in and move to the left and move to the right. There’s so much expected of product leaders and there really is no one product leader who can do it all.

Paul [00:05:24] Yeah. So I want to see some of the joy of this discovery for folks to go in and read the book itself, but could you give us a synopsis of these mindsets and sort of how you view that in a nutshell?

Ken [00:05:35] Sean and Paul, you’re so right. There’s this aspect of product managers that we’re expected to do so, so much, and generally, because product managers are seen to be problem solvers and they need to work across the organization, they’re exposed to so many parts of the business. There’s no chance that we can possibly do it all. And our innate strengths are going to be our innate strengths; it’s just, we can’t change that. And so I constantly running to people who doubt themselves, right. “Should I be doing that? Should I be getting into the technology discussion? Should I be up on stage talking about my product when really it’s all that work that the team has put in that’s really got this to where it is?” And so that’s not natural, folks. You know, that kind of imposter syndrome kind of feeling is very, very natural.

Ken [00:06:23] What I’ve found with the four mindsets is when you make those things explicit, you begin realizing that you have some key strengths and there are other areas that may be your blind spots. And importantly, you also realize that you might need to compensate for other people’s strengths. So you might have, for example, a founder who is very visionary and very, very powered by what it can be and just naturally an evangelist and naturally a big thinker. So you need to ground them. You need to be able to ground them in the data that they need to make better decisions and you need to make better decisions. You need to challenge them and make sure that those assumptions are being surfaced, not because you want to undermine them, or tell them that they’re wrong, but to make sure that their idea has a bigger chance of success. You want to battle harden it.

Ken [00:07:10] So in terms of the framework, it’s pretty simple, but it’s worth going and looking at it because I think it pretty quickly kind of shows itself for what it is, which is a very simple two-by-two matrix framework. But on one end of the scale, imagine on the horizontal axis you’ve got on one end this imagining the possibilities. It’s that very much being out there and suspending the reality and the every day and thinking what could be. What are the different kinds of ways we could tackle problems? And then on the other end of the scale, you have to be grounded in reality and inspect what you have, the data you have, the reality of what it’s going to take to get things done. And then cross that with another kind of vertical axis. And on one end of the extreme, you have this divergent thinking of the possibilities, the broadness; you don’t constrain your thinking. But on the other end of the scale, you need convergent thinking because you’re not going to have focus otherwise. You’re not going to be able to really zero in on and get to the level of details that you need. Now, when you overlay those two axes, you end up with basically four quadrants. And the four quadrants I like to call explorer, analyst, challenger, and evangelist. And all of that work is valid for a product manager. Every one of those things. Now, it doesn’t mean that you’re going to be great at it, but it does mean you shouldn’t steer clear of it. You want to kind of get in there to really make sure that you’re practicing those techniques, getting better at them over time. But if you don’t do it, no one else is going to do it for your product. And so go for it. Really try to actually embrace those different…

Ken [00:08:54] I can describe just a little bit more about each of those mindsets just so you understand kind of what I mean in sort of tangible terms. On the explorer side, imagine that you’re in a situation where you really want to discover new possibilities, discover new customer problems, seek out and embrace new ideas. How often do ideas just seem distracting to us initially? But we should be welcoming those and welcoming them wherever they come from: some stakeholders, junior engineers, even customers. In this mindset, you’re always trying to understand the context around the business and the customer, understand the problem space, and then ideally you’re seeking out multiple potential solutions before you focus on one. And that’s that explorer mindset.

Ken [00:09:38] In the analyst mindset, you’re hunting for new data and insights, kind of like a detective. You know what you’re looking to effect in terms of metrics, but you’re cutting and dicing and slicing, then segmenting it and trying to understand more about what’s actually going on. You’re always doing your own or participating in customer research and making sure you’ve built that empathy firsthand. And you don’t just focus on your solutions. You really get to understand the business and learn from the customer. And ideally, you’re as self-service as possible with your own data analytics.

Ken [00:10:14] On the challenger mindset, it’s a subtle psychology change. When you restate your ideas in terms of a hypothesis, it allows you to focus on the problem and not your personal feelings. It makes you err on the side of smaller iterations and constantly be validating. You’re looking for asking the hard questions, uncovering assumptions, and you’re actually embracing dissenting voices. You actually seek out those who are unhappy with your product or the people who criticize, maybe, your product or are unhappy with what you’ve delivered in the past and you try to learn, “what might they be saying that I do not?”.

Ken [00:10:49] And then finally, in your evangelist mindset, and I find this to be one of the hardest for product managers, particularly those who like to be in the background and work the strings a little bit, to be ready to focus and motivate their team and build broad-based support for the path that they’ve chosen. This requires constant, like over-communication, education on what outcomes you’re striving for, and sort of an infectious optimism and enthusiasm for your product. Now, this is why you’re being realistic. And to your point, the chameleon point, jumping around and still like looking at how this might go wrong or, “what data do I need to gather to build out,” that you’re still really showing that ownership, and importantly, you’re kind of losing some ownership to your team. You’re putting them first and making sure their work is celebrated.

Sean [00:11:42] I think that’s a really important point. The pattern that I see with really successful product leaders is they’re really good at that. They know how to pull out the nuggets of, like, what we’ve found to be successful and celebrate their teams and their team’s contribution, their people’s contributions. That’s amazing. Here’s a little zinger for you. So this reminds me of lots of personality profile tools that are out there, like DISC ISP; there’s a bunch of them. And you take this little quiz online and it tells you what quadrant you’re in. And what you’re saying here is that, and I believe this, by the way, all those personality tools, I have my own theories about them. I think they’re all super useful but I also think they’re all wrong because they’re not taken in context. And it’s the context that really matters, especially in the product space.

Ken [00:12:26] Right.

Sean [00:12:26] So what my observation here is that you’ve identified a pattern that’s really useful in the product space to be thinking about, “where am I right now? Where is my product, which one of these quadrants am I potentially in or where should I be,” so that you can be slightly more purposeful about how you’re spending your time? Because you like you said, like we all said at the beginning, you can’t do it all. You just can’t. So I think this is a useful construct. Paul just popped a little link into my chat here for the checklist that you have on your website, influentialpm.com. So we’ll put that in the notes for the podcast audience for figuring this stuff out. So thanks for sharing that with us.

Ken [00:13:05] No problem, and I’d love to say something about the personality test versus this and is I think one of the key differences is I believe that these are skills that are learnable. They take practice. They’re not innate necessarily. I’m an introvert. Yet I’ve had to learn how to be an evangelist and I’m on a podcast. So that’s something that you have to learn and practice for sure. But unlike sort of personality tests, they’re very much things that you can get good at.

Sean [00:13:33] For sure. You know, again, even with DISC, I think that’s the key point is they help you to kind of see the world through a lens that gives you a little more context in terms of how to communicate and how to organize things so that you can be more purposeful with your decisions. Because I think one of the most important decisions we make as product leaders is what to spend our time on next.

Ken [00:13:56] Absolutely.

Sean [00:13:58] You’re never done.

Paul [00:14:01] I see so many clickbait articles for introverts asking them if they want to become better public speakers. For once, as a fellow introvert, I’d like to see an article that says, “are you extroverted? Here’s how to be quiet and self-reflective for a minute.”

Sean [00:14:14] I think he’s poking at me right there, Ken.

Paul [00:14:17] Just a bit. I’d actually like to steer that a bit into my next question, which is around the concept of psychological safety because when we’re talking about teams and decision-making specifically, you said it before in some of your chapter headings, product managers are people, too, right? We’re bound to make a mistake at some point. And part of identifying what role we’re supposed to assume also includes us having tools in our toolkit to identify what cognitive biases might be affecting our decisions. And we’re getting information from a lot of different sources: from our customers, from business stakeholders, from team stakeholders, from technologists, UX, you name it. How can we, as product leaders, ensure that we’re collecting and funneling through lenses that give us the right information in a balanced way?

Ken [00:15:10] Yes. Well, nothing challenges P.M.s more than trying to prioritize a bunch of competing initiatives or features, saying no to stuff, which is hard, and it’s not easy because these are not easily compared against each other, right. So there’s a lot to unpack in this one. The first thing, to validate what you just said, is that everyone has a different lens on the business. It’s like that proverbial elephant where, you know, one stakeholder might be touching the trunk and the other at the tail and no one really figures out that it’s an elephant. Like your UX team sees the issues driving lower customers foot satisfaction, and they’re bringing those up. Your sales team numbers are off and landing that next big client is going to be much easier if you just gave them some more product features to sell. From the perspective of founder, fully realizing a strategic vision has never been so far away as just scaling the business and all these urgent issues are coming up.

Ken [00:16:03] And so how do you take all those inputs? The first is, is that I’ve actually discovered that the prioritization methodology that you use is not actually that important. I mean, you want something that’s culturally appropriate to your organization. In some cases, it’s super qualitative and kind of based on collective wisdom of your team. And that can actually be as accurate as going away and doing deep business analysis and business cases, particularly on things you don’t know very well that are guesses, that are sort of leading to the illusion of quantitative precision. So what you use to get there is less important than the fact that you collaborate. And the prioritization, the process is actually the easy part, but it’s that collaboration with a broad section of people and the process of getting everybody on the same page is the hard part.

Ken [00:16:52] The first is, and we may touch on this later, I’m not sure, but you have to work against a natural authority bias. So you have to work against the highest-paid person in the room.

Sean [00:17:03] The HiPPO.

Ken [00:17:04] HiPPO, as my friend Rich likes to mention a lot. It’s so important to be very much respectfully independent and having that mindset. And look, you are empowered as a product manager to make the prioritization decisions about the product and the business. You don’t do that in isolation, clearly, but you need to steward it through a process by which all voices are actually heard. And so taking pride in and taking the bull by the horns, so to speak, on that is one of the things that’s invested in you by the definition of your role and being ready to say, “that’s how I add value to the company.” And actually, that is how you add value to the company. Saying no to the wrong things is adding a ton of value to the company.

Sean [00:17:49] I always say, you know, objective prioritization is impossible. If it was easy to set up these rules and say, “here’s how we’re going to prioritize features, we’re going to follow this ruleset, done.” You would need a product leader.

Ken [00:18:00] You’d need an AI algorithm.

Sean [00:18:01] And everybody would be building the exact same thing. It just doesn’t work.

Ken [00:18:04] Yeah. You wouldn’t discover new ways of doing differentiation and delighting customers with things that they don’t even ask for yet. So, you know, I strongly recommend that instead, you think about this in a couple of different ways. The first is that your first goal should be to agree and align on the goals. You’re never going to get consensus. That’s the other thing you’ve got to recognize. You’re never going to get that. But if you can get the discussion around and abstracted away from specific requests that might be coming in or initiatives to the different dimensions and, “what are we trying to optimize for in the business right now? Is it revenue, margin efficiency, customer satisfaction? Are we going up to some strategic goals? Do we have some specific milestones in our business that we need to really be cognitive of?”

Ken [00:18:52] Now, none of those are going to be forced ranked necessarily and the answer might be, “we want a bit of all of them.” But you want that conversation to collaborate and align around what kind of goals we’re trying to optimize for. And the second thing is, how do we make decisions around those evaluation criteria? How are we going to agree on the relative importance of those goals so when we do look at the initiatives, we’ve got objective criteria by which we can discuss how we’re going to arrive at the decision. And then once those are in place, you now have a framing method: the criteria, the data that you require, the goals that you’re trying to optimize for. Now you can actually put up against any incoming request or anything you’ve discovered or an idea, if you will, in the business, and then you can actually put that up against that framework and see what ultimately makes it out in terms of priorities. And that is the key and it’s collaborative. So everyone understands the criteria by which you’re going to ultimately make those decisions. Now, you may fail. You may get trumped, OK. That happens. If you can’t agree on the goals, you’ve got no chance on anything else. So that’s your best course of action of actually getting to a point where everybody is objective enough around what should get worked on.

Paul [00:20:13] Yeah, and this collaboration requires trust. You need to have this concept of constructive conflict. The team needs to be able to challenge each other in an environment where they know they’re safe to speak up and speak their mind. The way that you describe it in your book, it reminded me of life insurance, right. It’s very difficult to get life insurance when you’ve already found out you’re terminally ill. You haven’t built up that bedrock of trust. You can’t have that constructive conflict. You can’t have those moments where there’s a bit of tension, where there’s some pushback and, you know, ideas get challenged. And I find it’s very difficult to maintain the status quo, day-to-day getting things done, and still keep, you know, a team-based environment. What are some practical ways that we can build trust on our teams? Is it the product manager’s job to do that?

Ken [00:21:01] Building trust on our teams, well, yes, it’s our responsibility to create an environment under which trust can be built within the team. And it’s our responsibility to build our own relationships with team members and stakeholders. And those two things might actually go together because you’re kind of leading by example. You could build all the trust in the world, but if your team doesn’t trust each other, then it’s going to break down. So you do need to solve for that. Look, it comes back to, you’re responsible for your product to be successful in market, which requires it to be delivered. All of those things are dependent on other people. So you need to figure out how to make that work and that’s a big job. So great product managers understand that they own that whole piece, including the interpersonal piece. You should build trust before you need it. I like the idea of maybe being trust being something that you lose rather than gain. But I’ve often found that, no, you invest in trust and you have to then use that trust to create environments where it can get uncomfortable. And you won’t get there unless you’ve got those strong, trusted relationships. Look, I don’t want to oversimplify it because I’m the first to admit that I failed in some key stakeholders in building trust and I’ve vastly succeeded in building trust where I didn’t think it was possible. So it comes down to knowing, first of all, that you don’t want to wait until that first moment of having to deal with an issue or ask a stakeholder to do something on your behalf or to make a difficult tradeoff to start building trust.

Ken [00:22:34] So identify your stakeholders and start actually reaching out. Now, stakeholders are not just senior people. They’re going to be some architect that maybe you don’t even know exists in the organization. It could be, and I will absolutely subscribe to this, it could be the head of I.T. that can fast-track getting that software license that you needed because you forgot about it. Like, it’s across the board. It can be executive assistants who control calendars and you can get that meeting that you need to take. So don’t overlook the broadness of where you need to build those relationships. It’s not just senior people. That’s first.

Ken [00:23:10] Second, I’m maybe oversimplifying it, but I think if it comes down to frequency of some kind of quality interaction plus your reputation is following through on your commitments minus your perceived self-interest. So, to break those down a little bit more, your interactions don’t have to be deep, long meetings, high content. They can just be frequent touch-ins to make sure that the communication is flowing. You are building that kind of personal relationship as much as the professional one. There’s a little bit of vulnerability there. You’re are sharing things about each other. Like that frequency, if you do it very infrequently, it doesn’t matter how great that meeting went if it’s six months before the next one, that’s not building trust.

Ken [00:23:55] Secondly, on the follow-through, it can be as simple as, “you said you’re going to email me afterward with your next steps and you didn’t do it.” Well, you’ve lost a lot of trust there. So it’s the little things that can really matter. Now, if you commit to some big objective and something happens and that objective can’t be reached, people understand that. But communicate that and explain what’s going on. Don’t withhold information in the hope that there’ll be a Hail Mary right at the end of that. So communicate, follow through. Keep people informed. And then the self-interest is really how you discuss and operate in those relationships. And probably the easiest way to illustrate that is, every time you go to talk to a stakeholder, you’re asking for something. You’re probably in the self-interested land. If you’re asking them about their goals and how you can help, you’re probably in a much better territory.

Sean [00:24:47] So Paul touched on the psychological safety, we’re kind of heading in that direction anyway. I know that’s something in your writing, in your talks, in your book as well. And we had sort of the godfather of modern trust, Stephen Covey, on our podcast a while back. I remember him saying, “you can’t get trust if you don’t give trust.” So somebody’s got to be the initiator and you invest in trust and you get trust back. So talk about how important that is in the team building and the collaboration. This seems to be the theme that you’re pushing on here, this collaboration theme.

Ken [00:25:18] Yeah. So let me start by maybe connecting back to the constructive conflict point. So the greatest value interactions are those that quickly identify the points of contentions and get to the decisions that need to be taken. And strong psychological safety, which I’ll kind of define a little bit more in a minute, really allows for everyone to put their cards on the table and kind of get down to it. So that trust can lead to that high sense of, “I can speak my mind. I can point out what’s wrong and what’s right and I’m not taking a personal risk on that, either because I may be speaking truth to power or my team might think I’m ridiculous because I’m saying something that just doesn’t sound right or is not the way we would have normally thought about it.” So essentially, psychological safety is the ability to be kind of wrong, if you will, in an environment. And that’s my definition a little bit, but having that environment in which I can be wrong and I’m not going to be ridiculed for it. I can say something and people are going to take it seriously. And more so, they are prepared to share their ideas and when we talk, we can actually even critique those and give each other feedback about those and it’s OK. It’s not taken personally. We’re actually really about the ideas and making things better and we can try to get to decisions.

Ken [00:26:43] It’s not always compromise either. So I don’t want to make it sound like it’s always about consensus and compromise. It’s actually about getting thorny issues on the table and being out to kind of deal with them and work them through. That’s what psychological safety is. Now with psychological safety, I mean, my favorite study on that was Google’s Project Aristotle, which I daresay many people have dug into. It’s not perfect. I mean, it’s obviously very Google-centric. A lot of teams, a lot of good data, and there’s definitely some aspects in there. But the fact that how comfortable do you feel taking risks on the team without feeling insecure or embarrassed? That rates higher than the dependency of my teammates, my ability to hold them accountable, the structure and clarity of my goals, and my role, even more so than the meaning of the work and the impact of my work. Like the fact that I can actually be in that environment is as strong, and if not a stronger indicator, of a high functioning team than those other things, which to me is astounding because we spend so much time on goals and OKRs and trying to get RACIs and clarity around your roles and so little, really, in creating that very psychologically safe environment, which I might add, is not secure or easy because you’re actually encouraging conflict. But it’s the absence of that personal feeling to it.

Paul [00:28:10] Speaking of being vulnerable, I do have to give credit where credit’s due. On influentialpm.com, you have a weekly summary TLDR email template that you shared, and I have adopted that wholeheartedly and gotten a lot of positive feedback from it and I owe you a thank you for sharing that template on your site there. But it goes back to that consistency, and trust isn’t one Hail Mary every six months. It’s a weekly summary email and being able to count on getting those pieces of information out. And like you said, projects get delayed, budgets get overrun. It’s going to happen if you’re in the game long enough. But if you’re communicating and you’re allowing for that conversation to happen, people get it and you can work through challenges if you’re communicating. So it’s been really helpful. So thank you.

Ken [00:28:55] That’s really great to hear. I really do like my templates and it’s a way of really making things very practical so you can pick it up and actually try it. If it doesn’t work for you, it doesn’t work for you, but if it does work for you, that’s fantastic.

Sean [00:29:10] Cool. I have one last thing to talk about. You talk a lot about, in your book, biases. And I think its an under-talked about thing in our industry. We use them a lot when we talk about nudging users, but we don’t apply them enough to our own behaviors and our own teams and I think you’ve done a really nice job of laying out some of the common biases in your book. So I encourage readers to really take a hard look at some of those things. When I read the book, I’m thinking, “oh, yeah, I did that. I did that. Totally did that. Still do that.” You know, and if we’re not purposeful about it and if we don’t understand the biases, it’s hard for us to act on them or to identify them in others and to tease him out. So I think this is going to be a very important skill for product leaders going forward to really dig in and understand the biases that are there, especially things like selection bias or survivorship bias is a really big one, right. So when we look at our user base, we’re basing all of our data on the people that survive. Well, what about all those folks that didn’t, you know?

Ken [00:30:03] Yeah. The tools get better and better and we get more and more data from our existing user base. We’re actually getting even more survivor bias over time. So as the tools are actually getting better, we’re actually getting worse at certain things.

Sean [00:30:17] So a quick question we ask all of our guests. How do you define the word innovation?

Ken [00:30:22] Well, in keeping with sort of my theme, I find innovation to be about the process of bringing together people with different points of view and different backgrounds and being able to look at problems in new ways and sharing that context. And then from there, being able to create collaboratively, together, solutions to those problems that may not have existed before or may not have been obvious before. Innovation can actually occur in very, very simple ways. And then, obviously, very big what we might term innovative products. But I see innovation every single day when I see teams like a designer, engineer, and product manager collaborating together and looking at a problem and what the designer would have done and what the engineer would have done and what the product manager would have done would have not been very innovative. But when they brought their perspectives together, there was something magical that happened that just; it’s just better. It just feels better. It looks better and it seems to work better on the technology side as well. And it actually solves a business and customer need. That’s my viewpoint on what innovation kind of looks like.

Paul [00:31:38] That’s great. So the last question that we have is, what is inspiring you? Obviously, we’d recommend The Influential Product Manager to anyone who’s enjoyed this conversation so far. But what are you reading? What is inspiring you? What book would you say a product manager should probably have on their shelf?

Ken [00:31:54] Okay. That one could be an interesting one. I’m just thinking about my bookshelf. If it’s like I won’t call it a specific book, but I obviously would love you to have product management books, including my own on your shelf. But I don’t actually think that’s necessarily what I would want to see in a great product manager on their bookshelf. I would like to see books that perhaps are a little bit more on the like, history, music, cooking, something that kind of is very creative or gives you that kind of like anchor that gives you maybe longer-term perspective on what it is that we’re trying to solve. In my case, I love alternative history and so I have lots of books on just things that just, the way the world has worked and things like… what’s the book? There’s a book called The Ghost Map of how they tracked down cholera. And I was just like, “these are problems that were solved by very innovative, creative people and they applied themselves in certain ways and I love those stories because that helps me think of, how do I be a better problem solver?” So anything like that is always good. And then to be empathetic in our roles, it’s helpful to get some books on design, or if you’re coming less from a technical background, not being afraid to pick up a book on, say, Scrum or project management or user stories and trying to understand a little bit more about what that world looks like. So you build a little bit more empathy, you build up some vocab that you can actually have better conversations with. So I hope that answers your question but it’s sort of maybe a little bit of a curveball on the answer, but that’s kind of I think very strongly about that.

Paul [00:33:38] That’s fair. That’s a great answer. I have had a blast talking to you, Ken.

Ken [00:33:42] Oh, thanks.

Paul [00:33:42] Thank you so much for taking the time to share your insights with us. We’ll definitely look forward to seeing more from you when the conferences start back up or. We’ll definitely hope to have some time to get to hear more from you in the future.

Ken [00:33:55] Well, look, it’s been an absolute pleasure. I really appreciate the opportunity and love what you’re doing in terms of reaching out to our community and getting great information out there. So thank you.

Paul [00:34:05] Absolutely.

Sean [00:34:05] And I want to say thank you, Ken. You are incredibly gracious and generous with the knowledge that you give back to the industry with your templates and your website and your book, very practical advice. The third or fourth time you’ve heard it in this podcast, but I really enjoyed reading it and I know the audience will as well. So thank you again for joining us, Ken.

Paul [00:34:23] Cheers.

Ken [00:34:23] Thanks very much.

Paul [00:34:27] Well, that’s it for today. In line with our goals of transparency in listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get so please leave a comment or reading wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch, and inspire the world, just like you’re doing. Thanks, everyone. We’ll see you next episode.