The Claude Code Setup for Non-Technical PMs That Nobody Shows You

1. 0:00 – 2:27

   Intro

   1. AAAndre Albuquerque0:00

      If you look at a lot of companies that have non-technical PMs in teams, they're bureaucrats. They're stuck in Jira, Linear, PowerPoints. They're dependent on their technical teams.

   2. AGAakash Gupta0:09

      Andre Albuquerque. He runs Europe's largest product builder school with over 4,000 students, and in today's episode, he is giving you everything for free.

   3. AAAndre Albuquerque0:18

      The product owner culture in Europe, it focuses a lot on a bit of a glorified delivery manager without the actual technical skills.

   4. AGAakash Gupta0:25

      What's the flip side to this velocity, though? And you even have the word slop here. How do you avoid shipping slop?

   5. AAAndre Albuquerque0:31

      The biggest fear a lot of people have is like, oh, if I coded bad code.

   6. AGAakash Gupta0:35

      Transformation is a big goal. Can you go ahead and show people how they get started with this new way of working?

   7. AAAndre Albuquerque0:41

      It has four steps. The first one, Lovable. The second step, a mix of Lovable and Claude Code. The third step is Claude Code and Vercel, and the fourth step is multi-Claude Code, multi-Vercel, and a lot of automation and agents.

   8. AGAakash Gupta0:53

      One of the things you wrote about on LinkedIn is that there are now only four jobs. Can you explain this? Before we get into today's episode, I wanted to share that you can get a free year of my favorite AI tools, including Bolt.new, Mobbin, Arise, Relay App, Dovetail, Linear, Magic Patterns, Reforge Build, Descript, and Speechify if you join my bundle at bundle.aakashg.com. On top of that, I wanted to quickly ask you to please double-check that you are subscribed on YouTube, Apple, and Spotify Podcasts. It's a free thing you can do that really helps support the show. And now into today's episode. [fire crackling] If you're like me, you're getting overwhelmed by all of the AI tools, all the AI noise out there, and 90% of the guides assume that you are technical and you're an expert in Claude Code. Today's episode is nothing like that. We are gonna show you very step by step how you can start with Lovable and AI prototyping, how you can layer in Claude Code to your Lovable workflow, then how you can move to full Claude Code, and finally, how you can use Claude Code with tools like Vercel and Cursor to actually ship updates to your codebase. There is not a episode like this on YouTube, and I think I brought in the best person to do it. Andre Albuquerque really excels in giving you simple understandings, building up your knowledge from zero. So if you're a non-technical PM and you watch till the end, I guarantee you, you will feel more confident using Claude Code, and we will even give you

2. 2:27 – 4:50

   The biggest problem non-technical PMs face today

   1. AGAakash Gupta2:27

      the Monday morning roadmap to go talk to your engineer. So let's get into it. Andre, welcome to the podcast.

   2. AAAndre Albuquerque2:32

      Hi, Aakash. Thank you very much for having me.

   3. AGAakash Gupta2:33

      So I wanna address the non-technical PMs from the get-go and give them something they can use. What is the biggest problem non-technical PMs face in their roles?

   4. AAAndre Albuquerque2:43

      If you look at a lot of companies that have non-technical PMs in teams, they're bureaucrats. They're stuck in Jira, they're stuck in Linear, they're stuck in PowerPoints. They're not actually building. They're not pushing code. They're not adding features. They're dependent on their technical teams to do that, and it's not like they don't want to. It's a combination of their not knowing how. They ... Maybe the management culture doesn't allow them. Maybe they don't have the, the skills and the tools to be able to do it. But they're basically, they're waiting and dependent on everyone. And when we look to a lot of AI-native organizations or even new companies moving super fast, you see that that is not the reality. You see product managers, technical or not, actually contributing, building stuff. You see CEOs contributing to, to repositories in GitHub. You look at the Shopify CEO, and his GitHub is fully green. You see, uh, entire teams that are maybe, it used to be, like, 10, 20 people, and now they are super small teams, and they're all actually pushing new features, new codes to production. And I think this is the, the reality that if you're a non-technical PM and your job is still managing backlogs, your job is still writing issues, your job is still creating decks or PowerPoints to present to someone and you're not really building stuff, honestly, you're being left behind. And I think you want to completely transform the way you see your role inside a team, which then will influence everyone else in the team to rethink their own roles and transform the squads entirely.

   5. AGAakash Gupta4:19

      So transformation is a big goal. I don't know if we'll be able to deliver everything on transformation, but can you go ahead and share your screen, show people how they get started with this new way of working?

   6. AAAndre Albuquerque4:30

      Yeah, so what I'm gonna show you, just, uh, to give you context, is how I actually went from, "I'm not a developer, I, I don't know how to code," and I started building. Now, this has multiple steps, right? And this is the format that worked for me. Uh, it doesn't mean it's gonna work for everyone, but it gave me a bit of comfort,

3. 4:50 – 5:28

   The 4-level builder PM framework

   1. AAAndre Albuquerque4:50

      and I'll explain why. So, uh, it has basically four steps, right? Uh, the first one, and I'm gonna address different tools. Again, you might be more of a, a, a fan of a specific stack or a specific tool. I went through all of them, and I'll explain why these were the specific steps. So the four levels were first with Lovable, and I'll explain why Lovable. The second step was a mix of Lovable and Claude Code. The third step is Claude Code, uh, and Vercel as the infrastructure, and the fourth step is, like, multi-Claude Code, multi-Vercel, and a lot of automation and agents.

4. 5:28 – 8:04

   Level 1 - Why you start with Lovable

   1. AAAndre Albuquerque5:28

      All right? So that's how it works. So I'm gonna show you and kind of explain what happens with, uh, each one. So let's start with, uh, Lovable. First of all, why did I start with Lovable? Because honestly, it's way less scary than just jumping straight into an IDE or jumping straight into, uh, a code environment. It ... The team at Lovable, first, they're European, so of course I'm gonna be a big fan of what they're doing, and second, they built a, a really easy p-Product for anyone who has never coded, who potentially is a bit afraid to just start doing, right? This is step number one. So y-- And you can build like really simple tools. And my recommendation is you start with something personal. You don't start with something on your professional environment, because that allows you to actually explore the tool. For example, uh, I built-- So my family has a summer vacation home, right? And we are quite a lot of people, and we needed a way to manage who has the house in certain periods of the year, who's gonna be there, is the house fully booked or not. And this is not commercial. Like, this is for the family, right? So I started actually building. My first product on Lovable was this simple tool to manage the availability of people. Now, this is actually a great way to start because, again, there's no risk. Like, you're not contributing to the company's repository. You don't even need access because this is just for you. And you can do mistakes. The codebase, it doesn't need to be beautiful because who cares at this level? Like, it's fine. So you start building on Lovable. And the beauty about Lovable now is that they bring a lot of the stack so that you don't actually need to care or think about it. Like databases, authentication, all the type of things that often tech-- non-technical people, they don't even know that it matters, right? If you spend a bit of time on product or engineering, you know what authentication is, you know what these flows are, you know what to call things. But when you have never worked there, like you don't even know that is something important. So with Lovable, as a step one, it actually doesn't matter. So it's a great way to get started. So this is my start. And by the way, the, the app, whether it's an app or landing page, it can be as complex or as simple as you want. Doesn't matter. You can play with it. You can start gaining a bit of feedback on how you're building. Like one really cool way is ask-- always asking your prompt if you're missing out on something, if you're not questioning or asking or prompting something you should. And you'll always get the feedback back, like you're working with a senior engineer, which for now,

