Overview
This episode of the Aboard podcast looks past the excitement of “vibe coding” to ask what AI-driven software development means for the craft of product management and design. Paul Ford and Rich Ziatti argue that the current AI conversation is overly centered on engineering speed, while usability and business alignment are being sidelined—temporarily.
They propose that as organizations experience the consequences of shipping faster without sufficient product thinking, product managers (and designers) who adapt to AI tools will become even more valuable as translators and governors of “ship risk” in a world where anyone can deploy changes.
Key Takeaways
A central theme is that “shipping” has become the headline metric, but shipping quickly is not the same as building the right thing. Much of what’s produced under vibe coding is described as “database-shaped” software: interfaces that mirror data models rather than reflecting user research, real workflows, compliance constraints, or multi-step journeys (the DMV-style product reality).
Rich frames the “apex product manager” as a three-pronged role: (1) usability-focused design understanding, (2) business context/KPIs, and (3) enough technical fluency to work effectively with engineering (“inspect the element” as a practical litmus test). AI, they argue, has distorted this balance by letting the engineering leg dominate—design is reduced to “use a component library,” and business stakeholders often aren’t even in the loop.
A counterintuitive prediction: despite fears that AI reduces the need for product managers, the hosts expect PM value to rise. As engineering teams (and increasingly, executives) gain power to ship instantly, organizations will rediscover the need for diplomacy, prioritization, guardrails, and user-centered decision-making. In fact, they predict a fourth prong is emerging: product managers will need to “speak” to LLM-based systems the way they already translate between business, design, and engineering.
They also flag an operational risk: bosses with vibe coding tools can now make sweeping changes directly—blowing up process, observability, and governance. “Ship risk” used to be the industry’s control mechanism; AI erodes that, making oversight and alignment more critical, not less.
Practical Steps
- Lead with your core discipline—then add AI fluency. PMs shouldn’t try to become solo engineers; instead, use AI to prototype, test flows, and explore alternatives while still grounding work in user needs and business outcomes.
- Adopt an “inspect the element” habit for AI-built systems. Learn to review agent plans, markdown specs, prompts, and workflow definitions so you can pinpoint problems, ask better questions, and accelerate engineering rather than route around it.
- Re-center work on business and usability artifacts. Pair rapid prototypes with clear KPIs, user journey maps, and lightweight research so what ships isn’t just a reflection of the database.
- Create guardrails for AI shipping. Advocate for permissions, review workflows, and change management so executives (and anyone else) can experiment safely without destabilizing production systems.
Notable Quotes
- Rich Ziatti: “What’s happened with AI is one leg of that stool, engineering, has sucked all the oxygen out of the room.”
- Paul Ford: “What I see actually getting shipped under the banner of vibe coding are lots and lots of things that basically are a data model brought into an interface.”
- Rich Ziatti: “Your boss is going to have access to the same vibe coding tools that the engineers do.”
Full Transcript
I'm Paul Ford. And I'm Rich Ziatti. No, it's the other way around. Nobody cares anymore. This is the Aboard podcast. It's a podcast about how AI is changing the world of software. I'm going to be clear, Rich. It's been a long day. We're recording at the end of the day instead of the beginning. I'm a little punchy. I'm a little silly. That's the entertaining Paul Ford. All right, let's go. Let's record. Aboard. Okay. You got any jokes? I have some good jokes. What do you got? There was a guy who was in his living room lounging around watching TV and then he heard a knock on the door. Thank you. He gets up, opens the door, and there's nobody there. Looks around. Nobody's there. Closes the door. Goes back to his Lazy Boy. Lazy Boy, for the young people listening, is a brand of recliner. Five minutes go by. He's watching Wheel of Fortune. He's got the remote. He's switching a lot. Another knock on the door. Opens the door. Gets up, opens the door, and nobody's there. Again. It's mysterious. Very mysterious. Goes back to his Lazy Boy. Sinks into his relaxing chair. Have I told you this joke before? No. No, I don't know this joke. Guess what happens next. Opens the door. Knock on the door. Gets up. Walks over to the door. Opens the door. Looks around. He's like, what the hell's going on? Looks down and sees a little snail at the doorstep. Picks it up. Throws it across the street. Goes back to his seat. Two years go by. Another knock at the door. Who is it? Gets up. Walks over to the door. Opens the door. Looks around. Looks down. Snail looks up at him and says, what the hell was that about? Okay, so. Actually, you know what? I have a good one. I think that's a very solid joke. It's wholesome. It's clever. Okay, what's orange and rhymes with parrot? Carrot. Yeah, there we go. That's your joke? That's not a joke. Somehow it was better when- Mine sounded human. Yours sounded like AI. I do that, by the way. I hit chat GPT and I say, give me 10 riddles for my kids so I can shut them up. That sounds great. That's really good of you. So you're paying $20 a month for that. All right, so let's get back to work, okay? Yeah. We can have a little fun in frolic and we can work hard. I don't know if that was frolic. We can play hard. We fell short of frolic. It's a lot of meetings. Executive life is, and this is actually a good segue into them, because what do engineers do all day? Code. Okay. What do designers do all day? Design. What do product managers do all day? Ask engineers to code and designers to design. In what format do they usually do that? A meeting. A meeting, an email, a Slack message. No, product managers are meeting people. Let's be clear. They do like to gather. Are you a meeting person? You're kind of a meeting person. You like to gather. I am kind of, I think at my root, like introverted writer technologist type. I'm always convinced that we could have done an email instead. We don't have to. Yeah. I'm the opposite. You like to gather. It's one of the things I've learned from working with you is like, no, you just got to get in a room. Also, I gather people in a room because I actually work through things through a dialogue more than others, I think. People think I'm trying to guide you to an answer, but very often I'm actually thinking out loud. It's often because you're very assertive and you say, let me offer an answer. Yes. Yes. That's true. People don't necessarily interpret that as you entering into Socratic discourse. The odd thing is it is. It is. And what I'm looking for, and for the dynamic you look for, actually a good product manager, a good manager, frankly, seeks out that discourse because you can get very in your own world. Your root culture is product. You think of yourself as a product person first. I do. I think of myself as engineer first, but I'm good at shaping an organization. That's sort of like- I think that's right. I was thinking about it. I wrote about this recently in the newsletter a couple weeks back, and it's very, very interesting to me how much the AI conversation is about vibe coding and making things and shipping things. I see a lot of product managers that I know leaning into that because they're so excited they can build, but I don't see a lot of conversation about what this is going to do to the craft and discipline of product management. Let me just go on for one second because what I see actually getting shipped under the banner of vibe coding are lots and lots of things that basically are a data model brought into an interface. I put the data in the database. Most software looks like that. It is, and that's Airtable, and that is sort of most forms on the web, but if you really do product, and product is never that. Product is like this form has 16 steps, and each step requires a little bit someone to upload a PDF, and a good example would be the DMV. You got to upload all this stuff to the DMV. Usually, those are bad products, but they're not mapped exactly to the database. They're based on research. They're based on how stuff is supposed to work, et cetera, et cetera. Anyway, what I'm getting at is we're not talking about that. We're talking not about how product management or program management are actually shipping or changing software so that it really maps to the user is going to change. We're talking about how fast it is to ship, which actually is, in a funny way, I don't think is good for people who use software. I think we got to talk about ... Product is about making something usable for a person so it aligns with the goals of an organization. Yes. Right? Engineering is about solving a problem using a system. Yes. Okay. You're a product manager. We're building an AI product management acceleration company. Yes. When you see vibe coding and you see ... I've been vibe coding a lot. When you see the outputs, what are your first thoughts? Before I answer that, I'm going to draw out for you what I think makes the apex product manager. Okay. Okay? The apex product manager is the center of three prongs. Okay. It's prongs, everybody. Prongs. Okay? The first is design. By design, I don't mean color scheme, which is important. Some product managers are very tuned into marketing and branding. What I mean by design is usability, which you just touched on. Right, right. The second prong is business. The truth is, business is like our turnaround for support tickets is too slow, right? Or our customers are waiting over 30 days to get a refund, right? That's a business objective. I mean, just to interrupt you, we'll get to the third prong in a minute, but if you work at a large org, it'll be like, okay, if you want to ship a product inside of this org, like a big, like a hyperscaler type of thing, you got to show that you can make $50 million, right? Like literally like- Yeah. But this is often packaged up as KPIs or key performance indicators, which KPIs are never like as mushy as like, make sure our customer support people are satisfied with the tools they use. That's not a KPI. No, no. It's 32% retention rate because today we're at 26. Et cetera. It's some quantitative thing, right? The third prong is they understand the contours and limitations of engineering. They are technical just enough to understand it. So- I always used to have a metric when we were interviewing, which I called the inspect the element metric. What I mean is you can right click on a webpage and you can, if something's broken, you can kind of look at the code. Correct. You don't need to necessarily understand the code, but if you can pinpoint the code and say, I think something's wrong here, when you file the bug and talk to engineering, you're accelerating engineering like tremendously. Absolutely. So that specificity is really important. So the three-legged stool of a great product manager is they understand business context. They want users to have intuitive tools because they'll work better, right? And they understand the technical limitations of what they're asking for and the contours of it. I mean, it's a famously diplomatic role. You have to run- Shuttle diplomacy is a key part of product management. Now let's bring AI into the picture. And what's happened with AI is one leg of that stool, engineering, has sucked all the oxygen out of the room. I cannot emphasize enough how badly design, and by design, I mean user experience design, like good intuitive design has been marginalized in this explosion of like AI and code. I'll just tell it to use a component library. That's enough. Exactly. And so what you have is a lot of pedestrian recognizable designs that have nothing to do with optimizing for use. So design has been absolutely sort of shown the door. This is what I'm getting at. Like most interfaces I see that are vibe coded are one-to-one like what's in the database. They're reflections of the stack. Yeah, that's right. And then business is absolutely not even, like they found out about it at the dinner party two days later. They were never even invited. So that business context, which is actually much more key context for why it should be, are not even in the mix, right? And so what you end up with right now, there's a catch up that's happening where the engineers, which everyone is talking about how this is going to take engineering jobs. What no one has noticed is the engineers have taken all the coins and they've run away. It's extremely... They left the party. It's extremely normal engineering behavior. It's very normal. And I'm not saying that's malicious or whatever. No, no, no. I'm coming to you as someone who's very engineering, you know, sort of centric. Yeah, exactly. Oh my God, look at what I can do. I am such a good, smart person. Exactly. So I want to reassure designers and product managers in this shift, which is they will be coming back hat in hand. You know what it is? It's going to happen. The focus got so... It was such a... Especially at Cloud Code, it was just such a radical disjunction that what everybody... Everyone forgot that software isn't really just code. So what's happened is instead we've been like, designers, you can code now. Which actually ties into like, it's almost a joke, like for 20 years, should designers learn to code? And so now you can. And product managers got all excited because suddenly they didn't have to talk to engineers anymore. You know, all kinds of stuff. And the business is like, wait a minute, can I save a lot of money and not hire all these engineers? But it's all really swirling around this kind of set of artifacts. Nobody gets to ace it. That's what's happening. Just because a product manager can now generate some code and make a good prototype, doesn't mean they're a better product manager. I agree with you. I don't think that... I think costs can come down. I think things get accelerated, but they've left the user out. No one is talking about how I can really accelerate and connect to a user and drive a business case for it. They're just like, oh my God, it ships so much stuff so quickly. Listen, I understand why this happened. Here's the thing. We're tribal. And by the way, our product I think is good for this, but this is actually not an ad for us. Like we're guilty of it too. Everybody's like, what just happened? No, no, everybody's guilty of it. Everybody's a... We're tribal. No, no, we're tribal. Look, every tribe of discipline looks at other tribes of discipline and finds them incredibly exhausting. Not only exhausting, but they just don't do anything. They don't do anything and they bring no value. Damn it. Their jobs aren't hard. If they were really smart, they would come do my job. Correct. And look, AI, the reason why engineers have kind of bullied everyone out of the party is because AI is an engineering invention. Like it is fundamentally... It had no UX. It wasn't this breakthrough. It's not a touchscreen. They're like, this is the extent we're going to use design. It's a box. Thank you very much. We're anti-UX. There's no buttons. There's no switches. There's no anything. Code for those who aren't engineers literally launched like the experiences inside of a terminal like it was 1983. Exactly. And proudly so. Proudly so. It's born out of that culture. Speaking about anthropic specifically. And the truth is they found a new revenue line that's in the billions already by just having a giant engineering love. It's a love letter to engineers. Let's be clear. This is what drives a lot of business and it's worth... It's a multi-trillion dollar industry. Correct. So, you know, we've been talking on the podcast about healthcare and, you know, insurance and all these things. These are huge sectors. And when you find something that locks in and can really make a difference, the money's going to flow. Yes. But the problem is for that, like that party will end for engineering. And the reason it will end is that most engineering, unless you're selling your own shareware, is in the context of... You lost 80% of the audience with that. Shareware was essentially what open source code used to be. Yeah, I'm 71 years old. So this is out there. But it was on websites with names like 2cals. Yeah. And you would download it and it would like pop up. You'd be like, oh, this will help. I messed up bad here. It's okay. This will help me like organize my hard drive and it would pop up with an alert saying send five dollars to Mike and it would be like a guy's address. Yeah. Yeah. Yeah. By the way, there's a there's a scan. If you buy a scanner, if you're doing a lot of scanning of documents, for whatever reason, like Canon makes one, Epson makes one, all the printer guys make one. For whatever reason, they sort of bailed on Mac drivers. Oh, yeah. And there's this one guy. Yeah. I have it. Everyone has it. Yeah. If you have a Mac and you bought a scanner. It's like 50 bucks. It's like 50 bucks. This guy ported all the drivers for all the hardware for Mac. Right. And he and they they're like Canon's like, bro, thanks. Yeah. Blessings. Thank you for doing that. Anyway, back to vibe coding printer drivers for HP laser jets. That's not where I was going. But engineers have appropriated this technology in a very like extreme look. Figma's doing stuff. Others are doing stuff. Everybody's doing. Everybody's doing stuff. Really? Yeah. The heat and the light is around the fact that someone can ship software so quickly. Correct. I'm going to share a piece of advice and I'm going to share a prediction. Okay. And I want you to interrogate. Okay. Both. Let's do the prediction first. My prediction is the winner eventually on this are the product managers who hang tight, learn the tools and understand that eventually their stock price is going to surge because engineers have terrible instincts and very little empathy for what's important outside of their domain. No, engineers like building systems, but it sounds like it sounds like a swipe. It's not meant to. I'll actually be really clear here, which is these new products show up and it's really disruptive what they do. Most of the world cannot think in the shape of software, right? Sure. Software has a way of, it has a shape like when I, when I'm working as a writer, I think in the shape of an essay. Yeah. When I am developing code, I think in the shape of the short for it. It has modules, components, functions, data flows through, et cetera, et cetera. Yeah. And most human beings, like literally like 99.5% just kind of don't think that way. I mean, it's a discipline. And so what's happened is that kind of thinking is greatly accelerated through AI, but that kind of thinking, again, most humans don't think that way. So we have to help the people who don't think in software, get access to the power in the software right now. It is just like a land rush time. Like, Oh my God, I can have everything that has never been what the industry actually wants. Yeah. What the industry wants is, Hey, we have a business problem. The business problem is that the error rate of our like signatures that are scanned into the paper. It's that kind of nonsense. I'll give you another one, which is they're delivering too many sweaters and we don't have a place to put them. Yeah. So we have to manage inventory flow. Something's wrong here. Right. Yeah. A classic business challenge. And so I think, you know, the hypothesis is you'll just describe that to a software system. Yeah. Maybe that will work. Maybe it won't. But if it's a general problem and somebody needs to be in there to interrogate and interpret, I do think what is going to change about product management is that just as they were, they're going to be diplomats to LLM based systems in the same way they are diplomats to engineering design and to the business. I think essentially you had three prongs. Yeah. I think a fourth comes in and everybody's talking to the fourth. Like it's not just them. The business. One of the things that I propose, and I think this is real and I think everybody has to watch out for this. This is one of the worst things that could ever happen to you. Your boss is going to have access to the same vibe coding tools that the engineers do. Usually the boss sends an email when they have a big Sunday, big idea on Sunday. Big idea. You know, guys, I think we should change the website. I've written that. I've written that email. You have. But now you can just go ahead and go right in. You can completely refactor the whole system. Sunday night, Monday morning, the engineer comes in. Why is everything a shades of green? First of all, they do their 45 minute slow pour custom grind drip that they do in the office instead of working, which is somehow something that happens with engineering culture. And then they sit down and there's 38,000 emails from the AI bot that monitors the system because the boss decided to completely change the way the marketing website works. Yeah. You think that's going to happen? Oh, you're kidding. What do you... It's probably happening right now. You cannot... Like the amount of power and the systems are here that anyone... So all of this sort of flexibility and fluidity is blowing up process because anybody can ship anything now, right? Ship risk was the organizing principle of our industry. There is no ship risk anymore. I guarantee you, no matter what you want to do, I can get that software over the line. Is it the right software? Who has access to it? How do we make it useful to lots and lots of users? Is it aligned with the business? Should the boss be able to come in and change the way the database schema works or update the SKUs? Right? Those are the problems the product manager is going to have. And like I said, I think it's four prongs. I think they're going to start talking to the system in the same way that the engineers are talking. Yeah. I think you're right. Let me go to the advice bit. Great. I think product managers are watching this right now. They're seeing engineers route around them. As far as I can tell, they're also thrilled to be able to code too, though. They are. I don't know if they've figured out how to translate that into something worth showing the boss just yet. But the advice I would share is this. I think designers and product managers are feeling like they have to learn a whole new job to compete. Their colleagues are generating code and they may feel like, okay, well, eventually I guess where the world is going, I have to ship the software entirely, all alone. And the truth is they won't. What they should do is this, lead with your discipline because it turns out that neglect of design and product management is actually going to come full circle because engineers, except for very few, and I've met a few, but very few, will come up with something really shiny that the boss says, the business stakeholders say, wow, I really appreciate you doing that. I've been struggling with that for a really, really long time. They won't do that. They'll do other things that scratch their itches. And what they're going to eventually do is go back to those product people and ask them what the business needs and they're going to go back to those designers and ask them what the users need because they still want to do good at their job. This is what's funny. The product manager is not really loyal to their discipline. The engineers and the designers tend to be. Product managers are loyal to the business. They are translators. If you can translate business needs to design and engineering needs, you are a great product manager. And as a translator in this future state, it is going to be everything. So I'm going to be two product managers. How many product managers have you interviewed in the course of your career? A couple hundred. Yeah. I mean, probably a hundred. Right. And so I'm going to be two different product managers. Ask me how I built the system. How'd you build the system? Well, I just honestly just prompted the whole thing. I used a bunch of agents and it built it. And that was really cool. I didn't even need to talk to engineering. Wow. Okay. Okay. Ask me again. How'd you build the system? Okay. So I worked with engineering and they scaffolded a lot. They use a lot of cloud code. That was cool. And so I actually got in there and, you know, I'm pretty good with this. And so there were a lot of things that are design research and working with design too, that I thought that the users needed. And so I prototyped a bunch of those. We were able to kind of AB test some of them. Then I went back to engineering. I'm like, do you think this is the right thing, you know, the right way to build this? Actually it turned out they were like, yeah, cool. You did a good job. So that was cool. It felt good to be an engineer for a minute. And so it's a lot of that. Like I take the core platform and then I build up on top of it. So I'm using a lot of systems, but I'm still like deeply in with engineering and design. Who are you going to hire? The second person. I mean, obviously, like I'm kind of, but seriously, like I think everybody's got this idea that the future is these big lumpy systems that you never look into. No. And I'm going to tell you, as somebody who hires, if you told me that, I'd be like, I don't want you anywhere near me right now. You're too dangerous. Yeah. Right. So I don't, you're going to hear a lot of that from engineers about like, oh, let's use this pattern and you just let the agents run wild. That is not what we want our product managers to oversee. I do think, I think what you're asking, what, you know, the advice really for, for product and design is go out and learn enough beyond your own discipline so you can understand these things. But you're leading with your discipline. You're still leading with your discipline. Your discipline is still going to be necessary. If you're stubborn about it, you don't want to use anything. You're going to be in trouble. So if you think like I'm a purist and I don't use tools and I use paintbrushes and acrylics, good luck. Again, hundreds of product managers hired dozens and dozens inspecting the element, right? Did you go in and look at the system? You don't necessarily have to be an expert in the system. That's still really important. You just, essentially what's happened is a whole new set of elements that need to get kind of understood and inspected, but you also have tools to interrogate and understand those elements. That's what people are going to be looking for if they're good. Markdown files are mostly in English. Yeah, that's right. You can read those. That's right. Skills, agent profiles, all that stuff. Get into it. If somebody tells me that's really exciting to me, I love to see the system get built that way. I like to contribute to it. I'm going to want to hire them just flat out like that's who I want to meet. Yeah. So there it is. I think there is, I think we're in this funny zone where everyone has forgotten the product managers exist and why they matter. But I think you're right. We're going to get, it's going to be back where we were. We're going to need them and we're going to want them. I mean, as a product manager, it's had a hard time defining itself for 20 years. I mean, again, it's basically the diplomat from the business. No, but there's no certification. There's no, it's always kind of been a little amorphous. Yeah, there's a bunch of, there's also a program manager and it's a project and it's a product. I think that this is actually exactly where you'd want to be professionally with this shift. Product management, we call them solution engineers here at a board. I think it's a great place to be, but you're going to have to go and learn some new things. Lead with your own discipline and experience, but go learn some new things. I get tired of thinking of humans as lumpy non-learners. I think people like to learn. They should. Yeah. They should. It leans into a lot of the principles we're talking about in this podcast. What we're doing is we're building a tool for solution engineers to build systems. Right now, we do that inside of a board. You talk to us and our solution engineers build stuff for you in the future. Who knows? Yeah. Who knows? But we work with really good, really big clients all across. Sometimes people are just trying to clear stuff off their roadmap and they're like, can AI help? Sometimes people are just really excited to learn more about what we're doing. We welcome all of those conversations. Come one, come all. Hellooutofboard.com. We'd love it if you like this podcast and you find it useful, please cherish us on a variety- Interesting. Yeah. Give us- Like and subscribe. Absolutely. Yeah, we appreciate your attention. It's really good. Keep learning. All right. Have a wonderful week.