Yeah, I think people are way too attached to languages. Languages come and go every three to four years, people are re-architecting and making changes. A lot of people are committing their organizations to a path without knowing how hard it's going to be to change. As opposed to saying, this is what we're solving for today with tomorrow in mind. We think we know that things might shift and change over time because everybody has had to re-architect. And in many cases, multiple times. That was the voice of Jessica Hall, the co-author of the book, The Product Mindset. Today is the second part of my interview with Jessica if you didn't listen to the first part and encourage you to go back and listen to that before you dive into today's episode. My name is Jonathan Cutrell and you're listening to Developer Tea and my goal in the show is to help driven developers like you find clarity, perspective, and purpose in your careers. Let's get straight into part two of my interview with Jessica Hall. I'd love for you to kind of explain further about how I might, more practically, dive into a product mindset. What are some ways, some things that I do today that maybe I'm not going to do in two or three years? And instead, I'm going to be doing something else. What are those things that you see more developers kind of participating in in the future? Yeah, so the product mindset has three principles that kind of underlie all the things. It starts with fundamentally, before you can get in the principles, building for outcomes. That we're not just here to build code. We're here to build businesses to help businesses serve customers and to grow and to continue to innovate. That it's not just about the code we write, but what does that code create? What does that code enable? What value does it deliver? And the first principle is minimize type of value, which is the idea that when you're working in your IDE, when you're writing things in JIRA, when you're in planning meetings, when you're doing sticky notes and drawing diagrams, that's activity. Value exists in the hands of your customers. Value exists when they can work with a prototype or use a feature and production or into staging. That's where value exists in their hands, where they can do something. So how do you as fast as possible put something to their hands? How do you reject the notion that it has to be complete? It has to be fully implemented. It has to have every bell and whistle. It has to have feature parity plus everything else. What is the smallest set of things that you can do that solves a problem for somebody and you could put it in their hands? How do you slice across and say, I'm going to deliver the ability for you to look at this, for you to manipulate it, and for you to get some sort of result on just this thin stripe of things. And from there, I can see people are like, gosh, it'd be really great. I really want to be able to do this thing. Great, let me build that thing. You know, it doesn't account for this thing. Awesome. I'll get on that next. But that first principle is really the idea that we have to deliver that small sliver, that small piece of the feature, not everything. And I think it goes back to school where you have this notion of completeness. And I don't want it incomplete. That's like an F. That's bad. I can't simplify these things down. I can't cut it down. Just take a piece. But taking a piece allows you to reduce waste, to increase learning, to start generating interest, perhaps generally, revenue much sooner. So the question you need to ask yourselves is, are you minimizing time to value? When you go to plan your releases, are you thinking about in every release and every sprint or whatever methodology you use, how fast are we delivering value to our customers? Are we waiting too long before we're giving them things? Do we have things that are clogging up the pipeline that if we could streamline them, we could get things out faster, which means we could learn faster? How do I, as a junior developer, maybe think about implementing something that might get it done a little bit quicker, a little bit simpler, as opposed to something that maybe has great ability to scale. But honey, we ain't scaling yet. We don't even have 10 customers. So, or, you know, when the team goes to do release planning to say, okay, let's break this down and make sure we have something that we can release, that we can deliver a value to to our customers and that we can learn. And we're open and we evaluate that learning. The next principle is solve for need. So the idea is that a product needs to solve a need. What is that need? Why does this thing exist? What do we do for people? You know, can you explain when you're at a bar with somebody you just met? Like, why your product matters? And, you know, what is the need? A need's are best defined by Steve Blake. I can't do any better than him. So I'm going to have to use his stuff. You know it's a need. You know it's a problem. Like, you know that doing laundry is a pain in the butt. And you probably don't enjoy doing laundry. That's, you know, number two. I know that that, I know the extent of that need. It takes time. It takes effort. If I don't, you know, if I don't get it done, then I'm probably aware. And so you can put a price on that pain. That you're trying to fix it. You're trying to fix it. You're trying to improve it somehow. You're hacking something together. You're laundry schedule or, I don't know, you're trying different services and things. And nothing's quite working. And the last piece is you're willing to invest in a solution. That's a need. That's something I can, I can, I know I have it. If someone has a problem and they don't identify it, they don't feel it, they don't connect with it, they haven't figured that out yet. Good luck trying to sell them. They kind of have to admit that it is this. They know it's a problem. They know it hurts. They're trying stuff and they're not finding the right thing. They're willing to make an investment in the new thing. That's where you want to play. And so that's kind of where it's helping understand the customer and having, you know, spend some time. No one's asking you to do detailed research, but maybe read some of the research that your team has put together. Maybe look at some of the data, maybe listen to a new interview. There's something really powerful about connecting with other humans. The last one is a cell change. So that comes in a couple different ways. You know, back in the day, you used to only be able to release once a month. Now we have good, better tooling, better processes, better ways to be able to deploy more often, being willing to invest in that. I'm reading this book called Accelerate about the Science of DevOps. It is not an easy read by any stretch. Like I can only go do a couple pages at a time because it's so dense, but it's also so fantastic in making the case through a very rigorous and data heavy process of why to make that investment. But it's not just the technology piece of that and getting your organization to invest in a technology, but also the decision making. You know, a lot of people complain that priorities change. And my answer is, well, yeah, they should. Because everything around them, you know, people change. Companies change, markets change, regulations change. So why shouldn't priorities change? It's priorities changing is such a sign of like an organization who doesn't know what they're doing. And they're, if they're changing without reason, if they're changing, they haven't been measured. If they're changing because, you know, somebody has a shiny object syndrome. That's bad. And usually people call me because somebody's got shiny object syndrome. That's not an uncommon thing. But if they're changing because there is something has changed in the world and we need to respond to it, that's a good thank goodness. Right. Yeah. Thank goodness that we're changing. Because if we don't, somebody else will get their first and we may not be here. So changing priorities isn't necessarily a bad thing. I need people to kind of think that when priorities are changing, question where that's coming from rather than say, oh, my gosh, product doesn't know what's going on. Oh, our leadership team doesn't know what's going on. Don't blindly execute yourself to the bottom of the ocean. Yeah, this is a problem, right? Because if you look at what do you mean when you say change, there's multiple things going on. You are in your environment and you may be doing something in that environment. But if the environment changes around you, then there's, it's essentially indistinguishable whether you changed or the environment changed. In other words, you can keep on doing the same thing, but that doesn't mean that doing the same thing is going to result in the same outcome. This is very, it's obviously true, right? Because you can say, okay, well, let's take a silly example. This is unrealistic. Let's say that I'm awake now. I might as well just continue staying awake. And I'm not going to sleep when the night falls. Because I'm awake and I don't want to change. Well, that's, that's crazy, right? Because we're talking about a different scale of changing. And to maintain homeostasis for your body, you need to sleep, right? So in a way, if you don't want to change, you should sleep, right? So, so if, let's say that the other scale that we're measuring on is growth. The company is growing, you know, let's say they're growing the revenue year over year at 100%. I don't know, some unrealistic number. And they, they don't want to change. Well, what is it that they don't want to change? Do they want to continue growing their revenue? Or do they not want to change something else and allow their revenue to sink? Right? That's, so, so I think we, we want to maintain our behaviors. But we forget that our behaviors are not the entire story. That the environment is changing around us. And so you're not the same person that you were before. You're not the same company that you were before. And certainly the things that you did before are not going to have the same effect as they, as they had previously. Yeah, I thought of pain in the butt. It makes it hard, right? How do you know what to do? Oh gosh, yeah. It's, it's really hard. And to say, you know, I'm reminded of Pixar, you know, string of hits. Not to say that they will, and they very deliberately brought in Brad Bird, who'd gotten like fired by a bunch of studios and said, we believe you will challenge us. You will shake it up. You will not allow us to go into complacency with Toy Story 17 or something. And so he, he was the, you know, the person to shake it up. And he took everybody one of his shake things up in the whole company and put them on one team. And they made the Incredibles. And so it's hard to do that. And I don't, you know, it's a, it's rough. You want to continue to see those numbers go up. And you want to continue doing something that makes you feel safe and secure that you know you can do. And that, you know, but when it all feels like it's smooth, something is coming. I mean, I hate to be the doomsday device, but like something is on the horizon. We've never, I don't think, and I'm going to get this wrong. But I think the number is that 57 or 75% of Fortune 100 will turn over the next two years. Like that didn't happen 20 years ago, but it happens today. Yeah. You know, and you've got choices to make. Somebody who's going to come for you or you come for yourself. You try to keep pushing it forward. And, and that's, that's scary. And that's hard. And your, as your company evolves, maybe some of the same people, they aren't right for it anymore. You need different skills. You need different people. You need different, you need different culture. You need a different way of working. And, and that's, I think, that idea of excelling a change. And we very deliberately put the word a cell when we were developing that. We didn't say like, be okay with change. Don't pay back for change. And that doesn't mean you change forever. Sometimes it's knowing when to hold. Like, you know what? Right. Now we're good. Bitcoin. Blockchain. I'm going to keep an eye on it. I'm not going to close it down forever. But it doesn't feel aligned to what we're doing. It doesn't feel like it's where our customers are headed. I'm going to keep my eyes open and my ears open. But I'm going to hold. I'm going to commit to some other things that I think I've seen. I'm seeing more evidence that my customer needs now. Yeah, I think that's the critical word is, is evidence. And we have the ability now to gather more evidence than we've ever been able to gather before. About behavior and not in a spying creepy kind of way. But about our customers' behaviors and the things that they care about. We have more opportunity to gather that information in more effective ways and to evaluate the information in more effective ways than ever before. And so now we don't have to just say, hey, you know what? I don't feel like this is the right direction. We can say that evidence supports that this is not the right direction. Or the more interesting version, I think, is the evidence is telling me something that I had no clue what's the case before. And now I have a new thing to reckon with. I have a new input to reckon with that is outside of my sphere of perception. I can't just imagine what the evidence is going to say. But I can look at what it says. I can actually observe it and evaluate it. And I think that's a really critical factor in all of this. Because that's really, you know, every good product, development firm that I've seen is heavily invested in focusing on what pieces of evidence support our decisions. I've seen that evolution really come through in the last several years where it has shifted that way. I mean, I think initially it shifted, sorry, you can't see my air quotes. It's like we said that, not really. And now I think it's becoming more meaningful. Almost to the point where when does that become too much? When do you lose artistry? When do you lose spark? When does everything become too... A.B. multivariated to death? I don't know. Yeah, I don't know either. There's this pendulum where it swings one too far where it's like genius is doing amazing things that nobody cares about or can use. All the way towards where is the spark? Where is the thing that challenges us? That takes us to a different place that pushes us into everything? And everybody's full of funny because everyone thinks that they're that person and they're so not. That's Steve Jobs. That's when they quote Henry Ford at me because he said if I'd asked them what they wanted they would have said it faster, Horus. Fun fact, no evidence to suggest he actually said that. And if you actually look at the history of Ford, the Model T was the right car for the right time. It was affordable, it was simple, it was reliable, it was cheap enough so that if you are a worker, you can afford one. And then you could go off and explore and have a good time. But then installment payments came. And when now you didn't have to pay cash for it, you paid paper over time. Then you had options, then you could have colors. But Model T was still in black, it didn't evolve with the times. And then they lost a bunch of money. And so you can go, you see these patterns throughout history. Where it plays out and I'll be totally honest, I just went way off the topic. But now I'll play with it. No, I think it's relevant because when you talk about making decisions for a product based on intuition versus based on data, who is right in that call, it's really hard to say because it is absolutely possible that the intuitive thing turns out to create a new set of previously unavailable. So a great book on the subject or really just a series of books, the Black Swan and a couple others by Nassim Teleb. He talks about the idea that before an extraordinary event occurs, the data would predict that an extraordinary event will not occur. So, and that's the paradox that when an outlier occurs that is beyond all other outliers, we don't have a way of expecting that outlier to occur. So we end up having these systems that predict, for example, an earthquake. And we build all of our earthquake preparations around these prediction algorithms, but all of the data that we've fed into those prediction algorithms would not be able to imagine, like humans can, that something larger than has ever occurred before may happen in the future. And that's actually what earthquake preparedness is about. It's about the outlier. And so if we're trying to become an outlier in a business, then perhaps we should consider those realities as well. But I think what you're saying here is actually more important. And that is that while it's true that an outlier may not necessarily be easy to predict, it's also true that most people, even most very successful people, are not necessarily outliers. In fact, most really successful businesses are just listening to their customers and responding well. Would you agree with that kind of summation of how product development should likely occur in the average scenario? I will have to go look at his book. That's why I like about the impact of something. Oh, I didn't know about this podcast. Oh, I didn't know about this idea. It's fantastic. And I don't have to get dressed in any fancy clothes. It's been wonderful. I think for the most people from, yeah, for most companies, there's some terrific companies. You've never heard of them. I haven't heard about it until I start to work at them. That's what you're doing. There's solving problems for people every day. They're making their customers lives better. What I like about working in the B2B realm is that I get to help businesses. And when I help a business, everyone who's touched by that business gets help too. When we help an organization listen to their customers and improve their product or get it to market faster or help their organization, they get better. They're serving their customers better. They're seeing better financial results, which creates opportunities for everyone who works there. And everyone that they serve. And that's a pretty, you know, I can tell my daughters that's why I'm leaving them a daycare today. Because I help companies and I help their customers and they're making improvements. And maybe I'm not Steve Jobs and I'm okay with that. But there's a lot of great things you can do in the world by just listening, being flexible, being adaptable. And again, take it some chances. You know what I'm saying? There's something I'm going to indicate this. Let's go for it. You know what? And if it doesn't work, we just turn it off. It'll be fine. Right. Yeah. It'll be fine. You know what? People will say, hey, we went for it. And your customers will be like, yeah, no. But we still like you. So we'll be back tomorrow. If you've ever wondered what it's like to work on a team that has the ambition, the projects, and the resources necessary to be innovative and to invest in learning, Barclays may have a role for you. Barclays is the global bank that has challenged its Developer To redefine the future of finance and make it easier for customers to manage their money. Go and check out the open roles that they have in a Wippening New Jersey, in Northam 10, in Glasgow, in London, in all of the UK. Go and check it out. Home.Barclays that's home.barcla.us slash developers at Barclays. Developers are always developing. It is an interesting thing. You know, when you have a company that doesn't have a, you know, it is that abstraction layer. Right. Where the thing that you do is helping other people do the thing that they do. And in a way, it's kind of like the manager role. Right. The manager's role is typically to help other people do their jobs. And that kind of stack of personnel and empowering other people. It can be really intoxicating in a lot of ways. But it also can have profound impact on the way that you build that business, the way that you build that role. If you can understand those people thoroughly. And again, going back to the theme of this episode. I think developers have a huge growth opportunity. If you can think about your work in terms of empowering, empowering other people. Right. Not just empowering through the product mindset, but also just empowering your coworkers. That's a different way of thinking that goes beyond just this basic skill set. It creates this, this human value in you where you understand what other people need. You're working from a place of empathy rather than purely a place of, you know, mechanical output. So I definitely encourage them. Yeah. I think you said it better than me. Yes. Thank you so much for joining me on the show. I have two quick questions. I know we're over time here, but I have two quick questions to ask you that I like to ask all of my guests. If you have a moment. Of course. The first question that I like to ask all my guests is what do you wish more people would ask you about what topic do you wish you could talk about more often? Oh, wow. Oh, that's a great question. I wish people would ask me more about. Here's a weird one. Planning. Planning. Figuring out what you're going to do. What you're doing. What you're going to do next. What's going to be the next thing? Somebody asked me about planning. Everybody asked me about what rituals should be doing. What tools should we be using? Who should we be talking to? What should we be talking about? People don't really are interested in talking about like, how do we make decisions as an organization? What should we do next? How do we think about taking this idea and breaking it down to pieces and decide what we're not going to do? Everybody wants to talk about what new thing they're doing. All I want to talk about is what are you not going to do? If you don't create space, there will be no space for all of your new stuff where that's going to go. You've got to kill some stuff and get rid of some stuff which will enable all the other things that you want to do. Until you do that, you really probably don't have any capacity and it's not going to work. That's a very good point. When you think about all of the way that you do the work rather than deciding what work to do in the first place, I think that's the productivity trap. We make the assumption that we know what's important. Then we try to work on getting those things done as fast as we possibly can. We get addicted to the concept that what we really need is more effective working processes. Most of the time, that's actually probably a thing that you're relatively good at. Working process, depending on people tend to work that out because it's the thing that we're doing most often. But the decision making process and the prioritization process, those are the harder things. I totally agree. In that consultant space especially, people should be seeking better decision making tools, better decision making processes. Then allowing those common work habits to prevail over, trying to experiment, iterate all the time on the working habits. Instead, focus on finding better priority. I think that's a fantastic way to think about it. Okay, Jess, in the last question I have for you, if you can give developers just 30 seconds of advice no matter what their background is, what would you tell them? Ask. Well, that was less than one second. That was great. Ask the question. Take a minute to when you're trying to go through your planning or you're presented with this ticket, trying to figure out what am I, what are we trying to do here? What is this about? Where did this come from? What are we trying to achieve with it? Take a minute to think about it and if you don't know, ask. Because that one little piece of information will help you come up with a better solution. Yeah. That will make you and everybody around you a little bit smarter, have a little bit more context, have a little bit more understanding. And I guarantee you somebody else is thinking. And they're not asking. And so that one little extra question, that one little extra thing to say, what's this for? Like, what are we doing? Help me understand. And most people, most product leaders, the good ones, especially, they don't shut up about that. And the fact that's how I judge you when I first meet you. So what are you guys working on? And if they just go on and they have this really nice tight script, let me tell you, I know they're good. But if they can't, you know, I have an hour long conversation. They've never told me what they're doing yet. Like, I think somehow suspect good things are not happening where you are. Yeah, it can be really tough. It can be really tough to know. You know, what level of information should I be sharing in a given moment? But if someone is asking me a question, and I can't answer it about the fundamental things that I'm doing, that feels like maybe I have some work to do. But beyond that, I think there's so much that goes on in our heads. And in our co-workers heads, that is incredibly valuable, but unfortunately never brought to the surface. And so what you said is incredibly true and can affect people's lives greatly that other people probably have the same questions that you have. And so when you ask them, you're not doing it for yourself only. It's something that maybe it's going to help you, but you're also doing it for the benefit of the people around you. When you ask a question, go ahead. Oh, no, I was going to say I just thought of something. You phrase that so nicely. It triggered a thought. Your product manager wants you to ask. Yes, absolutely. They do. Your UX designer wants you to ask because they much rather clarify in that moment and make sure everybody knows what's going on. And then for 24 hours to go by and then for it to come back up and we miss the time. Like they're doing it soon. Like, you know, the most part, it's always a good idea to soon good intent and to say like they're trying to do something. They're trying to explain it to you in the best way they have. So if you're not getting it asked because I hear it to you, they'll be they much happier right in the moment to explain it and make sure you're clear. And then to wait 24 hours, two days, three days into the next, you know, sprint review or whatever. And for that not to have gone wrong. Right. Right. And once you to ask because if they are not they're trying, but they may not be succeeding in being clear. And if they're not, you're just. So there's a way to ask that in a really obnoxious way that perhaps is not the best idea. But like for the most part, if you're if you're open and honestly trying to make sure you really understand that they're going to be so grateful that you took the time and you everything just got cleared up in the moment. So there were not wasting time and effort. Right. Yep. Absolutely. And the only way that you begin the process of that collaboration is by starting a discussion. You know, discussing something with another person. And that's, you know, you start to clarify your mental model on both sides of the equation. Jessica, thank you so much for joining me on today's episode of Developer Tea. It's been wonderful having you. Thank you so much. Really enjoyed the conversation. I have a lot of things to look up now. Yeah. I look for that. And can can you share with the listeners when your book is going to be available and how they can find it? Thank you for asking. The book is available on September 17th. And you can find it on Amazon. It can also find some other research we did at product mindset.com. Perfect product mindset.com. Thank you Jessica for joining me on Developer Tea. Thanks so much. A huge thank you to Jessica Hall for joining me on today's episode and the last episode of Developer Tea. I really enjoyed our interview and I think that this mindset that Jessica talks about in her book isn't just a fad or a bunch of buzzwords. It's actually a fundamental concept that you as a developer, you can grow from it. So I encourage you to go and check out the book when it comes out. Thank you so much for listening to today's episode. We wouldn't be able to do this without our wonderful sponsors. Today's episode was sponsored by Barkley's. Barkley's has a bunch of developer roles that are open in pretty much any language that you probably already use. Go and check it out home. Barkley's that's home.barclays slash developers. Thank you so much for listening to today's episode. If you don't want to miss out on the future episodes of this show, I encourage you to go ahead and subscribe before the show ends. Thank you again for listening to this podcast. We wouldn't be able to do it without you. And until next time, enjoy your tea.