People Driven Development (with Sam Higham from Glean)

Michael Luchen

As practicing or aspiring product managers, we’re constantly bombarded with certifications and specialized training that we are told is essential to our craft. Following a tailored process to build products is the key to success, or so we’re told. Keep listening as today we’re going to dive deep into this space. Are the certifications and tailored processes as necessary as they seem? Or is there something better?

This is The CPO Club podcast, the voices of a community that’s writing the playbook for product management, development, and strategy. We’re sponsored by Crema, a digital product agency that helps individuals and companies thrive through creativity, technology, and culture. Learn more at crema.us. Keep listening for practical, authentic insights to help you succeed in the world of product management.

Today’s topic is something that strikes close to my heart and product management. And I’m privileged to welcome Sam Higham to the show to talk about it. Sam is a user-focused product leader with a career-proven to change product, process, and people for the better. He thrives in both the detail and the directional aspects of making products work from their functional routes to the commercial expectations that they deliver.

Sam possesses limitless interest in the way technology and psychology interact in consumer journeys, supporting teams to identify ways to merge and fine-tune the two in order to deliver the best possible outcomes. Sam is the VP of Product at Glean, a note-taking solution for learning and productivity.

Glean’s note-taking solution records audio notes that you can capture and learn from information more effectively. Sam also serves part-time as a product coach and a product management trainer for Mind the Product, where he helps guide individuals through the product management career that they want.

Hey, Sam! Welcome to the show.

Sam Higham

Hi, thanks for having me.

Michael Luchen

It’s good to have you here. So, just to kick us off, can you share how you got to where you’re at today?

Sam Higham

Yeah, sure. I guess in short, lots of trial and error. I think like a lot of product people, I kind of fell into product management over the last sort of 10 years or so.

I think I’ve done pretty much every single role you could do in kind of a product development sense apart from codes. And even then I’ve tried my hand at pretty bad APIs in the past. So, yeah, I guess I formally started kind of working in a product management center about eight years ago, although not kind of by the title.

And then kind of over, that period of time, continually tried to refine what it means to be a kind of product person and how you kind of get better day-to-day. And I think a lot of that was really down to try to figure out well, what is product management? And it’s a question I still ask myself every single day, to be honest.

Michael Luchen

Yeah, what is it? Yeah, it’s a pretty big question.

Sam Higham

Yeah. I think to me it comes down to just trying to find the best way to create value given kind of context of where you are. Given any constraints that you have and the individuals that you’re working with. I think a lot of the kind of puristic product management approach is fantastic, but it doesn’t necessarily take into account the circumstances of, you know, the 95 plus percent of organizations that don’t have everything it needs to do it by the book.

I think that’s where some of the challenge have stands from. You’ve got a lot of great aspirational information out there that say, here’s how you could do product in a, you know, perfect laboratory environment, but none of us really work in that case. And none of us have, or very few of us have the funding needed to actually kind of apply all of these end-to-end things in the perfect way to make it happen.

And so a lot of it is around kind of iterative development, you know. It’s thinking about not just on iterative development in the software sense, but in the process sense, in the kind of collaboration sense. All of it is continually working back and forth.

Michael Luchen

Interesting. So what you’re talking about is that so much of, kind of the documentation, so to speak. The education around product management is around, Hey, be iterative around product development. But what you’re also talking about is you got to be iterative around the process and the people based on the environment you’re working in.

Sam Higham

Yeah, exactly that. I think, so much of it forgets the fact that we, as humans, are very messy people.

You know, we’re not these perfect package individuals that can follow everything to the T. And we don’t all share the same knowledge, and so I think when you try, as a product person, to come in blind, and I’ve done this myself. I’ve come into a role and just said, Okay, right. We’re going to practice product management, and this is the framework we’re going to use and everything’s going to work perfectly.

And I haven’t even taken into account, Okay, well actually, do my colleagues even understand what we’re trying to achieve here? Do they even get what or why this approach might be a valuable way to do things? How far off are we from kind of talking that same language? And I think if you don’t take that first step, to go, Okay, well, everyone that we’re working together, what’s the best way for us to do this?