5. 8:04 – 10:21

   Level 2 - The Lovable + Claude Code bridge

   1. AAAndre Albuquerque8:04

      AI is a senior engineer to you. And they'll also give you feedback, and it's actually a great way to learn. So that is step number one. Then step number two, which is actually an accidental evolution, but it worked really well for me, which was I wanted to be able to do more, right? And Lovable, uh, at least back when I was using Lovable, was still a bit limited on a few things. So I installed Claude Code, right? And I installed Claude Code on the Claude, uh, desktop app, right? So you start working with Claude Code on the desktop app. Um, actually, I'm gonna, I'm gonna switch screens to the desktop app. All right. So you should be seeing Claude Code desktop app, right? And you land here, and let's be honest, it's, it's, it's a bit scary. You land here, and it's a bit scary. Like, you don't know what this is. You're not seeing a product. You just came from Lovable, where you saw the product in front of you. You had a chat. You had feedback. You don't even know what to do here, right? Okay. So what I did was I knew I had to get my code somewhere. That somewhere typically is some repository. So you start an account on GitHub. That's the first thing. Super easy. And you connect your Claude Code to your GitHub. So when you connect your Claude Code to your GitHub, they're linked. You can also connect your Lovable to the same Claude Code and GitHub repository. So they're all synced. That means that if you actually do code on the Claude Code desktop app and you update your repository on GitHub, Lovable will also get that update, right? And the good thing about this is that even though you don't have a visual understanding, or at least easily a visual way of seeing your product evolving, you can actually use Claude, uh, Lovable. Sorry. You can use Lovable as your infrastructure. What that means is that you can be pushing code on Claude Code with all the flexibility and all the great things that Claude Code offers, but you can still see the evolution of your product on Lovable with all the easiness of the Lovable platform. And I think this is actually a, a great transition because you're not fully getting out of it. You don't have to deal with hosting and infrastructure, and you don't need to think about deployment because look, let's say that I am contributing to, uh, my Lovable project, right?

   2. AGAakash Gupta10:20

      I used

6. 10:21 – 12:14

   Ads

   1. AGAakash Gupta10:21

      to think I had a retention problem. Turns out I had a messaging problem. I was sending the same onboarding emails to every new user, whether they activated on day one or never logged in again. I had no idea who was slipping or why. Customer.io changed that. Every message I send is now based on what users actually do in the product. Someone hits a key activation moment, they get nudged to the next one. Someone goes quiet, they get a different path entirely. Their AI agent makes it fast. I describe the campaign I want, and it builds the full journey.Triggers, timing, copy, even branching logic. And when I want to know how something is performing, I just ask the agent directly and it tells me what to do next. They also have an MCP server, which means AI tools like Claude can see directly what's happening in your Customer.io workspace. Your segments, your customer data, your attribution, all of it. So instead of explaining your business context every time you need help, Claude already knows it. Notion used Customer.io to personalize their onboarding and hit nearly 50% open rate, improved conversion by 6 to 7% with localized campaigns, and pushed open rates up another 20% through A/B testing. The idea is simple. Customer.io helps you deliver more impact from every message you send. If you're a PM or founder and your onboarding is still one size fits all, try Customer.io at customer.io. Today's episode is brought to you by Amplitude. Replays of mobile user engagement are critical to building better products and experiences. But many session replay tools don't capture the full picture. Some tools take screenshots every second, leading to choppy replays and high storage costs from enormous capture sizes. Others use wireframes, but key moments go missing, creating gaps in your understanding. Neither approach gives you a truly mobile experience. Amplitude does things differently. Their mobile replays capture the full experience, every tap, every scroll, and every gesture, with no lag and no performance hit. It's the most accurate way to understand mobile behavior. See the full story

