What we talked about
Makoto Kern, Founder of IIIMPACT, joins Federico Ramallo on the Prevetted Podcast to share his journey from robotics engineering to becoming a product strategy and UX design leader helping enterprises de-risk complex software development. With more than 21 years of experience across cybersecurity, energy, healthcare, and SaaS, Makoto has guided Fortune 500 executives and high-growth startups to launch market-ready products while building sustainable product development practices.
Show notes
Makoto Kern built his UX career by accident:starting as a robotics and manufacturing automation engineer, he noticed that the software built by engineers for factory floor workers was nearly impossible for non-technical people to use, and started solving that problem. Decades later, he runs Impact, a consultancy whose “Strategic Immersion” process has one simple premise: the hardest part of launching enterprise software is not the design:it’s changing the minds of the people inside the organization.
What we covered
- Makoto’s entry into UX came from a $25,000 Turtle Wax project he found on Craigslist:an interactive virtual garage built in Flash:which convinced him to quit his engineering day job and go all-in on UX consulting. He was born and raised in Chicago and relocated to Austin about 11 years ago, where Impact grew substantially.
- The Strategic Immersion process runs two to three days of intensive workshops that get all stakeholders:from CEO to customer support:into the same room to reach explicit agreement on business goals before a single wireframe is drawn. Makoto compared the alternative to building a house, having people move in, and then asking what they actually wanted.
- Enterprise software has a fundamentally different user dynamic than B2C products: users are forced to adopt whatever leadership mandates, so the initial reaction to change is almost always negative. Getting adoption requires disrupting well-worn workflows people find comfortable, even if those workflows are inefficient.
- He described stakeholder misalignment as essentially universal:”99% guaranteed in most companies”:and noted that when he runs feature-prioritization workshops with sticky notes, leaders often cluster their votes near whatever the CEO points to first, revealing that alignment is performative rather than genuine.
- On AI, Makoto tracked a real-world case where a company redirected all engineering resources to integrate AI into their product, then monitored usage through an analytics tool like Pendo and found users submitting one or two prompts before abandoning the feature entirely. His diagnosis: the company wanted to say they had AI, not solve a user pain point.
- His closing argument was about cognitive dissonance: a developer who asks AI to write a marketing plan will be amazed at the output because they know little about marketing. A marketer who uses AI to generate code will feel the same. The gap in domain knowledge makes AI look like magic in areas where you are not the expert:and that illusion is what drives unrealistic expectations about what AI can actually replace.
About Makoto
Makoto Kern is the founder of Impact, a product strategy and UX design consultancy based in Austin, Texas, that specializes in de-risking enterprise software projects through its Strategic Immersion methodology. He has over 21 years of experience across cybersecurity, energy, healthcare, and enterprise SaaS.
- LinkedIn: https://www.linkedin.com/in/productuxdesigner
- Website: https://www.iiimpact.io
Episode 55 of the PreVetted Podcast.
Full transcript
Federico Ramallo (00:00) Welcome back to the Prevared podcast where we spotlight extraordinary people and remarkable talent reshaping our world. Today we’re joined by Makoto Kern. He’s a founder and product strategy and UX design leader at Impact, a company that has transformed high-stake enterprise software projects from risky bets into predictable strategic wins. With over 21 years of experience spanning cybersecurity, energy, healthcare, and enterprise SaaS, Makoto has helped
Fortune 500 executives and high growth startups alike launch products that not only succeed in the market but also strengthen internal development capabilities. Through impact strategic immersion methodology, Makoto bridges the gap between boardroom vision and market-ready software turning chaotic ad hoc development into a disciplined, outcome-driven process. Makoto, welcome to the show.
Makoto Kern (00:58) thanks for having me. You sure you got the right person? Sounds like that person’s done quite a bit. No, I appreciate you having me on the show. I’m excited to hear a conversation.
Federico Ramallo (01:09) It’s a, I don’t know if it happens to you, but every time, you know, I, I, somebody introduced me and all the things I’ve done. I’m thinking, you know, that doesn’t sound like, like me, right? Because you kind of forget everything you’ve done, right?
Makoto Kern (01:20) You
yeah, I know,
just trying to write and remember it so you feel like, ⁓ wow, I guess I’ve done a few things.
Federico Ramallo (01:32) Yeah, I tried to summarize it so I can do it in one breath, but sometimes, you know, it’s too much.
Makoto Kern (01:36) Yep. I guess that’s good that you can’t.
Federico Ramallo (01:43) Yeah, yeah, yeah. And then eventually you kind of have to pick and choose the experience depending on the context. anyway, yeah. So a lot of years of experience, a lot of experience with product strategy and development. So I think we’re going to have a very interesting conversation.
Makoto Kern (01:47) Mm-hmm.
for sure.
Federico Ramallo (02:01) so tell us a little bit about what was your eureka moment that led you to start Impact
Makoto Kern (02:10) Yeah. So I mean, you know, I, I started as a, did not start as a UX designer. started as a ⁓ robotics and kind of manufacturing automation engineer. That’s what I trained it for in university. And I did that for about a decade. And I was basically towards the end of my career, I was doing a lot of a kind of software modification for manufacturing floors. were generally, you know, software engineering.
products or things that are made by engineers for engineers, but people on the manufacturing floor are generally less technical. So, you know, they’re assembling a widget, they’re doing a thousand times. And if they get it wrong, then that’s going to cost the company money. So creating a software that they can easily see, Hey, there’s something happening or whatever, you know, and be efficient. was something that I think naturally progressed me to get into more of the UX side of things. And, you know, I’ve always been interested in entrepreneurship.
I always read all the magazines and books and everything about just starting your own business. And I guess I’m a bit of a, I hate the political games and I hate kind of being told what to do. So I always wanted to find, you know, my own thing to start. And, ⁓ yeah, just got, that’s when the.com boom was happening was when I kicked off a impact and I was doing a lot of websites, getting into that, creating it for friends, families.
And, um, yeah, I was on Craigslist even finding, uh, finding, uh, work on Craigslist and projects. it was funny too. One, some big company, uh, called Turtle Wax. Uh, they’re pretty big in the United States. They actually had this like sister division that they wanted to create this kind of virtual garage, um, to sell their products. So we made this interactive garage and flash. And I mean, it was like a $25,000 project. was, I was like, Holy cow, this is amazing. My first big gig and
And then I got to a point where I was just consulting and had a lot of projects. So I just decided to say, I can quit my engineering job. and yeah, I mean, it was, it was nuts. was driving back and forth. I was making phone calls, you know, in the middle of traffic during lunch, after work and visiting clients. And it’s just, I’m like, okay, I’m done with doing both. I just want to do a UX and yeah, just started getting into that and started growing my company. And, that was out of Chicago.
And, know, I was there probably for about, I born and raised Chicago, but we ended up moving to Austin, Texas, about, I’d say about 11 years ago. And, uh, yeah, we, that’s kind of where my, my, my team and my company grew pretty big. And that’s kind where we got into more of what we’re doing now, which is, you know, we, not just UX design and not just.
focused on, you know, conversion of websites or things like that. But we actually got into more of a enterprise software, mobile applications, but actually got into the project strategy piece. And that’s kind of where we we’ve evolved our organization into just knowing that just having the UX design is just one piece of the puzzle, but having the, the, having the, the ear and being at the seat at the table when you’re doing product strategy is so important. So we we’ve.
created this like strategic immersion process where we try to understand what the leadership thinks and what their business goals are and kind of create that empathetic ⁓ understanding of being more user-centric versus feature-centric. So like what are users pain points? Where are they trying to do their journey? And then tie that into your business goals. And then…
creating like a feature roadmap of what are the next 12 months look like, what are risky features, what are features we know we can start building. And then that kind of creates this holistic approach to actually launching products faster. So that’s kind of how it all came about.
Federico Ramallo (06:10) Wow, amazing. ⁓ it was quite a journey from robotics to product development.
Makoto Kern (06:11) Yeah.
Yep.
Yeah. And yeah, it’s been really interesting too, because there’s some serpentipity there because one of our clients ⁓ that I met in Austin, they turned out to be one of the top robotics companies in the world. And when they brought us in, they were already at a point where they tried another UX firm, couldn’t do it. And when I told them, like, hey, this is what I studied in school. This is amazing opportunity. so…
They were trying to redesign this, what I call like a Blackberry of controllers where it had all these hardware buttons and, ⁓ they, they were trying to change it. it was all touchscreen, much more user friendly, looked, you know, looked more modern than what it did before. And so, yeah, we got to working with them, was able to launch pro you know, this, this new controller for their robots. They actually showcased this app South by Southwest.
And yeah, they’re still using it to this day. So it’s been, it’s been really cool to kind of be able to work in the robotics industry again. So.
Federico Ramallo (07:25) Right, right. Something similar happened to me because I studied software industrial engineering, right? So manufacturing processes and all that. I didn’t graduate because I was pulled into work, right? But then I did my career as a software engineer. So ⁓ I had the opportunity to work on some physical storage, physical… ⁓
Makoto Kern (07:27) ⁓
Yeah.
Mmm.
Federico Ramallo (07:54) Objects, right? So we’re working with shoes and dresses and you have multiple dimensions on these products, right? So building these You know the planning of the warehouses, right? And and how the physical location of the of the product, right? So it was very interesting to work on that. Yeah, and ⁓ It came back to me as well. I’m ⁓ I started industrial engineering. So, you know ⁓ It was very very interesting. Yeah
Makoto Kern (08:07) Okay.
Yep.
Yeah. Oh, that’s
cool. I yeah, I remember, uh, yeah, that, that kind of, uh, you know, the setup within warehouses. mean, that was such an interesting thing because when we were in, when I was in manufacturing and got into it, uh, I didn’t start off with like lean manufacturing and creating Kanban systems and five S and when I got into that towards the end of my career, where this one company called Danaher corporation really big and push that type of, lean.
manufacturing processes. And so we had to rearrange the entire like, manufacturing floor where things are set up, optimize things. mean, just that, just that alone was very interesting and working with different industrial engineers on how to optimize just for movement, everyday movement and making it more efficient. And I can only imagine now when you have these, you know, robots, robotics that just kind of go off and do their own thing. I mean, that’s gotta be really cool to set up as well.
Federico Ramallo (09:19) Yeah, and see it in person, like, you know, everything moving. it’s so fascinating. I built the software and the organization, but I wasn’t able to see the robots working, which, you know, I was like, ⁓ I wanted to see that. ⁓ So for those that are, you know, unfamiliar, can you walk us through what the strategic immersion process looked like from start to finish?
Makoto Kern (09:22) Mm-hmm.
Mm-hmm.
Yeah. ⁓
Sure. ⁓ So basically when you start off any software product project and you’re going to see it now, especially with AI, ⁓ everybody wants to just jump right into code. Just jump into wireframes. If you’ve not been part of a good process, it’s almost like saying, Hey, let’s build a house first. Then let’s have the people move in and then tell me what you really want. And I always, I always try to tell like the people who’ve not been through good design
and good strategy. It’s like, when you do that, you could already imagine like somebody moving in and saying, Hey, I don’t want three bedrooms. I want four bedrooms. I don’t want two floors. I want a single floor. You know, there’s all these changes that they want to make in order to make it work for them. And that becomes expensive when you launch thinking you’re just going to get these wireframes or jumping right into development actually causes more problems. Because in the end, you don’t know if the, if the user really is going to use your feature. I’ve been involved in many companies where
many of our clients, we get in there and we see, they just launched a new feature. None of the users are using it. And so they’ve just spent a ton of money and a ton of resources just to launch something that doesn’t really, the users don’t really care about. And so, there’s a big difference, especially with like enterprise software versus ⁓ B2C. When you’re talking like SaaS or any type of e-commerce, the…
the psychology of making people click and making it easy for users. That’s so important, but, that’s a whole ‘nother way of approaching it. But with enterprise software, you know, the users are generally forced to use it because somebody at the top says, Hey, we’re using the software or we are internal teams developed a software. have to use it. And so when you do that, the, the product strategy is so important because it really sets apart where
Most companies, maybe Amazon and Google, do this well, but generally most companies, have poor communication. They make so many assumptions, and when you get in a room and they say, hey, what’s important for us? Everybody’s gonna have a different story. So guess what? When I go into a company and I’m the designer and I’m like, hey, what’s important for you? What’s the requirements? One person says one thing, another person says another.
And then once you figure that out, you move it up to up the chain of command and then the leadership says, no, no, no, I want something different. so that becomes a problematic scope creep. You know, you’re just, you’re causing more churn in the end and actually takes longer to build. So, you know, our process is really trying to get everybody in a room, get the leaders in a room and say, Hey, let’s make a decision on what really are our business goals. Because at the very end, it’s like,
Are we trying to drive revenue? Are we trying to increase our brand awareness? Are we trying to sell more widgets this way or whatever the case is? But that’s gonna help me as a designer then ask the right questions saying, okay, you wanna place an ad in the middle of the application that pops up every so often. Okay, well, why do you want that? Okay, because it’s gonna potentially raise our revenue. Okay, well, let’s figure out how to do that and let’s do that in a scalable way.
that we don’t have to change every two or three sprints. And so, you know, this is something where, yeah, we, get the leaders to make a decision, make it, make a group consensus of, of like, Hey, this is the, this is our business goals. And again, like, once you figure that out, then the most important thing is creating a user centered process. And, you know, Apple made this really valuable.
during the dot com boom, really showed like, you have to have the user as a center of the whole idea. Like if you’re not solving their pain point, no one really cares. You can’t just think we’ll just build it and then users will come and buy it. And that’s kind of what’s happening, I think a little bit with AI and we could get into that later, but just because you throw AI in there, do your users really want to use it in that way? Do they want another chat bot or a Clippy? Maybe, maybe not, we don’t know, but if you don’t do the right upfront.
kind of, hey, this is the pain point, this is their journey, does it really help them, then it may just not even be used, especially with enterprise, users are gonna go right to their own workflows that they’re comfortable with. Whether or not it’s most efficient, it’s efficient for them. So when you disrupt that, they’re not gonna like it. So you gotta be really, you gotta be really careful on how you approach enterprise software, because most likely the initial reaction is gonna be negative. And then when it comes to, ⁓
Yeah. When you’re creating that next six to 12 month roadmap, your development team has to know like, Hey, what can we fill our backlog with? What can we start like making? So that’s where you figure out like, Hey, these are things it’s a form or it’s a login page. That’s easy. We know how to build that, but this is like an entirely new workflow. We don’t want to just start building it because that’s going to be very expensive if we’re not sure. So that’s where you leverage the UX research and like create prototypes, get people’s feedback. And then you iterate to make sure like, Hey,
okay, we get it now, this is what we’re gonna build, then let’s launch. And then that’s where we create like metrics and making sure we consistently improve. And so that’s kind of it in a nutshell on how we came up with that ⁓ immersion process.
Federico Ramallo (15:17) Interesting, very interesting. Yeah, the… One of the things that I’m trying to follow is the lean startup methodology that basically allows you to validate your assumptions on what to build. Yes, yes. And I think that that’s geared towards startups, know, where they’re still trying to fit out product market fit. ⁓ But when they go to enterprise software, enterprise companies, they…
Makoto Kern (15:18) Yeah.
It’s like a lean canvas. It’s similar.
Mm-hmm.
Federico Ramallo (15:46) kind of forget to follow that same ⁓ ethos, right?
Makoto Kern (15:49) Yeah. ⁓
Yeah, it’s, it’s, you know, when it comes to enterprise, they’re so, they’ve been so buried where they’ve had this one product or whatever, how many products for years. So you’ve got this like environment of like, Hey, we, this has been making us money. So if we want to change it, let’s just make it look better. And then that’s all we need to do. They don’t change any of their processes. ⁓ they just keep the same way because that’s what’s been paying the bills. And so.
changing those bad kind of habits and getting them to understand like there’s far more efficient ways and doing things since when you first built your enterprise software and trying to change that throughout the organization. That’s like the hard part for us. It’s almost like therapy. When we talk to people where it’s like, you know, Hey, the design part is actually easy, but getting through people’s egos, making them change the way they normally do things because it’s comfortable for them.
That’s the hard part. And so that’s kind of where I think we get paid as a consulting company. If we’re able to do that, ⁓ then our job is pretty much done is because it’s changing the mindset of people within their organizations. It’s really hard to do that from the bottom up. You have to do that from the top down. So sometimes some of the clients have to get burned first to know like, yeah, maybe we shouldn’t have done it that way. ⁓ So yeah, it’s been an interesting journey.
Federico Ramallo (17:15) Right, right. ⁓ My maturity as software engineer started off, know, I take ⁓ whatever the product owner gives me as a software engineer, literally, right? I started by not caring about the rest, right? ⁓ Or not caring, I wasn’t aware, right? And then eventually evolved to, well, what we’re building, what we’re getting from the product owner is
Makoto Kern (17:27) Mm-hmm.
Yeah.
Federico Ramallo (17:45) what the product owner understands from the users so at the end of the day we need to ask as a software engineer is ⁓ what’s in it for the user? what’s the value for the user? ⁓ and then the product owner is the representative of the user but it’s not necessarily saying exactly what the user needs because there could be these assumptions or issues in that process
Makoto Kern (18:10) Mm-hmm.
Federico Ramallo (18:13) But as you said, it’s hard from the bottom up to change that. ⁓ I tried multiple times to help on that process, ⁓ but it’s hard on my side, On the software engineering side, yeah.
Makoto Kern (18:26) yeah.
Yeah, it’s, it’s, you know, when you, when you’re trying to make change, especially like, know on a, just like your, what you’re saying is where, when you start to have overlap with people’s skillset, when, when I have great developers or great product owners who are used to like having a different eye on things. Yeah. When they’re not just hyper focused on a small part of it.
When somebody is like more knowledgeable about the holistic approach, those teams run so much smoother. And, and you can tell the experience in that where, yeah, my front end or backend developers are like, Hey, what about this Makoto from a front end, from a UX perspective? And I’ll say something about, how about this? You know, using this code or tech base, or can you do it this way to make, to not affect the performance or whatever the case is. And when we’re able to do that, it just runs so much smoother, but it.
You know, getting people, getting those people into a team. mean, you can have such a, a much better output, much better quality when they’re able to work in conjunction like that. It’s not going to come cheap, but so is bad. So, so as bad code and bad teams that doesn’t come cheap either. So it’s a, yeah, it’s, yeah, the more I do this and the more you see, like, I mean, it’s funny for me as a UX.
Federico Ramallo (19:47) Right. Right.
Makoto Kern (19:55) designer, uh, I have to, I have to be very empathetic and understanding of people, like be able to read people pretty quickly. Cause they’re going to have biases and things like that. And so when I go into a consulting situation, I’ve got everybody in a room and you start using these workshops, you can quickly see the people who are like struggling, the people who are like, like really hungry to learn and people who are very defensive. And, and so the
You can almost put them in their own personas of like, okay, this person’s going to cause trouble. This person is going to be awesome. This person’s going to be, they’re not going to pay attention.
Federico Ramallo (20:34) Right, right, yeah, yeah, yeah. I’ve seen a lot of that. ⁓ The improvements that I was able to make in the process, in that process was to get agreements with the product owners to provide more clear requirements for the software engineering, right? And articulate better what’s in it for the user, right? ⁓ Because they know it and they have a lot of context, but with software engineers we don’t.
Makoto Kern (20:39) Okay.
Federico Ramallo (21:04) ⁓ We got better requirements and that way it allowed us on the dev team to work with less interruptions with less having to stop and ask questions because we have all the requirements. we did an extra, it was kind of meeting on both sides. We did an extra effort to understand the full workflow and the whys and then the product owners.
Makoto Kern (21:21) Mm-hmm.
Federico Ramallo (21:32) they did their part to provide us more clear requirements. There was a lot of resistance at first because it’s like, well, start building instead of asking me questions, right? So until we were able to get through that, right? ⁓ And then once we had all the information ⁓ and understanding what was the value for the user, then we were able to ⁓ build automated tests
Makoto Kern (21:43) Yeah.
You
Federico Ramallo (22:01) based on the value for the user, right? If you go to an ATM, you want to cash out, right? That’s the most critical thing, right? Same if you’re whatever workflow, right? If I’m purchasing something, I want to complete the purchase process, right? ⁓ whatever it is, understanding that, so we focus the automatic test for that, right? And then from there, we were able to provide more…
Makoto Kern (22:09) Mm-hmm.
Federico Ramallo (22:29) reliable estimations for when it was going to be done and making sure that it was actually done, right? But at one point we had to set a boundary on the dev team that is, as dev teams, it’s not our job to understand what the user needs, it’s to understand what are the requirements. Because if we go over that area we’re doing product and then we are overstepping our role, right?
Makoto Kern (22:33) Mm
Federico Ramallo (22:59) on a big team, right? And then, ⁓ you know, we start having a lot of friction with the product team, right? ⁓ So we’re, you know, we did get involved on caring about the user, understanding what are their needs, right? Asking many questions to make sure that we have that right. eventually realized it’s not our job to go and ask the user what they need, right? That’s product.
Makoto Kern (23:05) and
Federico Ramallo (23:28) So anyway, that’s what I’ve been doing for the last 10 years.
Makoto Kern (23:35) Okay.
Yeah. Have you, mean, have you been involved in any organization or any situation where you’re doing the designing and there really isn’t a designer. So you’re coding and designing at the same time.
Federico Ramallo (23:48) Yes, yes. In big teams and particularly in startups, in the big teams, mean, big corporations, what we did is eventually we got to the agreement with the product owners of giving them a list of components that were connected directly to React components, right? ⁓ They didn’t necessarily know that there were React components, but we basically told them,
Makoto Kern (23:51) and
Federico Ramallo (24:17) This is the toolkit. If you need a component that is not here, we can build it, but it has an additional effort, right? So if we can use these ones, then great. If we need one, then we can do that. But because what happened is that when we had 10 product owners, each of them would ask ⁓ a very specific component that was a little bit different than the other ones. And then eventually we realized we had like 10 components that were the same.
Makoto Kern (24:39) You
Yeah.
Federico Ramallo (24:45) with minor differences, so
we went back to the product and we showed them that and we said if ⁓ we can work with these components, if we agree to use them, we’re providing a restriction to them, but then you can pick and choose the components, understanding the behaviors, we can do that, we can test that very thoroughly, and then you can have the confidence that you will be able to use it.
Makoto Kern (25:10) Okay. ⁓
Federico Ramallo (25:14) Plus, we were working towards normalizing the interfaces. So, you know, there was an underlying effort for that, yeah. ⁓
Makoto Kern (25:23) Yeah,
that’s, I mean, that’s such an important point that a lot of companies, I think that are not as mature, ⁓ that don’t understand. It’s like when you, when you have multiple teams, multiple developers, multiple product owners, and you’re all working in, in creating different parts of the app, you’re creating more tech debt by having those 10, 20 different variations. Somebody has to say, Hey, how’s this different than the other thing? And then when it gets to the user, they’re like,
Well, on this page, the dropdown work like this, but then on this page, I can actually search within the dropdown and it works this way. And it’s like the cognitive load starts to increase the amount of effort for the dev team starts to increase. And then the amount of effort for the UX person who’s trying to put it together is like, wait, am I using this or this dropdown or this or that? So yeah, I mean, we always go in and saying, okay, let’s use the same kind of framework React or Angular, whatever you’re using. Let’s use that material framework.
So it looks all the same and there’s less thinking. And then that way we could streamline into solving the problem versus, you know, coming up with, ⁓ just random things that we put together that we think we’re using as far as components and, ⁓ having, you know, all that is just wasted inefficiencies. And, but, you know, so many companies are still working in that way where they don’t have a design system, whereas a single source of truth, ⁓ they’re all working in different silos.
I mean, even these big fortune 500 companies, the amount of silos that are going on where they’re not even talking to each other. And I’m not just talking like, like an energy company, which I’ve seen like the, don’t even talk. their teams within teams don’t talk, which is just scary. But then even consulting companies that I’ve seen the big ones, ⁓ not going to name any names, but even them, you know, they, the processes can vary so drastically between.
Federico Ramallo (27:12) You
Makoto Kern (27:17) somebody, you know, a team in Chicago versus a team in Miami or whatever. mean, some of them are work flawlessly with great processes. Other ones, they had, still using PowerPoint and having, you know, the, the product person present the designs versus the actual UX designer that created it. So they don’t know how to answer the right questions. So it’s just, it’s interesting to see still that vast, um, spectrum of maturity that’s out there.
Federico Ramallo (27:36) the
Yes, so on our project we even have issues with each button has different color codes. And the other part we pushed back a lot was, and we still try to, but it’s accessibility, right? ⁓ So contrast, ⁓ buttons locations, ⁓ accessibility, ⁓ being compliant on accessibility.
Makoto Kern (27:52) Mm-hmm.
you
Federico Ramallo (28:11) That was a big push that we did on our side. But there was no, I mean, it was a process, right? But at the beginning, was no, product owners didn’t see that as something important. So we have to educate them. And still it was basically they would say, we want to build this feature because we want to and we have the need for the user, right?
Makoto Kern (28:25) Mm-hmm.
Federico Ramallo (28:37) And then we say, but if we change just tiny bit of the color code, then we can have contrast compliance. Can we do that? And it took us 10 attempts until they said yes, right? Until eventually the next feature was a little bit better and a little bit better, right? And that was kind of why we came up with the components. And the intention was to go towards a design system. We didn’t get to that level, but we were gearing towards that, yeah.
Makoto Kern (28:53) Mm-hmm.
Yeah, and the accessibility people understand is that it actually helps with usability as well. ⁓ There’s different levels of accessibility and it is important. And I think if you’re dealing with, especially with consumers, you can get sued if you don’t make it accessible. You get in trouble, especially in United States. So it’s so important to have that, especially if dealing with consumers. Enterprise, feel like they don’t have to do it as much, but the amount of people that are colorblind.
Federico Ramallo (29:22) Right.
Makoto Kern (29:32) And how many apps I’ve seen where they just said, let’s just make that button red. And now show that it’s, you know, it’s important or it’s a warning. But I said, you know, how many people are colorblind that don’t see that as red. If you don’t have an icon plus the word or something that shows not just a single thing like color, they’re going to miss it. Especially if you’re looking at a table and they have to disseminate between something that’s a warning, whatever this or that. And, know, that becomes problematic. And then.
you see again like 50 different icons. like, my God, they got to memorize what this little tiny icon look, you know, means. mean, these are like common mistakes I see all the time in enterprise software.
Federico Ramallo (30:08) You
Right, right. Yeah, ⁓ we tried to work on that before showing that if we have to build a feature and then change it for accessibility, change it for ⁓ usability, then we were building the feature three times. So if we can do it once and do it right, it will save us time, right? ⁓ Plus React ⁓ is ⁓ very challenging to implement accessibility. ⁓
Makoto Kern (30:29) Mm-hmm.
Mm-hmm.
Federico Ramallo (30:42) because it looks like a select or a drop down or whatever, but it is a ⁓ JavaScript component. So it’s not compliant on anything. You actually have to build all of that from the ground up, right? ⁓ So it took us a while to do that. ⁓ When I started my own project from start and with that experience, I started using ⁓
⁓ semantic HTML as much as possible because they, it’s like this little ⁓ workhorse, right? It works, it’s accessible, it’s compliant, it’s everything. It doesn’t look as pretty as other interfaces, but hey, it works, right? Yeah, yeah, yeah. And there’s so much work on cross-browser compatibility, mobile. ⁓
Makoto Kern (31:25) I’m
Mm-hmm. Yeah.
Federico Ramallo (31:42) I know. So yeah, it took us a while to do that. Yeah.
So ⁓ you also talk about stakeholder alignment, right? And that’s one of the critical first steps before any design or development begins, right? ⁓ Can you expand a little more on that?
Makoto Kern (31:59) Mm-hmm.
Yeah, the so, you know, all the leaders again, like I said, they all make assumptions and most of them are poor communicators throughout an organization. You know, they don’t sit in a room. They don’t write down things. They just kind of assume that everybody knows like, hey, this is important or this is important. Every time we’ve gotten into a room and we have all the leaders, all the stakeholders kind of like basically map out here, all your features. Now let’s pick and choose which ones are the most important.
They’re all over the place. You know, some of them may cluster to like, you know, you have these sticky notes and you have these features and they may cluster in one area and another. Sure. But I think some of that is because they see the their boss putting this sticky over here. Like, I better, I better say that’s important. But, no, think having that alignment is just so key, especially, you know, maybe between, you know, the CEO to maybe his next reports or some of the VPs but,
There might be some alignment, but when you start jumping from sales to marketing to customer support, to product, to development, then it starts to become more sporadic. And what they think is important may not think of somebody else is important, but this is where, you know, having people make decisions in the room, it puts pressure on them, but it cuts down so much back and forth conversation. mean, we literally do these workshops within like two days.
three days tops and we are able to get to such clarity that when I hear like, we have a roadmap. Okay, let’s see it. they kind of disseminate that amongst certain people. like, why doesn’t everybody know this? This should be front and center to show like, hey, when I’m a designer, you tell me to do something. I’m going to say, well, does this tie it? This is why I designed it this way. Cause it ties up to this because everybody in the room is going to have a
opinion on design, because it’s very subjective in certain things. And, you know, when it gets to development too, you could say like, Hey, this component is going to take me 10 hours to create versus what you design may take me a hundred hours. Can we meet in the middle or I’m just going to go and do the 10 hour thing, but not realizing it’s a big detriment to user experience. ⁓ but your job is to finish that backlog. that’s your incentive. And so it’s like,
That’s why when I hear teams at our dev team is designing as where the product designers are proud of it, I’m like, you know, that’s, that’s a conflict of interest because you know, their, their job isn’t to, to, put the user first. It’s the feature. Let’s get these features out. And of course, like a designer, you want to showcase how good your design is as a developer. You want to showcase how much you’ve put so much effort into that component. So.
or component, so you try to show everything on that interface. And so again, that’s when you tie it back up to the leadership and that alignment. Like what is our, what is, what are we trying to do here in this? And it could be in context of the user, like is the user coming in and their job is to do X let’s okay, let’s get them to do X at that moment in time. And that’s hard sometimes for a lot of people to understand. It’s like, okay, here’s a dashboard. Let’s show them a bunch of pretty like.
graphs and charts and everything. It’s like, is that what they need? Or do they just want to know, give me a big red, you know, X that says this is broken, go fix it. And then that’s it. My job’s done. That’s all you want to do. Um, so I mean, that alignment is such a, it’s, it’s such a key thing. And again, this is where the therapy comes in and you see how misaligned leaders are. And this is just at the top level. When you go from the top then to the middle management, there’s gaps there too, that you have to.
Federico Ramallo (35:43) Right.
Makoto Kern (35:58) really communicate and say, hey, this is what everything’s looking like. And so you, again, you see, you see the maturity of an organization and how well communication flows through and decision-making flows through just through doing this type of workshop.
Federico Ramallo (36:12) Amazing, yeah. I’ve seen stakeholder misalignment and yeah, many times.
Makoto Kern (36:16) It’s 99 %
guaranteed in most companies unless you’re unless you’re like maybe Tesla, you know, I don’t know Or even Google I’m sure has that issue
Federico Ramallo (36:28) Right.
Yeah, mean on bigger organizations, you you most likely are going to have that issue and I think it’s this concept of, you know, unstable stability, you know, ⁓ if you grab something below the center of gravity is going to be unstable, right? So, but with electronics, you can keep it stable, right? ⁓ So, you know, you have ⁓ fighters doing that, you know, that’s how they fly,
Makoto Kern (36:43) Mm-hmm.
Mm-hmm.
Federico Ramallo (36:59) unstable by nature and they have lot of electronics to keep it stable. So ⁓ I feel that in any organization the tendency is towards misalignment, towards chaos, right? So there has to be always an effort towards clarity and alignment, a continuous active effort, right?
Makoto Kern (37:02) Mm-hmm.
Mm-hmm.
Federico Ramallo (37:21) Yeah, ⁓ I’ve seen that happen many times. the where I had ⁓ the biggest challenge ⁓ was working with startups, where the CEO is a product, a product leader, because they have their multiple issues. One is that they they are running multiple roles. So everything happens in their head. And by the time they give you the feature is like
Makoto Kern (37:24) And…
Mm-hmm.
Federico Ramallo (37:50) I don’t have time, just build it, right? I don’t have time to explain you everything, right? ⁓ So we as software engineers will lose a lot of context and sometimes because they’re, you know, it’s a new company, new organization, they have this ⁓ expectation where the software engineer should do software design, QA, test, deploy, everything, right? Part of it is because they’re a small organization, but still that means that
Makoto Kern (37:52) Yeah.
the
Federico Ramallo (38:20) the software engineer has to excel on everything, right? ⁓
Makoto Kern (38:23) Yeah, you got, you have to have unicorns
on your team. And if you don’t that, and they’re not willing to pay for those unicorns, not knowing like, Hey, isn’t the stat nine out of 10 startup fail? then nine out of 10 of those failed within the first five years. So there’s probably, you know, similar reasons as to why, most them have had hires and they don’t realize like, yeah, if you’re competing and you’re trying to move fast and create something that
Federico Ramallo (38:26) Right.
Makoto Kern (38:52) there might be other competitors on your heels, then that’s a
Federico Ramallo (38:55) they have these unrealistic expectations. And I’ve personally been able to navigate those by basically working towards alignment, towards setting the right expectations. But when I had issues was when I would bring a team.
especially if they don’t have much experience with this type of environment ⁓ where they’re more used to the specific role of developers and nothing more then ⁓ I see a lot of friction and leaving that team becomes tiresome because now I have to manage not only the work that I’m doing but what everybody else is doing and yeah, eventually it’s too much, right?
Makoto Kern (39:43) Yeah, it’s not scalable in the long term. ⁓ if you don’t have, yeah. If you try to have, mean, I’ve seen that so many times. I mean, the CEO is always the product owner slash CEO. And so trying to get an agreement with them and trying to extract what’s in their head. I was almost like, compared to when you’re trying to build a, a logo, it’s, it’s, hate logo design because
Federico Ramallo (39:46) Right.
Makoto Kern (40:11) They have an idea of what they think they want in their head, but they’re not quite sure how to articulate it. And that’s the same with a startup CEO is where they have an idea of what they think. And if they can’t articulate it just because of whatever constraint time, which is most of it, and they want you to do that, it’s, I’m gonna be in that situation now because I’m actually gonna start helping a startup as well. And I have a similar idea and I think a similar feel as to.
what I think is very good and important for what the features and what is needed in the application. But it’s going to be, I know, a little bit of a challenge where, yeah, I’ve got to become a product owner, basically, and let the CEO do their job and have that person trust us to create something that they’re happy with. so, yeah, it’s fun challenge.
Federico Ramallo (41:07) Yes, yes, it’s challenging. I mean, it’s interesting as well because it’s fast paced, you know, so it forces you to be on your toes, ⁓ But yes, it is challenging. ⁓ On the bigger projects, what I’ve been able to do is to pair ⁓ designers with the product owners so that way they will build together the requirements.
the mock-ups and requirements before it got to the development team. Plus, we had the designer on our team giving us clarity on the requirements. So we had the delivery of the new feature as a story. So the product owner would tell us the story. We would record that. Because we could have
Makoto Kern (41:47) Mm-hmm.
Federico Ramallo (42:04) Requirement documents, even if we have really big and long requirement documents, there were so many little pieces of information that were missing there ⁓ that when you’re writing it, you don’t realize, but then when somebody else has to read it without the context, you get lost. So we took that dreaded task into a fun activity because it was a… ⁓
Makoto Kern (42:14) Mm-hmm.
Federico Ramallo (42:33) a team activity and everybody was there it was like going to a movie you know like we’re going to learn about the new feature right so so that was great and then with our designer we would we will be able to ask any questions any specific questions that we missed right one of the things that i remember and it’s small but still is ⁓ the product owners will give us the happy path right you talk about the
Makoto Kern (42:58) Mm-hmm.
Federico Ramallo (43:01) the login form, right? Okay, what happens if there is a wrong password, right? I didn’t think about that. Just put a text, an error text, right? Fill it out, right? And then any text that we’ll put as developers will be wrong, right? They will say, no, change it for this and this and that, So instead of going back and forth, the designer would ask those questions, right? And that way we have the full, you know,
workflow with a happy path and the negative path and the errors and the validations and and and because we had this ⁓ Component catalog now we have we knew exactly where to put the errors, right? so all of that was you know, we evolved towards that and and the products owners eventually, you know, it took them a while, but eventually loved it because They they could set and forget right? And yeah, and they appreciate that. Yeah
Makoto Kern (43:52) Yeah.
Federico Ramallo (43:56) ⁓ so you mentioned ⁓ about AI, right? so how do you think AI is impacting this ⁓ product development and stakeholder misalignment?
Makoto Kern (44:12) So I think, and what I’m seeing is that some companies are just, bypassing the UX and product strategy piece again. They’re just saying, hey, we just need to integrate AI into our product and it’s good. That’s all we need. And I know with, I’ve seen firsthand where they did that.
They moved all their resourcing to create and integrate the AI into their application. And, you know, we track things using like analytics tool, Pendo, and we see what the prompts are. We’ll see maybe one or two prompts, and then that’s it. They’re not using AI anymore or not in the way that they want it to. And that’s exactly the problem that, you know, they’re like, ⁓ you know.
The CEO has some grand idea of just, Hey, we’ve got to say we’ve got AI in our product. Everybody wants to say that. But then it’s like, your users show that they don’t really care. Not in the way you’ve integrated it. You’re still not solving their biggest problem. And this is, this is where, you know, you have to, because the cost of integrating that is expensive. And, you know, this is where it becomes even more important.
to make sure that when you do integrate it, you’re integrating it in the correct way. I think, I don’t know, it’s again, where there’s a shiny new object, people just wanna like use it. And they think they’re gonna make millions using it. It’s just not the case.
Federico Ramallo (45:49) Right, Yeah, I mean, it’s like everything. It becomes these fashions where people just build it because it looks cool, ⁓ but not necessarily because it’s actually needed, right?
Makoto Kern (45:57) Thank
Yeah,
I mean, look at the VR system with Apple. How many people have bought that thing?
Federico Ramallo (46:10) Right, and
it became obsolete what two years later, whatever, right?
Makoto Kern (46:13) Yeah,
meta worlds. I mean, these things, nobody’s using it and they spent billions. Luckily they have billions to spend, but most companies that would bankrupt most companies out there.
Federico Ramallo (46:26) Right.
Makoto Kern (46:26) Okay.
Federico Ramallo (46:27) So what advice would you give to C-suite leaders that are about to launch a software product?
Makoto Kern (46:37) hire us so you won’t fail. You know, I think. If you if you’ve done it before and you’ve launched, you know, lots of products doesn’t mean you know how to do you have the best playbook. I mean, if you have success, then that’s great. ⁓ But if you’re trying to do this for the first time or you’re launching something that has high risk, ⁓ you have to really think about like.
Federico Ramallo (46:40) Hahaha
Makoto Kern (47:06) Where does your organization stand? Like certain organizations, they’ll have customers or they’ll have their own customers that maybe one of them pays for 50 % of the revenue. And so you’re going, you’re driven by that one, that one customer. And so is your organization set up that way? We’ve been involved in those organizations where this one customer is calling the head of development to say, Hey, we want this feature. It’s like, that’s how you, that’s how your process works. And then everybody else gets.
you know, a different build and now you’re maintaining multiple builds and it just becomes a nightmare. And they think they’re doing a good job, but that’s not the case. ⁓ it’s not scalable. And so you have to really take a step back in your organization and say, okay, if we’re going to launch a new software product, let’s think about like, are we solving the user’s pain points? How does that pay? How does that tie into our business goals? And then are we giving
You know, the risky parts. mean, that’s the biggest thing. Anything that’s risky. If you just start building that right away, that’s you’re just incorporating more cost and pain if nobody uses it. And now with AI, you are, you’re, you have to be fast. You have to have speed and you have to have direction because everybody else is using AI. It’s like, it’s the whole high, the high tide raises all boats. So if.
Your competitors are using AI and you’re using AI. You’re kind of at a null kind of ⁓ advantage, but if they’re using AI and they see what you’re doing, they’re like, ⁓ let me just vibe code or prompt my way into creating something similar. Then now they’re surpassing you. You have to consistently improve on your, on what you’ve created. So a lot of times, you know, they may do the first part right of strategy, but then I get
I get directives where, okay, thanks, Makoto. Thanks for giving us those designs. We’re done here. I’m like, are you serious? And it’s like, you have to monitor metrics, make it data driven. Okay. Your product owner says he wants to launch this feature. We launched it. How’s it performing? Is it really helping people with their time on task? Is your NPS score is increasing? You know, these are things that are things that you have to constantly measure. And then is your, you know, is your, ⁓
Onboarding is that happening quicker? people, the learning curve quicker? Because that again is going to be something that is taking away from your resources if you have to sit there and train somebody to use your software for much longer versus if they go a different route. So I think these are all things that they have to like really think about. And if they, if they can manage that themselves, great. But if they don’t, then obviously you’ve got to hire individuals that can kind of get you there. So.
Federico Ramallo (49:54) Interesting, interesting, yeah. So ⁓ we’re running out of time, ⁓ but before we wrap it up, do you have any final remarks?
Makoto Kern (50:07) ⁓ you know, I think…
think this, it’s been an interesting year and probably just for everybody. think a lot of people are overwhelmed at the, where AI is going to take us. I’m sure that’s on top of everybody’s mind, but I think you have to understand. And it’s something that’s interesting that I actually just posted on LinkedIn. ⁓ It’s the perception of, let’s say you’re a developer and you need to come up with a marketing plan, use AI.
Like, holy cow, this thing’s so smart. But I call it, it’s, it’s your cognitive dissonance against like, you don’t know much about marketing. know, a little bit about what it is, but you feel like this, this magic thing that just created this amazing, like AI, I don’t need marketing anymore because it just created that. But vice versa, if a marketing person says, Oh, let me develop, let me vibe code an app. I mean, let me just make the code through AI. You as a developer, when you look at that code, you’re like, nah, this is just okay. But.
You as a marketer says, I don’t need developers anymore. You have that cognitive dissonance and that, that perception of like, this thing created this whole thing. it’s because your distance, your gap knowledge gap is far away from what it is. And so I think people have to kind of take a step back and realize that because you’re able to gather information so much quicker, especially in gaps in your experience.
you’re thinking that AI is just gonna replace everything. But when you actually are the expert and you get into it, you’re like, nah, it’s okay and it’s helpful, but it’s not gonna really replace somebody who knows what they’re doing because I know then like, sure you created a website or design, but I can take a look at this and yeah, it could be improved or that AI just did that. There’s so many things that you didn’t ask it correctly, it’s not showing correctly. And it looks like the 10,000 other things that are out there.
Federico Ramallo (51:56) Yeah.
Makoto Kern (52:05) What are you going to do to make yourself stand out? You can’t vibe code your way into doing that. Maybe some things, but in reality you can’t. And so I feel like people are somewhat have a negative outlook on that. And it’s like, just use it to, to garner that information. So then when you do have the experts in there, they’re probably using the AI to help them force multiply their output and make themselves better. I think again, everybody who’s using it should be using it.
to their advantage. Don’t just omit it completely, but definitely don’t think it’s, I don’t need a marketing, I don’t need a dev, I don’t need a designer because I’ve got AI just doing everything for me. It’s not there yet, and I think we’ve got a bit of time before we have to worry about our jobs.
Federico Ramallo (52:52) Yes, yes, I mean I think right now AI is average of average of all master of none so you know and for vibe coding it’s great for building prototypes right to kind of show your idea for that is great, but then AI doesn’t know how to do abstractions so you know ⁓ So that’s where you need a software engineer to do that right so we can give you the first step, right?
Makoto Kern (53:05) Yeah.
Mm-hmm.
Yeah.
Federico Ramallo (53:19) but then if you ask for an improvement on that prototype you’re going to struggle ⁓ because it’s going to fix one thing, break another and you’re going to keep doing that ⁓ so yeah, but I think it’s a great tool for a non-technical person to build a prototype I think that’s great because now with a prototype as a product owner you can show it to the users have ⁓ a conversation about that rather than tell them an idea ⁓
Makoto Kern (53:24) Yeah.
All right.
Federico Ramallo (53:49) But can that code become production ready? Not really, right? ⁓ So yeah, I agree with you.
Makoto Kern (53:54) Yeah.
Cool. Well, yeah,
I appreciate you having me. This has been great conversation. yeah, I can’t wait to see where the future takes us.
Federico Ramallo (54:07) Yes, yes, I appreciate you being here today. ⁓ I think we learned a lot and I’m looking forward to hear more about where you take impact in the future.
Makoto Kern (54:18) Sounds good.
Federico Ramallo (54:20) Awesome. Thank you.
Makoto Kern (54:21) Thanks everybody, take care.