Intro teaser

[00:00:00] Scott: Hi before we get into this one a quick, thank you to Chris who has left this voicemail about the show.

[00:00:05] Chris: Hey Scott it's Chris here, loving your podcast really well put together with a great range of guests. I think the big thing for me is you've just got some of those key insights there and takeaways for all your listeners, and I hope people like me are able to put into practice in their daily working lives.

[00:00:20] Chris: So keep up the great work, looking forward to the next one.

[00:00:23] Scott: Thanks, Chris. If you'd like to leave your own message and get featured, you'll find a link in the show notes. Your feedback is appreciated. Thank you. On with the show. 

[00:01:00] Liam: The authority to be able to say, "no", I think is a bigger part of the product manager role in practice. And making decisions about what we should do as a product team, instead of just being told or asked to do something,

[00:01:13] Liam: I've worked on a project where I had a C-suite exec saying "right test and learn where we need to use this style of we test and learn test..." and just kept repeating "test and learn". I was like, what? Yeah, but what are we testing and learning?

[00:01:23] Liam: The cost to the company, just to get to that point to test it was in hundreds of thousands, if not more. But the way they solved it in the end was they just got some new cupboards with a big sign on it saying click and collect. And that was it. That was the solution. And we tried to solve it with some high tech app.

[00:01:38] Scott: In this episode with Liam Smith, we discuss the difference between starting with a problem and starting with an idea, doing lots of things quickly versus doing a few things really well, the power of intentional ignorance and much more.

Main show

[00:01:51] Scott: Hi Liam welcome to the Rebel Diaries podcast.

[00:01:54] Liam: Hi, Scott.

[00:01:55] Scott: For people who don't know who you are would you mind just giving everyone a bit of background to yourself who you are and [00:02:00] what you do?

[00:02:00] Liam: Yeah. Sure. My name is Liam if you want to put me in a box, I would describe myself as a product person. I try to solve fairly difficult problems with technology and surrounding services and two things that I do one is consulting.

[00:02:15] Liam: I run a small consultant business working with a couple of companies at the moment, helping them to not only deliver some business critical product features, but also help them improve their processes so that when I'm not working with them, hopefully, they're continuing to ship stuff that works for the customers.

[00:02:31] Liam: And to keep me honest, I also run a small SAS startup with a couple of people that we've been working on for about a year that I'm happy to go into that's called meal pro. And that's quite an interesting one. We work with food bloggers and Instagram influences and other people to help them monetize their incomes and help people eat better really,

[00:02:49] Scott: Great and for those that don't know what SAS is?

[00:02:51] Liam: Software as a service. The background to that is a couple of customers got in touch with me on the back of an article I wrote about building meal planning app because that's [00:03:00] a stuff I do in my spare time, cause I'm a bit of a saddo, but they wanted me to build them a custom app from scratch custom apps cost a lot of money, software as a service solves that problem by building something that people can pay for as a subscription instead of having to build it as custom software, basically. So that's what we are doing. And that's how we're helping small businesses.

[00:03:18] Scott: Great and what was your career history? How did you get into this gig? How did you start out?

[00:03:23] Liam: I started just over 10 years ago, I moved to London to start a job with a global technology consultancy called Accenture. And that's how I got into the software game. I didn't know a lot about it, but it sounded like quite an interesting, thing, you get to work with a lot of different companies solving their problems.

[00:03:41] Liam: I did about four or five years there. Worked on some really interesting projects with some massive companies, global fortune 500 companies. And saw the evolution from project management to more product management that in itself introduced product ownership into the mainstream. I think in a lot of ways, in what I saw. 

[00:03:56] Scott: For those that don't know what product ownership is or product [00:04:00] management. And I do cuz I was one for a long time and I'm a big fan of that thinking what's your take on it versus a project manager. How would you differentiate the two?

[00:04:10] Liam: I had this conversation with a client I'm working with recently, and I'm gonna tell you the view that I see in reality, not the view in theory, but the view that I think happens in reality. And of course, the caveat is that you get good, product owners and good product managers and you get good project managers, and I think, some of what they do can blur you also get some bad ones that don't do things particularly well.

[00:04:34] Liam: But in my experience and this is from me doing it and from seeing other people doing it, project managers generally again, generalizing tend to shuffle a request from one place to another and get people to do it and crack the whip.

