Hi everyone. I am Balázs Horváth and today I will talk to you about what is the last thing that AI will take away from us as people in the software business. So, at a point where writing code is no longer the bottleneck, the real thing is figuring out what it is that you should be building. And that comes down to people skills and being able to work the room because you can't prompt the room. You can prompt your AI.

So, at the beginning of the year, we held an internal hackathon where we had about 21 agent ideas and 17 of those were abandoned because they actually created no business value. We either didn't have data access or it just didn't make sense to build it. And those four were the ones that actually had a very big impact on how we work today. And it's a very good example of just making sure that we are building what is worth building.

And throughout my career in the past 13 years, I've always been the bridge between business and IT and the developers. I started writing, well, initially testings, functional designs, specifications, and then I wrote them. And as a functional consultant, I worked with large ERP and CRM programs in the US and the UK. And then I founded Visual Labs. And essentially, I trained my team on how to elicit those requirements in a way that we can turn them into good specifications for developers to build, for consultants to configure, and most recently now for AI to build. And what's not really changed over the years is how we interact with our customers, how we interact with systems, how we interact with AI is very much changing. But if you can read the room, if you can elicit the right requirements, then you will be able to build more valuable software.

And that essentially the big shift over the past 2 3 years was that getting access to code and being able to build is no longer the bottleneck to the software development life cycle. Now the real bottleneck is getting your people, your stakeholders, your decision-makers into the room and being able to access them and elicit the requirement and being able to spend the time with them. So that's the real bottleneck, figuring out what it is that should be built. Cuz you can prompt your code, you can prompt your AI, you can prompt your whole specification, but you can't prompt your room.

And what a model can't do is very similar to how Henry Ford's analogy of what he said about asking his users or his customers, if he'd asked them what it is that they needed, they would have said they needed more horses. But in reality, he built a car and he made a perfect success of them. So if you're just using AI to make things, build things better, the chances are that you are replicating what already exists because AI by definition is coded to give you the most common answers. So for us, the real job is to make sure that AI moves away from that average into what is better for us. So, we can just got to not a faster horse, but actually produce a car that's a magnitude shift better than what we had. So, it's really an interesting world where being able to write good code is no longer the most important skill to have.

Actually, the real skill now is becoming the analysis toolkit, which is things like story mapping, business model canvas, value canvas, and those those good old things that we are so used to using as functional consultants, business analysts, or in the world of design thinking. So, I'd like to zoom in on story mapping because that's the the skill set that I found as the most valuable. So, once you have the story map with the backbones and understand at each step what your customers, your users are doing, that would give them the ability to move forward in their processes. So, here's a support systems user story map: contacting, triaging, resolving, and then essentially closing a case. With this, you can understand different stages of the process, and then capture the user stories beneath them. It is intended to stay at a fairly high level so you can get a big picture, and then you can decide what it is that you want to build and release one like capturing intent, classifying urgency, drafting a grounded answer, and then logging it to a system of record. That's essentially your MVP. Those are the first things that you'd want to build, and those are your first four user stories. And beneath those, you've got the second set of user stories, like reading a sentiment, writing to a team, suggesting next action, chatting checking satisfactions, so on and so forth. Those will be part of your backlog.

So, what it would allow you to get really good results is by honing in on these user stories and making sure that you use these user stories as a means to elicit discussions with your stakeholders, with your business, and then work out what that user story should really be about. So, the first user story second user story would be as a support lead, I need to open cases ranked by urgency so that none of the escalations should slip. So, just make sure that every user story covers these is ideally written in this setup because AI is really good at pattern recognition and it was actually trained on the user story structure because it's a very well-known and well-used setup. So, if you go back to something that's familiar to AI, it will get you better results. And every user story is actually made up of these, you know, well-known structures, the persona, the what, the actual need, and the why. So, by packaging these up and giving it to AI, obviously with the acceptance criteria based on which you can derive the test cases, you will be able to create very good setup and very good results. And then if you just connect these user stories, daisy chain them up, then that will allow you to create a coherent system based on which you can create your specification and then essentially your code.

