Jason Knight 0:00 Hello, and welcome to the show. I'm your host, Jason Knight. And on each episode of this podcast, I'll be having inspiring conversations with passionate product people. If you like the sound of that and want to hear from me and some of the finest product thought leaders and practitioners in the world, why not head over to OneKnightInProduct.com, where you can sign up to the mailing list, subscribe on your favourite podcast app or follow the podcast on social media and guarantee you never miss another episode again. On tonight's episode, we don our lab coats and get scientific as we break down product management practices and examine the five steps on the Product Science Success Path and see if we can't insert a 6th. We talk about some of the ways teams can work to ensure they're setting themselves up for success, how much teams should be advocating for best practices versus just getting on with it, and how strong product leadership is needed to make any of this stuff stick. Talking about product leadership, we also tackle the thorny debate about CPTOs and whether it can really work to have one person in charge of product and technology or whether we should always aim to keep them as aligned, but separate leadership roles. For all this and much more, please join us on One Knight in Product. So my guest tonight is Holly Hester-Reilly. Holly's a board game geek, former competitive skater and figure skating coach who's hung up her blades and donned the white coat and moved into the laboratory complex of product science. Holly's passionate about helping people build great products, teams and companies and making a positive impact on the world, and given some of the stories I've seen in the business press she's got her work cut out. But she's working towards it anyway, by teaching people the benefits of good product discovery and experimentation via her consultancy H2R Product Science, and matching Product Science Podcast. Hi Holly, how are you tonight? Holly Hester-Reilly 1:39 I'm doing pretty well. How are you? Jason Knight 1:41 I'm doing fabulous. I do have to ask is a product science merchandising line? Like, can I get the lab coats and the goggles and the test tubes and everything with the logos on and stuff? Holly Hester-Reilly 1:51 You know, that is a fantastic idea. I think I'll get right on that. Jason Knight 1:55 Excellent. We don't need to do any discovery on that one is guaranteed to succeed. Holly Hester-Reilly 1:59 Exactly. Jason Knight 2:00 But let's talk about product science. So you're the founder of H2R Product Science, which is a consultancy. And the website says "we believe there's a science to building high growth products". So we'll talk about the science part in a minute, but in general, what sort of stuff are you helping people with with a consultancy? Holly Hester-Reilly 2:16 Yeah, so I help pretty much anybody who's looking to improve the way that they develop product, particularly with a focus on continuous product discovery and experimentation. And I do this with early stage startups, like I coach founders, all the way up to enterprises, like Capital One, and Weight Watchers, and everything in between. And the core thing about them is that they're looking to up their game, that they've read the product books, and they're saying "This isn't what life is like for me. And I'd really like to figure out how I get closer to that". And then I come in and help them do that, or my team does. Jason Knight 2:57 Well, fair enough. But that's interesting... a couple of things that are interesting in that, and one of which is like who is it that's actually calling you in? Is it the leadership of the company, like the founders, or the executive team? Or are you getting engaged directly by the product team, the CPO, head of product or whoever is in charge? Holly Hester-Reilly 3:14 Yeah, so in companies that are big enough to have a head of product, so anybody who's past that really early founder stage, it's usually the the head of product or the CTO or whatever level they've got going on at their organisation. But it's also not uncommon for founders to reach out to me who are really early stage and they're trying to find their first product market fit. Jason Knight 3:38 Right. So on that product market fit or pre product market fit type company then, like, is that really your sweet spot? Would you say like, is that like where most of your clients come from? I know you say you talk to enterprises all throughout the stack and big companies and small companies. But would you say that there's a weighting in a certain area, like certain types of companies that come to you or certain companies that you can do the most with? Or is it literally just across the board? Anyone that comes at you can you've got something for all of them? Holly Hester-Reilly 4:03 Honestly, it's literally across the board. And that is really because I believe that there is a science to building high growth products. And there are principles that are consistent across building high growth products, regardless of whether you're building that product on a five person team at a at a recently found a company or within an established enterprise. Jason Knight 4:26 Right. But those established enterprises have very different challenges and very different dynamics and very different... in some cases, political struggles that are going on and everything just feels a little bit harder. Now I've worked for enterprises in the past, so I know that I know what it can be like. So do you find that the concept... I mean everyone, every enterprise these days that you kind of see they're kind of talking about trying to be more product led or trying to be more agile and then they end up... start doing something ridiculous like implementing SAFe or something like that and start to wonder where all went wrong for them but like, how easy is it for someone like yourself who's obviously really steeped in all of the great product thinking and you know, you've got the podcast, you've spoken to so many great people, the experience that you have... you obviously live and breathe the product world. And then you're going into some of these big companies that aren't at all, like, is that easy to get them to make that transition? Is there something that for example, when you're talking, say, quote, unquote, digital transformations, that some way to kind of get that first little chink in the armour that you can then start to work on them? Holly Hester-Reilly 5:26 I wish I could tell you like, just give them this pill, and they will solve the problem. But unfortunately, it's not. It's not that easy. It's definitely hard work. And I think one of the key things for me, as always, who are the champions that are bringing you in? You know, you've got to have some, you've got to have buy in from someone inside the company and what level they're at and how much influence they have, is definitely going to have an effect on how successful you can be when you come in to try and help them change. Jason Knight 5:52 Yeah, absolutely. But are you there then to, as you say, go in, help them get set up, make sure they know what they're doing, quote unquote, properly, and then kind of push them on their way like a boat, and then they just sail off into the distance? Or do you have more of an ongoing relationship with these people afterwards, and keep checking back in with them and kind of steering them back on the right course, once they're actually on their way. Holly Hester-Reilly 6:13 So my typical engagements tend to last around a year, I always start with a minimum of three months. But I'll usually stick around for somewhere in the range of a year. And over that course of time, I'm able to make a significant impact on the way that the product team is functioning and on the lives of the product managers there. And then afterwards, I tend to keep relationships with some of the people. And so I'll check in and see how things are going. But in terms of the professional relationship, it usually does sort of come to an end, you know, somewhere in that year range. And then, you know, they hopefully have hired the internal staff that they need, or put the processes in place to make the changes lasting. Jason Knight 6:56 Fair enough. And if you had to estimate off the top of your head, how many of those people actually stuck with your principles after you left? Would you be able to estimate that? Or is it not possible for you to know? Holly Hester-Reilly 7:07 How many people stuck with my principles after I left? I think that's difficult to estimate. Now I'm reading through all the clients in my head and trying to be like, let me try to do the math really quick. But I'm just gonna end up with... Jason Knight 7:21 I just think because Rich... I remember Rich Mironov saying it was like 50/50, or something like that. I just wondered if that was like a standard. Holly Hester-Reilly 7:27 Actually the number that came to mind in my head is 50%. So I mean, I guess I can say that. I do feel like there are cases where you know that they aren't doing what you taught. And you know, usually those are cases where maybe you ended the consulting arrangement yourself, because you could see that it wasn't going to be successful there. And then there are other cases where you hope that they're still working in that way. And I can think of some clients where I know that they're still doing regular customer discovery, regular user interviews and running experiments. So some of both. Jason Knight 8:05 Well it's like with kids, right? You just teach them what you can and hope they do something with afterwards. But yeah, I always come home when we're close. And then listening to music you don't like. Holly Hester-Reilly 8:16 Mm hmm. Yeah, we're watching the wrong thing on YouTube. Jason Knight 8:19 Exactly. Yeah. Well, you don't talk about that. But you also the head of product and engineering at YourBase. So how do you manage to find the time to do both those things? I mean, that consultancy sounds like quite a lot of work. So how can you maintain that a full time gig and that consultancy? Holly Hester-Reilly 8:35 Yeah, well, the truth is that the consultancy has been around for about five years, and I did your base for about a year and a half, I've recently come back to full time consulting. And during that year and a half that I was doing YourBase, I wasn't doing as much consulting work. So kept the podcast going kept coaching clients and continue to gain new coaching clients and do some consulting work, but not as heavy, because I was so focused on YourBase for this period of time. Jason Knight 9:03 Well, I was gonna ask you, I mean, obviously, it's great that you're back consulting full time and helping loads more people. But you are the head of product and engineering at YourBase, which is an interesting mix, because there's a lot of headwind behind this whole idea of CPTOs at the moment. And the idea that, actually, it's much more efficient to get product people and engineering people and all of the other types of people that were put in through maybe a CPO or CTO into the same function and have everything managed from one central place. Now, I'm personally not 100% sure that I'm pro that. Because I think that it's nice to have that of healthy tension between product and development to keep each other honest and keep each other moving in the right direction. And not worrying too much about technology or too much about product but trying to find a nice mix in the middle. But do you think there are any solid benefits for maybe the time you had at your base or just in general of of having that all mixed up and reporting into the same leadership? Holly Hester-Reilly 9:57 Yeah, I do think there are benefits. I I think one of the things for me, that's big in product leadership is how you communicate the initiatives that you're going to be working on, and how you communicate the why behind the work that you're doing. And I think that as a head of product and engineering, who came up through product, that was always really essential to me. And so I feel like my team was always understanding all of the reasons why we're doing things and what it means to our customers into our business in a way that is not always essential, when they're those roles are separate. At the same time, I have to say, in some ways, this role that I had at your base being combined was a factor of the size of the company that, you know, the company was pretty small, was an early stage startup. So I didn't have a whole product team to lead, I had a product manager and myself. Somewhere along the way, somehow, I managed to impress my boss, that I had good leadership skills, and that I'd be really helpful on the engineering side, too. And so I stepped up and said, "Okay, I'll take that on". Jason Knight 11:04 But then when you're in a situation where you have to make a judgement call between the two disciplines, so like a technical implication, and a product implication, and, again, the cliche would be that someone that was heavily product or heavily engineering would really arrive inside of one over the other? Because that's where their instincts lie, like, how would you stop yourself? Or how did you stop yourself effectively reverting to type and going back to your area of most expertise? Holly Hester-Reilly 11:27 Yeah, that's a great question. I think, you know, to me, the best those big decisions where you might have conflict between the product leadership and the tech leadership, at the end of the day, the right decision to make is going to be the decision that's best for the business as a whole. And that is going to need to take into account both the impact on customers the impact on the business and the impact on the tech stack. And I like to think that even when I was pure product leader, and not splitting the responsibilities, that I was still a very engineering sympathetic product leader who believes that it's a smart product decision to invest in the right technology in the right infrastructure at the right time. So for me, the that conflict doesn't resonate so strongly, because I'm actually super passionate about paying down tech debt. And you know, having good engineering practices and making sure that we're making good architecture decisions, as well as we're making good product decisions. Jason Knight 12:24 I'm sold. I think it's interesting, because I came from an engineering background myself, but I've massively tried to push myself away from that over the years to try to make sure that those other parts of the three Venn diagram circles are all kind of covered and that I'm equally as able to contribute in all of those things. And I guess, the way I was thinking about it, when I started seeing more conversations about CPTOs is like, you have to be kind of not necessarily a unicorn, but you really have to be someone who's really conscious of your position and really conscious of how your decisions or what's informing your decisions. And I'm not 100% confident that everyone would do that. But I guess you could probably argue the same about having rubbish CPOs and rubbish CTOs right? There's always the chance for someone to be bad. And I guess on the one hand, I'm thinking, Well, you know, at least if you have a CPO and a CTO, you can kind of hear them justifying their decisions to each other rather than it all being locked up in one person's head. But at the same time, I guess, ultimately, to your original point, it's like, well, as long as it's good for the business is good for the business. And that's really how you measure success. Holly Hester-Reilly 13:24 Yeah, I think that really great CPOs and really great CTOs have a lot of skill that overlaps. I think there's a lot of... the great CTO understands why something is good for the business and good for the customer and isn't purely interested in building the most awesome current technology. And a great CPO is also going to be understanding the value of investing in the technological infrastructure. And if your CPO isn't doing that, then they probably have some learning to do. Jason Knight 13:59 Yeah, I'm pretty sure there's a bunch of CPOs out there right now that aren't doing that. But let's hope they pick up a book or something at some point. So, we've chatted before about the Product Science Success Path. And you mentioned a five step plan, the five step Product Science plan that you presumably go in and use as the framework for going into these companies and trying to help them along the path of being more effective at building products. So if you're going into a company, kind of cold, going in from scratch, and trying to get them to start doing product, quote unquote, properly, what are those five steps that you basically tried to take them through? Holly Hester-Reilly 14:39 So what I like to talk about is the Product Science Success Path, and it's, it's five steps, but everybody starts on a different rung of the ladder, right? So some people won't have to take all five steps because they'll already have completed the journey from one to two and some will not. But that first phase, that first step that's really important is just Agile product development. So agile product development in the first place, like if you're not shipping on at least a bi weekly basis, but I say at least with like quite the like hesitation, because honestly, you should be shipping much more than that. But if you're not, you know, integrating your code regularly and shipping code regularly, then you can't work with me. Like, there's not gonna fix that problem, find an Agile coach and start with that. Jason Knight 15:25 So that's like the first stage is, if they can't check that box, you're out? Holly Hester-Reilly 15:29 Yeah, absolutely. If they can't check that box, I'm done. I will tell them they need to start learning agile and and you find that in some of the large enterprises, you know, sometimes you do find companies that are still not doing Agile, or companies that think they're doing Agile, but really are not. You know, it's a very common one. Unfortunately, extremely common. And I think that that actually lends itself well to sort of the second one, which is the second phase is what I call product discovery practitioners and teams that are at that stage, they do some product discovery activities on top of their Agile software development, but they tend to do them only at major decision points, like the beginning of a project, or you know, when there's something major happening. And when you're doing that, you missed a lot of opportunities, and you miss a lot of chances to refine your plans and to invalidate assumptions that you're making. And you're, you're not setting your team up for success. And so that first step is really okay. Did you learn Agile, and then just take a big plan and break it into two big chunks and say, great. Like, if that's where you're at, you're still have a lot of work to do. Yeah, but that is a that is a place where I will come in and help people. So it's not uncommon for me to work with companies that really are just doing product discovery as a project for each major initiative that's happening on its own. And then the initiative is going and they're writing their specs, and they're like, "Okay, we've, I figured out the discovery, now I'm moving into the development phase". And that's not the way I believe we should be building products. So yeah, anybody who's at that stage, I'm going to try to get them to the next stage. And so when somebody is at that stage, what I do is I say, "Okay, let's set one learning goal for each sprint. Let's say that every sprint, there's something you need to learn, and how do we make space for your product manager, your designer and your lead engineer, that that whole trio to be involved in this learning? And how do we start a cadence of sharing what's learned, so that this becomes something that's as important to the company as what's built?". And that's a common systemic problem is just this focus on what's built, what's built what's built. And you know, like, what's learned, even if they are learning, there's, you'll see a lot of companies where the learning all stays in the heads of the few people who are involved in the research. And you know, if that's the case, you you still have some work to do. So I say, "Okay, let's start with one learning goal. Let's just say, let's get you into a cadence of something happening every sprint", and then once you are able to do that, then you you're reaching stage three, stage three is continuous product improvers. So the continuous product improvers are at least learning something every sprint, and these teams usually feel confident in the area that they do the most research in. But they often can get stuck as they're lacking an "Aha" as to what's going to drive the high growth or clear reason to prioritise one thing against another. So when you come in, and you see a team at this stage, and this is a pretty common, I would say this is actually the most common stage for teams today that I work with, because they often have read some of the work from people like Marty Cagan and Teresa Torres, and Melissa Perri, that tells them that they need to be doing more continuous research and be doing something more iterative and be, you know, empowering everybody with this knowledge. But a lot of times people get stuck at that level, they don't understand how to make sure that it's actually really valuable research and that they're not just running experiments for the sake of saying they're running experiments. Jason Knight 19:03 Yeah, ticking the box again. Right? Holly Hester-Reilly 19:04 Exactly. Yeah. So the thing that I teach at that stage, and this is one of the things that I do with with most of my clients is, we'll do a pre mortem risk assessment. And we'll say, Okay, before we go out to do the research, we got to figure out where the risks are, we got to talk about the risks, we got to figure out which risks are big. And I always like to do that across what I think of as the five major risks in product development. So there's the risk of value, so it not being valuable enough for the customer to want to use it. There's a risk of feasibility, you know, like, we found a really valuable problem to solve, but we're actually not able to solve it. And that's a problem. There's the risk of viability. So maybe we're trying to solve something. It's really valuable for the customer. And it's feasible, but there's actually no way for us to make a viable business out of it. And that's also a major risk. There's the risk of usability. And so you know, maybe we do all this, but we create such a crappy user experience that nobody can actually do. To the outcome they want to get to. And then finally, there's also the ethics risk. And I think that we should be talking more about that as product people. But you should also stop and say we're just because we can solve this problem, just because we can build this thing. Should we build this thing? What are the ethical implications of it? So I always encourage people to think about all of those when they're doing their pre mortem risk assessments. And then we use that to drive the research. And once a team gets really good at that, and they get into a cadence where they do the pre mortem risk assessment pretty regularly. Like, it's not just a thing that happens once at the beginning of a project. But it's something that they come back to and they reassess, and they think about, then we can get to a place where they become stage four, which is high impact experimenters. So at this stage, the teams are actually really good at figuring out what customers need. And they will likely understand what customers are going to do with a given product design. And they're not surprised when they put the product in the hands of customers, because the customers are actually doing what they expected, because they did enough discovery work to understand. Yeah, and that's a great place for a team to be at. I've certainly worked on teams at that place. And that's a lot of progress. And I think that we do a lot of work to do that. But you can't stop there. And the reason you can't stop there is because a lot of times, if you're in that stage, people will get frustrated, because they can't necessarily convince the other people in the business, the things that they know. So you know, you think of that product manager who's like, I wasn't surprised by what happened. But everyone around me was. Jason Knight 21:33 Well, yeah, because they thought that it was should have been something else. And they refuse to be shaken off of their original idea, right? Holly Hester-Reilly 21:39 Yes, exactly. So they thought their original idea was going to be great. And the product person figured out it wasn't going to be but couldn't convince them not to build it. Right. super common story. So much pain. Jason Knight 21:53 So stage five is the magic bullet to fix that, then? Holly Hester-Reilly 21:56 That's right. That's right. Stage Five is what I call high growth product leaders. And at that stage teams are both effective and impactful in their continuous product discovery practices. So they're not only figuring out what customers are going to do, but they're also able to drive business outcomes and business impacts and good product decisions. Because they're really good at communicating the research in ways that leaders can understand empathise, and, and act on. And once you have all of that, then you have a really well functioning product team. And I've always seen that create great products. So once you get all of those elements in place, then you're set up for high growth product. Jason Knight 22:35 There you go, then success and unicorn status straight afterwards. Holly Hester-Reilly 22:41 Yeah. Just you know, the next day, the very next day, you just check the box. No! Jason Knight 22:46 Well, because that's what people expect, right? These leaders, they're gonna be sitting there saying, Well, you know, Holly's coming in, she sought us out, she's got us to rung five. If we don't immediately succeed, then Holly's approach was wrong, and we need to go and do something else instead. I mean, obviously, that's not true. But like is that that's got to be. I mean, we all know the stories. And we've all been there with companies that don't really get discovery, or probably you think that some of the things that you've just said sound nice, but they wouldn't work here, and all that kind of stuff. Now, obviously, you said that you wouldn't work with companies that aren't even fulfilling the basic tenets of building software in an Agile fashion. But have there ever been any situations. I mean, I'm sure you work with a bunch of companies, but have ever been in situations where you basically had to kind of pull the ripcord and go, because you get to like rung 3 and you realise that it's just not going to happen because the weight of the company or the weight of the company's leadership is just dragging that down. Holly Hester-Reilly 23:38 Absolutely, there have been this situation that I think is the easiest for me to talk about is actually my very first consulting contract after I left Shutterstock was for Toys R Us, and Toys R Us and Babies R Us Jason Knight 23:52 Did you get to meet Geoffrey? Holly Hester-Reilly 23:54 Geoffrey was in the hallway. When I went in there, it was early 2017. And the writing was on the wall. But they were trying hard. They brought in a lot of agile coaches. They were trying to hire top tech talent they'd hired out of Amazon and Google and ... Jason Knight 24:11 Oh, cuz that always works. Holly Hester-Reilly 24:13 Yes, that is that's always a silver bullet. Just hire someone from Google and you'll be fine. So they were working on trying to figure out how to do experimentation and how to do Agile, and I could tell that they were not going to make it in time that even if they could make improvements, you know, it was clear that they needed a turnaround to happen on the scale of a year. And these kinds of changes. You can make these kinds of changes to the culture in on a scale of a year. But you also need to have time for the impact to be seen. And so yeah, you know, that's that's not it's not necessarily going to be you know, Holly comes in. She teaches as a team how to do things this way. And then, you know, six months later, you have hockey stick growth. You know, it's like, Well, okay... Jason Knight 25:08 Where's your ambition Holly, come on! Holly Hester-Reilly 25:13 Yeah. That's exactly. Jason Knight 25:17 That's step six, step six, hockey stick growth. Holly Hester-Reilly 25:19 No, I mean, I have seen hockey stick growth, I have seen companies that have that kind of thing happening and going on. But they're practising this way where they're able to make these good decisions based on customer discovery. For years, you know, like this. It's not like three months into it. It's a crap that you have to do every day for a long amount of time. Jason Knight 25:40 Yeah, absolutely. But one of the things that you touched on earlier was the need for really great product leadership, to basically come in after you, for example, to then take the ball and run with it, or hopefully, they're there already. And I can kind of come on that journey with you. But I think it's fair to say that there's a bit of a chasm when it comes to getting into leadership in the first place. Not we're not talking about the Geoffrey Moore, Crossing the Chasm chasm, we're talking about different chasm. And that's the kind of chasm between being an individual contributor, product manager that's trying to get this stuff done on the ground level, and actually then crossing that notional chasm into being a product leader that can lead their team and do some of the things that you've just been talking about, and make sure that those practices are embedded and can really help to drive the team to success. Now, that chasm definitely exists. And it's something that I've been chatting about a bit recently, but I wondered from your perspective, like, how did you cross that chasm in the first place? Holly Hester-Reilly 26:40 Well, I did a really good job as an individual contributor. And then people started asking me how I did it. And I started teaching them. And you know, they were my co workers. And so, you know, over time, it became okay, well, now, now, Holly's teaching us about product management and about product discovery and delivery. And then from there, you know, I started to hire product managers to work for me and to design the structure, you know, to say, how do we design the right processes and the right infrastructure for these product people to be successful? And, and that's actually something, you know, I could have put this in the notes about interesting facts about me, but I forgot. That's something that I'm passionate about, because I actually studied chemical engineering. And so that's my background prior to moving into tech, and chemical engineering is to to two major things. It's process design, and its product design. And that is, you know, I think once you start getting into product leadership, you're you're doing org design, and that is a form of process design in a way. Jason Knight 27:50 Yeah. So kind of sounds though, aside from your academic background, which is obviously really helpful that a lot of your actual progression into leadership positions and being able to coach and, and lead and define their strategies and processes was kind of school of hard knocks, is that fair to say? That you kind of just worked out as you progressed, and presumably did join experimentation. And some of that worked. And some of it didn't, and kind of iterated your way to being an effective leader. Is that fair to say? Holly Hester-Reilly 28:17 I would definitely say that's fair to say, I think that I think I learned a lot. You know, I learned some things by doing them wrong. As we all do, we all make mistakes, right? And I learned, I learned some leadership lessons the hard way. I also I love to read books. So you know, I read books, I went to workshops and tried to learn from the best. And then I came back, and I tried to apply it in the role that I was in. And then I went to another company, and I tried to apply it there. And, you know, to varying degrees of success, but it was a lot of fun. And I feel like the the teams that I lead made a good impact. Jason Knight 28:53 Oh, that's the force multiplier in full effect. But it's interesting, you're talking about books as well, because there's a common theme going on in and around the product community at the moment. And we chatted about it before as well about how there are so many wonderful books out there. And you've mentioned a few of those yourself. Yeah, talk about Marty's books, and Teresa Torres's books and all the other books. And there's there's books on my vanity bookcase behind me all the other books that we've all read. And I'm sure that you and I both share very similar opinions on and would agree with most of the things that are in these books. But there's this kind of theme going on in the community at the moment that those books don't necessarily represent the world of many, or maybe even most product managers, because they may be working for companies that are minus one on your scale or something like that, or just in general having really bad internal problems or the value of Product Management just isn't clear within that company or for the leaders of that company. Now, there's obviously a gap, but how much do you think that PMs need to just kind of make peace with that and just do their best and try and do what they can to make things a little better versus being a bit more bullish and trying to be that advocate and spokesperson to try and actually drive transformative change across all these companies? Holly Hester-Reilly 30:07 Yeah, that's a great question. I mean, I, I believe that everybody should be trying to make an impact on the people that are around them. And so if I'm coaching a person who's at a product organisation where there are tensions and product isn't functioning very well, and they feel like they're just asked to ship ship ship, and they're just feature factories, I always have some tactics that I will share with them that we will try to see if we can help get them out of that cycle. Yeah, but at the end of the day, they also they can't just go in like a bull in a china shop. They can... Jason Knight 30:44 Oh, they can try. Holly Hester-Reilly 30:46 They can try but they won't be successful. Not usually, you know, people don't like being told that one of the ways that it often comes off is like the product manager is telling everyone else they're dumb. And that's that's not a good way to build relationships with your coworkers. Jason Knight 31:01 No, not normally. Yeah, I think there's just this general feeling from various parts of companies where is like, it's all seen as too abstract. And it's all seen as too theoretical. And it's all seen as a classic line, that wouldn't work here. Stop talking about it, we just need to do some stuff. Right? Well, that's cool and all but again, I guess the point of hiring product people is to do product people stuff, right? So it feels like people should be listened to a little bit. But a flip that around then talking about books, again, if you had to recommend a book about discovery. And I'm going to caveat this by saying you can't mention Teresa Torres's book because everyone should already have that. If you had to recommend a second book about discovery, to try and get people good at it and try and help people get along and do more of that. Like what book would you recommend? Other than Teresa's? Holly Hester-Reilly 31:52 Yeah, I mean, you obviously just hamstrung me, because the first thing I was gonna say was Teresa Torres's book. Jason Knight 31:57 Fabulous book. But you can't say it. Holly Hester-Reilly 31:59 But if, if, if that's not the one, the next one that comes to mind, for me is Lean UX. It's a little older. But I think that that's a good book too. Jason Knight 32:07 Excellent. I'll make sure to link that in so people can buy it, make Jeff some money. And what's one piece of Product Science that anyone listening to this should try tomorrow, like go to work, they've maybe not got all the way up that ladder yet. I can't afford you or they don't know, they can't go to you and actually contract you anytime soon. But they want to get started. They want to do something. So what's one experiment they can do to make their product life a little bit better tomorrow? Holly Hester-Reilly 32:36 I think the first place to start is trying to add discussion about what you've learned to your team demos. So I call it the Built/Learned/Planning demo. So instead of a demo, where you're just saying this is what I built, you also say this is what I learned. And you say, this is what I'm planning to do next. And I think just that small change to the process can have a really big ripple effect, because you start training everyone around you to care about what you've learned, and to care about how it affects your plans, and to start expecting that actually, the things you learn are going to change your plans, which like, sounds so obvious, but it's not. I mean, so many times we work in environments where we learn things, and then we just put our head down and and go forward anyways, because you know, the boss asked us to. So getting getting that, that exposure for the value of learning is the place to start. Jason Knight 33:34 Sounds good. And I just had another thought actually kind of combining the advice they could follow if they can't get hold of you. But also talking back about books. I mean, is there a Holly Hester-Reilly book coming up? Holly Hester-Reilly 33:45 Oh, well, that's so nice of you to ask. I definitely hope to write one one day, but I haven't started writing anything, so we'll see! Jason Knight 33:53 We should keep our eyes open and hope for something to come over the horizon. Holly Hester-Reilly 33:57 Yeah, exactly. Jason Knight 33:58 Maybe that can be the book that people recommend when they're not recommending to visitors. Holly Hester-Reilly 34:01 yeah, that's my that's my hope. Jason Knight 34:04 Where can people find you after this? If they want to talk about product science or product discovery or just product stuff in general? Holly Hester-Reilly 34:11 Well, they can find me at H2RProductScience.com and on Twitter @H2RProductSci, which just ends with Sci, because science was too long. I ran out of letters. Jason Knight 34:29 Well, I'll make sure to link that in. And hopefully people will come across and find you connect and start to learn how they might go up the ladder themselves. That's been fantastic chats, obviously really grateful for you to come on, spend some time and talk a little bit about your ladder and some of the ways that people can make products a little bit better. Obviously, we'll stay in touch but as for now, thanks for taking the time. Holly Hester-Reilly 34:47 Yeah, thank you as well. It's been a pleasure. And I look forward to having you on my podcast so your listeners can look forward to that too. Jason Knight 34:56 As always, thanks for listening. I hope you found the episode inspiring and insight If you do it again, I can only encourage you to pop over to OneKnightInProduct.com, Check out some of my other fantastic guests sign up to the mailing list or subscribe on your favourite podcast app. Make sure you share with your friends so you and they can never miss another episode again. I'll be back soon with another inspiring guest, but as for now, thanks and good night