I have that open conversation, then you can bring your own experiences. You can bring your own techniques that you’ve tried and worked in the past and try to apply them. But don’t expect that to just happen and work. And sometimes I think you can end up being kind of blind by that well, you know, it works at Google. It works at Amazon. It works at wherever without thinking, Well, does it work for us?

Michael Luchen

Yeah. Yeah. And I think what’s really fascinating is like the more I learned about the inner workings of like Google or Amazon it’s, I mean, maybe I think a lot of those stories that we tell ourselves or from like the early days of when they were kind of like the poster child of startups and how they work.

But now they’re massive enterprises that have so many different teams and so many different ways of working, even themselves.

Sam Higham

Oh, yeah, definitely. I think, actually, it’s a really nice point. A lot of people talk about the best experiences they had at that startup level. And I think that’s because you’re in a space where everyone understands what you’re trying to do, and you’re all trying to figure it out together. You all have that common language. And so you’re willing to have the open conversation very quickly about what you can do.

And I don’t just mean in terms of the product development people, not, you know, design products engineering, I’m talking sales, marketing, operations, everyone is in that same space. And so, you’ve got that really nice tight feedback loop as an organization. And I think the challenges and where process kind of comes in and you start to get frameworks involved is as you get bigger and bigger, and then you start losing that because you’ve got your own internal way of talking about things that actually reduces the accessibility for other functions to collaborate effectively, because your approach is almost so far ahead.

So far beyond, like what other people might understand about your function. If you don’t continually do that, Okay, well, here’s what we’re trying to do. Here’s why we’re taking this approach, kind of feedback loop. You lose out, and then all of a sudden sales aren’t engaging properly with the product people and product people aren’t engaging properly with the engineers and, you know, everyone is talking about how great their function is, but not how great the organization could be together.

Michael Luchen

It sounds like a lot of work.

Sam Higham

It is right. And that’s it, right?

Michael Luchen

Yeah. Yeah. And I’m kinda, you know, I’m thinking about our listeners and many of which whom I think might be at some of these larger organizations that aren’t quite the startup and, you know, how do you guide those folks to work in that environment where they really have to be able to champion process, but maybe they don’t feel like there’s that space, maybe there isn’t that space available for that?

Sam Higham

I think start, end small as, as was everything. I mean, a lot of the, the very good fundamentals from things like the Agile manifesto actually, I think is still as valid now. You know, starting small and thinking about what’s the leanest experiment you can run as a group within your control. And I think it’s also being comfortable with what is within your control. Right?

I think sometimes you can get very frustrated when you try and change too much, too quickly and you don’t actually, you’re never gonna win and you’re never gonna win that battle because you’re saying, Okay, right. I’ve now heard this one person. His podcast saying, right, we should all do these experiments and collaborate more effectively together. And I’m saying it because that’s what I’ve heard, rather than actually saying, Okay, well, let’s say you work with one development squad, but hopefully it’s a nice cross-functional one.

You’ve got designers, you’ve got engineers, you’ve got product people, and just saying, Okay, well what could be some experiments we run together that mean we were more effective? And then how could we bring in another function into that collaboration? And then start demonstrating through that kind of showing of the approach and understanding, actually, that might not work. Like it may not work and you have to understand why it hasn’t worked and then start having those conversations.

And it, it is a lot of effort a long way away from what you think might be the best way to do it. The more time it’s going to take to get there, but doesn’t mean you shouldn’t start. And the best time to start is today, right? Like that’s the only thing you can do.

Michael Luchen

Yeah. Yeah. I love the focus on starting small and that’s something that I’ve seen to be successful as well is, especially working with various clients that are building their own products. It’s like, we always are like going in and out of environments that are changing on process. And so we’re always kind of going through this challenge, and what we found to be really successful is if you really narrow in and say, Hey, we’re going to try this like two week experiment.

