Have you ever wondered how product managers turn chaos into a symphony? Our latest episode, featuring the perspicacious Simon Berry who shines a light on the crucial role these maestros play in harmonizing user needs with project realities. From the stormy beginnings of a product's life to its standing ovation in the market, we chat about everything that makes or breaks its success. We promise you'll come away with a renewed appreciation for the delicate balance of art and science in product management.
Dive into the heart of the tech world with us as we unravel the subtle yet impactful differences between product management and project management. Hear firsthand accounts of the tightrope walk balancing business pressures and customer ecstasy. Then, eavesdrop on the secret language of UX professionals and developers as we share strategies for better collaboration that could spell the difference between a digital masterpiece and a one-hit-wonder. Simon’s extensive experience in the startup and FMCG landscapes brings a richness of insights that you simply can't miss.
To cap things off, we get real about the agile development process, sprint estimations, and our collective drive to 'fail fast' and learn faster. We also detour through the world of personal finance apps, contrasting their quirky features and understanding what makes users tick—or kick. And for a little extra spice, we share our gripes with apps like Spotify when they hit a sour note. It's an episode that fuses tech talk with real-world wisdom, all underscored by the hum of user experience. Join us for a session that's as informative as engaging—with a side of laughter.
All this and more are answered in this episode of Faster Horses, a podcast about UX, UXR, UI design, products and technology (sometimes!)
🐎 80% comedy, 20% UX, 0% filler
👕 Get stickers and tees at https://www.paulwilshaw.com/shop/
The show is hosted by:
Paul Wilshaw
https://www.linkedin.com/in/paulwilshaw/
and
Mark Sutcliffe
https://www.linkedin.com/in/sutcliffemark/
If you want to suggest an idea, or join us on the show, send us a message 👆.
Have you ever wondered how product managers turn chaos into a symphony? Our latest episode, featuring the perspicacious Simon Berry who shines a light on the crucial role these maestros play in harmonizing user needs with project realities. From the stormy beginnings of a product's life to its standing ovation in the market, we chat about everything that makes or breaks its success. We promise you'll come away with a renewed appreciation for the delicate balance of art and science in product management.
Dive into the heart of the tech world with us as we unravel the subtle yet impactful differences between product management and project management. Hear firsthand accounts of the tightrope walk balancing business pressures and customer ecstasy. Then, eavesdrop on the secret language of UX professionals and developers as we share strategies for better collaboration that could spell the difference between a digital masterpiece and a one-hit-wonder. Simon’s extensive experience in the startup and FMCG landscapes brings a richness of insights that you simply can't miss.
To cap things off, we get real about the agile development process, sprint estimations, and our collective drive to 'fail fast' and learn faster. We also detour through the world of personal finance apps, contrasting their quirky features and understanding what makes users tick—or kick. And for a little extra spice, we share our gripes with apps like Spotify when they hit a sour note. It's an episode that fuses tech talk with real-world wisdom, all underscored by the hum of user experience. Join us for a session that's as informative as engaging—with a side of laughter.
All this and more are answered in this episode of Faster Horses, a podcast about UX, UXR, UI design, products and technology (sometimes!)
🐎 80% comedy, 20% UX, 0% filler
👕 Get stickers and tees at https://www.paulwilshaw.com/shop/
The show is hosted by:
Paul Wilshaw
https://www.linkedin.com/in/paulwilshaw/
and
Mark Sutcliffe
https://www.linkedin.com/in/sutcliffemark/
If you want to suggest an idea, or join us on the show, send us a message 👆.
Right, the record has started.
Speaker 2:Nice.
Speaker 1:Cool, and this is where we awkwardly linger for about 10 to 15 seconds wondering how do we actually start one of these? I know, just like the back room, it's so many times.
Speaker 2:Those people who listen for the first 5 to 10 seconds on our podcast just go.
Speaker 1:This is Rubber and then just quit, yeah, there's a lot of slamming your head against the wall to break through to a faster horse's experience that's actually going to teach you anything that's worthwhile.
Speaker 2:And, of course, a big part of that is pulling ourselves like this. We cannot claim we're going to teach you anything whatsoever.
Speaker 1:No, that's true, that's true. We never do though we never do. We might teach you something, but it's likely to be the wrong thing and we're okay with that. Yeah, yeah. But yes how is everyone?
Speaker 2:Nice I'm always asleep. Oh, yeah, you know what I had to tell them all night sleep as well. I'm going to blame. I'm going to blame Stormisha, right, okay, this will put us in a time frame for everybody listening, so when we put this out.
Speaker 1:Yeah, yeah, yeah.
Speaker 2:Like when I get around to editing in six months time we'll have no reference whatsoever. Nobody will know who or what we're talking about.
Speaker 3:I've lost two fence panels.
Speaker 2:Oh, you're joking.
Speaker 3:I know it happens every time.
Speaker 2:I thought that was some kind of view for me man.
Speaker 3:It could well be Slowly losing that, one fence panel at a time.
Speaker 1:There's no perimeter, you're just leaking out everywhere. No, I can't blame Storm, whatever it's called. It was my birthday last week.
Speaker 2:Yes on Wednesday.
Speaker 1:So I had a lovely tempered time on Wednesday because it was sensible I was in work. The weekend, however, made up for all of that. So whilst I'm not hungover today, as is very often the case when we're recording, I will caveat I am very tired, so I've got a feeling that's going to bleed over into a very similar sort of contribution from me. Nice, I can actually expect. So, that being said, shall we start?
Speaker 2:Yeah shall we, and shall we introduce the mystery voice?
Speaker 1:I think we probably should.
Speaker 2:Today we're joined by Simon. So, simon, do you want to give us a little intro? You are, what are you doing and why the hell are you here?
Speaker 3:My name is Simon Berry. I'm a product manager. I'm not quite sure yet. To vent my frustration with wind and fences maybe, but I think we're going to talk about product management. Maybe there is a metaphor, there, isn't it? It's like putting fences up that keep getting blown down, or maybe kicking in by senior management, who knows?
Speaker 1:I'll just jump over. Over the place, or they don't exist.
Speaker 2:Hopefully you've got a roadmap to put your fence pole back in.
Speaker 3:See the road.
Speaker 2:Yeah, nice, nice, welcome to Faster Horses, simon.
Speaker 1:Pleasure to have you yeah.
Speaker 2:So yeah.
Speaker 1:Where do we start?
Speaker 2:Good question.
Speaker 1:Tell us about the realm of product management. Yeah.
Speaker 2:What is it? Give us a yeah, a why we should care? Has you met people or anybody in general?
Speaker 3:Yeah.
Speaker 1:It's a very good question. A letter isn't it?
Speaker 3:Two very different answers. Maybe, yeah, it's been a long time since I've been asked what product management and what should you care? I guess to me it's making stuff happen. Right, I'm that person that goes into a business, especially with my backgrounds. A lot of it is in startups. I did cut my teeth in the FMCG world. It wasn't for me. We might, we might get onto that.
Speaker 3:But yeah, like I guess, making stuff happen, you prioritize all of the wonderful things that come in from everywhere and then hopefully, you have a product at the end of it. Slightly more complicated than that, but in the simplest terms, I think I've said and this may maybe not to all the project managers out there but I don't really care about budgets and time, I care about the outcomes that you get. So I'm not sitting in Gantt charts saying that's like, I'm saying what does the user want and how do we make that happen for them? Refreshing, and why should you care? Refreshing Is because, hopefully, if you've got a good project the project, I said it myself then if you've got a good product manager, you should care, because they're on the side of the people that want to build the products. Nice at the time, nice.
Speaker 2:I like that. Yes, all right.
Speaker 1:I'm going to throw the question out there at you, Paul. Then, off the back of that description we've got, how have you found your interactions have been with the various PMs in the past? Things like that.
Speaker 2:Good and bad. I think this always comes down to interesting, though People who do product management much better, people who do project management not so much. It's interesting, isn't it? Because I think there's a very similar, but there's a massive divide between the two. Simon, can you relate to this?
Speaker 3:Yeah, definitely Project and product managers in the tourist who don't get on very well.
Speaker 2:Anyone.
Speaker 3:I started my life off as a project manager many moons ago.
Speaker 3:Just because I was doing some product stuff and it was a start-up and they didn't have enough money to pay me full time if I didn't do some project management. So I did it and I didn't find it fun. But I think any sort of project manager that's got a bit of product in them, they end up in a product role anyway and that's why they're a bit chalk and cheese. I think it's like why is it not on time? Why are we spending so much money? And then the other side you're going well, the customer doesn't want that or we need to fill this, we need to spend more money, we need more time and it's hard. The two roles that are valid, obviously, but they're sort of opposing sometimes, because the business is one breathing down the neck together product out, and the other breathing down the neck to make it as cheap as possible.
Speaker 1:Yeah. So you're automatically in a catch-22 of delivering everything but paying absolutely nothing for it and getting as close to those to completely divergent points as is humanly possible. My experience with product management has always been an interesting one, because where I am right now is small enough that we don't actually have much in the way of either product or project management. I should say that the roles are kind of emerging because we're getting to that point where the company is starting to develop in different directions and needs that. Prior to that, it's usually been the CEOs pointing in one direction, saying run in what I would consider quite an entrepreneurial approach. That's me being very forgiving with that. I think I've used the term only a few podcasts now, but that's my way of saying. They don't actually plan anything. They just throw shit at a wall and see what sticks.
Speaker 1:But my experience with PMs in my previous role was, in fact, an exact opposite. There was at least a dozen. There could have been two dozen, and I was part of a huge UX function, part of the leadership team, which meant that my job was trying to establish a process with these individuals. But what had happened is because they were so established in their routines and their existing processes. It was all more impenetrable to get them to prioritize anything from a user experience perspective because their focus was on meeting KPIs. They got from the business requirements rather than anything to do with user requirements. Have you guys had similar experience of that?
Speaker 3:Yeah, go on.
Speaker 2:Simon Care to elaborate.
Speaker 3:I think the interesting point you said there is yeah, I think product management is needed when the founder or the CEO can no longer manage to communicate with the team effectively and put better and I think you said it is they just throw shit at a wall. That's generally what a lot of entrepreneurs do they try new things, they do stuff. I think the product manager steps in when they need to throw the shit at someone else. So I've been the person that catches all the shit. The shit shield, yeah, the shit shield and then collates into something that the business can understand.
Speaker 3:All the developers, all the UX or QA or whatever in the team. And then, yeah, we start going OK, well, we're going to do this bit. And a lot of the conversations are and you hear this so many times why? So? Why are you throwing shit at me? You sure that that's going to work? Do you want to test it first? No, you just want to do it. Ok, well, I've only just met you, so we'll do that for a bit, and then we'll learn a bit more about each other, and then maybe I'll say why again, and then maybe one day you'll go. That isn't a good idea, because I trusted you that one time.
Speaker 2:Nice yeah. Yeah, I think it's interesting, is it? Because I did? It seems like a year ago now, but I did some scrum training and on that scrum training it was like the product owner is like the CEO of the product.
Speaker 1:And.
Speaker 2:I think that, for me, is kind of quite crucial, and I think that gets lost quite a few times In the way you know. Everybody tries to own the product and I think sometimes it's, you know, kind of like UX wants to own it, devs want to own it, the C2O wants to own it, but essentially if everybody's own in it, then nobody owns it as well. So it's that balance and you want everybody, you want skin in the game for people, but at the same time you just sometimes need to say just can't do that.
Speaker 2:You know, touch that new technology we're building onnr.
Speaker 1:You know we're just getting out there, because that's the skills we've got.
Speaker 2:Stop learning the language. Let's just crack up with this shit, and then we'll figure out later.
Speaker 3:This is a point to everyone, but you have to.
Speaker 1:So to expand on what you've just said there, like so was it PO's PM's a combination of the two actors?
Speaker 2:like the.
Speaker 1:CEO of a specific product. The one product that I assume is when back off what you said, simon, about it PM's materializing when the CEO can't effectively communicate with the rest of the team. That implies there's usually multiple products going on within the organization. So because I kind of I kind of really like that analogy, because it keeps things kind of localized, it gives quite specific boundaries towards what a product is and help define where the overlap between two products might be. But do you think that then, if they emerge as the CEO of their product, to extend the analogy, do you need then people who formulate the rest of that C-suite around them 100%? Do you need your version of the CTO? Who isn't the CTO?
Speaker 2:Yeah.
Speaker 1:Like C-DO, or I'm going to try and pioneer the term CXO as the chief experience. I don't know. I said pioneer the problem, millions of CXOs as well, but that's just what I want to become. But so do you. You know, would you find that for every PM, you need to have the equivalent senior stakeholders within that product?
Speaker 3:Yeah, I mean, my analogy to being in any team is it's a football team, right? If you're going to have a player game, let's call that the product. You're going to want your best defenders. You're going to want your best goalkeeper, your best midfielders, your best forwards right, it doesn't really matter where you're sitting. That wants to point in building something for someone if you haven't got the best people around you, and that could be at a team level or the highest business level.
Speaker 3:But, yeah, I absolutely agree. If I, if I'm going to prioritize or make a decision as the mini CEO I don't like the term product owner, by the way just want to get in there because I don't think anyone owns the product, I think everyone does Like people that write code, design, like even the people that support it. You know, it's not the people that just put the money in or tell people what to do, you know. But yeah, you want to. You want to have an amazing team around you and you all want to be aligned to do the same thing. Right, which?
Speaker 3:is a good product, hopefully.
Speaker 2:Yeah, thanks, chris, although that's a little bit harder to put.
Speaker 3:It's getting harder. Yeah, yeah.
Speaker 2:Nice.
Speaker 1:So, saravan, I'm going to ask you an eyesore and an ending question, but to bring this, we are a UX podcast after all, yep, so I want to know I'm sure Paul is just as keen what your experience has been like working with UX people. What does that look like for you?
Speaker 3:Yeah, Personally, I love it because I've done a bit of it in my past and that's when you sort of go into the first roles and they go well. Can you do a bit of this? I'm not very good at design. I'm quite good at thinking through customer journeys and experiences and wireframing and I think I've had to be because there was no one else to do it. But yeah, when I think it's working with someone in UX should be a partnership, product in UX should just be side by side. I don't mean that in hierarchy, I mean that in sort of solving problems, customer needs.
Speaker 3:I guess that the best when it's working well for me and when I've seen the most, is I work with them to say this is the next thing coming up, give them as much information as I can, let them go away, have a think about it, check in. When everyone's happy, we get all the developers involved and I'll leave them alone until we've got something then and I think that's where I work best. What I really like is I like seeing developers in UX. People work together and iterate and it doesn't happen as often as it should. But I think if you can find someone that you can trust with like trust to think about the first bit and then leave them to do the second bit, you end up with a much better product or feature. It's not always at the product level.
Speaker 2:No, no, no, Definitely.
Speaker 2:Interesting because you say that, like UX, people and devs don't talk as much as they should. I'm quite passionate that they should be talking all the time, but there is this don't know what it is, but I don't know whether it's kind of like people can think, oh, I did UX thing and then, once we've designed it, just throw it over the wall to devs and expect them to build absolutely everything and have no pushback, and then when they push back and you spent like a month doing stuff, then gets frustrated devs get frustrated and then the whole communication lines break down.
Speaker 2:So is there anything we can do to kind of make that communication better, to make that kind of at the forefront of what should be happening?
Speaker 3:Is that to me?
Speaker 2:Anyone, you're probably best to answer this.
Speaker 1:I also got to be a bit biased. I mean, mine's going to be biased as well.
Speaker 3:Oh well, that's fine.
Speaker 3:It's hard right. So I've managed UX. I've never really directly managed any devs and I think I should right. For starters, I don't think product managers should manage devs, Arguably they should maybe not manage any of the people in the team, but needs must right. In my last role, I directly managed design or UX and QA, so I had an idea of each end of the process and that was people managing, and I tried not to get involved in the management of like this is how you'd be a good QA, because who am I to tell? But I guess, to your question, which I can't remember what it was, the gods have it.
Speaker 2:How do you foster that?
Speaker 3:early on.
Speaker 2:So that people don't get frustrated.
Speaker 3:Yeah, so can you bring everyone in a meeting all the time together? Is it worthwhile? No, it's not and I don't think it is. You know, like if, let's say, the CEO of a company comes to me and says we're going to build this big feature, I want you to do it and these are the reasons why. Now it's my job to explain to the team that we're going to build it.
Speaker 3:But do I get, let's say, someone that's going to build the infrastructure, someone that's going to build UI and a UX person in the meeting to start saying that we need to do user research? Probably not, because it's just a waste of everyone's time and they've got stuff that they're doing anyway. Then, on the other side of it, do I bring a UX person into the meeting where we're talking about what tech that we're going to use to scale it for the next 18 months? Sorry, probably not Now. You could, you absolutely could, but you think, well, in most of the businesses I've worked in, time is precious and you probably just sit around in meetings all the time. So you've got to kind of make a decision, and it's quite easy to make these decisions because you can ask people if they think they need to be there. It's not.
Speaker 1:It's mad, isn't it? Yeah, you don't have to do it for the decision, the decision powers with them.
Speaker 3:So you go, I've got this meeting right. So typically what I'll do is, if the business comes to me and say we want this feature, my initial thought would be why do they want that? Or yes, let's do it, because obviously I'm excited or not, and then we'll take it. I'll take it to a UX person and say, look, do we need to do some research on this? Like, how are we going to do it? Do I do some prototyping, like wireframes or whatever?
Speaker 3:But I'll start talking about the team that we do. I'll start talking with the whole team that we're doing that, maybe in a stand-up or something saying oh, this is come, we're working on this, we will involve you when we do it, when we need to. So maybe we'll do a bit of research and stuff or prototyping. We'll come back, we'll see it throughout little bits, throughout this process, and then we'll go oh, now we're ready to actually talk about it. So we'll get everyone together before kickoff, whatever project planning, and we'll sort of do it. And then we'll just iterate through that process of let's build it. And I think the crucial point and I'd love to know your two take on this actually- is it's quite hard to design user experience with movement.
Speaker 3:So when something's being used and I know you can do like you can get something out there and see if it's used and stuff and this is why I think having a very good UI designer as well as a very good UI developer is paid dividends, where I've sort of been. When stuff starts being real and the UX person starts interacting it where it's built, because the UI developers can have an idea of how they want it to work and the UI designer or UX person whatever they're going to have an idea, that's where I think the power of making a really good product comes together. It's then sitting down and going. I didn't think it would work like that and that's where I think those conversations.
Speaker 1:Yeah, I think, depending on the feature itself, because, interestingly, at work now myself, I mean almost exactly the scenario you described where I was pulled into a session. I was just actually pulled into a session because the head of engineering was like I've got five minutes to come to this very dull meeting and, lo and behold, it was the CEO who's had a new idea for a feature, an idea off the back of requests from our biggest client.
Speaker 1:So, there was a bit of weight behind it and then it turned out to be now one of the highest priority things on the list and we haven't had the time I mean, we don't really have the foundation right now, but we haven't had the time to do any generative research about it to go to our various existing customers and say, well, we're going to add this, what do you do? That's similar. Are you using any workarounds? That's similar. What would you get from this task? You know third-party software that does the same thing for you or that you've been looking at to do this. I think when you are not able to go out and ask people what they would do, how they might use it, whether that's just asking in a discussion session or an ended, or with some kind of mock-up, whether it's paper, whether it's infigma or even some throwaway code I think you then have to get a bit more creative about where you get your information from. So in my case, we have some great internal users who do a lot of the setting up for our customers and have spent a lot of time with the product. So I get to exploit them. So I've been asking them what they think, but of course that means that you're only speaking to two or three people. I think the other thing that we've been able to do is, thankfully this feature is pretty standard and I've been able to find like eight I wouldn't call them competitors, as said, they're not direct competition, but eight people who are doing the same thing, eight products are doing the same thing, and then having a nice clothed look at how they've been achieving that.
Speaker 1:And this was just after that meeting. I went away from that meeting. I thought and I heard from the CEO I owed him say you know, it's probably good to see what other people are doing, but let's just get out there and do it, and that's a bit of a red flag line. So I went away and did the comp analysis anyway and it revealed quite a few little insights about what the industry standard is. The fact that there isn't an industry standard in this case where it can be useful, that is probably as close as we can get to something that is, as you say, moving Because it's in flight for competition. We can use it and engage with it ourselves with a discrete account, and, you know, we can start to feature porch and I think that's probably one of the ways to work around.
Speaker 1:This idea of this is presuming that you don't have, let's say, the lead time to properly mock things up, as is the case. We're against quite a bit of time pressure and so we've kind of agreed to go with the best we can, best on the moving parts we can see, iterate where we can, where we can, and hopefully that won't fall apart the moment the first version is out there. What I will have to do and I think in this case, if you're in a similar situation to me, you do have to keep the pressure on to say, right, okay, our client is now using this part of the software, let me add them. I've got to understand as soon as possible how they're using it, because I think that can reveal just as much about their interpretation of what you've created. And of course you just want to get that feedback in as soon as possible and iterate it. I'd say that's kind of the approximate experience I've had recently. What about you, paul?
Speaker 2:Well, interesting, because I think you've hit the nail on the head there, Simon. Well, it's not real until it's on the actual thing people are going to be using. So I always say that my designs, even though they may be beautiful, they may be absolutely amazing if I do say so myself.
Speaker 1:That's always awful.
Speaker 2:But I always say that the sketches, they don't work without the codes, they don't work without. And what I've been doing recently is spending the whole day kind of, like you know, just on calls with, like the dev and we're just going through like well, this is the design, this is how it's working, these are the calls. What should the callers be on here? What? I'm just going to move on here, and it's just so much better to do it that way than think you've got to think about all the interactions as well, because when you work in partnership with somebody who knows the dev, the front end stuff, then you don't have to kind of make these amazing prototypes, you don't have to do this shitty dribble gif animation.
Speaker 2:Sometimes it's nice to give kind of like the idea of what you're trying to get, but most time just do it in code. You know, don't have that starting off point and then go and build it on the device you're actually going to use. Yeah, what was interesting? Because I had a problem recently. I was designing for mobile devices and then I realized the flip phones are in here to stay, probably, which is the horrible.
Speaker 2:It's come off, though. So you start off on this really thin screen and fold them out into this tablet, and how do you transition from one side to then go to kind of like a tablet? Or, if you've got the clump shell effect, you're on a really thin screen. I think it's like the Galaxy Z Fold is 217 pixels, yeah, and if you're designing for like an iPhone, a 375 pixels that's off the top of my head You've got a lot more screen. And then you kind of go like whoa, actually it doesn't work. So you've got to test it out on the actual devices that can be used in it. It's a whole design, so I had to rethink everything else.
Speaker 1:It's changing. Now you know what's. Horizontal scroll bar.
Speaker 2:We use the bathroom.
Speaker 3:It is almost frustrating, isn't it? The amount of different devices that you have to cater for. Now, I'm all up for like technology, but I generally I mean this big opinion here. But is it those phones just a bit of a gimmick? I know people that have bought them.
Speaker 3:They've seen like the color in the fold starts to get a bit rubbish and I know a few people that have had them and just got rid of them just because of that, and it's like you're causing us pain here. We have to do a load more testing and we have to build something else. If it's going to take over, then yeah, obviously you have to adapt, but I don't know.
Speaker 1:I feel like if it was going to take over, it might have already taken over. Apple would have done one right, yeah, yeah, well, exactly, yeah, you know. There was one thing that I wanted to touch on, actually regarding your question early. I can't remember if I did know, but one thing I think, when it comes back to working closely with development, getting these things realized, one thing is this is very easy to do when we take for granted that there's a bit of lead time to even establish what's necessary. But I found myself in situations in the past where it's been UX as a service, where Johnny CEO has come to all the equivalent thereof, which has been I do say, Simon, your ilk products managers has come along and said, look, this thing's in development.
Speaker 2:They were project managers, we've probably made that mistake.
Speaker 1:No one's innocent here but where they've said this thing's in development now and we need designs for it, and I think that is a very, very common situation. But I think, if you find that you're in that situation, you are going to really struggle to get any level of communication back, Because even with developers, when you're speaking to a developer, you're speaking to them about changes they've got to make to code. They've just spent a sprint or two putting together. What do you do in that situation? How do you and this is to both of you and to me as well, but I prefer your voices to mine what do you do about that? How do you react to it? How do you get ahead of it? Is it something that isn't on UX designers to recognize? On product managers to develop, to recognize who's responsible for this and how do we fix it?
Speaker 3:think I think a really interesting thing is I'm gonna flip it on my head and I'm gonna have a little. I'm gonna have a little mode about CEOs and which is equally, they go to the UX people first, sometimes as well, which is very frustrating.
Speaker 2:Yeah, yes, I think.
Speaker 3:I've always I've always installed a mentality that you work for these people right their vision areas. They probably know a little bit more than us about the market or they should, you'd hope so so they've had conversations with other. Let's say they're trying to, they've got a market share. A new customers come along and said we will Join you for X million pounds If you build this thing and they go. Well, that's my job. Right, to bring money in to pay all these people. They're here and I think the frustrating thing is and I've always said this you tell me the what, we're gonna validate it, but we'll do that quietly.
Speaker 2:She don't wanna don't know where's one of my.
Speaker 3:Let's deal with a how right and that's across all of the disciplines, so you can come in and say I want to build this feature. It's gonna make us a million pounds. Let us decide as developers call insurance, people, ux, product. Let us define that how we're gonna do it and trust us that will do it. Don't give us any time scales, which is never been, is it? But yeah, so I mean in those situations.
Speaker 3:Yeah, where I mean you have to do it right. There's no, that's yeah, you have to do it. How you do it should be dictated by the teams that are doing it. The time you get to do it isn't always the same, but I guess in that situation I've had it before. You just have to have a honest conversation and be like no one wants to be doing it like this. We know we don't. No one wants to have to rewrite the code again when you've got so far. But and I think the thing that we haven't actually spoke about for the last what nearly 30 minutes is, and I think everyone forgets is there's a customer here, there's a user, and it's what does the user want? So, if you have to, if I've been in places where we've built something that we absolutely thought that they wanted and they start using it and go.
Speaker 2:This isn't right.
Speaker 3:Yeah, you get a bit frustrated with yourself or whatever, because you're like shit, how do we miss?
Speaker 1:that For using your product for. Oh yeah, yeah, oh yes.
Speaker 2:Yeah, that's a classic. Never you. Yeah, we built this feature.
Speaker 3:It took us three months to build it and the customers not using it, why? Why are they stupid?
Speaker 2:Yeah yeah yeah but let's make a video how to use our product. But yeah, you have to.
Speaker 3:You have to think and I do this a lot and I've had a lot of these conversations. It's like, okay, you're here working, you've written some codes you're gonna have to write again. Or you've designed it, you could have to design it again. What? Why are you in this role? Is it to be happy all the time? Or is it to make the users a better product or feature? And then everyone knows that they're to Make a better product of each? Obviously, that hopefully increases revenue. That's right and you just have to. I think you just have to have those conversations very open, in, honestly, and nine times out of ten, unless someone digs the hills in and they start being an asshole about it, they're gonna be okay and if they are, I'd say you're probably not right for the organization.
Speaker 1:Yeah, you've got no passion. Yeah, you just want to spend your time not doing yeah.
Speaker 1:It's really interesting that it reminds me of An analogy that a friend of ours, a friend of the show, is responsible for, our. Our theme tune is James med, but he has. He? He illustrated an analogy of three planets orbiting each other and I'm gonna extend on it a bit. So the three planets in this, in this scenario, are your business requirements, your tech constraints and your user needs.
Speaker 1:Now, what I think I've taken for granted in the past is the idea that, okay, I'm on planet user needs and I think that's fine, and I can expect mr UI developer misses UI developer To be on planet tech constraints. I can also expect, let's say, product owner for now to be on planet business requirements. I Realizing now, I think, that you, simon, other son around which we are all supposed to actually be Arbatic, because it's you who Perhaps has to hold these things in balance, if we find that word. You know we're spending too much time on the tech constraints and nothing's getting done because people don't want to Refactor code or there's there's no. You know where we're allowing.
Speaker 1:I'm not saying this always happens. I've realized I'm giving you I does a bad name, but we're allowing too much pushback against actually doing some dev work or Likewise, we're spending too much time there is such a thing as too much time on research. It's very difficult to do. I've never seen it done. And there is such a time, theoretically, or likewise with we're just going in In the business too far with the business requirements, just Creating something that it turns out that the user doesn't want at all and maybe the tech stack doesn't support, and it's just an entire shit show. But you're in the middle of all this is. It's it feels like, and I wonder if you agree with me or disagree with me and why it feels like you're the one that's supposed to hold us in in balance here. What do you think? What do you say to that Accuversion?
Speaker 3:yeah, it's like a. It's like a solar system, venn diagram and product management. Product managers love a Venn diagram, don't they? But yeah, I think that's what the role should be. You know, it should be that person that says Business, fuck off your mental. Based on, and that could be based on, the other two planets, saying this is going to take 18 months to refactor. So, yeah, we're not gonna. If we're gonna build it, and you want to build it right, we gotta do this way or that's gonna take a lot of research. But equally, on the other side, it's gotta be. You've got it. You've got to sit in the middle of it when a UX person or Says this is gonna take six months of research and you go.
Speaker 3:Well, it should, yes, but we can still put something out with two months of research. Maybe it won't be as good, but there is that opportunity. And I think one of the one of the things that I always try to Try to think about is I mean, I've spent a lot of time in the world of star, so it's a bit easier. But think about building for how many users you've got. I think Monzo did this really well.
Speaker 3:I went to a talk a long time ago and they bill I forget what it was.
Speaker 3:It's like an overdraft facility. But they were like, right, we're gonna build this overdraft facility and we're gonna have to do we're gonna have to integrate with Equifax, all the like, to do a credit check and all of this sort of stuff, and I think they just hide someone to do all the manual stuff in the background and they got the products out in a couple of months. You know, and and that is a case of like, well, for the first and I talk about this a lot with teams for the first 200 users, it can be a bit shit, you know, and maybe the UX might, might be perfect and maybe it crashes a couple of times and the business will just have to accept that you want it in this period of time, then we'll do it. And then you go Okay, well, when it gets to a thousand users, it'll be a bit more robust and we'll know a bit more. Then, when it gets to a million users, you probably have got a big enough brand that someone's gonna complain about you on Twitter.
Speaker 3:So yeah, it's now, so you probably can't piss that many people off well.
Speaker 1:Yeah, I think that's a. It's a really really good point and I was gonna say something in to compliment that and it's just completely left my brain.
Speaker 2:So, paul, obviously, Well, I was gonna say exactly the same and I think sometimes you know kind of, whoever you give that lead time to, you should never give Too much lead time to anybody, because if they take six months to research, six months to design it, six months to build it and you might put something out there, that's a complete another piece of shit. Okay, um, I'd I do a talk on. You build it up, you stop building the wheels, you build a platform. We've got a skateboard, you stick a handlebar on, you've got a scooter, and then add a few more things, add a motor.
Speaker 2:Before you know it you've got a car. But then all the time you're getting little bits of feedback along the way. And I think if you do it in big, massive chunks and you did this big research piece, you do a big kind of like technical exploration, do all those things, then guarantee you that Somewhere along the line something's gonna fail and then you're gonna waste a shit like you better waste in Two weeks or, you know, two months. Then you are like with 20, 20 months worth of work.
Speaker 2:Yeah so just putting stuff out there early, getting feedback as well, of course. I think this. This ties in nicely back to you know you've got to see it on a real device. You should see on a real device. You know you're the first user testing it then and you do not use a test, otherwise everything's theory based you know you do a PhD part-time, you six years into proving a thesis that may never come true.
Speaker 3:I think, yeah, the whole world talks about like you hear one of the buzzwords out there like fail fast and stuff, but I don't know. I don't know if people actually know what that means. That's not an excuse to do shit work, it's. It's an opportunity to do something quickly and not Take massive repercussions. For you know so and and that means, and that means, like I do it in my role, you know, like I'll never. This is like something that's fundamentally built into me, because who I am and I'm very like process driven, but I will always write a business case for everything I want to do, not bugs and less you know, but most of the time bugs do. Yet, to be fair, like I'll always write business and that's for whoever it goes to right.
Speaker 3:It can be a massive document, which I try not to do, but it's sometimes you need a product spec for some of big. But I guess it means that you can fail right in the business case a little bit because you didn't get it right and then you revisit it and you can fail with the first iteration of the research or design or whatever, and you can fail right in code. But, like, if you don't do it, then I think it just takes so much time. Like I I'm on the project I'm working on at the minute. I'll put a feature out into it and there's this really annoying part.
Speaker 3:It's it's kind of annoying and you might wince at this, but like pasting a URL because you can add YouTube videos to it and the the button, but he's below the keyboard so you have to tap to Find the button. Yeah, well, yeah, it's frustrating, but people have been asking for video in this app that we built for like two months, so I just like put it out. We'll fix it next time. Yeah, yeah, I mean I'd yeah, that would read as a bug really, but yeah, it doesn't feel like one that's impossible to fix it.
Speaker 1:If it meant to be a bug, I feel like one that's impossible to fix it if it meant getting something out there two weeks Quicker to get the feedback on it or, even more likely, a release cycle quicker. Um, well, however long that is, I think to feed into that. You know, the failing fast concept is, I think it's misunderstood, because a lot of people read a headline or a book title with it in and think, oh, I couldn't chew at what that means and I'm going to make everyone do it. Um, but I, you know, I'm, I've done this myself and, to be honest, I can be a bit hostile about it. Sometimes. I've realized only in my in the confines of my own school, which I think helped. But sometimes a developer will send me a thing, I think, to UX review, and it'll just be a message, because it's a really small thing. It might be so something to do with selection, making sure that we have multiple select options, and they'll send it to me and I'll think the be first instinct is usually a sigh because it's like well, this is clearly your interpretation of how we should do this, rather than any to any kind of universal standards, but that's not always a bad thing. But usually what I end up thinking instead is yes, fire this out. Because what all I'm going to suggest is things like talking changes color, change font.
Speaker 1:Again, I would love to release things accessible first time, and there will come a time when we have to as a legal imperative. At the minute, we're not there. So if it's not quite accessible now, I will sometimes say look, this isn't accessible, these colors aren't right, these things aren't. If you can fix that in the next hour, fine, I'll do that. If not, if this needs to be done by the end of the day and you've not got enough time, we'll make an orc of it, it'll go on a backlog somewhere and we'll eventually get round to it.
Speaker 1:And I think, as much as I'm kind of loath to do that because I'd rather see the good UX in from the start. That is what failing fast would mean in these contexts. It's what lean UX means in this context is which you are able to say right, it's not perfect, but we've met the minimum viable. We can fire that out now. We'll have feedback in two weeks and you know what, if that feedback is, I'm not able to use this because of something stupid you've done, I can turn around and say, look, I told you, so I can have my moment on the hill. I mean it could be something I've done wrong. Someone will be able to say, I told you so and it's like, very good, we'll have a drink, we'll move on, we'll get it fixed in release, and I think being able to have those conversations and react like that. But again, bring this to the common point and we'll know this is something we're going to have to fix later.
Speaker 3:And I think that is Sorry, go on.
Speaker 1:No, no, is it?
Speaker 3:Yeah, no I think that's where I think you can build the most trust as a product manager. To be honest, when you make a decision like that, that isn't the decision that everyone wants to make and that's a priority call, isn't it? We're talking about them, and if you don't follow up on it, then you start losing the trust in the team. And maybe that's a developer that said you told me I could do this, or maybe it's the business that said you will fix this, or your ex-person that said you'll give me time.
Speaker 1:Yeah, and I think you make a really crucial point. Something that I've experienced not happen is that follow-up, that transparency, that this Right, we've released this as it is. We're going to do some evaluative research. Here's the time we've boxed for that, even if it's not put into a sprint or whatever just yet. Or here's where the further enhancement work lives on the backlog, even if it's just a line of a user story that will sit on there for a while. There's so many times where I've said I think you'll have experienced this a lot, paul, and you've probably experienced this yourself when you go into something you say, okay, we'll release the 0.5 version of it and we'll iterate on it's future, and then someone goes great and never touches it, ever over again.
Speaker 2:Yeah.
Speaker 1:And users are perpetually trying to find the submit button when they've just put a YouTube link in.
Speaker 2:I was going to ask Simon how Because as a UX person, one of the things always kind of goes makes my heart break, you know, or we'll put it on the backlog. I like yeah, as Mark alluded to, never gets touched, Kind of like how? Because the backlog only gets bigger and bigger, and bigger, and after a time, how do you go like should we even bother with this yet, or yeah?
Speaker 3:Don't put on the backlog. That's the easiest thing, isn't it? Put in the next release.
Speaker 3:If you think you have to do it now, we'll do it next, right? Obviously, the next could be the next one or the next one, but it's got to be at the forefront of your mind. If you've consciously made a decision together that we're going to do it, then you have to follow through and you do it. And you've got to keep it in your front of mind. And this is where I think it's easier in a smaller team. But when you've got massive business with hundreds of developers and competing priorities and the business doesn't know exactly where they're going, you know there's no, there's focus, but there's not focus on the little things. I think it's up to product managers to carve out that time and make sure that you do it.
Speaker 3:And again, it's back to the user, right? The conversation we just had was we made a decision to not put something in that we know we need to do. Don't just put on the backlog. Equally the amount of times I've just completely deleted a backlog. Like I do it. When I go into companies for the first time, I was like just get rid of your backlog. Like, oh, we've worked really hard on that, yeah, but you've not delivered it, so it doesn't matter anymore.
Speaker 2:Like if it was important it would have been done right. Yeah.
Speaker 3:Normally I export it into a spreadsheet, so it still exists.
Speaker 2:Yeah, yeah.
Speaker 1:We need that back now, or else you are fired. Yeah, on your fired, we're going to go back.
Speaker 3:I think a really interesting point about this is that people take things quite literally, like you said, mark, around like this is how we're going to do failing fast and this is how we're going to do. So that and I think I mean I quite openly say that I don't believe in scrum. I think it's a thing, but scrum is not agile, it's just a way of doing things.
Speaker 1:I completely agree with you. I have to say I think it's something that it's been quite a slow devolution in my mind. When I learned scrum as part of my university course, it was yeah, and that served its purpose, but at no point have I seen UX design and UX research successfully integrated into a scrum or even to print based system. We always have to use a parenthetical system, something that just lives on the sidelines to what this main quote, unquote agile thing is and kind of feed into it. But there's no membrane, as it were, between what we're doing and what Sprint is doing, what the scrum teams are doing. So it just never happens and you just end up bouncing against walls and, as I mentioned earlier, with no lead time to do anything, your centralized teams working away on stuff that you hope to get in to scrum, whilst the scrum team is coming to you with things that they think you should prioritize because they've already started development on. So yeah, I have to say, completely agree with you, and that's I'm sorry.
Speaker 2:I read the other day that the guy who came up with the whole scrum ethos he said didn't he write an article and say like just doesn't work, it's?
Speaker 1:a pilot piece. I was wrong.
Speaker 2:And yeah, companies have implemented agile and scrum of wasting billion.
Speaker 3:I think it is interesting. Is it better than what was happening? Absolutely. Is it hard and fast? I think so. I've worked in companies where we've got scrum and I've come in here. You don't understand scrum and I might have a little rant here, if that's all right.
Speaker 2:Yeah, yeah, please do.
Speaker 3:I hate the concept of story points. I think it's ridiculous that you sit in a room together and you create imaginary estimates. That takes up so much people's time to put things into a window, and you know what. The worst part about it is and it gets me every time is let's say, we've worked out the velocity based on people that are on holiday and people that are here and what they've done previously, to do a new thing which they've not done before, which inherently is ridiculous, like if I said Mark, can you paint the Sistine Chapel?
Speaker 3:How long is it going to take? And the only thing you've ever done before is I've entered plenty of chapels.
Speaker 1:Well, okay, before I was t-shirt, size it as an XL.
Speaker 3:But then you're the right person to maybe estimate it.
Speaker 2:But if you've never done it before, maybe your background's a cobbler, it's like.
Speaker 3:And then the worst part about it is you get like I don't know, you get a 13 and an 18. I don't even know if that's in the Feminist scale properly, but you get a 13 and 18. I'm going to do some maths here. That's 31, right, yeah, 31. And the velocity?
Speaker 2:of the team is 30.
Speaker 3:It means I have to take one of those things out and fill it with shit that the customer doesn't need.
Speaker 3:And then you've got this whole and then you plan it, you do it, you put it out for two weeks, then you get to do the next one and you're about six weeks away from delivering the thing that the business actually wanted, and it's ridiculous. So we just do releases. That's what I've always done. I go into a company, they go, we do scrum, that's all right, try this, what is it? We're going to release it. When this is ready, we're going to release it in three weeks.
Speaker 1:Maybe it takes one week, yeah our job is not, as I'm sure there can be a degree of estimation involved in in release and and releases.
Speaker 1:But yeah, I feel like we're at this point now where, especially in that scenario where you've just described, where people are meant meant to be estimated, in the void, where we put in the horse before the car yeah and, yeah, you, as you say, you end up in a situation where you're delivering shit because it also, at the same time, I guarantee that those 17 spare sprint story points, it's not tech debt that's getting addressed at that time, it's never tech being of the future.
Speaker 1:Close it, yeah, yeah, yeah, another feature that is on the backlog and has been picked out completely around them yeah, I totally agree and I think, again, working towards releases is, again, it opens up teams to things like lead time for research, to things like lead time for design, to feeding proper relationship between what you're doing, centralized in your UX team, your design system to your component enhancements, etc. To what is supposed to spit fit in. Well, what would? You would have said it fits into spread, but in this time, fits within a release, because all of a sudden, your release timeframe encompasses so much more than just 30 imaginary points on an imaginary scale.
Speaker 2:Every time I go in an organization that you scroll by, I always ask what the points equal and then you go from team to team and it means totally different things. Someone will say like, oh, point means a day, another one. Somebody will go like, oh, it's just how big a feature will be, and like it's all arbitrary then and it doesn't why you wasted time on something that's theory. Going back to the theories and like why? Yeah, I don't get why you spend so much time doing this and people have done like landing poker and all gamification around this.
Speaker 3:It's just, yeah, I think, playing cards with no cards the way I am, the way I always pitch it to the businesses. Okay, we've got a team of eight people and I'm gonna get them together to do sprint planning every week, let's say and collectively that's 20 hours of time that there could be writing code now bear with me or designing, because you say that to a business, but actually what you let them do is in that time you let them do self-development as well. You know it's not just writing code time, it could be self-development, it could be learning. You know it could be anything in that time that you get back. I've never, like I've never been one of those people that, like dev, output should be a hundred percent. It's not an agency like we're not billing. Well, it could be, but you know I mean it shouldn't be run like it is, like your time is 100% billable, alright. Well, when do when do I go for a piss?
Speaker 2:then you know yeah this is an Amazon warehouse, thank you yeah, but under the, there's a ball under your desk just for that, yeah yeah, right it's.
Speaker 3:It's interesting as well, though, because I've not really thought about it for a long time because I've not worked in that scrum sand. But what? What do they do if all the tickets are complete? When? When do they start the next sprint? For the end, right?
Speaker 2:yeah, yeah, yeah, twiddling the phones. Yeah, something to them usually.
Speaker 1:Usually someone or your PO sneaks something in. Yeah, that'll fight them for you today. But then you have to trust that that estimates correct, because what you do if you're halfway through, do you abandon it or do you carry that through? And has that taken off your velocity of the next? And what do you do with this so-called velocity? Still, anyway, who's just being reported to? It's just who.
Speaker 3:Yeah it's just a number that's made up from made up numbers like it doesn't mean anything this reminds me.
Speaker 1:Actually, I tried to help my. I think scrum might, might work if you have a team of one or two people and you're working dedicatedly on something, because I was working at trying to see how scrum could help my sister when she was doing her degree and my idea was she never actually ended up doing it, because it's a lot of as we've just talked about, it's a lot of pissing about writing up stuff that's only gonna get deleted. You know there's an ecological impact on that, never mind anything else. So these days it's just, it's just not the best approach. It's not sustainable, but I can see it. It working when the entire organization is interned within a one person's head and in this case, an organization is a person doing their degree, maybe a set two people doing their degree, and it allows you to align on.
Speaker 1:Alright. Well, I've got all this reading to do, all these essays to do. I know I have much more accurate understanding of where my time boxing sits, but I still think it'll. It's never gonna be as simple as going right. We've got this deadline.
Speaker 3:I need to sit down and get it done yeah, because humans are inherently very good at procrastinating as well. Right?
Speaker 1:oh yes, and you know, I think that's what scrum is in this context. It's an excellent way to procrastinate.
Speaker 3:I think it works very well and I've seen it.
Speaker 3:I've been on the when I, when I spoke about the FMCG that works in, we had an agency that they ran the scrum process and I was fill in all the marketing needs you know, 173 websites all built on either WordPress or Magento and that agency did very similar things for us across the different brands.
Speaker 3:You know it'd be like run a campaign to a bespoke campaign for this, do that for that, and the first thing the marketing team wanted to know was how much does it cost? And the way that you get an idea of cost is you get an estimate and if they are using the same platform, building similar things again and again, then you can probably work out a cost and it does work. I mean, it never gets released on time because people, but then there's always changes and stuff and it does work quite well in that sort of repetitive cycle. The problem with that is people don't like working in a repetitive cycle, so when you, when you've got an agency that's doing this stuff for you, they rotate the teams because the people get caught which flows you froze, you have lost it out.
Speaker 3:I think it just if it's, for I think the biggest thing that it's people use it for is management, estimation, management right so say we can probably do that in three weeks. Do you want to do it? But to me that comes back to a, let's say the, the brand, and then we'll call them like Wella, the hair company go. We need to build this campaign. That wasn't, it will work for by the way but they want to build this campaign.
Speaker 3:In this campaign from the marketing team, it's gonna make us I don't know a hundred million quid in product sold and it's gonna get a reach of this. They've got their KPIs and they go to the agency we need you to build this. And they say, right, we're gonna estimate that it's gonna take 10 days. What blended rate of a thousand pound a day? Let's just say it's 10 grand. Yeah, they go. Oh, it's not really, I haven't got the budget for it.
Speaker 3:And then that and that then needs to not be a conversation with the agency to reduce the price. It needs to be a conversation with the business to increase the budget. If the, if, the, if the result of it is gonna be good, then you should do it. But if the agency came back and said that's 30 days, 30 grand, and then they just go okay, well, we won't do it. And I think people get so involved in their ideas that it has to be done. It's like we have to do this now because I've done all the planning and we have to build it and it doesn't matter how much it costs or it has to cost this much, and then you have to do it.
Speaker 3:And again, you forget the reason why you're doing it. Who are you building it for? What's the reason? Obviously, it's always ultimately make money, because business but it it does have to be a we are giving the user something. And then the choices, and it's very simple, right? It's not when you get into it, but the choices do you want to build it or do you don't want to build it? Every product, yeah, there's a binary at the end of it.
Speaker 1:Yeah, I think again, there's so many variables, like I can see the point, I can see the the use for for this kind of methodology within estimating that there are so many variables that I think even within that context, that's why you never get a correct estimate. Yeah, it's just, it's just a given, or at least it's a zeitgeist, an unspoken agreement that will. Also, this is the closest we can get to an estimate based on all these perpetually moving parts. I think where it falls apart is all right, you can. When you've got anywhere where you've got fewer variables, and when you're making estimates is when it just you've no chance.
Speaker 1:Design is a great example of that, because a lot of what we're doing is actually qualitative, not constant. When it's one of the problems. I mean we could do a separate podcast on UX metrics, but it's a great example of you know when, when you're trying to improve the UX or something you're trying to improve, how good it is for the, how good the user experience is, well, how do you measure that? Because you can measure the rate at which someone goes through it. But someone can go through the process of leaving a review very quickly if they just smash on a keyboard and hit enter. So yeah, I think, I think. Yeah, working within strict variables is one thing, but the moment you shift to something that's not quantitative, you fucked that's my hot take.
Speaker 3:It's really, really difficult to measure success, isn't it? It is, it's and it. And I think that's measuring humans, you know, because they'll typically they'll use it. I think there's, I think there's three levels. There is I absolutely I'm not going to use this and I'm going to tell you how shit is, and that's probably the best feedback because you can change it, yeah, and then you've got the it's amazing, I love using this product, and then they'll tell you about it. And then you got the bit in the middle which is it's not great.
Speaker 1:It doesn't annoy me enough to tell you, but that's probably where you can make the most gains, I think, and that's probably where most people sit right, because, I think there's a secret for one, because a lot of good UX, especially good UI, is totally invisible. It's like you don't spend your life thinking, oh, what a good thing it is that I don't have a stone in my shoe. You only notice when you've got a fucking stone in your shoe, and I think that is a real you know, when someone's able to say in fact, I suppose it's actually the same point as you're making is when a person says, well, this is a bit shit, but I put up with it. They're also likely to, you know, not not realize it's there because we're so used to putting up with a degree of heartache, yeah, something being a pain. They ask, especially digitally, that we just we don't, we don't even think that there's a standard above what we should be working on what we're currently experiencing, sorry, it's interesting because that everybody's got a different threshold level and this.
Speaker 2:This is what bugs me about MPS scores and metrics like that, because people have different thresholds. And I was just before Christmas, I was walking by on the street and somebody did did an MPS quiz on me about subway and they asked me kind of what I thought about subway and kind of experience of subway. I didn't even go in the fucking job but I was intrigued kind of on there and they kept marking me and I went like yeah, it's pretty good, and they kept marking me as a seven and anybody knows MPS those that are seven is it's quite a good score, but it's a neutral score and it doesn't get rated to was in nine, ten, nine nine yeah, it's a positive, and they kept putting me down as a seven because their threshold of good was seven and like anything above seven would be good.
Speaker 2:But on the MPS rating I was a total neutral person and it's that. But like I might have a different threshold. To like digital stuff is way higher than loads of other people and they'll use something even if it frustrates me, and then I won't complain about it as well. But other people, the pick, the pick something up and they can like oh, don't like how that feels, and then they'll get rated zero. One star out of five. I'm turning into that post very very quickly.
Speaker 1:But there was something, because I'm quite good at, you know, if someone advertises me an app and I think, oh, that will solve a problem I have right now, so I can give an example of this. That happened today. But one of my new years resolutions is to continue I'm going to say continue to get my finances in order, because I made a bit of progress last year not much, but a bit. So I enjoy, of course, because my phone is permanently listening to me. I got advertised I think it's Snoop, which is a financial budgeting tracking app, and I thought, okay, I'd be very interested in seeing how this works, because I know that NatWest stuff has I. It just doesn't work for me. Everything else is so far.
Speaker 1:The onboarding process was great. It was just clicking through, really personable, quite, and it's quite enjoyable Connected my accounts completely painlessly Then Tom, and it had listed 13 payments for this past month as friends and family. At least three of them were the pub I was in. So the reality was that I'm going to have to click through every one of these and say, no, this is actually this business and it comes under that category. Am I going to have to do that for every single expenditure I make, which part of the problem is, as someone who budget says who wants to budget more. Is there too many of them anyway? Am I going to have to go through them manually? Click each one. So I should close the app and I intend on installing it later today.
Speaker 3:It's like what Monzo did. It's so good. I think it's really good, see, and this is where users are different, right? So Monzo did their RAPT, didn't they? The version of Spotify.
Speaker 2:RAPT.
Speaker 3:And people were kicking off like why are you guilt-tripping me for going to, like you were the top 3% in your area for Greggs or something like that, and guilt-tripping me into being fat and stuff like that, and I get it right. That's a user's opinion. My opinion is this is great. I thought it was really funny because I know that I did it right and this is where I looked at it and that's my opinion.
Speaker 3:right, I was around my friends' house and they're quite healthy. People go to the gym every day. He's a fine man, she's like one into a fitness and stuff and I've got an Okay so they're out for some. Yeah, I've got a bulging equator, let's call it that. But I.
Speaker 1:Your waist is like Exactly.
Speaker 3:Yeah, I looked at it and I didn't get my dollars 52 times.
Speaker 2:Oh yeah, which is oh.
Speaker 3:You had two weeks.
Speaker 2:I was. Yeah, yeah, I was, but I think yeah.
Speaker 3:And I'm just like you know what I own it Like and you've got it, yeah, yeah. And some people won't do that and they'll get annoyed and start tweeting once right, yeah, then what do we call it Exing now?
Speaker 1:I don't call it anything, to be honest with me though I don't have.
Speaker 1:Well, I do have a Twitter account. It's just not been active ever since I got it, like 10 years ago and yeah, but I totally agree, Like actually for me that would actually be really useful. I suspect my biggest expenditure outside of rent is likely to be Ubers, Because I'm likely to get an Uber very frequently when they're like five quid and I can't be asked because it's darker, it's raining or whatever. But when I'm doing that several times a week, all of a sudden I'm spending a third of the year on Ubers.
Speaker 1:you know Mine was.
Speaker 3:Enough to actually hire the keepers of the year, the wrong people. Mine was Tesco Milleveals. Years ago I was in the same boat and I was looking for a product that sort of helped me out. And yeah, I got Monzo and I just moved money over and then I realized that in a month I'd buying. I think there were £2.50 then. So it was a while ago, yeah, but it was like £2.50, £2.50, £2.50. It adds up anything. Wow, yeah, I should just take lunch to work with me.
Speaker 1:Yeah, but the interesting thing is, though, is that the UX of that RAPT only tells you Well, I don't know, I didn't use it. I do have a Monzo, but I don't really use it for long enough to show me anything, but it tells you where you're spending most of your money, not what on.
Speaker 3:No, it tells you, so it gives you a breakdown. It gave you a breakdown of all the different companies where you spent your money. So, yeah, one of the highest ones was shout out to the Magnet Pub in Stoutport. Yeah, of course. That's where I spent a lot of it. Yeah, I think it was Monzo Grey and marketing and it was a bit of a given.
Speaker 1:Yeah, it was a good, especially considering the dominance with which Spotify RAPT exists for people. It turned out. So, spotify RAPT, not that anyone is interested. I think they give you eight different genres for your top genres. Six of mine were classical music. So it told me nothing. Yeah, because you know. Yeah, I know that Also. What I didn't know is how stupidly Spotify divvies up its classical music. It's not actually the way it's. So the RAPT time, the way classical music is split, is by dates. You've got the Baroque period, you've got the Pre-Baroque period, which goes by various names.
Speaker 1:You've got your classical, which is its own period You've got your romantic and then you've got your modern, which can be split into different things that if they had sent me those different categories I would have been a very impressed young man. In fact I was an infuriated bitter boy. And again, when my partner was like, oh, that's two Spotify RAPT, I was like, yeah sure, the top listen to thing is the thing I have on my alarm every fucking morning and six of my eight genres are all the same.
Speaker 1:So not the most optimal experience for me, but I'm just a different user.
Speaker 2:I'm the same. I'm the same Because I've got songs of kids play bed, because they're just kids over there. Once there's a popular song, that's it Number one all the time.
Speaker 3:There's a good point in this, though, which I was going to say before, and I just remembered users will use stuff even if they don't like it, and now this one we're talking about is just because it's trendy, right.
Speaker 3:You're like, yeah, and there's different reasons. But I think one thing that sticks out in my mind is I went to talk it was at the product tank in Manchester and it was someone from the government and they had this absolutely atrocious looking form, right. It was, I think it was like 120 multi-select fields on a webpage with no design and it was like slightly agree to strongly disagree or whatever. It was All the way down 120. And he said, right, raise hands. How many people do you think just didn't fill this in. And obviously everyone put their hand up and then they went down and down the percentages and it had a 98% completion rate, right, so the form was filled in. And that's for two reasons, right, one is there was no other option, so they had to do it.
Speaker 3:So that was the only way they could collect the data. And the second thing is sometimes people will just do it Like we know that people will just go through a bad user experience.
Speaker 3:Sometimes, if the product is, it does give them something because you can't get everything right, there might be a bad bit in it, like you're saying, mark, that it is a bit of a pain in the ass that you're going to have to if you continue using this app, that you're going to have to map those things, but in the future maybe they've got a plan in the roadmap that can automatically do it based on your previous mapping.
Speaker 1:That would be yeah, or the mapping that other people do. You know, salt Dogs Limbs in Manchester has been around for a little while now. I was surprised the system hasn't picked it up already. The interesting thing, though, is I realized and about this was it was the same problem I had in Monza, I think I did, but and Nat West, my bank, so it wasn't actually solving the problem for me, it was just giving me another place to experience it.
Speaker 3:Yeah, that's true. I've got one at a minute actually, I'm going to call someone out and I do this a lot and I should. I've emailed, like Jira last year. They're the worst. You know. They're a product company that literally designed tools for people that build on some of their UX is shocking, and I always, always, give them feedback. Never, never, have they ever contacted me back and Facebook my God for such a big company.
Speaker 3:There's a lot of people that I call it. Some of their UX is shocking, however, this one's the National Lottery app. It crashes every time you open it. You close it, you open it again. It crashes. Right, I'm putting money into this app, but the I will still use it because it's the only place that I could potentially win 15 million quid on a Tuesday and a Friday. Yeah, yeah. And they probably know that it crashes.
Speaker 3:I do assume they will know that it crashes and they're just like is it the amount of people doing the lottery going down? No well, it might be a really hard bug right. It might be something that they just can't figure out, but you still use it.
Speaker 1:It's possibly more likely that people are still getting lottery numbers the old fashioned way rather than migrating to the app. Because does the app support things like syndicates, lottery syndicates and stuff like that people going in together and going out together?
Speaker 3:No, but that's a good idea you do the UX, I'll do the other bit, we'll find a team to build it. Yeah, yeah.
Speaker 1:We'll start our old lottery fucking.
Speaker 3:We'll sell it to the National Lottery. Yeah, yeah.
Speaker 1:Well, we, because it's going out at some point. So if we can get that done before Paul edits this episode together, we might have something before National Lottery just picking up and run. Anyway, this is assuming out of our four listeners, one of them's working at the National Lottery.
Speaker 2:Nice, we're going to have to wrap it up. Yeah, and now UX tomorrow.
Speaker 1:No, and to think I got AI to put together some tasks.
Speaker 1:I was going to sit down with my partner Ethan, and say, right, we need to as a little icebreaker not icebreaker like a little break, icebreaker implies I don't know who my partner is as a little kind of break, let's think up some random shit, put in the UX umbrella. And then I thought, hold on a minute, open up chapter BT and said to it give me a simple list of 50 random tasks, object things, activities, products, events. It did that, but it did so in a far more helpful way than it thought, in the sense that it was like plant a flower, it was like things to do, solve a crossword puzzle.
Speaker 1:So I said remove anything that isn't known. And so it came back with flower crossword puzzle, chocolate chip cookies. I said remove the numbers before each item and then so pluralize each item were grammatically correct. And then I put that into our little tomb, all the wheel, for it to apparently sit and collect fucking dust. Sorry, I'm glad I've had a trip there with my partner and spent 15, 20 minutes thinking of all this shit.
Speaker 2:Well, we will do it soon, Simon. You come back on, come back on for another episode and we'll do UX tomb all the way proper. Oh absolutely yeah.
Speaker 3:It's been great fun to you. Not quite the same as the last time after the UX meet in the pub, was it.
Speaker 1:No Opinions are the same.
Speaker 2:Yeah, we're getting a bit more random, but welcome back any time.
Speaker 1:Yes, so, simon, what can people find you if they are? Too, fine, oh yeah.
Speaker 3:LinkedIn Simon Berry when else.
Speaker 1:There you go.
Speaker 3:Burnage in Manchester.
Speaker 1:Oh sorry, Most specific. I'm really hooked.
Speaker 2:Yeah, you're excited. I did have a website, but I just turned it off.
Speaker 3:Most people kept calling me from it. It's annoying. So instead of taking my phone number off, it was built in HTML by myself a very long time ago. I was just like I can't be bothered to turn it off Full of dough. Yeah, no LinkedIn, well LinkedIn it is yeah brilliant.
Speaker 2:Nice.
Speaker 1:Well, thank you. Now you noticed, at the start of our podcast we spent that awkward 15 seconds spinning up. This is where we bookend it with the 15 seconds of awkward mumbling and silence.
Speaker 2:and thank you, goodbye and good bye.
Speaker 1:Good bye and good bye Before we just hard cut off the episode.
Speaker 2:Yeah, just tails off. We should perhaps be like songs of like the 60s 70s, where they're just kind of like we just carry on talking and they just fade off into oblivion If you do that at the point where you should say we should just fade off.
Speaker 3:Yeah, just fades out.
Speaker 2:Yeah, that requires a bit of Edison, so that's not going to happen.
Speaker 3:You could just talk very slowly, right? This is the end of the podcast we're going to fade off Done, that's it.
Speaker 2:Oh well, no, thank you for that, that was really interesting. Yeah, it was really good.
Speaker 1:I managed to display some of my internal blame I had for the way I've done things in the past on to ineffective product managers and product owners. So that was vindicating.
Speaker 3:It did feel a bit like therapy, which is good yeah.
Speaker 1:It's kind of what this does actually to serve that purpose.
Speaker 3:I think more people just need to talk and work together. The concept of work doesn't feel like work anymore. It feels like everyone doing different things, doesn't it? It's a bit of a weird time.
Speaker 1:Yeah, I think you know I've seen a bit about work-life integration over work-life balance and I think what that I was so very cautious of that. I think a lot of that comes down to just the communication. What the fuck did that do?
Speaker 2:I was trying to ignore that because it was like Hello, what are you doing?
Speaker 1:Mortal right, yeah, you can download it yeah.
Speaker 3:My God.
Speaker 2:I was very serious.
Speaker 3:Yeah, I was very serious. I've got a serious face, resting product manager face.
Speaker 2:Resting yeah.
Speaker 1:I'm not sure if in a photo where all you can see is my fucking filthy laundry in the background.
Speaker 3:Yeah, I cleaned the room, forwarded it. Yeah, all my laundry is piled up on there. It's on the bed.
Speaker 1:Yeah, I mean, that's not actually mine, though, that's my brother's, but this is my dressing going on the back of you.
Speaker 3:Cheers for your time, thank you.
Speaker 2:Lovely to speak to you again.
Speaker 1:I'm an ant. Yeah, we'll speak again soon, love you all.
Speaker 3:Contact me about that UI person.
Speaker 1:Oh yeah, oh well, he is very good. He is like a real one now. Okay, okay, that's great.
Speaker 3:Brilliant. Bye. Kids, Cheers Sweet.
Speaker 2:Bye, see you later. Bye.