[00:04:48] Liam: It's a very, it's a generalization, but that seems to be what happens, not quite a glorified administrator, but not far away, product management and product ownership, really, in my opinion is more about [00:05:00] understanding what various people want, need are trying to do and synthesizing that into something that, as a team, as a product owner, product manager, we actually decide to do so we're not taking requests formally. 

[00:05:12] Liam: Basically the ability or the authority to be able to say, "no", I think is a bigger part of the product manager role, a product owner role in, in practice. And making decisions about what we should do as a product team, instead of just being told or asked to do something, that's my high level take on it.

[00:05:30] Liam: It's a generalization that a lot of people won't agree with it, but that's how I've seen it work in practice.

[00:05:34] Scott: In your experience, where do the project managers get their work from? Where does that come from? Because product owners are, are looking ahead. They're thinking about the problems that need to be solved. They're looking at roadmaps, they're thinking about that kind of stuff.

[00:05:47] Scott: Whereas project managers are, they're generally not doing that. Someone else has got to be doing that right though? So someone else is feeding the project manager that to then crack the whip, as you said to the people that need to do it.

[00:05:59] Liam: [00:06:00] Exactly. Yeah. Yeah. In, in, in terms of how do we know what we should be doing? I think it's such an important question. And a company I'm working with a health tech startup at the moment. I would say their product has regressed over the last year.

[00:06:11] Liam: I've only joined recently, but from what I'm told, they've introduced some features that frankly have made the product worse and disappointed customers. There's a massive gap in doing that in, in, in basically understanding what, again what the people using the product are actually trying to do, irrespective of not just with their product, but in, in their day to day jobs and day to day lives.

[00:06:33] Liam: So that's first and foremost the most important thing to me is thinking, okay, so this person is interested in using this product or this person is struggling with the problem that our product can solve. Let's learn more about that. And that is really difficult, especially if you're just starting out.

[00:06:46] Liam: If you have customers, it's easier because you can actually speak to them. If you have people who coming to your website as leads, you can speak to them. It's obviously hard to do when you're just starting out and it's hard to do in different contexts. But yeah, speaking to customers and having, call it an interview, call it an informal thing, [00:07:00] but really getting to to understand their emotional pains and what they're trying to do.

[00:07:03] Liam: And what's underserved. I think fundamentally is where I think product management needs to start and people might say, yeah that's more of the job of a user researcher or this person or that person. I think the lines in my opinion are blurred. And it depends on, what the individual and the team's strengths and skills are, but then, there's a ton of other stuff.

[00:07:21] Liam: There's a working product. So actually, there will be things that aren't working from a usability point of view from a a user experience, performance point of view, even security issues. There might be bugs. There might be whatever it is. So actually understanding what is working, how people are using it, versus how, how we think people should use it.

[00:07:35] Liam: And then everything in between. You've got a problem. You. Then you work through how we might solve it. And that's where you get all your test and learn and your let's do some wire frames and do some usability testing and let's do some AB testing. Everything fits in somewhere in between that scale, depending on the process.

[00:07:49] Liam: So a bit of a long-winded answer, but I think fundamentally it's understanding what people are trying to do.

[00:07:54] Liam: So yeah and Jobs to be Done is something that I'm getting very much into and starting to use a lot [00:08:00] more. I've dunno if you're familiar with Jobs to be Done? 

[00:08:01] Scott: I am, but if you could explain it for the listeners, that'd be great.

[00:08:04] Liam: Yeah, sure. So I'm by no means an expert. But it's something I've gravitated to naturally over the course of my experience. And I can talk a bit more about my side projects that led me to it. But fundamentally I think it's, as the name suggests, it's understanding what is a, person trying to do.

[00:08:20] Liam: And what is stopping them basically is my understanding and what you're really looking out for are the things that are high importance. So you're looking again, the emotional cues where something is really causing an issue for a person and likewise, the things that are not served.

[00:08:34] Liam: So one problem that I see when it's being applied including one of the companies I'm working with at the moment is they assume they see an underserved need. Or they see something that somebody's doing in the day to day jobs, for example it might be a nurse who is trying to make sure the ward is clean and actually they identify an issue and they wanna make sure it's tracked.