And it’s like, you’re selling that. You’re not selling a way of working for the next year, but you’re really planting the seeds for that. But what we’re really selling is this two-week experiment. Just trust us, let’s go through it. Let’s see how it is and then that’s where you’re able to prove value and then start to introduce other things as well.

I’m curious as well you know, one of the things we talk a lot about as product people are just of wearing a a coaching hat. Is there a coaching responsibility that plays into the success of this in your day to day?

Sam Higham

Yeah, definitely. And I think, coaching for me is just making sure that you’re kind of asking questions more than giving answers. At the top level, it’s much more around how do we find answers together? And that tends to be by asking better questions. A lot of the stuff that I do day to day, whether working with kind of individuals as part of a team or individuals in terms of an actual coaching conversation. It is about just asking questions of, Okay, well, you know, what sort of things have you considered here?

Why are you considering those things? Have you considered other options? And if so, you know, why have you chosen this one? Have you thought about how you might involve other people in this process? And you’re trying then actually to get them to build the habit of asking the questions themselves and asking others and everyone kind of going in methodology.

And I think also from a coaching point of view, try and get into that mindset, you’ve got to be comfortable with being more the shadow of success than being in the limelight. So you almost got to be like happy with people winning because you’ve been at the sidelines helping them but never actually acknowledging that you were part of the process, because it will take away from their own development.

If it’s like, oh, Well, actually that was Sam in the background, coaching that individual on doing that or coaching that team. It should be no, the team have overcome whatever problem it was themselves, so the team have got to that improvement. And actually, if anything downplay my involvement completely, I almost don’t want people to know that any of these conversations have happened or that we’ve spent hours and hours going through various different ways that, let’s say, a presentation could be delivered.

Like, No, that person owned that presentation. They were the one that did it, and they were the one that won. Like, the fact that I might have asked some questions that help them get to that stage irrelevant.

Michael Luchen

Yeah, that’s really well said. And I think it also kind of goes the other direction as well. In terms of, failures and letting folks fail through that coaching so that they can learn firsthand, Whoa, that was a really challenging situation. But now I know and I’m empowered uniquely on how to see my way through it next time.

Sam Higham

Yeah, definitely. I think sometimes we’re scared to fail and I think that sometimes there’s some of the challenges in organizations where there’s almost this unseen sense of culture where failure shouted out about too much more.

And what I mean by that is, let’s say this, what it could be quite a small bug in a piece of software. And all of a sudden there’s emails going around and one of the most powerful executives in an organization saying, When’s this going to be fixed? Oh my god, this is a disaster. And what you don’t realize is that the direct consequence of that is that all failure, all minor changes, you know, people are scared of those.

And so they’re less willing to take risks. They’re less willing to actually try anything less. They be the ones that are called out. It’s the same with things like, design crit sessions where there’s some really good practice around demonstrating design open and afternoon, early and getting people to collaborate.

But if the criticism that comes into their sessions is over the top, quite direct to kind of the designers capability. All of a sudden, they’re not going to show as often or as early, and you’re losing all of that power of learning and failing and actually kind of getting to that mindset. I think as a leader, you have to be really conscious of that and you have to help other people not do those things, as well.

I think quite often that those little unseen senses can be really harmful for getting anywhere close to the positive mindset you want, where people are willing to give things a go and treat them as learning opportunities and not failures.

Michael Luchen

Yeah. Yeah. Well said. I think that’s something that I’ve recognized a lot is it’s the leaders of the organizations who set up the structures for folks to be able to have that safe ability to fail and learn from those failures versus having all the fear of failing and thus not learning from it. And that’s probably one of the most challenging things to do, because as a leader, it’s like, you’re thinking, Well, I don’t want my organization to fail.

So perhaps for the leaders listening, what is the value for the results of my organization and letting my product people kind of fail their way to those results, so to speak?

Sam Higham

It’s a great question. I mean, hopefully, the actual results kind of seed out. You can see the teams that are comfortable, confident, and empowered. Actually, being proactive around, Okay, here’s this experiment we ran that proved inconclusive or incorrect.