7. 12:14 – 28:37

   Live demo: connecting Lovable to Claude Code via GitHub

   1. AGAakash Gupta12:14

      with Amplitude.

   2. AAAndre Albuquerque12:14

      On Lovable, let's say this is a project that I've used in that transition period. So I was building a platform, right? And this platform was for my school Builders Camp in the beginning, and I was already using Claude Code because I wanted to understand the tool, I wanted all the capabilities, but I didn't want to completely leave Lovable because it was super comfortable. Like, I had my chat here. I could see and ask questions anyway. But, uh, what you see here on the chat on the left side is merges, right? What that means is that I'm actually using Claude Code to work. I'm merging, meaning I'm sending the code to GitHub, and GitHub is telling Lovable, "Look, there was an evolution on the product, and it changes here." So the beauty about this is that I can actually test the product, do my QA, my quality assurance, directly on Lovable. And as I'm using Lovable as my infrastructure, the deployment, meaning putting stuff live for people in the actual URL, comes from Lovable. I don't need to deal with all the more technical infrastructure like Vercel, and I'm gonna go there next, because Lovable takes care of that. So it's, it's a accidental, uh, jobs to be done way of using Lovable that I don't think they intended, but it worked really well, and it's a great bridge.

   3. AGAakash Gupta13:28

      I haven't seen anybody talk about this. So this is new alpha. This is really exciting information for people. If somebody's just-- they need that extra step of you showing them, can you just show us exactly how to connect Lovable and Claude desktop app-

   4. AAAndre Albuquerque13:43

      Yeah

   5. AGAakash Gupta13:43

      ... to the right GitHub repo that's the same one?

   6. AAAndre Albuquerque13:46

      Yeah. So let me-- So, uh, I, I need to do some, some setup, so very quickly. Uh, let's say, let's see if I can use one that I already have. Uh, because yeah, I agree. It's, uh, it's something different, right? So let's see if I can do this. Um, yeah. So what we can do is let's actually build a, a small tool or a small product right now. Uh, I think that's, that's the step, okay? But let's also do this. Uh, one recommendation is that you need to have your repository, okay? Let's say that you have your GitHub, and it's under your name. Even my, my personal one is under my name. So it's here. Um, and this is where I'm gonna basically keep all the repositories that are connected to Lovable. Because again, what we're saying is this is for your personal usage or even for your business, not for the company. If it's for your company, the setup is different because your engineering team is gonna have their own repository. They need to give you access, but we'll go to that a bit later. So let's say you have... These are projects that I have for myself, okay? So let's say that I wanna build a new product. Let's say, so I'm gonna go to Lovable, and I say, "I wanna build a mentorship." So I'm gonna say a mentorship matching tool. Make it simple. So I'm gonna build. So what this does is I'm actually bootstrapping the tool on Lovable, which is way easier to start than starting on Claude Code if you don't have the infrastructure yet built. So let's assume you don't.

   7. AGAakash Gupta15:22

      Mm-hmm.

   8. AAAndre Albuquerque15:23

      So you start on Lovable. You say, "I wanna build something." So you explain. And then throughout the, the, the episode, I'm also gonna show you how this gets significantly more advanced without actually you having to know a lot more than what I just did here. So Lovable right now is going through its setup. So while it's working, it's important. You need to have your repository here, and then what you also need to have is your repository connected to Lovable. But I'll show you how you do this. So now it's-- I asked it to be simple, so it doesn't take a long time, but it still might take a few seconds in. So we wanna make sure that, just to recap the flow, is you have your GitHub repository, you're starting on Lovable, but you also have a Claude Code account. Now, you can use, I think you need maybe a pro account to be able to use Claude Code. Not fully sure if the free account allows you to do this. But let's say you're on the lowest plan, which is more than enough to start playing with this. Uh, you have your Claude Code account. All right? So now what I'm gonna do... Oh, and it's important to know that you also need to have your Claude Code connected, so your GitHub connected to your Claude Code. While Lovable is building, I'm gonna switch the share to my Claude Code desktop app. So you should be seeing my Claude Code. And if you go to your connectors, and you can see I have a lot of connectors here-You need to guarantee your GitHub integration is connected. And when you're connecting this, mine is already connected, you're gonna choose your account, you're gonna log in and authenticate, you're gonna put your password, and it's gonna link. What that means is that when you go to Claude Code, so if you see here, when you go to Claude Code, your repository is gonna show here. You'll be able to work on it. Okay? Uh, and you can choose your repository. So these are my repositories right now. So what I'm gonna do is, as I'm gonna be creating a new repository on this new Lovable tool, I'll then open it up here. So I'll add it here. Okay? So let's go back to Lovable. Let's see if we already have, uh, our tool available. So it's called Mentor Match. All right. So we have something that was built. This is what I call the bootstrap. So the bootstrap is you start with a prompt, however big, however simple, however complex, it doesn't matter, you're bootstrapping the product. Okay, now it's here. Now, let's say you want to continue on Claude Code, because you're already okay with working with the tool. So what you're gonna do is you want to make sure that you connect this to your, um-- Okay, give me two seconds. Let's say you connect this to your GitHub. Okay? So you should be able to go to, uh, GitHub. So Git, GitHub, and you're gonna have your account. So I'm gonna connect. In this case, I have multiple accounts. So I'm gonna connect to my personal account. So I'll connect. What that means is now the code that Lovable built is gonna go straight to GitHub. Now, important thing with Lovable, if you create your code on Claude Code, send it to GitHub, you won't be able to actually port the code directly into Lovable. It doesn't work that way. You need to start on Lovable. They made the product super simple for that specific use case. All right. So this now created a new repository called Mentor Match Simple. So if I actually go to my GitHub and I refresh it, you now see Mentor Match Simple is here. So now you go to Claude Code. Remember, up until now, we bootstrapped the product on Lovable. We connected to GitHub. I showed you the GitHub page. And since your Claude Code, you connected to GitHub, your GitHub via the connectors. Now, if you actually are in Claude default and you select the repo, you'll see that now Mentor Match is here. Okay? So now I know I'm coding to Mentor Match. So now whenever I do things here on Claude Code, on Claude Code desktop app, I'm gonna do something. So let's say I wanna change the design system to green. So let's keep it simple. Okay? I'm just asking it to change. Keep in mind, we started on Lovable, so I'm gonna switch to Lovable. And as you can see here, the tool is basically beige and, and red tones. Theme that is more on this, uh, palette. And I, I wanna change the, the setup. I asked Claude Code to do a bit more, uh, green. So what will happen is I'm actually coding into the repository, and when I say merge or add to the repository, as Lovable is connected to the repository, it's gonna update here. And you'll be able to see. So you'll be able to see, do I like it? Is this the experience or the feature that I wanted? In this case, I'm changing the design system, so I'll be able to actually visually see, is this what I was looking for? And if I don't like, I can either do the changes directly here on Lovable, or I can continue working on Claude Code. And in reality, what I'm doing is I'm using Lovable as my infrastructure before I bring this to production, before I actually publish. Keep in mind, this Publish button is what puts this live, not the actual Claude Code merging into that repository. I'm using Lovable as my infrastructure. And it's, in this case, super simple because I don't need to deal with branches. I don't need to deal with way more complex stuff. Keep in mind, this is non-technical, so we're trying to simplify life. So I am gonna now switch to Claude Code to see what is happening there. Okay. So the tool is working and done. It says light theme, re-replaced orange tones, dark theme. So it basically worked on the background. Uh, and now what we're gonna do is we're gonna ask it to actually, uh, merge this. So we're telling this, "I want you to update the product itself." Like, "I want you to take the code you just built." They're gonna be checking for a pull request, creates one. So it's doing all the stuff that typically your engineering team is doing that you as a product manager, you don't tend to see or care. And now you can still not see or care, but it's happening anyway. So now the pull request was created and merged, which means that if I actually go into Lovable, it's gonna be changing. Remember, the previous palette was beige with red tones. So now we should be seeing something different, right? And one thing you'll see is that, see here on Lovable, where you can actually see switch design system colors. This came from GitHub because you just merged something from Claude Code directly. So if things worked out, we should do some update and the product should have changed. Again, I don't know what. I'll be able to QA or I'll be able to see it. It depends on what happened with the code. But I asked to-- the design system to change. All right? So it's updating. So you already know that something's happening in the background. Uh, and by the way, see? This is what happened. So the design system changed. You didn't work on Lovable, but you're able to QA, you're able to test, you're able to see, "I don't like this. I want this to be different." So let's do something else. Let's say I don't like this, uh, header. So I'm actually gonna take a screenshotAnd I just screenshot. I don't know if you can see this on the screen, but I took a screenshot. And what I'm gonna do is I'm actually gonna go and paste this on Claude Code and say, "I really don't like the header." So now I'm gonna share my Claude Code. Keep in mind, you're using this format, which is what I call the bridge, is you're using Lovable as a bit of a QA infrastructure. Uh, but you're still using Claude Code and everything Claude Code brings to the table. And this will include skills and agents. We'll talk more about that. But you can still, in the transition period, use Lovable as a bit of a way of hosting your infrastructure, dealing with your product, visually testing it, which becomes a big part of your job. So I just pasted the screenshot I took, and I say, "I don't like this header. Do something different." You can go like-- You don't even need to specify it. You can just say, "Do something different," and then you'll see it changing on Lovable, and that's also a great way to experiment, to try new designs in a really simple way. I mean, there's other new tools like Claude Design and whatnot, but if you're trying to simplify your life because you're just getting started, this is actually a great way. So it's running everything, so guaranteeing that it understands what you asked, understanding the screenshot. It's having-- It, it's going through all the context of the code. And now, again, the same thing is gonna happen. It's gonna give the implementation. You're gonna ask it to merge it, and then you're gonna see the change on the, uh, Lovable environment. So now it's done. Uh, now it's committing, so it's actually already knowing what to do because it adapts to your, uh, to, to, to the way you worked. And we're just gonna ask it, "Is this merged?" Because I wanna make sure that this is on GitHub. If it's not on GitHub, you won't see it on Lovable. So I can even ask stuff. By the way, one of the most interesting hacks for non-technical people is the interactions with Claude Code, they don't need to be just, "I need this implemented, implement." It can actually be a conversation that you would have with a chat of Claude. The same way. Yes, it's consuming tokens, but you can ask questions. You can actually ask Claude Code to ask you questions so that you can improve the requirements, do things differently. I mean, all of that is actually, um, a, a great way of working. You can see it as interacting with your lead engineer or your, uh, engineer on your squad. You do the same. You can treat it the same way. So it's asking me, "Do you want to merge it?" I say, "Yes." So let's actually push this so we see the evolution on Lovable. So now I'm gonna pass the recording to Lovable, and you'll see what happens.

   9. AGAakash Gupta25:18

      So for a non-technical PM, they might be intimidated by merge and branch and pull request, so here's the simplest explanation. There is a main branch, and what you typically do when you're working on coding something is you'll go out and you'll create your own branch off the main. And once you're happy with it, then you'll submit a pull request, and somebody will usually review it, and that'll merge that back into the main branch. That's like the basics. I'm oversimplifying it. So what we're doing here is we're kind of skipping the pull request review phase, which is usually-

   10. AAAndre Albuquerque25:55

       Yep

   11. AGAakash Gupta25:55

       ... what engineers do because we're just vibe coding this on our own really quick, and we're just merging it to main.

   12. AAAndre Albuquerque25:59

       Yeah, 100%. Uh, keep in mind, we started with personal projects. The moment you go into your company and your squad, you'll be adapting yourself to the development process and the pipeline, meaning the way the engineering team works together, and you'll be able to integrate that the moment you're comfortable and they're comfortable, and you'll gain a lot more knowledge about everything Aakash just explained, that you explained. Um, so for now, I mean, you don't need to be afraid of this because you don't even need to know that-- these terms. You can just ask it, "Look, I don't know what to do. Just put this live or just add this to my, uh, code or code base." Claude Code will actually know what it means. So now let's see if this has landed. So we're now back to Lovable, and you can already see that the redesigned hero header, which was the feature I just asked, is already here. So it's already showing automatically. I didn't need to do anything. And Lovable takes a bit of time to update, but we already know the code is here, so we should be seeing the header change. I don't, don't think it changed yet. So we'll wait for a few seconds and eventually, uh, there is a change in the header. Okay, now we're seeing Lovable loading a new experience with the code that we just developed on Claude Code, and it completely changed everything. Again, I didn't give any specifications. I just said different, and it did. It's significantly different. And now to finalize this, as I said, even though you push that code, if you're using Lovable as your infrastructure, you still need to publish the app, right? So what happens is you're gonna click Publish, you're gonna click Continue. You're gonna say, "Oh, is this a public link or is this just for you?" Let's just say that you are e-either the free or the lowest tier, so you can actually do this. So we'll say, "This is public. I want people to be able to access it." And you can just actually say yes, yes, yes to all of this. If you are looking to do a commercial application, then I'd recommend you working on this. Otherwise, you can just continue and boom, your app is gonna be live. So you just publish this, which means that this URL, people can access it. Now, very important here. When you do changes on Claude Code and you push them, they'll update here on Lovable, and you need to publish it to update the public link. While you don't publish, Lovable works like a preview. You can see the link, so you click on this, and you'll see that this opens up a preview link. This preview link is your way of QAing outside, so doing quality assurance or testing outside the Lovable interface. You can actually see how it works on mobile, how it works on a browser. You can send the preview link to someone. SoThis is