[00:08:51] Liam: They might be using Excel for that. And that might be working well for them and the team. And actually what they're trying to achieve is getting done[00:09:00] so that in, in some ways might be a quite a well served need. 

[00:09:03] Liam: Jobs to be done helps you understand, the theory helps you understand what are people trying to get done and then, okay.

[00:09:08] Liam: What of those things are actually being served quite well and what things are underserved. And then it's really the underserved things that are important to people those are the things that as a product team, product person try to focus on. And as I said, it might not be delivered through your product.

[00:09:20] Liam: It might be delivered through additional training or services or, or it might be suggestions on how they can use your product alongside other things. 

[00:09:28] Scott: This is linked into user empathy isn't it? I've often said you need to get out in the environment and observe users, asking people in a workshop scenario will go so far, but you probably will get out artificial answers, whereas nothing beats, real world , get out there, get the whole team out, see the users, struggling with things.

[00:09:50] Scott: See the environment they're working in. It's very easy to sit in the boardroom or the office and just assume isn't it?

[00:09:57] Liam: Absolutely. Yeah. So it's something I'll [00:10:00] admit. I've fallen fall of early in my career when I was working. When I started my career as a consultant, which never quite sat right with me because I felt like if I'm advising companies on something, I feel like I should have done it myself first, which is why I work on my own side projects.

[00:10:15] Liam: But there was a big trend. I dunno if it's still the case where we're trying to set up sort of innovation labs in these massive companies, because their IT departments were so clogged up with everything else going on. 

[00:10:27] Liam: So " we need to innovate, we need to do this".

[00:10:29] Liam: And it's always you know's high tech it's " what apps can we release?" And the problem is you get some C-suite executives say "we need to do something with an app" or "we, spoke to this startup. We need to let's try and integrate this technology for our customers- test and learn".

[00:10:42] Liam: I've worked on a project where I had a C-suite exec saying "right test and learn where we need to use this style of we test and learn test..." and just kept repeating "test and learn". I was like, what? Yeah, but what are we testing and learning? And I've got a problem with that statement itself, cuz to test anything you need to start somewhere and already, I think you're already past the point at [00:11:00] exploring what are the main pains that people are struggling with.

[00:11:03] Liam: If you order a parcel for click and collect into a retail store on the high street, we introduced again using a startup that on one of my first days working on the project with this company, I was introduced to the startup.

[00:11:14] Liam: They showed me a demo and said " we wanna trial this out in our stores" okay. And I'll be honest. I was naive. I went along with it and we introduced this click and collect trial. So basically customers would have to download an app from the app store when they're near the store, we'd use beacons, it would go, "oh, I can see you're in the store near the store. Do you wanna pick up your parcel?" 

[00:11:31] Liam: So we introduced it into seven stores where it still took about six months to get to that point, which for the company of that size was quite quick. Introduced it and lo and behold, it was just, it just felt completely flat. And the expense I know my day rate at the time was ridiculous.

[00:11:48] Liam: And everyone else is, similar. So the cost to the company, just to get to that point to test it was in hundreds of thousands, if not more. And you think that problem, it was never really a problem we were solving [00:12:00] because getting to store to collect a parcel, first of all, isn't a major issue.

[00:12:04] Liam: But even then the way they solved it in the end was they just got some new cupboards with a big sign on it saying click and collect. And that was it. That was the solution. And we tried to solve it with some high tech app.

[00:12:17] Scott: Can I just check that? So the idea was the customer just happens to be passing a store, have forgotten that they need to pick up a parcel? And it just pings 'em and says, Hey, you're near a store. Your parcel's ready. Is that the problem they were trying to solve? It sounds like a made up problem.

[00:12:30] Liam: That bit was never properly defined. And I think the assumption is, yeah, they're going to store and then what, we can get ahead of time. And, we know when we know they're coming, we can go and get the parcel ready and we can be ready for them. But again, we're not really solving a critical issue there.

[00:12:44] Scott: No that's solving an organizational problem. Isn't it? It's about getting the parcel or quick what's yeah, the customer. Yeah. Okay.

[00:12:53] Liam: So it was an interesting one. Yeah. But again I think we've, we talked about before the, there's a difference between starting with an idea and starting with a [00:13:00] problem and the health tech startup I'm working with at the moment. Even the language they use in internally, there's a lot of, oh, what about this idea?