So, the software development life cycle doesn't change as much as a result of AI. It's actually the toolkit that we are using is changing. Right. So, when we work with systems and when we think about what we want to build, I always like to ask these four questions as whose problem is this? Whose problem are we actually solving? So, we can name it to a direct person, direct persona, and it's very much quantified. What does winning look like for them? So, when are they actually successful? Are they achieving the right outcome? Can we help them achieve that right outcome in a quick way or a smooth way or a safe way? And what would that make them refuse to use it? It's not available on their platform, it's cumbersome to use, it's the data security aspect applies, so they wouldn't actually use it. And would it change a decision? Ideally, we want to be impacting how a person makes a decision and we'd want to, you know, tilt them to making better decisions. So, does it change a decision and what is the decision that it changes?

So, once you can answer these four questions, then you'll be able to elicit better responses from your AI and just make sure that you track all of these in a good old markdown file in your repository so that AI can access it. It will just get way more context out of it. And you know, if you just did something as generic as build us an agent that handles support, you will not get the answer you want. So, what we always do is go from value, so understand how value is created, what constitutes value, how the process currently flows, what is the underlying architecture beneath it that supports that process, and then you can start the actual design where you can start designing. So, we like to call this thinking process VAD, value architecture design, and this is what we want to always go through. So, always have, you know, value in mind, how we're creating value, what is the value we are creating, what is the value that your customer is looking for, what is the underlying process that supports this, and how you can design a system around it so it best supports the value and the process, and what process changes are needed along the way.

So, you might ask, isn't this just good old product management? And to certain extent, yes, it is an old skill, it is an old trade that is worth picking up and learning, because this is now becoming the mode, if you will, of how you can elicit the right requirements, how you can build better software, because we all have access to the same tools, so the difference will be who can understand the business need better, because then we can all just have the latest and greatest model write the code for us. So, it's old skill, but new economics, and it's a real shift towards analyst toolkit.

So, what building the wrong thing looks like, if you've got velocity of your shifting shipping new features like crazy, but the adoption is not good. If people are barely using it, that's actually a very very poor pattern, that's what you want to address. If people are trying out new features, they're logging into the new system, we just wiped Google it out, craziest newest thing, but they are not actually reusing it. So, don't look at time of usage and time spent on site. Much rather you got look at the frequency of a certain activity.

Um, if another miss pattern and anti-pattern is if the demo is the deliverable. We want to make sure that people can put things into production. It's really fast to do a demo and it will look nice, but people aren't actually using it. So, the demo system is not a live system. And if your PRD has no real user testers, so if you if you don't gather proper feedback from a real user, then it's chances are it will not make it into a live environment and people will not use it.

So, the big thing here is actually putting your you know your everything is needs to be moving upstream here. So, earlier on before the AI boom, we had our smartest people writing our code, but what now we need to be shifting our smartest people towards our customers, towards the business problems, and we need to be spending more time on deciding what to build because that's the expensive part. Building it has actually become very cheap.

So, couple of things that you can start doing from Monday morning or from the next day is audit the wrong thing, right? Just start figuring out what are the wrong things that you're currently tracking. And just make sure that you are realigning your measurements, your time, what it is that you're looking for. So, the number of features shipped last quarter, that should be eliminated and you should just start looking at the number of features that we shipped that is actually used more than twice. So, that would be a good a good shift in your KPIs and your metrics. And just make sure that you're moving those real subject matter experts to a more customer-facing, client-facing role or position where they have an actual impact on what gets built. And I'm not suggesting that everybody should become a functional consultant or a product manager, product owner. I'm just saying involve them in the decision-making because they have the most experience of what worked in the past and what didn't. And just making sure that gets included in the decision-making of what should be built is a super important aspect. And I still do this I recommend it to everyone to actually start doing a mapping session before you build. Just make sure that you either create a user story map or business model canvas or any old mapping that highlights where the value lives and just make sure that you understand how you create value. So, I hope you found this valuable. It's a lots of lots of old things stitched together that will really make a difference. Just give it on shot if you have a good use case that you want to wipe code. Try building it with user stories first or without user stories and just compare the difference in the results. When I did this for myself, that was the big big shift that I started doing is holy cow, I still need to incorporate user stories in my development. So this way we can build the right thing and not just the next thing. You can scan a QR code to connect with me on LinkedIn. I would be happy to chat further. Thank you so much.