8. 28:37 – 31:02

   Level 3 - Cursor + Vercel for real production

   1. AAAndre Albuquerque28:37

      a way of using Lovable as infrastructure.

   2. AGAakash Gupta28:39

      Love it. So that's level two. Level one, Lovable. Level two, Lovable plus Claude Code via that GitHub integration that we just walked you through. What's level three? Show us that.

   3. AAAndre Albuquerque28:50

      So level three. Level three for me is I got off Lovable, right? Because I wanted to start working faster, and typically to work faster, you need to have branches. So now we're gonna get a bit more technical. The moment you start playing with repositories and Claude Code and Lovable, you start-- If you're curious, you start understanding a bit more of things. And you don't need to be as technical as your most senior engineer, not even close. But you start learning a bit about branches, and you start learning about merging to main, and you start learning a bit about worktrees. And the moment you start playing with Claude Code, you'll see yourself very quickly wanting to work with multiple sessions at the same time. What that means is that you're gonna start building multiple features at the same time, right? So that means you need to have an infrastructure that allows you to work well, safely, with multiple branches at the same time, that when you branch, you can deal with conflicts, that basically you can see stuff in a rela- reliable environment, right? For that, that means I transition from Lovable as my infrastructure, and by the way, Lovable isn't supposed to be an infra product, I just use it that way, to Vercel, which is way more known as the typical way of working. So what happens is you set up your Vercel product, right? Uh, so I'm gonna, I'm gonna share my own. So I'll actually share the Builders Camp one so you can see how it actually works. And in my case as well, you can then decide one of two things. You can keep on Claude Code desktop app, uh, or you can start using an IDE. Let's say that you like to go into the files themselves. You like to see the code. You want to explore. In my case, I like to use Cursor, but I use Cursor with Claude Code. That means I have the Claude Code extension inside Cursor, and I'm using Claude Code basically, not the Cursor agents or anything. But I use Cursor as my IDE. I get access to the files, to the code, if I want. I don't need to, but I like it. Uh, in my case, personally, uh, and I think this is gonna be a bit of a, uh, spaces versus tabs in engineering, which is, like, in Cursor, and I can actually show you my Cursor, uh, the Claude Code. So I'm gonna

9. 31:02 – 33:22

   Ads

   1. AAAndre Albuquerque31:02

      share my screen.

   2. AGAakash Gupta31:03

      Here's the dirty secret about prototyping. You spend two weeks building a prototype. You validate your assumptions. Engineering loves the direction. Then what happens? You throw the whole thing away. Bolt changes this completely. When you prototype in Bolt, you're not building throwaway mock-up. You're building real front-end code that integrates with your existing design system. So when you hand it to engineering, they don't throw it away. They ship on top of what you've built. I use Bolt every single day. I host my LAN PM job cohort on it, and honestly, I'm up till two AM some days just vibing in the tool, having fun, and building. That's when you know a product is good, when you're using it past midnight, not because you need to, but because you want to. Check out Bolt at bolt.new. Link in the show notes. I'm notoriously bad at my inboxes. I guess there's a version of that where I seem cool and unavailable, but the reality is I miss sponsor emails, guest pitches, and stuff that my team actually needs me for. So I got an AI assistant, the sponsor of today's episode, Ariso. Ariso connects to my email, calendar, and Slack. Then I just chat with it over Slack, and it helps me with everything. It builds workflows to respond to emails, resolve customer issues, prep me for meetings. It actually comes to my meetings, updates its own knowledge, and remembers context from past conversations. So every time I talk to it, it already knows what I'm working on. I used to pay for Granola and Lindy separately. Ariso replaced both. One tool does more, and it lives right in Slack where I already work. Check it out at ariso.ai/aakash. That's A-R-I-S-O.A-I/A-A-K-A-S-H. I hope you're enjoying today's episode. Are you interested in becoming an AI product manager, making hundreds of thousands of dollars more, joining OpenAI and Anthropic? Then you might wanna do a course that I've taken myself, the AI PM certificate ran by OpenAI Product Leader Miqdad Jaffer. If you use my code and my link, you get a special discount on this course. It is a course that I highly recommend. We have done a lot of collaborations together on things like AI product strategy. So check out our newsletter articles if you want to see the quality of the type of thinking you'll get. One of my frequent collaborators, Pavel Hern, is the Build Labs leader, so you're gonna live build an AI product with Pavel's feedback if you take this AI PM certificate. So be sure to check that out. Be sure to use my code and my link in order to get a special discount. And now back into today's episode.

   3. AAAndre Albuquerque33:21

      Uh,

10. 33:22 – 35:40

    Why Andre prefers Cursor over Claude Code desktop

    1. AAAndre Albuquerque33:22

       Claude Code shows as tabs, right? So you should see... So you see all my tabs are up here, and I'll actually dive deep into this in a few minutes. Uh, while in the Claude Code desktop app, so I'm gonna share my screen back to the Claude Code desktop app. They show as... Sh- they show differently. So as you can see, they're here, right? And in my opinion, I don't know why, again, I think this is something more personal, uh, I prefer the, uh, vertical, uh, view. So Cursor became comfortable for me, but I think every single person will find their own comfort, all right? Uh, and again, I'm not technical. It's not like I can write the code directly into the files. I'm not doing that. But I just find some comfort. And what you'll see is that when you're non-technical working on some technical stuff, you want to find the comfort areas, right? It's gonna make you feel less fear and be more focused on, on doing stuff, okay? So let's go into Vercel. So as you can see, this is my Vercel environment. And now this looks a bit scary if it's the first time you're seeing something like Vercel. Um, and on the overview, you can see, like, my product. This is Builders Camp webpage, so website. Uh, and on the deployments, what you see are all the features that I'm building, right? These are all features that I've been building in the lastHours, you can see the hours, right?

    2. AGAakash Gupta34:44

       Wow.

    3. AAAndre Albuquerque34:44

       So busy day. Um, in every single one of these lines, what it basically is, is a branch. And inside a branch, you can have a feature, a change, or you can have multiple changes that were maybe bundled into a single branch. And what is happening here is that every single one of these is showing you a change in the website that is not yet public. What's happening is it's saying, "Look, you just built this, and now you can test it." All right? And the good thing about Vercel is it also gives you a preview link where your changes to the code are basically here, and you can experiment, see how it's working, if you, if it goes in line with your requirements. And then you can say, "All right, it's all good. Let's merge this. Let's get this into production," which is, "Let's put this on main." Right?

    4. AGAakash Gupta35:34

       So if I'm a non-technical PM, I'm a little confused right now. Vercel kind of seems similar to Lovable.