[00:13:06] Liam: I've heard someone on the Slack channel say, "oh, wouldn't it be cool if we could have a winter theme, like this app that this company does it", and then people start responding and then you get people weighing in. "Oh yeah, let's do this. "That, that didn't happen in that case. But other things like that have happened.

[00:13:19] Liam: And I have to explain to people any time I hear "nice to have", or "wouldn't it be cool if", or "what about this idea?" I just shake my head 

[00:13:28] Scott: Trigger words!

[00:13:29] Liam: I actually explained this to a customer on my side. Yeah I explained this to a customer on my side project the other day, she was giving me feedback about what her customer's using with the app that we've developed what they're saying.

[00:13:38] Liam: And she said, oh yeah and this person said, "it'll be nice to have". And I said, "I'll just stop you there. I'll be honest, anytime I hear nice to have I take it with a pinch of salt" and she just, and then next time she said, "oh, and this customer said, it'd be nice". And then she just smiled and laughed at me.

[00:13:51] Liam: But yeah. Fair enough. 

[00:13:53] Scott: So I, and I get it cuz I've yeah, I've seen it as well. And in the C-suite I call it the shiny effect where it's [00:14:00] oh, shiny tech. Let's just do it because we can, or even because it looks good on my CV. I had a previous guest talk about that and I've seen that myself and I found myself as a product owner defending the customer from this crazy idea that was driven by reputation rather than empathy for the customer.

[00:14:21] Scott: And it was also based on all those assumptions around it's cool tech, so everyone will want to use it. And it was just represented a complete misunderstanding of customer need and behavior. And yeah, I'm with you on that. The product owner fiercely needs to protect the customer from organizational madness.

[00:14:40] Liam: yeah, you summarized it really when you said defending the customer and it is so true. It introducing any new feature can make things more difficult for the customer to do what they're trying to do. And like you said, gotta be vicious in, in, in how strict we are.

[00:14:55] Scott: Yeah, and it took me a while to get my head around as well. I used to, earlier in my career, it [00:15:00] was about the more you produced the better or the better regarded you were, cuz you produced more stuff. Whereas learnt over time the hard way actually it's about minimalism.

[00:15:09] Scott: It's about what's the minimum we need to do and simplicity always works doesn't it? So especially when you're building products and interfaces, it's like there's some companies out there that are really strict. They could expand their product to do loads of different things, but they say, no, we're just gonna be really good at that niche thing.

[00:15:27] Scott: Because that I've seen plenty of products that overlap, even if you don't wanna bad mouth Microsoft, but if you look at their product offering, I see they've just offered a new version of outlook in preview that. Strangely has this pinning feature in your calendar that looks remarkably like their planner app and Trello.

[00:15:44] Scott: So I'm like, it just confuses users when you've got all these overlapping capabilities on products.

[00:15:50] Liam: Yeah. Yeah, it's it. I agree. It took me a while to realize that as well, and people will if I think focusing on yeah. Solving the main problem and [00:16:00] actually just solving it enough and people will quickly tell you what else they need or what else they want, if they start using it. And it's much easier to do that than to introduce a load of stuff and then try removing it cuz no one ever does.

[00:16:13] Liam: And again, like the, one of the companies I'm working with at the moment, their product is so bloated and whilst I have a lot of respect for how developers work. It's quite evident that a lot of the product is being designed by developers with just so many fields that make sense from a data model perspective.

[00:16:31] Liam: In terms of how logically how you would build something, but not necessarily how you would use something and that. Yeah. It's yeah. It's an interesting one.

[00:16:39] Scott: Yeah, developers are great and I've led teams of developers and they can change the world. And one of them even said, "developers will destroy the world one day "But um, years ago we had a developer was working on his own and I can't remember the product, but it required a search.

[00:16:56] Scott: And the search he produced was technically very [00:17:00] clever, but from a user experience perspective, awful cause like I was kept saying "we need to just one search box, just make it simple". But there was all these different filters you could apply and advanced searching capabilities. And it was, it was the developer showing how clever they were he wasn't doing it out of, bad behavior or anything like that. He was trying to offer a good solution, but had to keep winding him back and say, "this needs to be simple this is just overly complex for the customer".

[00:17:25] Liam: When you get into solutions mode, and it's very easy to get into solutions mode, once you're in that mode, it's very easy to then start thinking, "oh what if this, what about that? What about that possible scenario in that could happen in six months time? "