But what it now means we can do is this other thing, and being kind of quite active and outspoken around, why they are choosing to take these risks and what they’ve learned around those things. I think it also, genuinely, it comes down to velocity. So, when people talk about velocity, they talking about story points.

I don’t really mean anything like that. Well, I mean is, people’s ability to work comfortably and confidently and quickly because they’re not mentally fearful of having to go and get an additional layer of sign-off or having to triple check that everyone has signed on the dotted line that it’s okay for them to run this really small kind of experiment.

But the opposite of that is actually having a conversation with your teams to say, Okay, well, here’s the level of empowerment I want you to have. Here’s where I would like us to have a conversation about whether we should go forward to this. And here’s where I think I need to still take the onus of decision-making. And that’s about risk, right?

It’s just about agreeing what’s the risk appetite for an organization, and at what level do you, right, if you’re going to say, Okay, I’m going to make a life change to our entire database. And I’m not going to kind of close on their website and there’s a high chance it’s going to fail. We might not want your product team to make that decision without you, but if it was, Okay, I’m going to run an A/B experiment on a button and it’s going to be to 10% of our user base.

And the worst that can happen is that conversion is, drops by 0.01%. Well, then you probably want those teams just going ahead and doing those things because the iterative improvement far outweighs the negative, potential impact.

Michael Luchen

Yeah. Yeah. So almost bit of a working agreement between the product team and the leaders.

Sam Higham

Yeah. And I think even then there’s still some room for you know, having coaching conversations where it was too high or too low. And actually, you know, you want to then just have that active conversations to actually, because of the risk involved in that next time, let’s make sure that we just catch up about it.

You know, it doesn’t have to be more complicated than that.

Michael Luchen

Yeah. Speaking of complicated, I think one of the things that’s really apparent talking through all this, it’s just how complicated and messy and ambiguous that product is. And, just listening to your perspective on product development, which I agree with, is that there’s not really like one true process or framework to rule them all.

I can imagine just for product manager getting into this. It’s like, Well, where do I go? Like, do I start with a process? Do I you know, go to the team? Do I go to the leaders? Like, what is my compass? How do I navigate through this?

What advice give them?

Sam Higham

I can share my own journey, cause I think, you know, it may work for other people, it may not. I personally kind of learn things at a last responsible minute. So, what will that means is when I started out being a product person, I was literally learning the thing I had to do at the point I had to do it.

First time I had survived my presentation. Right, best land. How you can do a road map and which ones, you know, what options are there to present it and why might want to be better than another. And then, the second time I came, Well, what did I learn from the first time? Okay, how could you prioritize a backlog?

Right? Well, the best go figure out how you can prioritize a backlog. That genuinely is how I learn. And the reason that I chose to do it that way was because I personally get quite overwhelmed by consuming information and forgetting it all. I think there’s a temptation to read 20 books about product management, and then assume that you’re going to be able to act as you recall all of that information at the right time for you to use it.

And if you can do that, brilliant. Go and do that. That’s a great way of doing it. But I can’t do that. I’ve got direct recall, I have to practice something. I have to learn about it and I had to figure out whether it was something that worked for me or not. And so that’s still what I do today.

Like if there’s a new thing that I’m going to try, then I’ll try and learn about it at the time. I’d still read a lot, like I still try and get inspiration of what things are happening and trying, but when it comes to actual application of it, it’s the last responsible minute.

I think the counter to that and some of the ways that some people might go about it taking some sort course. I don’t think there’s anything wrong with that, like, I think it’s good to have a foundational knowledge and things. I think as long as are not relying on that to be the exact way it plays out and being rigidly, you know, sticking to the thing that you learn in a day or two days, then it’s okay.

That’s another way you can learn, but I don’t think it means you then know how to apply it practically, because of all of the complexity that comes to the fact that we’re all humans and we’re trying to work on things that are complicated and there’s a million external and internal factors that make doing sometimes simplistic work very difficult.

Michael Luchen

