Jason Knight 0:00 Hello, and welcome to the show. I'm your host, Jason Knight, and on each episode of this podcast, I'll be having inspiring conversations with passionate product people. If that meets your requirements, why not come and hear some other stories from me and some of the finest product thought leaders and practitioners in the world? You can head over to OneKnightInProduct.com where you can sign up to the mailing list, subscribe on your favourite podcast app or follow the podcast on social media and guarantee you never miss another episode again. On tonight's episode, we speak to a business analyst who got bored of writing out all those requirements and built a platform to do it all at scale. We talked about the job of a business analyst and what they really do and how it differs from product management. We talk all about user stories... What's a good user story? What mistakes do people make with them? Are there any better alternatives? We also ponder what to do with that one stubborn developer who always wants to do things their way, and if it's really okay to have to work around them. For all this and much more, please join us on One Knight in Product. So my guest tonight is Richard Awe. Richard's a business analyst, data artist and wannabe animator who spent 15 years working in and around finance and banking... currently working as lead business analyst for the European Central Bank. Way back before that Richard had a job on a construction site and he's now taking that building expertise into his new startup Requstory, a platform that hopes to take the pain out of writing user stories. So let's try it out. As a podcast owner, I want an insightful and entertaining interview so I can release it to my listeners. Hi, Richard, how are you tonight? Richard Awe 1:33 I'm alright, Jason, how are you? Jason Knight 1:35 I'm doing fantastic. Thank you very much. Richard Awe 1:37 That's good. Thanks for doing this. Jason Knight 1:39 Yeah, no worries. So first things first, before we talk about your startup, let's find out a little bit about you and your journey. So you're currently a business analyst for the European Central Bank. Yes. So what sort of stuff are you working on there? Richard Awe 1:51 Okay, with the European Central Bank, working on some identity and access management systems across a few business areas. I think the last xount was about 100. And that's rounding off soon. We're going to get old application and I'm gonna go elsewhere. But yes, my management, typical BA stuff get everywhere I maintain implemented. Everybody's happy. As simple as it sound, but yeah, yeah, no, I mean, that's what I'm doing for them. Jason Knight 2:21 Yeah, but that sounds like I mean, if you're working for the European Central Bank, that sounds like the sort of thing that'd be quite wide ranging, you're talking already about, like 100 different... I don't know what, teams or things or systems you have to invent or integrate with. That sounds like there's going back to those requirements, there's probably quite a lot of them, right? Like, is that something that's quite overwhelming? Or do you manage to kind of tread a happy path and all of that? Richard Awe 2:41 Well, like you notice, I've been doing this for a while. Jason Knight 2:44 So you're a BA ninja! Richard Awe 2:48 Yeah. Maybe if I, if this was 10 years ago, I've been worried, but I'm going into, it wasn't, it wasn't too wasn't too much of a hassle. If I could give you a very brief of what happened, it was working in a strange manner, was agile ish. So speak to business today, you speak to a particular business unit today, take on their requirements, get the team to implement them, and go back to them tomorrow, and say, "Okay, we've implemented can we start testing", we test and after we've tested, we go back and be okay with what we've implemented. We go ahead, and sometimes you might implement and go back to them, and they'll say, "Oh, we're not ready to look at whatever you've implemented". And you go look for another business area and come back and try again. But it's not complicated. He was was more around talking to people than talking to the technical side of things, because technical guys knew what they needed to implement. Jason Knight 3:45 But talk about that technical I mean, before you went into the world of work, you studied, and you got a bachelor's in agricultural engineering, and you got a master's in chemical engineering. So you've got a very scientific background. How did you go from that into business analysis? And why did you do that in banking? Richard Awe 4:01 So short story. So my background is in agriculture and five year costs for diversity of technology in Akure, in Nigeria, and my master's in chemical engineering and University of Glasgow, but say, working well, in Nigeria, I work for bank Access Bank, and then moved over to the UK after that, and to do my master's. And then once I finished my master's, I was working for also another bank mathletes. But it was just one of those rules were you needed to do you just mentally finished a master's and you're trying to get a proper job. I was actually still looking to go to Aberdeen to go into going to oil and gas and become a process engineer. But one of those interesting evenings I was signed up for this mechanical engineering association. So they go to some companies to go just check out their structure, check out their infrastructure. So I went in there and one of the there was a beer making company in Glasgow, and I went in When I made the process engineer, I was late in the evening, the process engineer was still there. And he was, he showed me around, he told me my, my partner was in chemical engineering. And he showed me around, you know, these big distillers and all this processing stuff. And I go back home, and my girlfriend and my wife now I told her, Okay, I don't think I'll ever be a Process Engineer. And she was like, why, why? And I was like, those things are noisy I can. And, and that was the end of the actually think I had some interviews coming up with some of the old phones in Aberdeen at that point in time, but this wasn't for me. So I kept on walking up Barclays and luckily, I met a guy who was the business engineer, and business analyst. And he spoke, come to do some stuffs at processing centre then. And I was like, what do you do? Tony was a business analyst, and we bonded over the next few days. I was like, "Yeah, I want to do this job". The good thing about business analysis was because it's as close to engineering as possible. You're drawing diagrams, you're speaking to people, you're making stuff, or you're getting stuffs out there. And that was an attraction for me, and Natalie's really good then. So I spoke to some people in HR, and they moved mountains to get me a business analysis role. And then when I was in Glasgow, but the business analysis show was in Manchester, so we had to relocate from Glasgow down to Manchester. But yeah, that's how I got into business analysis. wasn't entirely by design, but it was more by an iterative process. I knocked off a few rows out of along the robot. Yeah. And I love I love being a business analyst, believe me, it's the fact that you get to talk to people. And it's actually made me develop a few skills that I never even knew I had to I could actually make use of so it's been good. But yeah, that was a journey. Jason Knight 6:59 Yeah, sounds good. So one of the things about a business analyst on the show before, and you've touched a little bit on some of the things that you're working on there, but just for the record, how would you describe the role of a business analyst? And how similar Do you think it is to, for example, a product owner or product manager in an Agile team? Richard Awe 7:15 I usually say we're the guys that ask "Why?" Jason Knight 7:19 But that's what product managers do. Come on! Richard Awe 7:20 Well, what product managers, x y of the team, business analysts, xy of stakeholders, and the users and every other person, so but I think that that definition was rubbish online recently, also, like some people said, No, don't x, y. So many things I like, but the life of a business analyst is around trying to juggle between what the business wants, and what the user wants, and what can be delivered. So you're asking stakeholders, the project sponsor or the product owner, about what they want to do, you're trying to liaise with as many business areas to make sure that you've taken everything they want, from markets into compliance, essentially, compliance in banking. And you're also trying to battle with the technical guys that deliver things to say, okay, yes, this is what the business wants, how are you going to deliver that? Obviously, you create the requirements log, and you draw designs, and you, you map out the current state and future state and you trying to say, Okay, this is what we're trying to achieve. So that's the life of a business analyst. For some reason, it has, I think, because there's a very solid community around it. Also, it has some form of standard, when you compare it with a product manager, I know we've had some of this debate on Twitter, where nobody knows what the product manager does, or the job is too complex. But for some reason, what business analysts will do is kind of well defined. I remember when I started out my career, one of the things we do, one of the things that will get set to you by a most senior business analyst, so a little bit of analysis, you're not a project manager, you're not responsible for timelines, they're just responsible for gathering requirements and passing it on to the next person who needs to work on it to gather requirements and pass them but as you grow older in the profession, and as you grow older, in your career, you realise okay, maybe that shouldn't be that simple. You should take some form of responsibility, gather requirements, make sure it gets to the to the guys who will build it, if they need any help getting 80 of them be there to get involved in the testing of it. And you help getting make sure you deliver some value to the user. And again in and like you see for my LinkedIn profile from the guys, I've worked in the banking guys and so they're not really that agile, they are no getting products that most of them are struggling with meeting regulatory dictates for them to build this or to do that. So they're not really going to the customer and asking every five minutes. Is this what you want? They just need to Butte stuff so most of them are still very waterfall in nature. Oh yeah. Like I was saying to a friend recently, like, I've done every form of agile of him from swagged, out to Hodge out to Badjao. Everybody wants to have a form of idea. But in most cases in most of the banks in the tried to create teams, and this the the app productive, and as I know, whatever in the true sense of it, they still need to do waterfall because in a regulatory environment, you're not just going to throw in stuff and test it and come back and change it in the next week in another sprint, it's, it doesn't really work that way you need to build and you need to make sure it's fit for the customer. Now, do you get customer feedback after that? Yeah, you could get it and change it at the next iteration. But it's usually mostly waterfall for most of the organisation, especially those ones struggling with regulatory stuff. So that's the life of most banks. I know the challenger banks these days are putting them on their toes and all that. And they all they're all still trying too hard to get into the ideal space. But it's never been that easy for them. Jason Knight 11:06 Well, but you're scratching the true product each with your own startup now, though. So you're the founder of Requstory. So let's talk about Requstory. What problem does Requstory solve for me? Richard Awe 11:16 Okay, so Requstory, I'll tell a story I was recently working for on a project. And we had to write lots of user stories and requirements and all that. And some of them were repetitive. So because it was one of those setups where you just had to write those requirements and knock them off and prioritise them as you go along and take out the ones you don't need, and the ones you need. And I found out there was, so I was typing C's or unexploited type, so as to come up with something to me writing this requirements faster. So I came up with some spreadsheet as you start to say, okay, just a few clicks, and I'll get these user stories out as much as as fast as possible. After I've done that, I decided, okay, actually to a colleague who might have a friend who also fed Oh, this is good. I've never thought about this. After that, like she's into a no call to buy used card and table. And then some of their friends used it. And they were like, Oh, this, this will work, especially for new guys who are just getting into this. So was on that basis that we set the record straight to say, Okay, we could we could have a tool for people to simply easily write these stories, especially for people who've never seen them before, or people who've written them for, and they just need something to churn it out faster, and Dallas stuff. And after that we just met get in touch. It's one of the developers and he helped me to put it together into the proper setup, because I just didn't want to have a no could send out every heavy ounce of my energy to maintain that time. So I just needed something that would be more stable. I know people call it a startup, but I just still think it's just too, and we're just trying to get people to use it. And see and come back with comments. But yeah, that's it. Jason Knight 13:15 Right. So you're really trying to help to make the process of making user stories a lot quicker, a lot more efficient, I guess. But is it primarily focused then around efficiencies? Or are you also thinking about other things like collaboration? Or oh, yeah, maybe even started to have ways that you can try to not just type stuff in like sort of Mad Libs, like fill in the blanks, but kind of provide more guided input? Is that something that you're looking at as well? Richard Awe 13:43 So once we started once I got that out some of the feedback I got, especially from some people on Twitter, some groups I am on Slack and Discord were like, Oh, you could be could add this in this should be good. So you could have some collaboration, you could add a way for people to see the fancy. I want to share with my team so that you could share with your team. Oh, some then some people came? Oh, you could that's me, I element and it's all right, or the easiest service for you. And you don't have to do all that. And I was like, Okay, fine. We could we could be the same. So that's the space we're in now. We just wanted to get the idea, rolling with something, and he treats Anita and see how he goes. But the first thought around it was essentially help people react is a series of people who acted faster. And there's a lot of products in that space, or we interviewed the guy from Click Up before and it doesn't want to start competing in our space. So it's like JIRA. It's like Click Ip it's like because that becomes becomes a bit more monotonous. It becomes something big. I'm not sure if it's if it's going to get to that extent. One of the feedback I got from a very big product manager was that, oh, this needs to be able to connect to JIRA, I need to be able to just click a button and it will populate a JIRA ticket for me and I'm like, Okay, we could do that. But in the end, what so what's the value for that it might work for him. But I'm not sure if it works for every other person that's doing that. It's all our feature lists, we have one. And we're gonna go, we're making that public, I was actually writing the code for that today, we'll have a feature list where people can vote on what they want to pursue at our backlog. And we will build on that. But yeah, this this space is big. And we could add so many things into it. So I'm just taking one day at a time and getting people's feedback and deciding if it's good enough, or if it's not. Jason Knight 15:43 Oh, yeah, I was gonna ask a question, then. I mean, obviously, you're working as a BA, day to day you're writing a lot of these user stories yourself. Yeah. As for your day job, and you've probably got at least 100 different ideas about things that you could do for this yourself from your side, which you've kind of touched on a bit like all the things that you could do. But from a kind of product management perspective, how have you actually decided, what makes the cut for that MVP versus coming out later? Or maybe never? What was the process that you went through for that? Richard Awe 16:14 So the MVP was just based on my need. So I needed to do this. And, and it's, it's do just that in its raw form, actually, there are some typos on this version that we have. Now, they were just typos that I put it. So the MVP was just on that basis. Okay, this was what I needed. And this is how we're going about it. The next set of features based on feedback, so I've got the we are we've had those, you need to do AI, you need to really maintain today's thing with if you want investment you need. Exactly, I think we have like 10 of that already. So I'm like, Okay, we need one of the comments, I also got that because at first I was just like, we'll just have it and see how it goes. But someone said, I would never use a product. If it's if you're not, if you don't have a pricing system, because I always worry how you're going to maintain it if you're not charging some like okay, so and for the stuff we want to build. And for some of these things we need at some point, we need to start charging money. So okay, where we need to add price into the next two mega things that will come into it. Next is AI and practising. But there are some other stuff that will come in collaboration, there is the enterprise elements, there is the what I call the Creator portal where any product manager or anybody could build a solution and end, okay, if you're going to be for instance, if you want an app that is an app that looks after your child, when you're away, this is everything you need to build it from end to end, this is all the user stories you need. This is all the this is the technology that you need to build it and they put it on registry and if an enterprise feels or want to be this, and they could always contact them and make them pay them. So does that some of those features that we have. But again, one of the things we want to use, for some markets innovate is also to have people vote on the features and say, okay, yes. I'd like for you to update No, this wasn't working, and all that. Jason Knight 18:20 So I have a user story, then, as an example, I don't know, as a buyer, I want to be able to see a list of my previous orders. So I can keep track of my spending habits, or something like that. Yeah, that's my user story. Yeah. And the old fashioned ways before registry, I could just go and write that down in a document or something. But maybe I've got a load of those things I want to get them through quickly walk you through the process, then like, how does your tool then help me do that? What would I do in your tool to get that out there? And how would I then share that and enable my team to start looking at that and working on it. Richard Awe 18:52 So if you've got a few stories, and everything is a requirement before if it's not even in a workshop, so for I'll give various examples. So if an in an enterprise setting, you're probably in a workshop with some stakeholders, and you're trying to gather user stories, okay, you have a few people and their trading ideas. Instead of you manually writing it down, you could walk up the stream, and just as someone speaking, you could click a few of these drop downs, and you're populating those user stories and right there, and then you could share these stories with everybody. So now, if you've been in a workshop setting before, oh, yeah, and foremost vas, you're trying to write notes and you're you're trying to write stuff, some posts and all that and most of the time it's missing. So Requstory has fields for you to quickly click on some dropdowns and populates whatever user stories you're trying to write and put it out there for specific examples, like the one you mentioned for as a buyer, and all that. He tells you helps you with context so you're not struggling for what and I've been in, in settings like that, where you're saying, who as a buyer, I want to watch out I'm looking for, we've got a few contacts in there, there will be more where you click it, and it suggests words that you could actually use. And that guides into properly properly articulating the user story that you're writing. Another thing that he does, there's a share function. So if you don't that by the time you're done typing, you could make 10, you're done writing a couple of user stories, you could just share to a team. Another exam, another reason why it enterprise, because you have a workshop, today, you've gone through a whole barrage of user stories, maybe written 20... 30 user stories, there's a team out there in the Philippines or in India, pop in their email address, and you follow the two they're like, Okay, this is our first draft of a user story, tell us what you think it helps you start those discussions as soon as possible, you're not taking it back and sitting on eating on your laptop and scribbling stuff to get back. So there's a few as in the next rise from that it is now there's a few very good use for it, it might be slightly tailored on the Enterprise end, because that was when I found the need for it. But also, and this was one of the feedback, I've gotten one of the one of my friends who is he actually had this idea around an application and actually went on registry. And he started writing some of these stories. He knew the developer friend, and he just finished writing it. And before there is an issue with the developer, and they are actually building the product. Now as I speak based on Okay, he has an idea, instead of just scribbling stuff down that doesn't make sense to him is actually writing some user stories around what they will do. And it will encourage further discussion and for them to beat stuff. So those are the problems I tried. Jason Knight 21:51 Fair enough. But one of the things you talked about, there was kind of guidance. And I'd like to take this opportunity. In essence, I'm talking to a business analyst to talk about some of the characteristics that you would consider a good user story. I mean, we've all heard of user stories, but I'm sure that many people are misusing them. What does a good user story that like in your eyes? Richard Awe 22:09 Okay, a good user story. I know you'll probably ask me about a bad user story next. So a good user story encourages some discussion and some debates, if it doesn't do that. So if you just take it that you say, Okay, fair enough. It's not good enough. For me, a good user story should be okay, so what this, can you take me through this, and you need to be able to explain what is on your mind at a point in time, a good years, you couldn't you can never finish, the user story is never fully written in the first draft. It's just, it's supposed to be spontaneous, okay. At ease, I want to do this so that I can do this as easy I want to, I want to have a banking application, so that I can check my bank balance. And then those discussions that one of the things I really want to do is for people to be able to annotate to say, Okay, this is what you said, but this is what you mean. So for this, you will need a database. And for this, you need some UI for this unit, just for a good user story. We'll call for some discussion. That's it from discussion, some debates, some higher, calling yourself further, but obviously doesn't have to be nonsensical. Yeah. So he has to make sense, as you assume for for whoever is writing it from the perspective of that person, then we take it forward. That's my that's the biggest thing for me. As long as it encourages discussion, then you could, it's a good user story. Jason Knight 23:46 Yeah, I've seen some people describe it very much as that record of discussions, but also, this idea that it's a very collaborative document that you kind of build a shared understanding around. And it's actually really interesting, because in some cases, like, you'll be looking at a user story. And two people that were involved in writing, it would have a full understanding of everything that that user story actually encapsulated. But you give that to one other person, and they would maybe missed off because they weren't in the conversation. And that shared understanding was filling in the gaps for the people that wrote it. So I always think it's a really interesting, dynamic, that idea between being detailed enough and being too detailed, but then if we consider too detailed, or some of the other things you could do wrong with a user story, and you mentioned earlier, what are some of the characteristics that you'd call out for bad user story? Other than that it doesn't provoke a discussion. Unknown Speaker 24:38 Okay, if you don't improve, okay, discussion? Yeah, that's one. One other characteristic if you do a bad user story is being out of scope. And I've seen this before. So for instance, you're building a product and you're targeting a particular set of people but you're thinking ahead and you're saying, Okay, we could also have these demographics. it into those that were targeting. That's that's another issue with user stories, you could always write it and throw it in. But again, for the for the sake of everybody who's working on that, it doesn't make too much sense for you to put this kind of, for you to deviate from your initial plan. When you're throwing stuff into user stories. One other thing I would say around user stories also is available. There are various flavours of user stories out there some job stories and all that different types is, in most teams, and this these are for advanced and developed things, then it's it's like a user easy language. And some people don't like the language, for instance, some I've seen developers who don't like using a user, oh, so they just say, just give me this, this is what I need that some. So you need to also be able to ensure that the end recipient speaks their language and not just throwing stuff at them saying, This is how I write my stuff. No, because if you're writing for them, and you want them to understand, they need to be able to ensure that they also understand where you're coming from. And in this particular format that they always insist on, as a BA, and apologies. For some of the guys I mentor as a BA you need to bend to the will of the addressee to their will to say okay, yes, okay, this is the format you wanted written in, we'll try and write it in this format. But at first for you to come up with your own ideas and get your juices flowing. You could write it in any format that you understand, but you need to also translate for them. One of the features we're adding in is the different flavours of user stories that we will have. So the job one, the typical requirement one, the job one is usually, I could quickly talk to you about the context of the job story. I'm not sure if you're familiar with the job search, but job so usually goes when I am I want to so I can, as opposed to as a user I wanted. So that's the job. So there's also Gherkin, and some some developers like Gherkin because it helps them. But all these are actually interchangeable. And one of those things I want to do is for you to write for me to write a user story in the novel as a user, and for you to be able to click on a button and to give you a second version, or click on a button to give you a job study version. Those things exist, because as a developer, you could actually write some programmes in a particular language. And some, some interpreter will change it to the other language for you. So this is all the stuff I'm sure we could do with requis tree over time, but it just just needs to be something people want. And not just another another feature for feature sake. Jason Knight 27:53 Absolutely. But I think you touched on it a little bit yourself there this idea of like, well, people don't have to use user stories. I mean, there's obviously the advantage that the using user stories really focuses on the user. But you seem to sometimes get people seem to try and fit everything into a user story. Like even things that aren't really for users. Like, as a product owner, I want x because why? I mean, I'm assuming that you can't specifically stop that in the tool, for example. But are there any other really bad examples you've seen of people really mashing things into user stories in your career, which really didn't belong there at all. Richard Awe 28:28 So even on.. even on Requstory, we've got, as soon as I say from user, so we've got product setup, we've got, I think developers or monitoring tool, it makes sense to just populate your backstory and your backlog with as many of these items as possible. So and Requstory is not your backlog. So on your backlog, you could always filter down to Okay, these are the these are stories, just particularly to users. But as product setup, and as much monitoring tool or as any of the awkward personas as they might be, they also need to be considered because you're just not if you're building for just users who's gonna manage the backend, there needs to be something at the back end, that is also going to take care of the users. So those concentrations just requirements need to be stated. And that when when we're being requested, we need to put that in because we just don't want it to be just about users. But in the past, things go on, you also need that differentiation needs to be made. These are strictly for users. This is strictly for we manage this tool or this application. And then these are these stories or requirements. Man that's that's why we have that's why it's called regulatory requirements and user stories because some are just requirements for the system. So these are the requirements. And these are these are stories and then you make this differentiation. People will like I usually say around product development. It's not really exact science. So, obviously, you will have some situations where some things are not as you've prescribed them or as everybody knows them, but they, you still need to get on with it. So you get some of that. But it's it's an it's also a question of style. So some, there was a developer who I met, I can't remember the company when he was, but he is, is he, I want to say 10x, or whatever, he's actually very, very good. There's a way develop stuff that is very, very different to everybody. So he just doesn't do if you go into a session with him and his team, and the first the first thing he Axio is really, really concerned about the backend and the front end and is really concerned around, okay, we need to lay this foundation before you start thinking of anything fancy the customer will see. And y'all you always need to fall for him. The concern is not really a user story. The concern is, how does the product setup and how does it set up? But obviously, you also need to consider the user so Jason Knight 31:05 Surely he should be fine. Richard Awe 31:06 That's the order, right? I've been here 20 years kind of guy. Julius. Oh, yeah. You always have to listen to whatever he has to say. And yes, okay. Yeah. But he's good at what he does. So I wouldn't complain too much about him. Jason Knight 31:24 I don't know, I might complain a little bit. But you know, I don't work for him. Richard Awe 31:28 So developers in my experience, and in my career you need to just do whatever developers mess up whatever you're even even working on. But what I was just going to point out for him, so he might not user stories might come in at some point. And what is mocking around? What do you want me to deliver from a back end perspective? So you need to write this kind of requirements for him to get stuffs out of the way. Jason Knight 31:57 I still want him right. And, again, that's not my fight. Richard Awe 32:00 I did actually, at some point, we actually did get to that point where we said, Okay, why don't you just give us what you think we need and will retrofit with what we think we need it? And I think that was how we resolved it. Can you remember, what is this engagement model with your team? And he was actually on the wasn't land was like notations were? Oh, we need to focus on the customer. But yeah, when this guy was No, I need to focus on the system, my architecture and every other thing then after that, I'll get to your customer. Jason Knight 32:33 Well, if you're listening, I'm very disappointed. Richard Awe 32:37 Well, he gets his job done. He gets his job, when I'm sure anyway, if he listens to this show. What are you talking about me? Very, very likely. Jason Knight 32:56 And what piece of advice have you got them for young ambitious business analyst or wannabe business analysts trying to make their first waves in the business analyst career like any way that you could help them get started or give them some inspiration in their career? Richard Awe 33:09 First thing I'll say is the soft skills is what gets you far. For some reason, I kind of found that out. And I wasn't really looking for it. But I found it out it was it's a soft skills that gets you far. So the coffee afterwards. Afterwards drinks with the developer who's been playing hardball with you all day, we'll get we'll get you will get yourself put in into development faster than any other thing that you think you know. It's what I've learned. So the soft skills, learn how to talk, learn how to chat people. Learn how to walk into a room and everybody feels comfortable talking to you. That's how you get your requirement out. If you don't do that, you're just gonna keep getting frozen stares. Whenever you're running a workshop, we've all been there. But yeah, so those those are the stuff that will help you. And as I would also say, as soon as you find your feet, get technical if you're not, if you're not get as much understanding of how systems work as possible, or health, you will always feel inadequate. If you don't, there was one of the reasons why I did get technical and micro write code for production proposed. Before I write anything, I don't interact for analysis purposes but this athlete I will have an understanding of okay, this is how the state works and this is the stuff I set up so do get technical. The lady I was trying to remain remember Irene you see she's doing something else. I'm actually forwarded a website to some some people recently to see if they wanted to ever do anything but yeah, she's she's great, great. So yeah, if you if you VAs if you find your feet to three ends of business analysis, try as much as possible to get. It helps it helps you feel more confident you do stuff, you get all the jobs in the world do you get called to to work for big organisations? Jason Knight 35:21 There you go. Not too big though. We want nice agile ones. Pretty nice. Richard Awe 35:25 The nice agile ones don't pay the big bucks. Jason Knight 35:29 I see, I see where you're at! Where can people find you after this? If they want to find out more about registry or chat to you about user stories or business analysis in general? Richard Awe 35:39 I would say I'm active on LinkedIn. My full name is Olawale Richard Awe. If you look for me on LinkedIn, you'll find me. I've got two Twitter profiles. I'm active on both. So @Richard3d7 is my profile on Twitter, @Richard3d7 on Twitter. I'm also @Requstory on Twitter, although somebody might be managing that account soon. And but I'm still doing managing on the way. Just just just to get I definitely get involved. A few people who are interested in helping to run it. I want to give you some ideas around it. Yeah, so those places you will find. Jason Knight 36:20 I will pop that into the show notes. And hopefully you get a few people coming across and trying to find out more. Well, that's been a fantastic chat. So obviously really appreciate you taking the time to tell me a bit about your new startup bit about user stories and business analysis in general. Obviously, we'll stay in touch as we have been already, but as for now. Thanks for taking time. Richard Awe 36:38 Thanks, Jason. Jason Knight 36:41 As always, thanks for listening. I hope you found the episode inspiring and insightful. If you did again, I can only encourage you to hop over to OneKnightInProduct.com, check out some other fantastic guests sign up to the mailing list or subscribe on your favourite podcast app. Make sure you share with your friends so you and they can never miss another episode again. I'll be back soon with another inspiring guest. But as for now, thanks and good night.