[00:17:37] Liam: Again I've heard people saying "future proofing" this week when I've been in calls and I'm like, "yeah, you need to think about the future, but you can't design, you can't build everything for the future. And if it's not a problem right now, then let's not try and solve it". And like you said about pairing it back to, making it simple for the user.

[00:17:55] Liam: So something I'm trying to do with with one of the companies I'm working with is get more alignment. [00:18:00] Yeah. Like you mentioned about, C-suites trying to do things shiny that don't really help the customer to try and get more alignment across everyone in the business. It's only about 50, 60 people.

[00:18:09] Liam: So it's doable around what the core needs that we are actually trying to solve with the product and actually not even with not what we're trying to solve with the product, but actually what the customer's trying to do, that they're struggling to do, which again is back to the Jobs to be Done what we were talking about.

[00:18:24] Liam: So already, there's a couple of people in the product team who are doing a ton of customer interviews, picking apart certain workflows in terms of, when something goes wrong as part of an inspection, how do we actually resolve that issue? A very simple thing, but in, in terms of the product that is available right now, massively over complicated and people don't use it and they're using Excel.

[00:18:46] Liam: Which actually, I know I mentioned earlier could be like quite well served in, in some cases it's not. So there is a room to to solve that from a product perspective. But that is gonna be big undertaking. I think we're gonna have to, like you said, get everyone out in front of customers and if not in [00:19:00] front of customers, at least relaying the feedback that people are saying and then hopefully charting something in terms of, these are the customer journey flows, the things they're trying to get done.

[00:19:07] Liam: This is what's underserved, and this is where we need to focus from a kind of product perspective. It's a big undertaking, but, series of workshops and all that good stuff. But I think it's the only plausible way I can see forward in, in that particular setting.

[00:19:18] Scott: On the idea of product management and product ownership and I do interchange those terms. I probably shouldn't, management is, tends to be the more senior role, more strategic. I'm doing an air quote for people who are listening and can't see me, cuz strategic is a word that gets banded around quite a lot. It's almost lost meaning, but I've always thought that concept of, if you break it down to somebody in the organization who is trusted, who is the business lead, who is thinking about the customer who is empathizing, has the skills of a business analyst, a project manager, but that business lead being really key.

[00:19:54] Scott: I think that's, that applies beyond just the software development space. It's about that service. Have you [00:20:00] seen that work well in any organizations or outside of development or have you mainly been in the development space?

[00:20:07] Liam: I've mainly been in the development space, but I yeah, one of the companies I'm working with consumer electronics manufacturer well- known brand the team I'm working with, are more on the marketing side around how to market the products and actually what we are helping them with.

[00:20:20] Liam: What I've been helping them with is build a content management platform and website that allows them to market it. So in that sense I've worked across different areas. But I totally agree with what you're saying. I think I'd pick up on one point just before I answer your main question. I agree that, there needs to be somebody who is thinking about that stuff and has the authority and responsibility, all that good stuff. But I don't feel like it's something that can be delegated. And it's what I'm finding at the moment is people feel, oh yeah, we can hire a product person or we can hire a designer or, they'll solve this, they'll work out what the customer needs, but, as a founder of a startup or a leader [00:21:00] within a business I fundamentally don't know if that can or should be delegated to another individual. I feel like that should be part and parcel of what everybody is doing is understanding what customers needs, in a for-profit business even in a non-for-profit because what else is there really I that's what I struggle to understand it cuts I agree. It cuts across everything or it should could across everything. 

[00:21:21] Liam: Have I seen it done well, no, I think the way I tend to, work with companies, I'm generally brought in within the product function, or software development to deliver something and help in terms of processes because it's not working as well, or there is a gap in expertise and it often feels like I'm having to try and coach people above me in terms of whether it's the client or in terms of, the organizational rank. On the fact that we should be listening to customers. We should be doing more user research. We should have a user experience designer is literally a conversation I'm having to have at the moment. So I've not seen it work well.

[00:21:55] Liam: Have you seen it working well outside of software and [00:22:00] product?

[00:22:00] Scott: No but then my career up until setting up Digital Rebels last year was 20 years in one organization. So we brought in agile methodologies thinking and product ownership was why was the only product manager if you like in the organization? And it worked well, cuz we got to a place where we were trusted and I was the business lead and we were absolutely protecting the customers and the organization and delivering that empathy and challenging assumptions, all that good stuff.