11. 35:40 – 41:17

    Mental model: Lovable vs Cursor vs Vercel

    1. AGAakash Gupta35:40

       Can you just clearly help me in my mind understand Lovable is X, Claude Code is Y, Vercel is Z. What are these exactly?

    2. AAAndre Albuquerque35:47

       Yeah. So important to say that I'm using Lovable in the most atypical way possible, because Lovable is a AI IDE, meaning you build projects on Lovable. That's its goal. Vercel also has that, which is called v0, but what I'm showing you is the infrastructure version, and this is, I'm sim- oversimplifying on purpose, is the infrastructure of Vercel for the applications and the projects. So what I'm showing here is basically you have your place where you code, let's say it's Claude Code. And then you have the place where the code lives, which is GitHub. And then you have Vercel, which is your bridge between your GitHub, your repository, and users, right? You need to have this connection, the bridge. And what you're doing is you're pushing the code from Claude Code to your repository, and then you're telling, "Look, Vercel, now make the code I just created available to users." That's basically it. All right?

    3. AGAakash Gupta36:47

       So basically, Lovable has some of this infrastructure hosting databases built into its product, so it's a little bit more easy to use. Now we're uncovering one layer. We're showing you one more layer. Even Vercel is a bunch of abstractions built upon a bunch of stuff.

    4. AAAndre Albuquerque37:04

       Exactly.

    5. AGAakash Gupta37:04

       But we're basically showing you how you go from GitHub to users.

    6. AAAndre Albuquerque37:08

       Exactly. Exactly. And by the way, one of the most important things when you're non-technical is you don't really have the time or ability to really deeply understand every technical aspect. You just want to be pragmatic and just make stuff work. That's what I did with Lovable in my beginning, and probably this is what I'm doing with Vercel as well, if I'd compare my usage with technical folks. It has absolutely nothing to do with that, but it works for me, and that's what you're looking for. That is the best skill you can develop right now as a non-technical PM who wants to start building. So I'm now gonna show you my Cursor and how I'm using Cursor to develop, which is the next level, which is like, okay, you're using Claude Code or you're using Cursor with Claude Code. So I'm gonna switch to-

    7. AGAakash Gupta37:53

       So we keep layering on the complexity for you guys. We had Claude Code desktop app plus Vercel. Now we're doing Claude Code inside Cursor plus Vercel. And Andre gave you a couple reasons why he likes Cursor, the vertical visual tabs. I would add in, like, at least two more reasons why you might wanna use Cursor. Number one, Cursor has a very, very generous free plan, so you can use their agents to debug issues that you have with Claude Code. [chuckles] Let's say Claude Code isn't spinning up and you're unable to sign into Claude Code. You're just stuck at step zero. You open up a Cursor agent, which you can do in this top right there. You see this, like, button up there in the top right to open up a Cursor agent, or you can go to the top and hit New Agent. And then you can literally paste in whatever issue. There, Andre's p- opened it up. You can paste in whatever issue you're getting, like, "Hey, I'm unable to turn on Claude Code," or whatever, and the free Cursor agent will help you debug any issues. So that's reason one I recommend you guys use Cursor. Reason two is what Andre mentioned around GitHub. Cursor is really good at syncing up with GitHub. Once you log into GitHub once, everything, all the projects you open up in Cursor with Claude Code will automatically be linked up to your GitHub. So this is the next level. Start using Claude Code inside Cursor.

    8. AAAndre Albuquerque39:15

       So on this level, as you can see, what you're seeing here on top are multiple sessions. And for me, a session is, I have a, an epic. Let's say you work in product and you work with epics. Or you can even say they're stories, but my sessions are at epic level, which means inside an epic, there's, like, multiple features, right? So when I open up or spin up a, a new session, I'm gonna say, "Look, I wanna tackle a specific epic. I wanna work on this. Uh, let's see how we can implement this." And Claude Code is gonna basically do the code for you. You're gonna interact with it. I'll show you a couple examples. And the moment that you're ready, you're gonna say, "Let's, let's deploy this," or, "Let's merge this," or, "Let's open up pull request," as Aakash explained, and it's gonna show up as a branch, as a new line on Vercel that you can test. And the moment you're happy, you can just come back to the same session and you can say, "All right. Everything worked. I QA'd, I saw everything I needed to see. It's working. Let's merge this to main," meaning let's put this on the live, uh, branch, the, the main branch, and users can now access it. All right? So this is, like, level three, which is you are using Claude Code, you're inside the IDE, you're pushing this to a Vercel or an infrastructure. You're being able to run multiple branches. As you can see here, the yellow line is a branch that is outside the purple line, which is your main, which is your, uh, the, the-Branch that people are using. And eventually I merge it, meaning they combine, which means the features that I worked on the yellow line are now available on the, uh, purple one. And again, the visual part of Cursor is, is nice for non-technical people because it makes it very simple for you to understand what's happening. Now, you don't need to understand Git and how branches work and whatnot. You don't need to be very technical there because the visual explains you what's happening, right? So that's level three. The last level, or level four, is

12. 41:17 – 42:50

    Level 4 - Agents, skills, and CLAUDE.md

    1. AAAndre Albuquerque41:17

       agents and having agents and skills and creating your own process. I think that is the last level. It allows you to actually run multiple sessions in parallel, working on multiple projects at the same time, uh, being able to actually ship very large epics in parallel, uh, without actually creating problems for your product, and even experiment on Vercel with different approaches. So I, I'd say that is the last level, uh, that we can get to.

    2. AGAakash Gupta41:44

       All right, agents, how do I build those?

    3. AAAndre Albuquerque41:45

       Okay, so the, the-- this fourth level, the agents, uh, the most interesting thing is-- or, or actually let's, let's say it like this. The biggest fear a lot of people have is like, oh, vibe coded code is bad code. Or when you're building with agents or vibe coding, uh, they're gonna do, like, they're gonna create a lot of complexity, a lot of lines of code. And thinking like this is not wrong. Like, it happens to a lot of people. Especially when you're non-technical, you don't know what you're asking, it's very easy with very simple prompts to be creating a lot of slop or a lot of trash. That's where a good agent infrastructure can help you. So I wanna show you what I have. And by the way, I wanna show you also what I bring to my team. So what I did was I built my own repository of agents, of skills, and even my Claude's MD, which is the memory or the culture. I like to call it the values of my Claude or the interactions I have with him. And this is basically what allows me to work very freely without being super considerate about the rules or about what I need to care about when I'm talking with Claude