Yeah. Yeah. That’s awesome. You know, and it’s something that recognized as well in my own journey and seen other product managers around me thrive is, that focus that say, you know what, I’m just going to jump in, I’m going to learn by doing. Because there’s just so much in our field that like you mentioned, like building a roadmap, it’s like best way to do it is to maybe do a Google search and start playing around with whatever tool choice you have and seeing what works and what resonates with the team and what doesn’t.

Sam Higham

Yeah, definitely. And I think that’s it, right? There’s no, I don’t think there’s any right way to do a roadmap. I think there’s some ways that might be slightly better, but they might not work for your context. It’s very easy for me to say, Right, you should do it now, next, later roadmap without any dates, no features, outcomes only. But then I don’t want to be responsible for you to get screamed at by your executive, because they’ve never seen that, they weren’t expecting it and it’s completely outside of the kind of way that they work.

And so you’ve got to have that kind of incremental change between, Okay, well, what would be the ideal thing that I’d like to do? And then what’s going to work for me right now? And then how do I bridge the gap between those two things?

Michael Luchen

Yeah. So, a lot of the stuff that we’re talking about too, especially because it involves people it sounds like a lot of this is kind of keeping our eye on the long game. Not just the long game of the results that we’re trying to create for the product or the metrics we’re trying to achieve or whatnot, but really the long game of the optimization of the team that we’re collaborating with.

How should a product manager keep that kind of in mind every day as they go about working with their teams?

Sam Higham

I mean, some of the really easy ways you can, I say easy, none of this is easy. Some of the ways that you can do that is through things like retrospectives. Actually, you know, self-assessing as a team is for me much healthier than some arbitrary figures that you pull from a ticket management system or something that other people are assessing.

I think that’s probably the best way to do it. I’ve also run things like team health, retrospectives or workshops where you kind of agree, like 10 things that you want to focus on as a team and then quarterly or something you review that to say, Okay, have we improved or got worse at a particular aspect and what are we going to do to kind of change that?

And those kind of cover two different aspects. So, a normal retro is thinking much more around the here and now. Okay, what are we trying to do given the particular piece of work or given kind of where we are? And then the team health is a slightly more kind of broader, most like a mega retro, like it’s a broader themes retrospective that you can use to keep kind of more general track of where you’re trending.

And some of the things you might want to focus on as a team that might indicate you’re either healthy or not healthy. And again, the team can agree what goes into that, kind of broader assessment. And then I think it’s a lot to do with the soft skills as a product person. I think you have to be quite aware of things like seeing changes in how your team are behaving. So thinking about actually, all of a sudden, I’m not getting anywhere near as much interaction on kind of discussing what we could or how we could achieve our short-term product vision.

Or how we could go about solving a particular problem and trying to be unconsciously thinking about, Okay, well, what’s changed here? What’s happened? And then go and have the conversations with the people and ask them. I think a lot of the time you can kind of sit back and do armchair psychology and just go, Right, well, why that’s happened so therefore, I’m going to do this other thing.

Then I would go and actually have the conversations and figure out what’s happened. It could be that, you know, without you knowing, someone’s got some really harsh feedback or, you know, something’s gone wrong or they could be precious, you know, externally or internally.

You know, again, we’re humans, we’re destined to communicate. That’s how we’ve survived and created as a human race is through collaboration and through the formation communities. And I see a product team as a small community and, you know, kind of get bigger across the organization.

Michael Luchen

Yeah, that’s awesome.

A product team is a small community. That’s really quite something. You know, you speaking of community, it’s just so, again, so focused around people as this entire conversation is. What if I’m a product manager and I’m like, you know, team health exercises, retrospectives, this all sounds great.

And maybe I’ve even suggested this, but my leadership or others that I’m working with, they see it and they’re like, what’s the value in that? Like, let’s not spend time on that. That’s a waste of time, even, maybe it could be some language that might be thrown out. How do you navigate that?

Because we all know it’s not a waste of time. So how do you navigate that side of, kind of people challenge?

Sam Higham

Yeah, I think again, it’s about doing this stuff in the open, so it’s about saying, you know, why are we trying to do this thing? And what do we think is going to be some of the indicators of it being a successful experiment or not?