[00:22:31] Scott: But beyond the development and that did apply beyond the development space actually, to be fair.

[00:22:35] Liam: Yeah.

[00:22:36] Scott: But yeah, what you said is interesting, it's almost like I'm really surprised and I guess I shouldn't be that these companies you are coming across are wanting to outsource effectively the responsibility of understanding their customer's needs.

[00:22:53] Liam: It's how it feels sometimes.

[00:22:55] Liam: It, maybe that's a bit unfair. Maybe, maybe that is unfair, but, and maybe it's the [00:23:00] nature of what I do. I'm I suppose, an external consultant and people bring that expertise in for a particular reason maybe because they don't feel they possess it as an individual or the organization is lacking.

[00:23:11] Liam: So maybe it is skewed. And of course, there are companies who do that really well and probably do rely less on external consultants and, whether that's on a contract basis or more on a kind of consulting basis. 

[00:23:23] Scott: And I, I get that. I think to be a product owner, or manager, you need to have a certain mindset. You need to be wired in a certain way. And I get that some organizations won't have that, but I don't think it's sustainable for that to go long term, I think. Yeah. Get someone in short term to understand what it's all about.

[00:23:42] Scott: But surely you want to bake that into the organization, make it part of the organization's structure. If you can. Cuz I've long said change should be not an addon, not a separate thing, let's normalize change. Let's just make it that the organization [00:24:00] thinks in that way. Embraces change moves at pace, along with your customer's needs and the changing world, not, oh this big change thing.

[00:24:07] Scott: We need someone else outside to do it for us. Cuz then you just doesn't feel sustainable to me.

[00:24:13] Liam: I totally agree. And I, again, like maybe it's the context of the organizations I've worked with, for example, global fortune 500 companies who maybe have monopolies in particular area can fall foul of not needing to do as much as that and still be successful, obviously, not in the long term necessarily, but and another company I'm working with at the moment is a , start of more scale up.

[00:24:34] Liam: But again, at that size of organization, I guess it is quite common maybe to lose sight of the initial problems we're solving as a company. I dunno if you've read Base Camp's Shape Up. So Base Camp being the project management software they write a lot of books about how their processes work and things.

[00:24:50] Liam: And I think they're a big proponent of Jobs to be Done as well, actually. But again, they're a similar size when they wrote Shape Up, they were a similar size to one of the companies I'm working with and a lot of the issues they're [00:25:00] facing at the moment, which is they're not really shipping things.

[00:25:02] Liam: They're struggling to ship new features regularly are and they're also not necessarily hitting the mark with what they do ship sometimes, and that's what I'm seeing as well. But I think

[00:25:10] Scott: What's causing that? Why are they not hitting those? Why are they not able to ship regularly?

[00:25:15] Liam: Taking on massive projects that just clog up the pipeline is an issue. And I think. What I've been trying to do and what starting to do as well, actually is breaking things down into smaller and more manageable things. Even time boxing to like eight, eight to 12 weeks in terms of what can we solve within the eight to 12 week period and getting stuff out into production is a way to solve that I think.

[00:25:35] Liam: Every C-suite every founder, every whoever wants to deliver at pace. And they think seems to me, my experience by and large people think it's about doing lots of things quickly, as opposed to doing a few things really well. 

[00:25:49] Liam: And again, back to your earlier question about product versus project product is always thinking about the long term effective things or at least medium term, I think.

[00:25:59] Scott: Yeah [00:26:00] versus project, project by definition has a start and an end, whereas a lot of software and products don't ever end until people stop using it. So the worst thing I've seen is where an organization launches its website or its intranet, and then says "job done, project finished."

[00:26:16] Scott: And then the whole thing just gets neglected for the next few years. And then they wonder why everyone hates it because no one was actually keeping on top of it. Yeah.

[00:26:25] Liam: Internets are probably the worst thing for that as well. I think.

[00:26:28] Scott: Oh yeah, absolutely. . So when we launched our intranet I said the day it launched, I said to the team "right now we start really" cuz that's when all the requests came in from, vanity content. " Oh we like this new internet. Can we put all this stuff on it?" And again, we were protecting the organization from itself.

