You Can't Prompt the Room: The Last Skill AI Won't Replace - Balázs Horváth, VisualLabs

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 figure is figuring out what it is that you should be building.

Um, 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 agents, uh, agent ideas, and 17 of those were abandoned because they actually created no business value.

They, uh, either didn't have data access or just didn't make sense to build it. And those 4 were the ones that actually had a very big impact on how we work today. And it's, it's a very good example of, 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, uh, the bridge between business and IT and developers. I started writing, well, initially testings, uh, functional designs, specifications, and then, and then I wrote them. And as, as a functional consultant, I worked with large ERP and CRM programs in the US and the UK, and then I founded VisualLabs.

And essentially I trained my, my team on how to elicit those requirements in a way, uh, that we can turn them into good, uh, specifications for developers to build, for consultants to configure, and most recently, uh, 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, um, and that's, that's, uh, that's the big thing now. Uh, but if you can read the room, if you can elicit theright requirements, uh, 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 lifecycle. 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 theright, that's the real bottleneck, figuring out what it is that should be built. Because 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, uh, 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 very big success on them. So if you're just using AI, uh, to, to make things, you know, build things better, um, 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, 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 get to, uh, 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, uh, being able to write good code is no longer, uh, the, the most important skill to have. Uh, actually the real skill now is becoming the analyst toolkit, uh, which is, you know, things like story mapping, business model canvas, uh, value canvas, and those, those good old things that we are so used to using as functional consultants, business analysts, um, or, or, uh, in, 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, uh, once you have the story map, the backbones, and understand at each step what your customers, your users are doing, that would give them the ability to, uh, to move forward, uh, in their, in their processes.

So, uh, here's a, uh, support systems user story map, contacting, triaging, resolving, and then essentially closing a case. Uh, with this, uh, you can understand different stages of the process, uh, and then capture the user stories beneath them.

It is intended to stay at a fairly high level so you can get a, uh, a big picture. And then in, you can decide, uh, what it is that you want to build and release one, like capturing intent, classifyingurgency, drafting a grounded answer, and then logging, 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, uh, uh, the second set of user stories, like reading a sentiment, writing to a team, suggesting next action, chatting, checking satisfaction, so on and so forth.

Uh, those will be part of your backlog. So what would allow you to, uh, to get really good, uh, agentic results is by honing in on these user stories and making sure that you use these user stories as a means, uh, 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, uh, second user story would be, as a support lead, I need to open cases run byurgency so that none of the escalations ship slip. So just make sure that every user story covers these is ideally, uh, 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, uh, setup. So if you go back to something that's similar to AI, it will get, get you better, better results.

And every user story, uh, is actually made up with, uh, 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, um, very good results.

And then if you just connect these user stories, daisy chain them up, then that will allow you to, uh, to create a coherent system based on which you can create your specification and then essentially your code. So the software development lifecycle doesn't change as much as a result of AI.

It's actually the toolkit that we are, uh, we are using is changing. Right. So when we, uh, work with systems and when we think about what we want to build, I always like to ask these four questions: Whose problem is this?

Whose problem are we actually solving? So we can, we can name it to a direct person, direct persona, uh, and it's very much quantified. What does winning look like for them? So when are they actually successful? Are they achieving theright outcome?

Uh, can we help them achieve thatright outcome, uh, in a quick way, or a smooth way, or a safe way? And what would that make, make them refuse to use it? It's not available on their platform, it's cumbersome to use, it's.

The data security aspects applied so they would, 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, and what is that 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," uh, 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, and then you can start the actual design where you can start designing.

So we like to call this, uh, thinking process VAD, Value Architecture to Design, and this is what we want to always go through. So always have, you know, value in mind. How are we 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 a 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, uh, the moat, if you will, of how you can elicit theright 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, uh, because then we can all just, uh, 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 up, you're shifting, shipping new features like crazy, uh, 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. Um, if people are trying out new features, they're logging into the new system, we just vibe coded our 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 can look at the frequency of a certain activity. Um, if another, uh, miss pattern, uh, anti-pattern is if the demo is the deliverable, we want to make sure that people can, uh, 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 a demo system is not a live system. And if a PRD is no real user tested, so if you, if you don't gather proper feedback, uh, from a real user, then chances are it will not make it into, into a live environment and people will not use it.

So, uh, the big thing here is, is actually putting your, you know, your everything is needs to be moving upstream here. Uh, so, uh, earlier on, before the AI boom, uh, we had our smartest people writing our code, but 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 a 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, and just make sure that you are realigning your measurements, your time, what, what it is that you're looking for. So, uh, the number of features shipped last quarter, um, that should be, uh, should be eliminated.

And just, just start looking at the number of features that we shift, uh, that is actually used more than twice. So that would be a good, uh, 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, uh, role or position where they have an actual impact on what gets built.

And I'm not suggesting that everybody should become a, uh, 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, uh, is a super important aspect. And I still do this, uh, recommend it to everyone to actually start doing a mapping session before you build.

Uh, 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, uh, how you create value. So, uh, I hope you found this valuable.

It's lots of, lots of, uh, all things stitched together, uh, that will really make a difference. Just, uh, give it a shot. If you have a, a good use case that you want to vibe code, try building it with user stories first or without user stories and just compare, uh, the difference in the results.

Uh, 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, uh, in my development. So this way we can build theright thing and not just the next thing.

Um, you can, uh, scan the QR code, uh, to connect with me on LinkedIn. Uh, would be happy to chat further. Thank you so much.