And you if you’re talking about things like team health, retention, might be a great thing to start talking about, or you can actively, you know, get people to self-assess happiness. There’s loads of tools that now do that, like on a weekly basis, you know, how satisfied do I feel at work or whatever. But that there are ways that you can measure those sort of things.

You can also talk about more generally. Okay, well, how is our team performing and where are some of the challenges we’ve got? Let’s say, work is consistently, blocked because you know, we’re not getting in touch with the right departments in the right time. Okay, well, our hypothesis might be that we’re going to start to be much more active in collaborating with that department upfront.

We’re going to do that by involving them in our planning process at the start of a piece of work. We’re going to also bring them into kind about our weekly demos if we do weekly demos. And then what we’re going to hopefully see is that we don’t get that last minute, Oh, you’ve forgotten that thing, and now you can’t get live for the feature, because you didn’t involve us.

So, it’s been quite active, I think, you know, general, open communication is always healthy. And then the other way you can really challenge it is to ask the leadership team, Okay, well, what would you like to see? How would you like us to measure some of these things and then have some kind of active conversation?

There’s a chance that could go the wrong way. They can start saying, Right, well, I want to see, velocity and story points increasing every we can, in which case, I’d probably say, run for the hills. But you know, you still got to hopefully, a trusted conversation with leadership and again, you’re almost bringing them closer to the problem if you can have that.

You know, getting them to come in and I guess it’s a bit almost like coaching up. You know, you’re trying to ask the questions to understand what is it that they want, or what is it they’re fearful is going to happen if we do these things and how do we alleviate the anxiety that they might have for us to waste time, you know, doing some of these pieces of work versus not.

Michael Luchen

Yeah. Yeah, yeah, no, that’s great. And you know, interesting too. That kind of coaching up, it’s like asking those, going back to what you said, it’s asking those questions. Just simply those high-level questions and so even I love your sentiment of run for the hills if like velocity, your story points, you know, it’s like increase those, cause I’ve heard that.

But what’s interesting is that sometimes you asks, Well, why? And it’s like, well, that’s just a fundamental misunderstanding of what the value of, tracking story points for velocity is. And you get to have that dialogue in that conversation.

Now, if it still comes to very like, Okay, we understand that, but we still want it to increase. Then that’s the run for the hills, right? But it’s interesting that I think even there’s sometimes we as product managers, especially, we have just this really wide generalist knowledge of all these different processes and toolkits and stuff.

And we can’t always assume that especially our stakeholders, have that same knowledge.

Sam Higham

Oh, yeah, definitely. I think that sheds understanding and languages is sometimes so much a part of the problem, even down in my opinion, to calling things, product-led. So, you know, saying that actually, you have a product like culture.

Well, unless people understand that what that means is that collectively we’re just working together to build an incredible product so that it helps to sell itself more than having other ways of doing it. They could assume, well, that just means that product is going to become the most powerful function and it’s going to be the arbiter of everything and all of a sudden, like, that’s how you start getting those people kind of in their castles, getting scared, and fighting over everything.

And so, you know, again trying to think about, well, how language is so powerful? All of these things where people misunderstand and you’re not explicit about what things mean, can get inference for people and all of a sudden you’re in this conversation you don’t want to be in, because you know, people have already kind of made their conclusions.

It’s definitely something that I personally be much more conscious of is, Okay, well, what sort of terminology am I using? Does everyone understand that terminology? And if not, how can I simplify it or explain what’s actually important here, because you know, it’s all about that.

And people are very reluctant to speak up if they don’t understand something, you know. And you only get the most confident people in a meeting saying, Hold on a second, what do you mean by product-led? Most people will just sit back and be in this kind of silently going well they must mean this thing, so it can be quite dangerous.

Michael Luchen

Yeah. It’s kind of, we kind of have to take a posture of being a guide of sorts, like a patient guide with everybody.

Sam Higham

Yeah.

Michael Luchen

So, I’m curious, one last question before we start to wrap up. You know, you’re in a really prestigious role. You have a great career. You are coaching and training folks on the side.