13. 42:50 – 45:24

    The CLAUDE.md memory file explained

    1. AAAndre Albuquerque42:50

       Code, because I know the agents and the skills in my claude.md will take care of that for me. So let me dive a bit deeper because this is what I call level four because it frees you time. It gives you time to focus on what you should be focusing, which is, am I solving the right problem? Do I understand the problem well enough? Do I have all the requirements? Have I talked with all the people? Like, if you're spending time on solution design, you're not gonna be spending enough time on problem discovery. And we all know that the best product managers out there, they spend more time on problem discovery, right? But you need to create your infrastructure, I call it the machine that builds the machine, to be able to spend that time there. And this is my machine. So we have claude.md, which again is your values. I'm gonna go deep into mine in a few minutes. But I also have my agents and I have my skills. So let's start with my Claude MD. So as you can see, Claude MD is something that exists inside your Claude Code. Uh, and every time you ask Claude something, on the background, you don't see this, but on the background, they're gonna be reading this. And that means that all the rules, everything you decide to put here, they're gonna use it to define their own way of working. It's like when you're inside a squad, a team, and you tell them, "Look, this is how we work. These are the things we care about," et cetera. You know that your team is gonna be thinking about that as they make decisions or as they work. Claude MD works exactly the same. So in my case, I have a default behavior, I have rules, so this is how I see it working. I have then agent strategy, I'll explain that in a minute. And I have architecture, I have specific things that happen depending on the feature that I'm asking. So all of these rules are here. I'm happy to make this available, uh, on the show notes or to, to send on, uh, on, on the podcast. But basically, this is the memory, these are the rules, and these are the values that we care. Very important. As you're working and you see that you're doing things repetitively or that Claude is doing stuff that you don't like, you can actually improve your Claude MD. You can say to Claude, "Look, I don't like this," or, "I'm repeating this. Can you please add to Claude MD so that the next time it already knows what to do and how to do it and you don't need to keep getting that error, that issue, or something you don't like?" Right? So this is like part number one. And you can see this can become super complex. You don't need. Mine is significantly less complex than Claude MDs that I've seen a lot of people, but it works well. Now, it works well because of my agents. So let me go to the agents because I have a very specific agent that I use a lot,

14. 45:24 – 53:26

    The PM orchestrator agent pattern

    1. AAAndre Albuquerque45:24

       and this is called what I call the PM agent. So this agent, which uses the agent infrastructure of Claude, is my product manager. I have a personal product manager inside Claude, and it's specifically an orchestrator. Now the PM, which is a PM MD, uh, is not gonna be building stuff. It's only gonna take information and deciding which other agents to call because they're gonna be better at doing something, right? So as you can see, I explain very specifically what the product manager orchestrator is, what they do. I even say never do the work yourself because there's gonna be some agent better than you. You're simply orchestrating, meaning you're deciding who does what, who you go to, et cetera, which honestly is a bit the work of a PM, right? And then this PM agent-

    2. AGAakash Gupta46:11

       What if I'm lost right now? What exactly am I seeing here? I'm a non-technical PM.

    3. AAAndre Albuquerque46:16

       Yeah.

    4. AGAakash Gupta46:16

       I've never used Claude Code.

    5. AAAndre Albuquerque46:18

       Yeah.

    6. AGAakash Gupta46:18

       You just showed me Claude MD-

    7. AAAndre Albuquerque46:20

       Yeah

    8. AGAakash Gupta46:20

       ... which seemed pretty complex, and now you're in the agents folder, PM. What exactly are these agents? Who is this? Does this mean that you're gonna spin up a new Claude instance every time this agent is called? Is this agent gonna be proactive? Help me understand what this agent is.

    9. AAAndre Albuquerque46:34

       Yes. All right. So every time you spin a new session, your claude.md is loaded, right? And everything that you have inside that folder, the Claude folder, which includes your agents and your skills, they're also there. So they always exist whenever you spin up a new session, when you start a new session. When you ask something to Claude, the one thing that Claude always goes to is the claude.md, right? It doesn't go anywhere else. It doesn't go to the skills unless you call them. It doesn't go to the agents unless you call them specifically. It goes specifically to Claude MD. Now, on my Claude MD, I have a veryImportant rule. Rule number one. For every task, call the PM agent. So it's like, let's say that you're the CEO, and the first thing you're gonna do is if you're the CEO is you go to the PM and you say, "I'm the CEO. We found a new opportunity. Please work on this new opportunity." You're kind of doing the same, but in this case, instead of you having a team, you have agents. So-

    10. AGAakash Gupta47:31

        Got it

    11. AAAndre Albuquerque47:31

        ... it's gonna call the agent, which is a PM MD. And then the PM MD-

    12. AGAakash Gupta47:35

        It's not proactive but-

    13. AAAndre Albuquerque47:36

        So-

    14. AGAakash Gupta47:36

        Because we've architected our Claude MD in this way that says, "Always call the PM agent," Claude MD is always loaded, so then it goes to the PM agent, and then it gets called.

    15. AAAndre Albuquerque47:47

        Exactly. Exactly. And then the PM agent is gonna decide which other agents are actually gonna do the work, right? And we have multiple agents here. As you can see here, you have a researcher, which does what user research typically does in the team. We have discovery, which is a very specific agent, and I'll go a bit deeper here because it's a very interesting one. Uh, we have a designer, which is very knowledgeable about design system, about best practices of UX. We have an engineer, which is an agent that is preventing my code from being a bad code or ideally being a bad code. Uh, we have an implementer, which is the final person who's gonna actually write the code and implement stuff. So these are just a few examples. One recommendation I give to people is don't try to reinvent the wheel. Try to see how you actually work with your teams and try to represent them as agents. Like how they work, what they care about, how they decide. Write that down and make them the agents, right? That's one of the best recommendation. One of the worst things you could do is go on X or go on LinkedIn and see all of those skills from really famous people who have very specific ways of working and then just loading hundreds of those skills that you don't even know they exist and you're not thinking in first principles. You can learn from them. There's great content. But dive deep into which skills make sense to you, which ones could fit your, uh, flow, and then only adopt those or ideally write your own based on what you're exploring and seeing, right? So this is what my PM MD is basically doing. Let me actually show this working in, in a production environment. So now we are on a cursor with Claude Code, right? And we have a feature, right? And whenever I ask for a feature, what it's gonna do is gonna run my Claude MD on the background, and my Claude MD already knows that they need to call the PM. I don't need to call the PM. I just need to say what I want it to do, right? And as I built this infrastructure, they are solving the problems that I don't need to care about. I only need to care about the, the feature, the problem I'm solving, the requirements I raised, like the typical thing you do as a PM, which is great because you just built your team. And I, I asked this feature, right? And let's see. I got an answer. Like, I'm not gonna give you the whole context of the feature, but I got an answer from the engineer. The engineer found some things inside the codebase and gave me some recommendations, right? And it's telling me specific things so that I'm aware. I don't need to understand everything that's here. I mean, you can if you spend a bit of time. I understand it, but, um, it tells me this is my recommendation. I'm actually gonna go up because I want you to see an example where multiple, uh, multiple agents are being called. Okay, so perfect. We have this example. So I asked for a specific feature, but I wasn't sure about the design. So what the PM decided was, all right, the-- myself, me, Andre, is not sure about the design. I'm gonna call the designer agent. So the designer agent does a brief. This is an answer, right? And it has a summary of the designer's decisions. So it talks about a specific layout. It talks about the code because it also has, uh, understanding of the code. It talks about visual expe-- uh, experiences. It gives recommendations and even asks me questions. Uh, and these are questions before the engineer agent writes the code or writes the architecture. So it's asking me stuff so that I can answer or make decisions so that the next agent can start working on it. And the beauty about this is that even if you're not technical, which is the case, you're answering as if your own engineer or your own designer in a team, in, in a team meeting with you would be asking you the same questions. And the fact that you're giving them the information, it prevents your code from being worse. It prevents features from being wrongly built or adding functionality that your product doesn't actually need. And this is the level four, which is like you're starting to build a machine that then is gonna build a product for you. And you can focus a lot more on problem framing, on understanding what to build, what makes sense, what priorities, because you have the team. Now, I have a final recommendation here, uh, which is when you're building something, let's say you build a functionality, you have this flow going, and you get to your branch after building something and you don't like what happened. You don't like the flow or you don't like the design or you don't like the decisions. Your instinct would be, "Oh, I'm gonna just say to Claude, 'Fix these things on the feature so that it's great,' and then you can push this and make it live for your users." That's actually not the right mindset. The right mindset is what within the flow, the pipeline, your agents and your skills failed and led to a bad result? You identify that, and you change the agent or change the skill or change your Claude MD. Why? Because the next time you're gonna have a feature, you don't want that to happen again. So you just improve the machine so that in the future it becomes way easier for you to just, again, focus on the problem, ask your team, ask your agents, and then ship the feature better. I even do something else, which is if I don't like a feature I just created, I change the machine and I ask it to build it again.Run the pipeline again and see if the final result is closer or is exactly what I actually want. This is what AI-native teams are doing, is they're working 50% of the time on improving the infrastructure of the machine itself rather than just tweaking feature by feature, right? So if you actually