[00:26:43] Liam: Yeah.

[00:26:45] Scott: But yes, they just, yeah. People just think, oh, that's job done. Move on to the next thing. 

[00:26:49] Liam: it's, yeah, that, that is the first question that goes through my mind as well. When someone requests something it's " why do you need it?" And what you're saying about like C-suite and sales teams and others, people will say to the product team, "oh, the [00:27:00] customer needs this". " Why?" 

[00:27:02] Liam: And that, probably one of the more challenging things I'm working with at the moment.

[00:27:06] Scott: And that getting that evidence I've always thought there's a couple of bits there. There's one is it requires effort and energy, which a lot of people don't have time to do, cuz they're so busy. So it's easier to just jump to a solution. And the other thing is there's a risk that your assumption could be wrong and people don't like to be wrong, cuz you know, some people take that personally ", oh, I'm maybe not a good expert in this area because I tested something and it was wrong".

[00:27:28] Scott: So better to 

[00:27:28] Liam: Yeah. 

[00:27:29] Scott: fool yourself and make an assumption. Whereas the whole thing around learn what doesn't work to get better is really powerful.

[00:27:37] Liam: Exactly. And I think something I mentioned earlier when we spoke previously about intentional ignorance, I would say over my, 10 years only the last few years really do I feel more competent in, in in the product role, because, I know enough about software development and, understanding customer needs and a bit of marketing and a bit of this and a bit of that.

[00:27:57] Liam: But the more I try and act like I know nothing [00:28:00] ask really dumb questions, not just with customers, but internally as well. I'll happily post on like Slack channels with companies I'm working with questions.

[00:28:07] Liam: I probably know the answer to, but it's an assumption like I'm 90% certain I know the answer to, but I'll still post it. Even if people think it's a dumb question, same with customers. I might go in with an assumption. I have to be aware that assumption could be wrong and it's not just testing an assumption cause you're looking for confirmation biases.

[00:28:25] Liam: It's really trying. And it's really difficult, especially when you work on something for a long time and you say, oh, I spoke to 10 customers. They all want it like this. It's really hard to have that intentional ignorance, but I feel like the more I more, I do that and the more I can do that, the better a product person I feel I am.

[00:28:40] Liam: And the better product that I'm delivering based on what customers are telling me as well.

[00:28:44] Scott: Yeah. I can't remember where it was. I read it or it might have been on a video I was watching, but it was like, kill your idea. Like just do everything you can to kill it, to prove that it is a bad idea. That's the only way you really find out where the value is.

[00:28:59] Liam: [00:29:00] Yeah. Yeah, absolutely so with meal pro app, I again, I I was doing some consulting work back when I started 18 months ago, started doing proper research around it. A couple of customers were asking about, oh, "can you build me this app? Can you do this? Can you do that?" I was like, you know what? I'm quite enjoying my cushy consulting lifestyle. It's comfortable money's good, et cetera.

[00:29:18] Liam: I want to disprove this idea. , I wanna try and get to a point that I don't think it's a good idea, cuz I it's, not that I don't want to do it. It's it wasn't necessarily on my plan to do it. So I just created a simple coming soon page. Based on what customers had told me, like literally two or three customers I'd spoke to got a few mockups done with a designer on Upwork, got them up, ran a few Facebook ads so that customer about a thousand dollars.

[00:29:39] Liam: And then I spent about $300 in Facebook ads, I got 25, 30% conversion rate on the page. I was like, okay, that sounds promising. But even then, still not sure I want to go ahead with this.

[00:29:49] Liam: Cause there's a lot of work to build a new product from scratch. And then yeah, I spoke to a few people and ended up pre-selling it to a couple of people gave them like a year long subscription for a discounted price of a, like $500 or [00:30:00] something. So I'd, pre-sold it at that point and again, along the process, although it sounds like, oh, you've, pre-sold it.

[00:30:05] Liam: I wasn't trying to pre-sell it. I wasn't trying to validate it. I was trying to disprove it. And that's an idea that I've tried to adopt since then, as well about what the product ideas that I've had.

[00:30:17] Scott: Yeah. I've heard asking people, would they buy something and you get, yeah. Loads of people say, "yes, I'd buy it". But when it comes to parting with money, it's very different. And the whole thing about customer research in an office, we go and speak to customers about what they'd like and someone pitches this great snazzy idea to them and they go, "oh yeah, I like that. that looks cool". And there's also biases and behaviors and they don't wanna be negative. They might have been paid for their time. They might have been given a nice buffet lunch in this session.

