Holistic Problem Identification
00:00:00
Speaker
I told them that yeah I'm willing to to approach any problem and and document any problem. like if you're If the people who work at the facility don't like the coffee, and I hear that from everybody, I'll make sure that I write that down and let you know. But you know the the problems that we identified weren't typical software problems. right We weren't just looking for, all right, well, what are your digital problems? We were looking for, holistically, What are the problems that all of your employees are encountering? What are the friction points and what would make everybody's jobs easier?
Podcast Introduction
00:00:36
Speaker
Welcome to the forward slash where we lean into the future of IT. I'm Aaron Chesney with my beautiful co-host James Carmen. James, who do we have in the hot seat today? I love that word beautiful. Thank you. Thank you very much for that. um It's radio. They don't know a line. Yeah, that's true.
Guest Introduction: Ryan Wilson
00:00:57
Speaker
Today we have Ryan Wilson with us to talk a little bit about the the world of product. Ryan, introduce yourself a little bit and tell so tell us a little bit about yourself, please. Sure. Hey. um Well, my name is Ryan Wilson. I'm the product practice lead at Caliberty. I've been working in the field of product for almost 25 years at this point. I've got a degree in human computer interaction.
00:01:25
Speaker
That's excellent. Can you tell us a little bit about like, when when you say product and we talk about product, we kind of throw that word around and I know it it might mean different things to different people. maybe Talk a little bit about like, what do we even mean when we're when we're talking about product?
Understanding 'Product' Holistically
00:01:37
Speaker
Sure. um Well, I kind of gravitate towards Donald Norman's definition of product. So Donald Norman is considered the godfather of user experience. And back in the 1990s, he was working for Apple's product department and thinking about what the best way to create products that will resonate for people. And what that meant was the holistic output. It wasn't just this, once you get the computer and turn it on,
00:02:08
Speaker
How does interacting with that make you feel? It was, what does the packaging look like coming from the factory? How how is that product displayed in in a store? Does it look daunting? Is the packaging created in such a way that you're able to carry it out of the store easily and get it into your backseat without too much trouble?
Experiential Products in Services
00:02:30
Speaker
How is the box designed once you open it up and think about how to take things out and get everything set up? And then ultimately how it looks sitting on your desk, but also, you know, how do you, how do you interact with it? How does it work when you turn it on?
00:02:46
Speaker
I know a lot of people talk about like when the difference between like a product based business and and kind of you know our business being the services based business for products you consume them whereas for a ah Service you experience it, but what you're talking about sounds a lot like an experience right though You're thinking more about an experience even in the product world. So can you talk about that a little bit?
Start with Problem Understanding
00:03:07
Speaker
Sure Yeah, I mean to me good products mean something that has been well thought through ah For both what the stakeholder wants the product to be but also for the audience who's going to adopt it and so you know to get to that level you really have to start at the beginning start at product discovery and
00:03:25
Speaker
start thinking about what is the solution? Well, actually even further back than that, what is the problem we're going to solve here? Who's the audience that this problem is going to solve it for? Let's talk to them immediately and find out if their problem aligns with what the stakeholder thinks is the problem. And then get alignment from the stakeholder on this is the thing we think we need to solve.
When Not to Build
00:03:48
Speaker
And here's our potential solutions to a 20,000 foot level before we you move into a product definition phase. is the answer ever. there The solution is to not provide a solution. Often the solution is sometimes you don't need a solution. If you meet with the intended audience and they don't have any friction points or frustrations and you know the the product that your stakeholder wants you to build doesn't do anything for your audience and you've proven that that audience is the correct audience and not an edge case or a secondary audience and there is a an audience that the problem solves for
00:04:24
Speaker
then recommending not to build is just as equally as important. I had a professor in one of my classes once say that you don't want to be a solution looking for a problem. Always make sure that you have a problem that you're providing a solution for. That's well said. Yeah.
Ryan's Journey: From Architect to Product Designer
00:04:47
Speaker
How does one, or maybe it's not a general thing necessarily, but how how did you get into like, how did you get to to you know, decide, hey, i I want to do this for a living. How did how did Ryan Wilson arrive at that? this is This is what I want to do when I grow up. Man, that's a great question. I i stumbled through what I want to do when I grow up for so long. um I figured, you know, by the time I got to college or before college, I would know what that was. um Early on, it was I wanted to be an an architect during the day and a standup comedian in the evenings.
00:05:24
Speaker
um But I learned that my stand-up routine isn't so great um early on.
Education in Visual Communication
00:05:33
Speaker
But the the thing that got me was, so when I when i was an undergrad, websites were becoming well-designed, well-thought-out websites were becoming more of a thing. And you know to date myself, this is the the time of the internet explorer Netscape Battles, who who was going to provide um better internet display.
00:06:03
Speaker
I was trying to make my own major because I gelled with what marketing was, and but I gelled with what ah visual communication was. And so I went and I pitched yeah i'm I'm going to create my own major. This is what I'm going to do. And these are the courses I'll take for it. And the person was like, have you heard of the School of Visual Communication? And I said, no. And so I went and talked to them. And they had a website design and animation design um program that was called Interactive Multimedia. And yeah again, dating myself, ah we were focused on creating interactive CD-ROMs.
00:06:42
Speaker
And so that was a big focus and and creating things in director and writing in a coding language called lingo. And that just made, like entering that program, I was excited about every project that I did in every single one of the classes.
Love for Problem-Solving
00:06:59
Speaker
I've always been a problem solver. And so that allowed me to approach these new problems that I've never had before and go about solving them in ways that were still, you know, at the time, I went into a career of creating e-learning modules for the medical community, for the legal community, for e-commerce training. I did a coffee training module for baristas, for the franque symphony in the early 2000s. But that's that's generally why I think I like product consulting, is that every problem is new.
00:07:40
Speaker
And so again, getting back into the whole idea of of product discovery, I love going in and hearing what the problems are that the stakeholders are having and what their audience is having and and diving into that and understanding it as quickly and as thoroughly as I can, and then coming up with different solutions on how we might solve the problems that they're having. and And for the younger audience, I just want to say a CD is this little plastic disc that you would put into a slot and it would hold information. So you may not have seen one in your lifetime, but that's what they are. Uh, you could have used, it's like a DVD, but I don't think nowadays nobody, it's kind of the same thing, right?
Product Design Insights: Xbox vs. PlayStation
00:08:26
Speaker
It's like, eh, in a DVD is another plastic just that they put movies on or software sometimes.
00:08:34
Speaker
So Ryan, is there is there a product out there where you've you've taken a look at it and like I said, you know I really like what they did with this. i they They really put some thought into what they were putting out there. Let me start by saying this. I am a picky consumer. Based on what I do, I have high standards for everything that I i buy or or everything that I use. um So you know I don't know if I have a ah perfect product that I've ever used, but I think most recently, and good a good comparison is the the new Xbox Series X or whatever it is, and the PlayStation 5. I have both of them for specific games for each of the platforms.
00:09:26
Speaker
And I love the PlayStation 5 because it's clear that they've thought out everything about it. Not just the digital interface, but the machine itself, where it sits, how it brings in the air so that you're not sucking in as much dust in comparison to how I think the Xbox is laid out. But down to the controller. like They've thought out how the controller works and how when you press the buttons it has a softer feel and a softer sound. So I'm moving the the sticks around and there's not a bunch of clicking.
00:09:58
Speaker
as opposed to when I was playing Starfield last last fall on my Xbox and my wife's asleep in bed beside me. And I'm going, clack, clack, clack, clack, clack with the Xbox controller because they just took the older controller and put it in a new plastic housing, but didn't think about how to buffer the sound or how even if that... Is that a good experience for somebody? Is is the way that these buttons feel and the noises it makes Or yeah did they just ship it because it was cheap? And some gamers love that hard, tacky, click, click, click, which I'm like, well, not if you're streaming because then it comes through your mic and all you hear is tick, tick, tick, tick, tick. And it's like annoying.
00:10:44
Speaker
it's I mean, I like that too, right? With their keyboards, with the clickety clickety keyboards. i I don't like, yeah. i don't But I mean, that there ties back into product, right? it's There's all this subjective things that you need to think for think of. And so again, that goes back to part of that problem problem or product discovery.
00:11:07
Speaker
It's not my opinion. It's never my opinion. it's my I think of myself kind of like a private detective. I come in, I try to get all the facts, I paste them up on a wall and I bring red string between everything, but I need to know what their audience wants.
Audience Preferences and Product Decisions
00:11:22
Speaker
Because if the audience wants ah clacky remote and a clacky controller, then that's probably what we're going to ship because at least holistically or a majority of their audience wants that, then that satisfies a need for what they have. If there's no preference, then you know we could recommend going with something a little bit softer. And again, I'm talking about physical products, which the the discovery for physical products and the discovery for digital products are fairly similar.
00:11:57
Speaker
i' fun I've even used some applications where they've added in like clickety clack sounds for when you're typing so that it, it sounds like you're typing on it. Now it was a typing tutor, which made sense, but you could hear your rhythm and, and actually as you were doing it, it was like, I kind of see why they did that. It kind of helps you feel your pace. and in notice that you're getting faster as you're learning. And I'm like, oh, that's kind of a cool little aspect of ah
Ergonomics and UX Evolution
00:12:30
Speaker
of that. And if that wasn't a forethought, that probably came out of usability testing where the feedback they were getting from the people who were doing the test is like, yeah, I'm trying to type, but I can't hear where I'm at. So, you know, if I had a metronome style field, then maybe I'd have something to pace myself against.
00:12:50
Speaker
Yeah, i think I think that application probably predated usability testing. um I ran it on Windows 95. Probably not. They've been doing ergonomics and human factors since the 50s, if not earlier. So the the field of what is now referred to as UX user experience has been named so many different things over the course of about 100 years.
Uncovering User Preferences in Testing
00:13:25
Speaker
I would imagine, I mean, product's not my world. I'm um traditionally a software engineer, so it's, you know, a little different background. But like, I would imagine there's, there are times where, you know, like you're talking about here, Aaron, maybe, you know, just using two different products, the clickety clackety, they don't pick up on that's why they like it better. Like they can't articulate why one is better than the other. Do they teach you special techniques like in the product world? Are there, do they, you know teach you how to figure out like and dig into that and really you know get that out of the user and understand like things they can't articulate on their on their own like to help them articulate what what they like about a product? Yes and no. What I found works the best in both, so it's not just usability testing, it's it's interviews, it's observations, is sitting with the user and letting them talk.
00:14:17
Speaker
and hearing what they have to say. And the the more silent you can be, the more you're going to draw out of them. Nobody ever really likes an uncomfortable silence. And so if you ask a question and they answer it short, you can do a six to 10 count. And usually they'll start to backfill other things that they're finding a problem with. and i've actually much like podcasting, ah you start off with questions where you know you're going to get an easy answer and you're going to get them comfortable with giving you feedback. And so by the time you get to your actual questions, which you want to keep them short to like maybe 10, 12 questions at most, but by the time you get to question four, they're on a roll and they feel comfortable giving you
00:15:01
Speaker
any sort of feedback, if it's back to the key analogy, that's where they might say, well, you know, when i when I press on this key, I really want to feel it click and I want to hear that click. And that way I know that whatever process is running. On on the usability side, I've also seen in some of the usability tests that I was able to participate in is that sometimes when you don't say anything and you're watching their screen, you can see where they're lost. Like if if you ask them to do a simple thing, it's like, where would you go to save a file? And you can watch their mouse kind of float around the screen and not see them finding a solution is like, oh, well, if they don't know where to go to save it, maybe there's a, you know, something that we need to change in
00:15:59
Speaker
in our interface so that we it's it's a little bit more apparent so that they're not lost in that kind of view.
Usability Testing Challenges
00:16:08
Speaker
it And you also need to consider how many tests are you performing, and is this an edge case? I ran a series of tests, well, more than a decade ago, ah where the So you you capture time on task to typically. So like the time that they start the task to the time that they complete it. And up until, I think I tested with eight different people. And so the first seven people, the time on task for this was, you know, somewhere between 30 and 45 seconds.
00:16:39
Speaker
reasonable with the new interface. And again, i stepping back real quick, I like to test every usability test with a new user, someone who hasn't seen the system before, because we want to test usability, not memorability. But in this case, my seventh user, and I remember it so clearly, it was the end of the day, like 4.30, and I was like, yeah, the the all the other tests, all of the tasks had taken like 10 minutes to complete. And we're in task number three, and we've been testing now for 25 minutes. And he's stuck on this one task. And as ah as a tester, one of the one of the key things to being a good usability tester
00:17:26
Speaker
is to sit there and have a good poker face and be quiet and just watch and remind them, you know, we're we're testing the interface, we're testing the product, we're not testing you. So feel free to make mistakes, but we don't answer questions, right? Like we're not we're not there to help them, guide them along, cause that's not testing. And I've noticed in a lot of like younger product people, that's a hard thing to teach is because you want everybody to succeed. You you want them to do good. And so this guy was on, time on task was like 45 minutes. He wanted to get it right. I was like, you can end the task at any time. We can move on. Now I'm going to get this. I'm going to get this. And so like, it's like five, 30, six o'clock. My wife's expecting me home like 45 minutes earlier for dinner. And I'm waiting for this guy to finish task number five so we can go on to task number six. And, uh,
00:18:25
Speaker
Yeah, so backing up to to comment on what you were saying, you have to be wary of edge cases, because there are people who just aren't going to get it. So if you're seeing a majority of people making that save error, then you know maybe placement is unclear, or maybe your audience is a younger audience and doesn't know what a floppy disk looks like, which is a traditional modern save icon. Well, most of them call it the save icon. They don't realize it's a floppy disk. I've actually said, oh, that's the save button. I'm like, no, it's ah it's a floppy disk. They're like, what's a floppy disk? So yeah, it's it's one of those those gap things where they've seen it in applications. They know what's what they hit to save, but they they don't know the origin of it. ah So like for those of us that have been around and know what the technology is,
00:19:22
Speaker
it It's, oh, okay, yeah, it's like a saved disk thing where they just know it from using older their applications that, oh, that's the save button. Yeah. And once something becomes learned behavior, you know, I have a question. Do they need to know what the origin is? Like if that's what they associate with, this is what this thing is. Is there a need to change
Product Consulting vs. In-House Work
00:19:46
Speaker
it? and Kind of like a red octagon, right? Everybody kind of knows, oh, that probably means stop. You talked about um you know the world of product a lot so far, and but you know I think when you're working for a company that you know that that's your day job every day, in and out is and day in and day out is is building this product and living and breathing in that world is one thing. But as a consultant, I would i would guess it's a little bit of a different approach or or there are there are unique challenges in the consulting side of of you know being a product consultant. ah talk Can you talk a little bit bit about you know what what does that look like?
00:20:24
Speaker
In my experience in consulting, I've worked for large corporations, ah like enterprise level companies. I've also worked at ah corporations doing product. And I've noticed that there's a big difference between the two worlds, whereas a an enterprise level company is likely to have a very structured agile type company or type product group. where you have your POs and your PMs, and there's a very defined curriculum for who has what role and what requirements or what duties those those people do. In consulting, I found, and numerous clients, I'm sure would agree, is the faster you can move to the best results. And what I found is,
00:21:17
Speaker
you have to be a little bit more lean than having all of those multiple roles, whereas those just become hats that one or two people will wear in the discovery and definition process. and so you know i I think that I can do a very good product discovery given six weeks time and ah a technical consultant to either work alongside me or consult with so that as I'm identifying these problems, somebody's asking the right questions from a technology point of view, but also that we're
00:21:55
Speaker
what we're conceiving should be the solution. And again, talking in discovery here, so we're like 20,000 foot top down view, but we want to make sure that what we're recommending can be built because that that's the worst thing to happen, right?
Importance of Discovery in Product Development
00:22:11
Speaker
is that And I've seen this at larger places where everybody's siloed and yeah the product design team sits over here and they're just tasked with, hey, make this thing. And they make it, but you know who knows if it's actually going to be able to be built or it doesn't utilize any of the existing company's components or structure or anything like that.
00:22:41
Speaker
And so ah I was talking about product discovery. So in working in that product discovery, you want to get to the 20,000 foot view of what the requirements are. What is this thing? What's the general shape of this? And what are all the things that we need to consider? What are all the requirements we need to consider within that to be able to have it built? And then moving forward into your definition phase with a high enough level confidence that that's the right thing to do. And yeah I've already talked about meeting with users with interviews and observations and and doing usability testing. And that's how you get to that first level, like high level view of what the product should be.
00:23:21
Speaker
And then when you go into the definition phase, you're really digging down into each one of those requirements to create actionable issues, tickets, epics, so that you can shape up, size up. And Aaron, I know we were talking about scope earlier today. um so that you can really scope out what this thing is, the size of it, what needs to be built, what are the features that are going to be included, what are the stretch stretch goals for this, and then be able to do an accurate development estimate and get alignment with the stakeholder on, this is what we're going to build. And hopefully, you know in that agreement, you're avoiding scope creep so that you can just be focused on building what is
00:24:06
Speaker
And I know this is a visual medium, but I'm making air quotes, but what is the right program or right product at the time? What have you seen happen when those things don't fall into place as planned? Like maybe they haven't done a good round of discovery or don't have their requirements fully defined before they hit the ground running.
Consequences of Poor Planning
00:24:34
Speaker
or they're working towards an imaginary date that they've put a line in the sand on. Or they brought you in because they don't need you to do discovery because they've already done discovery. So they already know and what needs to be built.
00:24:49
Speaker
I've been on all of those examples of projects before and the the same thing always happens. You get a couple of weeks in and you make recommendations on what might be you know the right thing from your perspective as you're starting to really understand this or to modify things that are already in action and you get pushback because we'll know the plan is already this and you we have to hit this deadline. like But we want to build the right thing because if you build the wrong thing, then you're going to spend a whole bunch of money fixing it later to have it be the right thing. And so the the best thing to do is really do that discovery and definition upfront, which is going to save you so much time during development and even afterwards when you know the right product was created. But i've going back to your question, i've been on one of the projects I'm thinking of specifically is
00:25:43
Speaker
There were too many stakeholders. I think we had about 10 stakeholders who only met every two weeks to review the product and all had different ideas and opinions on what the thing should be. And so every two weeks, the scope shifted completely and we couldn't get, like I was saying, hey, can we get just one stakeholder who's in charge, who can meet with those stakeholders and then come to the demo meetings and just be one voice so that we can guarantee that we're going to hit a timeline and guarantee that this is what the scope is going to be. what you know This is what our push is going to be for the next X number of weeks rather than trying to pivot every two weeks because we're never going to get anything done. And in speaking of deadlines, i I love deadlines in the whooshing sound that they make as they fly by.
00:26:35
Speaker
I mean, if you can accurately scope a product or a feature or whatever, hitting those deadlines should be realistic. I mean, you know if you go through discovery and definition, and everybody agrees on what that MVP is, and it has these four features, and that doesn't shift, realistically, your deadline should be easy to achieve. And when those things don't fall into place, you know something has to give. If you've got somebody that's hardlining a date in a given scope, you know generally your quality or your experience is just going to decline to the point where it's not going to be a successful product. Yeah.
Investigating Project Deadlines
00:27:25
Speaker
But it's always good in, you know going back to the the private detective analogy,
00:27:32
Speaker
I find myself in all of the engagements that I'm on asking why, why, like I sound like a three year old, but why, why, why is that deadline necessary? Like why, why is it that day? Okay, well, what happens if we don't miss it? Okay, well then if nothing really major happens, can we push that back by two weeks, which will guarantee us X, Y and Z. One of the directors that I worked with used to say, try and ask five wise. And anytime that somebody asks you to do something, you know, and, and that's a, it was a good way of drilling down to get to the meat of what they're really asking for and, and why they need it. It it was great for a discovery. Cause sometimes you couldn't even get down to five wise, you know, by the third one, they've gotten, they've either talked themselves out of needing it or they've
00:28:30
Speaker
gotten so succinct about why they need that, that it was like, okay, yeah, I could see that and and you didn't have to ask any more questions.
00:28:40
Speaker
Yeah, as long as you have stakeholders who are willing to have those
Consultant-Stakeholder Dynamics
00:28:45
Speaker
conversations. I've also been on projects where it's been, and and you know as a consultant, yeah As a consultant, it's always the stakeholder who's having you on the project. You're there to help them. And so you can make a recommendation of saying, hey, with you I've heard what the audience is saying. I've heard what the stakeholders are saying. And I think we should be building X, not Y. And they need to make that decision. And their decision can be, well, no, we we brought you on to build Y. We're building Y. And so then you, you know,
00:29:21
Speaker
Pack up all of your information around why you should have been building X, document that so that if anybody afterwards has to go back and build X, you've got all this information for that, and then you get on board with building Y, because that's what the stakeholder wants. I've also been on projects where asking why more than once was too much. you're just No, I just have you here to do these things. Just do the things. I'm telling you what to do. That's why I'm paying you to do these.
Challenging Traditional Methods
00:29:50
Speaker
the other The other thing I've run into sometimes is the issue with tradition. Well, we've always done it this way. ah what What are your recommend recommendations for getting over that hurdle of tradition? I think it goes back to the the five whys that that you were talking about a second ago. I worked with a guy a couple of years back who ah he called it the hardy boys method. So it was really the six whys, the who, what, where, when, why, and how.
00:30:19
Speaker
And again, going back into that we're private detectives, it fit really well. And so I found that asking those questions really helps to identify, well, why have you done it all that way all the time? Or why has that been the way that you've always done it? And is that working and showing you know interviews and observations or usability testing showing to them that that isn't working or that the value lies somewhere else? then really can help to change change opinions, not all the time, but especially if you have ah quantitative metrics, not just qualitative metrics, but you can say, hey, look, you know we we did a time on task for what you want to build versus a time on task for what we think is the right solution. And look, you can save you know X number of seconds over across everybody at your company
00:31:17
Speaker
in one day, productivity is going to increase increase tenfold. When you look back on your career, do you have a you know favorite product or you know endeavor that you were part of, that you're the most proud of? or You don't have to like name names or anything if you just want to talk about the gist of what what the product was about.
Favorite Projects and Team Trust
00:31:41
Speaker
Sure, the the perfect project has is always kind of a white whale. You're always chasing that perfect one. And up until recently, I would have said this project that I did almost 10 years ago now um would have been my favorite project that I had ever worked on where you know the stakeholder came and said, hey, I have this idea. I don't know how to get it to market. It's all in your hands. Go.
00:32:07
Speaker
um that given the fact that they came in and gave the credibility and trust to myself and my team to take their idea and, you know, still work alongside of them, but run with it and get it to market. ah And we're open to ah a lot of our ideas in building that. That always put them at the top of what my favorite project ever that I worked on was, but up recently, um
00:32:38
Speaker
Caliberty had a ah client that was very much and the same type of client where they're like, hey, we brought you on because we know we have problems. And we're going to give you six weeks to come in and and meet with everybody and identify what those problems are. And we want you to tell us how we might solve those problems. And so we did a ah very short run. I would have preferred to have a couple more weeks on that project. But we identified 11 problems across their facility, three of which we recommend building digital solutions for. And here in about a week, we're kicking off the second phase of that where we're going into definition to flesh out what those three digital products will be and give them estimates to build one of the builds has already been greenlit and funded. Did you ask him the question? What would you say you do here?
00:33:37
Speaker
I told them that yeah I'm willing to to approach any problem and and document any problem. like if you're If the people who work at the facility don't like the coffee, and I hear that from everybody, I'll make sure that I write that down and let you
Holistic Solutions in Facility Management
00:33:51
Speaker
know. But you know the the problems that we identified, it was myself and a technical consultant from Caliberty. The problems that we identified weren't typical software problems, right? We weren't just looking for, all right, well, what are your digital problems? We were looking for, holistically, what are the problems that all of your employees are encountering? What are the friction points and what would make everybody's jobs easier? And one of the big solutions was
00:34:20
Speaker
you need a centralized wiki for all of your processes because over the 20 employees that they have in the facility, Somebody keeps all of their information in written notebooks. Other people had SharePoint stuff, which the company had stopped using years ago, but they still pointed to the SharePoint files. And they're stored in both PowerPoint and PDF. And so you copying those or sharing those, duplicating those into new formats is harder for them.
00:34:52
Speaker
um I forget there were like three others. Oh, there's binders, printed binders on how to do this research. And the facility, one of the requirements for this facility is a need for speed to be able to do these processes quickly. And so to be able to do those processes quickly and to make it uniform for everybody who works there to be able to find that information, you really need just a central hub where all of that information is and really just a search bar so you can say, here's my problem, type, type, type. And to be able to find that information quickly so you can solve your problem and go about you know continuing what you would be doing at the facility.
00:35:35
Speaker
Yeah, it's it's it's interesting that you like it it just seems like as you talk about you know what what you're doing with product and and you know when it comes to consulting, I mean, consulting is really just a fight against the XY problem in general, like forever with with consultants. who you know they They need to solve X, but they they decide, okay, if we can just do Y, that should solve it. And they come in and ask us, how do we do Y? Will it tell me how to do Y? So we come in and we think the answer is to help them figure out how to do Y, but if we take a step back, we really need to solve for X. like that That's the problem we really need to solve. and we If we we focus on that, Y is not even a valid solution for X. so Let's forget about that. right so I think it's it's interesting that if we can, from a consulting standpoint, if you can get to that you know that problem early and
00:36:21
Speaker
go on the path, you know, you know divert the the project down the path of X instead of taking that detour down the path of Y that's going to lead to nowhere, you can lead to better outcomes. So I like that that aspect. You didn't phrase it in that way, but that's just kind of how in my mind, it that's how I framed it to myself so I could understand it. Yeah, no, that's really well said. And often, you know, in consulting, by the time you meet with a ah client, they've already done their own problem solving, they ah then they might think they need, I forget which one you used, X or Y, they might think that Y is what they need because they've been having meetings for the last six months in order to meet with consultants to pitch that solution. And so it's it's really that private detective work going in there and really finding out what the real problem is. Yeah. I can't tell you how many times i've I've gotten burned by the X, Y thing. And it's, you know, when you're really busy,
00:37:20
Speaker
It can happen, right? So that, you know, in my experience, what was happened to me in the past, I mean, Aaron, you've probably been around for some of these when we worked together in our former former career. Somebody will come to me and say, how do I do why? And I say, oh, well, you just do this, this, and this. And they go off and do what I helped them with, and they go and try to solve the problem. Well, it blows up. And the answer, they say, well, why why on earth did you do this? this way Well, James, James told me how to do this. Hold on a second, I didn't know you were trying to solve this other problem over here. That's the thing that we run into and and it happens on on a larger scale with consulting companies. you know That's just a small scale thing, but but that's the kind of thing we're talking about is is you know avoiding that.
00:38:04
Speaker
Oh, Caliberty told you to, told us to do, you know, write a mobile app and that'll solve all our problems. Well, that's not what we said. You you told us you wanted a mobile app. So we, we we built a mobile app for you. But if we can get upstream from that and decide, make the decision, well, you don't really need a mobile app. You really need a Alexa action or something like that, right? That wouldn't be better for your, the people that are using your product. I've actually done that to myself before in a development process where I, was like, Oh, I need to solve this problem with this. And then I get, you know, down the road with it and go, Nope, scrap it. Restart. I was, I was totally going down the wrong path. I didn't ask myself the question of what it is I really needed and, and didn't solve my own problem correctly. So yeah, it, it, it does make a difference. In fact, I, I.
00:39:01
Speaker
did this just in the last couple months? Well, the I mean, the one of the examples I've seen in this XY problem you know world is you know someone comes to you and says, well, how how do I get the last three characters of a file name? um Well, you just do you know substring, lastter you whatever, whatever string of manipulation function you use to get the last three characters. All right, there's my answer. Well, if you dug deeper into it, what they're really looking for is what is the file extension? But not all file extensions are three characters. So you just told them how to get three characters. You didn't tell them how to get the file extension. But you know it's it's that sort of thing, right? If you dig deeper, there's ah there's an underlying issue that you're actually trying to solve. And gee, us three characters isn isn't going to do it. You need to look for the dot, right? The last dot.
00:39:48
Speaker
which goes back to what I was originally saying, how every project, every product needs a discovery phase. And in that discovery phase, we hope to unearth what the root cause is or what the root problem is for what our clients are asking for in order to provide them with the right solution.
00:40:09
Speaker
Yeah, and it's it can be difficult because I know people they they they take offense to you know when they come to you and say, i just just I need to know how do I get the last three characters of a string? And you say, well, hold on a second. Back up a second. Tell me what you're trying to accomplish.
Extracting User Needs Artfully
00:40:24
Speaker
what are the What's the outcome? you're look ah Forget about that. I just i just need those three dig or three characters off the end of the string. Just tell me how to do that. Tell me how to do that. How do you artfully kind of walk them backwards and help help them get to the point where they understand, OK,
00:40:41
Speaker
I gotta back up a little bit and really take a look at the the underlying outcome I'm looking to achieve. How how do you do that? the What's the magic sauce there? yeah I think that the way that we all would probably solve that would be similar and be like, oh, yeah i I hear how frustrated you are. I hear how quickly you need this answer. So here's a quick solution that I'm giving you. um In the example of, working with clients and and doing product discovery and definition, it's that proof. So you're creating documentation around, you know here's the problems that we heard. We we interviewed 11 people who work at this company and here's all of the problems generalized yeah kind of in a thought cloud of what we're hearing. And the big clusters are around this and this and this. And so therefore I think we need to dig in here a little bit further
00:41:33
Speaker
and being able to articulate that and show documentation and qualitative and quantitative metrics around that and saying, you know, seven of 11 people said that you need to have a better source of information for the facility. It's an easier sell and also ah I assign severity ratings to each one of the problems that I end up finding in these discovery phases. You can read people's body language and their feedback and these interviews and observations and so if you're hearing a lot of people who say this is a problem but you're also feeling that they're frustrated or maybe they're even voicing how frustrated they are then that increases your severity level
00:42:14
Speaker
Also, if it's a breaking problem, so if youre you are talking about a digital issue or even down to a physical issue, the coffee machine is broken or we're frequently out of filters. Maybe that's a problem that you need to solve, but that's a severity that's a higher severity rating because it's going to ah quickly decrease by solving that problem. It's going to quickly decrease that employee's pain point and allow them to do better work. All right. So, oh, Aaron, sorry, you had something. Yeah. I was going to say that, you know, I actually started drinking black coffee because of that kind of a situation where our, our coffee situation was degrading where I used to, I used to drink coffee with cream and sugar. Well, we were working a lot hours and I really needed coffee and we ran out of creamer. So I just went to black with sugar.
00:43:11
Speaker
Then we ran out of sugar. I'm like, well, is I just gonna drink it black and have worked through that. And now I always drink my coffee black. And it's just kind of one of those things where it's like, I don't need this problem solved for right now. What I really need is caffeine. So, you know, ahll I'll solve it by just drinking it black. Are you ready for the lightning round?
00:43:40
Speaker
I think we're ready as well. I'll ask the first question. My colleague will ask the second question and so on and so forth. And we'll do until we're tired of you answering the questions. That's how that's how it works. All right, question number one. Invisibility or super strength?
00:44:04
Speaker
Flight. Okay, but I will accept that answer as well. ah Super Mario or Zelda? Zelda. Do you snore? Only when I drink too much. What's the capital of New York? New York City. Albany.
00:44:27
Speaker
Are reindeers... reindeer? Real creatures. Yes. Paper or plastic? Paper. Have you ever slapped someone in the face? Yes. What's your favorite carnival food?
00:44:49
Speaker
Steak on a stick. How many redheads are you friends with? Five if you count my children. Taylor Swift is blank. ah The one person my wife and I can agree on. Make a high-pitched sound.
00:45:06
Speaker
I don't think that was an E actually. there
00:45:11
Speaker
All right with that I would like to thank our guest Ryan Wilson and my lovely co-host James Carmen. I'm Aaron Chesney and this has been the forward slash where we lean into the future of IT.