15. 53:26 – 1:01:33

    How AI-native teams spend 50% of their time

    1. AAAndre Albuquerque53:26

       now see a, a AI-native team, what you'll see is like you can have like two or three people. You can still have the typical trio, like a product manager, engineer, a designer, but they're all builders, meaning that they're all shipping code, they're all building features. But then a percentage of their time is improving the agents or the skills with their own knowledge. So the engineer is gonna be improving the engineer agents and the engineer skills inside the infrastructure. The designer is gonna be improving the designer agent, the designer skills, and even the PM is improving the PM orchestrator skills and agent so that then every single one of them, when they build, they all have access to this infrastructure, and it's all becoming better over time with their own ways of building. So now you have three builders, you have an infrastructure supporting them, and you have a triple acceleration of what you can build. This is how you see small teams in AI-native companies shipping so fast with so few people.

    2. AGAakash Gupta54:24

       And it sounds like the connective layer is that team Claude config that you showed because the engineer will be updating the engineer MD and what it's using there. The design member will be updating the design MD. The PM will be updating the PM, and they all are connected into that team Claude config. Is that right?

    3. AAAndre Albuquerque54:41

       Yeah, 100%. Everyone's gonna be, uh, connected to that. In my case, for example, I create this repository with my skills, and every time I make a change, I push it there, and my team gets a notification on Slack saying, "Hey, uh, there was an update on the team's repository of skills. Please upload or download or clone it again or update your own so that you're up to date and you're using the best ones." And then you can choose which ones to use, of course, but at least you're creating standards. Now, if your company's bigger, you might even have a whole team, an AI ops team or R&D team just building this for everyone else. But if you're in a small team and those are the teams who need to accelerate more, you definitely want to invest or put time, uh, on, on that specific topic.

    4. AGAakash Gupta55:25

       One of the things you wrote about on LinkedIn that relates to all of this that we've just shown people is that there are now only four jobs. Can you explain this and what the future really looks like of these roles?

    5. AAAndre Albuquerque55:35

       Yeah. So I love this post. Uh, it wasn't me originally writing it. I liked to comment on it. But, um, this is completely true every time you look to a new startup. Like I worked for a while in VC investing in early stage, and those early stage teams, they're super small, so they're gonna be very pragmatic. And you're gonna have maybe three founders, and you have typically one founder which is significantly more commercial. You have one founder who's significantly more technical, and you have typically one founder who's significantly more product-oriented, right? This is what happens. And if you think about these four roles, it's what those founders look like in their inception, right? You have the commercial one, which is the hot one, which is basically guaranteeing that sales are done, marketing happens, you're getting the word out. Uh, you have the product person who's basically guaranteeing that something gets built. Now they have the ability to actually build it, right? And yeah, they're gonna be vibe coding and slopping and doing a lot of stuff because in the beginning when you're trying to find product market fit, who cares if you're doing too much stuff? You're trying to get shots at the target. And then, of course, your technical person is gonna be the person trying to guarantee that what gets done has the right scalability, is reliable, it's built the right way, et cetera, et cetera, so that when you grow the team, uh, when people join. So it's not that different from this reality, but now applied to multiple teams. So you can easily see a, a full stack squad that is an owner, that owns a P&L, owns a, a, an impact, owns an outcome, and has this stack. And the beauty about this, and I wanna highlight specifically the security or SRE or infra, because the moment you create a great infrastructure that allows a non-technical person to actually code with AI to a production repository, it doesn't matter if that person is not technical anymore because what matters is the infra or security person is doing a great job at protecting the repository. And protection here doesn't mean prevent the code. It means new code that comes in needs to go through a bunch of checks to guarantee that when it goes into production, it's safe. This is literally the same thing a senior engineer does when a junior engineer out of school joins a organization of software developers, right? It's not new. The difference is now the junior engineer is a non-technical person using AI to vibe code a new functionality. And I see a lot of people making a fuss out of this, but this is a known reality, and I think a lot of teams are gonna be transitioning this way because the velocity to ship is crazy different.

    6. AGAakash Gupta58:12

       What's the flip side to this velocity, though? And you even have the word slop here.

    7. AAAndre Albuquerque58:17

       Yeah.

    8. AGAakash Gupta58:17

       How do you avoid shipping slop? How do you avoid, you know, famously like the Claude team shipped like this, but they have bad uptime. How do you avoid those issues?

    9. AAAndre Albuquerque58:26

       Yeah. I mean, again, the, the more you invest in infra and security, the more likely are you to prevent situations like that because you create friction, right? The friction here is not preventing people from building. It's, is this passing all the checks so that when it goes live, it's not creating more risk or more problems? That's number one. Number two, the friction you create on the problem, on the problem side or-- and this is where product people investing in infrastructure should, uh, be putting their time. Because, for example, I have three skills that whenever I run an Epic, I have a jobs to be done skill. I have an opportunity solution tree based on Teresa Torres' amazing book, and I have a Moscow skill which goes for the must, should, could, and won't, uh, prioritization technique. And what it does is like it creates three Notion pages on that requirements, on that PRD that explores those three frameworks. And what I'm actually doing is I want people to read through them and seeIs this making sense? Like, have we dedicated enough time? Can we check and go to the next phase of solution building? And until that document or that memo or that addition to the PRD, which is built by the skills with Claude Code, is completely thought through, like, I don't want people building the solutions. But then that becomes part of the initial process, right? And it's not just PMs or non-technical PMs doing that. Engineers do that, designers do that, because we're all builders, and it completely changes the, what you decide to build. And that's the two ways you prevent slop, in the beginning and the end. And I want to highlight something really important here, which is, um, one of the things that decelerates people, teams, companies the most is collaboration. And this sounds contrarian, which is like the fact that you have people having to collaborate, it's what slows everything down. Now, if you look at the development process in three stages, ideation or discovery, stage one; execution, stage two; and delivery or enablement, stage three. Collaboration should be happening in the beginning and in the end, meaning you get people together deciding, working on problem, et cetera. And in the end, you get people actually having the product in their hands and helping push it to the market, push it to commercial. But in reality, what's happening is collaboration's happening on the execution, right? It's happening on dependencies. It's happening on I do this, you do that, et cetera, and it slows everything down. And then in the beginning and the end, there's no collaboration. Only PMs are in the decision. Only, like, engineers are delivering, and it, it's completely flipped up. And when you start changing this, you see acceleration deeply because then people work a lot on collabor- they collaborate a lot on decision-making. And then every single person, people, teams of one can execute by themselves, and then they come back in the end and collaborate on like, "Does this make sense? Can we merge this? Is this working with the product?" And we together deliver the product to the user. I think this completely changes the, uh, completely flips. But if we, this happens, we reduce a lot of slop and we accelerate teams a lot.

    10. AGAakash Gupta1:01:29

        You caught my eye a couple months ago when you made this LinkedIn post about