[00:30:47] Scott: And then, they're gonna be, they're not gonna give a realistic response to real world use, which is, what you did was actually get it out in the real world and start, take some money and then you've got some, you validate the things haven't, you.[00:31:00]

[00:31:00] Liam: Exactly. Yeah. It's hard to do, but that's the point and I've tried several things in the past in terms of startup ventures. But again, software products I thought might work and a lot of them would fallen flat on the face. And I used to think it was a bad thing. I used to think, oh God, I'm, I dunno anything.

[00:31:16] Liam: I think it's a good thing. If I try something and it doesn't work. So I'm like, actually that's gonna save me a lot of pain. I tried to get a bad idea off the ground, even then starting with an idea. Isn't something I tend to do now. Like my approach is I try not to do anything until people ask for it unless somebody is struggling with something or is specifically asking for something who can tell me a good reason why they need it. I just won't do it. And maybe that's another issue in product is when we don't have an influx of new things, we should be building. We find things to build so we could do get mature products that continue just getting worse and worse when they don't need to like, even Apple's iOS software went through a phase.

[00:31:56] Liam: I think it's getting a little bit better in my opinion now, but there was a [00:32:00] few years where it was still not perfect, but whether they're just doing extra things, it was just like, you're just making it worse and harder to use for people. And I do think it's a, there's a case of I'm in a job I'm supposed to be doing things.

[00:32:12] Liam: I need to find stuff for me to do.

[00:32:14] Scott: Yeah,

[00:32:15] Liam: Sit on your hands. Enjoy yourself.

[00:32:18] Scott: I think it's also probably driven by that whole feature bloat and marketing around saying, Hey, new version this year, we've added 300 new features for you. That's, helps sell products. Doesn't it? Whereas people think, oh, 300 new features. Great. And then probably use like two of them.

[00:32:34] Scott: If that it just adds complexity and bloat. 

[00:32:36] Liam: Yeah. 

[00:32:37] Scott: It's been great chatting to you one of the things that I ask all my guests if you could take one book with you to a desert island, what would it be?

[00:32:44] Liam: So I have thought about this question because I have listened to some of the podcasts

[00:32:48] Scott: Ahh you knew it was coming.

[00:32:49] Scott: I did the first one I put down, but this is more a book I would gift, I think is, and I'm gonna mention it cuz I think everyone should read it It Doesn't Have to be Crazy at Work, which is by the Base Camp team again.

[00:32:59] Scott: [00:33:00] I feel like it's if a hippie took over an organization and just made everything just a bit nicer to work. But in terms of what I would take, I think it would be the old fashioned encyclopedias, the ones that have like pictures of sharks and stuff like that.

[00:33:11] Scott: And just loads of knowledge of I think the curiosity, I think it's the thing that defines me as a person is a curious person. And if I had to sit on a desert island with a book, I think it would just be something I could just spend hours learning about random stuff that I'll never need to know about again.

[00:33:27] Scott: Great, so if anyone wants to get in touch with you how do they do that?

[00:33:32] Liam: Yeah, so LinkedIn, I think is the best place to contact me for consulting stuff. Yeah. So I think you'll post a link to my LinkedIn profile. It's just forward slash Liam Sean Smith, I think SEAN.

[00:33:43] Liam: Also, if you wanna check out meal pro app, that's just mealproapp.com and yeah, you can sign up for a free trial if you want to just have a play around with the product.

[00:33:51] Liam: Yeah. So between the two.

[00:33:53] Scott: Great. Thank you. I'll put those links in the show notes, Liam. It's been a pleasure talking to you. Thanks for coming on the show.

[00:33:58] Liam: Yeah. Thanks Scott. Thanks for having me.

Outro
A big, thank you for listening to the Rebel Diaries show. Your time is precious, so thank you. It is appreciated.

We've got more amazing guests lined up so be sure to subscribe for next week's episode.

The full show notes and links to things we've discussed can be found on the website, www.rebeldiaries.net.

Finally, it would really help us out if you can spread the word with your friends and colleagues about the show.

Take care, be a rebel and deliver work with impact.