So you have like a really intimate knowledge of our industry. So I want to ask you, where do you see product management going in order to be successful in it? What does product management of the next, I was going to say five years, but that’s too long, so let’s just say three years kind of look like?

Sam Higham

I think it’s probably going to start splitting down a little bit into more specialisms because I think product management started very broad. And so it means so many different things to so many different people. I think somehow it’s going to start slicing it up into two more specialties, more particular types of product management people.

Very much like you would see in software engineering, for example, have kind of specialisms, sub kind of product management people. It might be things like growth. It might be B2B, B2C. A lot of the terminology gets used, but I don’t think we’ve started to really tie that up to, Okay, well, what works best in, if you’re a growth product person or you’re a B2B product person, or a B2C. We’re a marketplace or you’re, you know, whatever type of product person it is.

And I think, you know, part of the broader education and content, especially stuff that I started to see now, is angling towards that way. And I expect that it will just almost formerly follow as kind of a discipline. So actually you’ll start getting these specialisms and slice because we’re getting to such a big community of product people now. That’s naturally going to happen.

Michael Luchen

Awesome. Awesome.

Before we wrap up, I’d love to ask some personal lightning round questions, if that’s okay?

Sam Higham

Yeah.

Michael Luchen

Alright. Which of your personal habits has contributed most to your success?

Sam Higham

I would go, resilience. I think a lot of what we talked about today is failure. And sometimes, people aren’t quite as accepting of failure and you can get a hard time if things don’t go right, and you’ve not got a safe environment. So that’s definitely up there. Adaptability is probably another one. I mean, that’s just how I learn is by continually adapting to whatever information I’ve got. And so that’s definitely one.

And then probably, humility. I openly say that I don’t know half of the stuff that I need to know. Actually, I rely on a lot of other people who are far more brilliant at the things that they do for us to succeed. And I try my best never to pretend otherwise that actually I’m the expert and I know everything because I don’t. And I don’t think I ever will.

Michael Luchen

I love all those characteristics and can definitely relate to the value of them.

What’s your favorite tool that you use regularly?

Sam Higham

Miro or Myra? I don’t know how you pronounce it. I can’t remember which one it is, but it’s the most flexible tool. I would be lost without it.

I use it all day everyday for everything. I mean the last company I was at, and since we use that to launch a billion-dollar business in six months. Like it was just a Miro like it was nothing out. So it’s a pretty impressive tool. I use it for all my content and everything as well. Yeah, it’s a great tool.

Michael Luchen

Yeah. Yeah. I’ll definitely second that. My team and I, we adopted it back when it was real-time board. And it became quickly, like the most widely used tool ever in the company’s history, like so quickly, so valuable.

And lastly, for the start of someone at the product journey, what is the one piece of advice that you’ve given?

Sam Higham

Ask for help. I think there’s an assumption that as a product person, you should know everything because you’re kind of at the intersection of everything quite a lot of the time. I think you can be reluctant to just ask for help when you don’t know things, whether that’s other product people or it’s an excellent engineer you work with. Or a designer or someone in the organization. You know, some of the best people I know in product management are the ones that are actively, always asking for help, because they know that helps them get better.

I think there’s a great growing community Twitter for product people as well. And, you know, I think that most people are on it because they want to help other people kind of learn. So, yeah. Ask for help is my number one piece of advice. Well, actually, not just for product, for anyone. Full stop.

Michael Luchen

Yeah. That is fantastic. I absolutely agree. I mean, even if you think you know, you should ask for help, because it just getting a second opinion can be valuable of itself.

All right, Sam. Thank you so much for joining the show today.

Sam Higham

Thanks for having me.

Michael Luchen

You can find out more about Sam’s work on Twitter or LinkedIn. Again, thank you so much, Sam, for joining. Thanks everyone for listening in and be sure to leave a review for the podcast. Also please follow and join our community at theproductmanager.com if you’re not already.

Again, thanks everyone for joining and see you on the next one. Take care!