16. 1:01:33 – 1:07:45

    Why 90% of European PMs are still non-technical

    1. AGAakash Gupta1:01:33

       90% of European PMs being non-technical. Talk to me a little bit about the differences between PMs in Europe and the United States and the implications for adopting AI tools.

    2. AAAndre Albuquerque1:01:43

       Yeah. So, uh, even though I'm not 100% sure of the number of, if it's 90%, if it's 99 or if it's something in between, it's going to be a pretty, pretty high number. You got to see the, the product culture in Europe is very different. If you go to a lot of European companies, you're going to see a large number of POs, of product owners, something that you very rarely see in the US or even in the Asia market. Uh, and the product owner culture in, in Europe, it focuses a lot on a bit of a glorified delivery manager without the actual technical skills. You're, in a certain sense, you're paper shuffling between someone defining strategy or roadmap or listening to customers and then the engineering and the design team on the other side, and you're kind of in the middle. You're trying to do a great translation work. You're possibly trying to do a bit of a project management work within these teams. But unfortunately, your hands are a bit tied by this product culture. And, um, yeah, I think this is one of the biggest problems we see in a lot of tech or software development in Europe is that the people who are talented, who are smart, and who should be able to actually drive a lot of decisions are not being able to drive them.

    3. AGAakash Gupta1:03:04

       So if the system is broken, what's a move for a PM in this environment? Go work for a multinational company, or how do they get out of it?

    4. AAAndre Albuquerque1:03:11

       I think it has to do a lot with, uh, your personal energy because, I mean, I don't think you should move because that's your reality. I think if you have the energy, you should try to fight to make it a better reality. Uh, I, I truly believe, like, a lot of this is ingrained in, in management, right? Like, maybe the managers, the product leaders, they haven't seen any other way, so they're kind of trickling down that format. But you just need to spend a bit of time in a US company, for example, or seeing how they build, and you see it's, it's very different, right? So if you have the energy, you should definitely try to influence, uh, how product is built, uh, create that small pocket of, of experimentation, of doing things differently. Because it's not just good for you to actually gain the scope of product management and kind of leave behind the product owner. It's also good to the team, and specifically because one thing I notice in a lot of companies that I work with is that when you have a product owner, what the team is, well, unconsciously or consciously seeing is that that person alone owns the product. And that's actually not true because the entire team, the entire squad at least, should be owners of the product. But they're not because the title says that person is the owner of the product, which is a lie. And you, at the same time, again, unconsciously or not, you feel like you're the owner of the product, which makes you an, again, a leader where you're not, or at least a manager where you're not. And again, the title is, is breaking all of this. And you end up seeing in a lot of European organizations squads or teams or pods which are completely disempowered, and they don't like that. They, they, engineering teams are not participating in decision-making. They're not part of the ideation. They're not part of the discovery. Often you don't see the design teams participating in the final delivery and actually bringing the product to the customer, and it feels like the teams are all siloed. And in my opinion, it actually starts with the fact that there is a product owner rather than a team feeling owner of the product.

    5. AGAakash Gupta1:05:12

       So what is the answer here? How do, how can PMs start to build more themselves?

    6. AAAndre Albuquerque1:05:17

       First of all, I think you need to understand that that is not... the reality that you should be aiming for. Like, there's other ways to do. That's the first thing. I had a manager who once told me that to cook great food, you have to have had great food. Uh, so you need to understand that there is great food out there. Like, there are other ways, better ways of building product. Number two is get some coaching or get some mentorship from people who are maybe inside companies who are building this way, and spend a bit of time, if you can, spend a bit of time asking them, like, "How does it work? What am I supposed to do? How can you do this?" Like, my own program and when you read content online, content that you post, you see how other people think and how they build and how they interact with their teams, how they set up their own design. So start there. Start by understanding what great food looks like so you can start cooking it internally. Number two is you want to start getting that rapport with your manager, getting that rapport with the product culture within the organization, and start understanding where you see a gap to start changing the way you operate. And number three, you want to start getting allies with your team, meaning your engineering team, your design team, your AI team, and kind of explaining to them, "Look, we don't want you to be in the end of the line. We actually want you to participate in every single point of the development process, both from decision to ideation, to, uh, to, to the discovery, to the last delivery and the go-to-market and the enablement. Like, we want a team to be an owner of the entire process." So start with this, and even if you already have a roadmap, you have a track, and your manager has expectations because you have milestones, you have a roadmap to deliver, start trying to find some things in the roadmap that you can just try to manage differently within the team. You don't need to completely change the way you work from one day to the other. You can start small as an experiment and try to do things differently. Now, that means that you need to also change a few of the rituals, right? If up to now you have a ritual of discovery or decision-making where maybe a significant part of your team is not in the room, well, start by getting them in the room. Otherwise, they'll never participate, right? If you're doing all the decisions of scope and requirements and design decisions, like, that is already a problem. Like, other people should participate or even have ownership of, of that process. So I think making these small changes is definitely step number one.

    7. AGAakash Gupta1:07:38

       Wow. So much ground we covered here today. What's the thing a PM should go do on Monday morning?

17. 1:07:45 – 1:09:07

    The Monday morning move

    1. AGAakash Gupta1:07:45

       What's the Monday morning roadmap to becoming a builder PM?

    2. AAAndre Albuquerque1:07:48

       Okay, so th-this is ambitious. Let's say it depends a lot on your team. But if I was getting started on this and I went through the levels and I'm getting to the level, like, three and I'm feeling comfortable, I would definitely go to my engineer, uh, and let's assume you have a GitHub account, and I would ask, "Look, put me as a collaborator of a r- a low-risk repository," meaning even if you can, create a repository for me, like, that is connected to product, uh, a new repository, a new feature, and, and just allow me to just do something. And then go to your backlog. Pick a, a, a feature that has been on the backlog forever. Like, literally sort it by oldest. Doesn't matter, right? Pick something. Uh, something that you know that is in the bottom of the backlog and it's never gonna get done. Every single PM has a bunch of these.

    3. AGAakash Gupta1:08:37

       [laughs]

    4. AAAndre Albuquerque1:08:37

       And then ask Claude Code with that requirements to build it, right? And you can even push a branch. You're not gonna merge it to production, like the engineers are not gonna let you, but just try to see the magic happening. See the power you just gained by being able to do that as a PM. Right? Now, imagine a reality where every single person in the product squad can do this for the actual backlog. Like, this would be my M-Monday morning, like, I heard this, and this is what I would start doing.

    5. AGAakash Gupta1:09:06

       Amazing.

18. 1:09:07 – 1:10:11

    Outro

    1. AGAakash Gupta1:09:07

       Andre, people loved the episode. They want to learn more. They want to get in touch with you. Where should they go to find you online?

    2. AAAndre Albuquerque1:09:13

       I basically use LinkedIn. Feel free to connect. And if you want to know more, Builderscamp.com is where we run our boot camps, where we train people to become builders. So that's basically it.

    3. AGAakash Gupta1:09:24

       All right. And I think he even does corporate training, so if you want to get your boss to get Andre to come in, consider him for that as well. Andre, thank you so much for being here.

    4. AAAndre Albuquerque1:09:33

       It was a pleasure, Aakash. Really appreciate the time.

    5. AGAakash Gupta1:09:35

       See you guys in the next episode. I hope you enjoyed that episode. Couple things you can do to support the show. One, comment. Two, review. Those ratings and reviews really help other people understand the value and the production that we are putting into this, right? This wasn't an easy episode to produce. We put in a ton of pre-work. We edited it for you. We brought in the best guests. If you don't mind sharing a rating and review, sharing the episode with others, making sure you are subscribed, that really helps the show do bigger and better productions. I'll see you in the next episode. Here's one of those that YouTube thinks would be a great fit for you.

Episode duration: 1:10:11