← The Growth Podcast
Loading summary
Transcript54 lines
- [00:00]
A
If you look at a lot of companies that have non technical PMs in teams, they're bureaucrats, they're stuck in Jira, linear, PowerPoint, they're dependent on their technical teams.
- [00:10]
B
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.
- [00:18]
A
The product owner culture in Europe, it focuses a lot on a bit of a glorified delivery manager without the actual technical skills.
- [00:26]
B
What's the flip side to this philosophy though? And you even have the word slop here. How do you avoid shipping slop?
- [00:32]
A
The biggest fear a lot of people have is like oh 5 coded bad codes.
- [00:36]
B
Transformation is a big goal. Can you go ahead and show people how they get started with this new way of working?
- [00:41]
A
It has four steps. The first one lovable. The second step a mix of lovable and cloud code. The third step is cloud code and Vercel. And the fourth step is multi cloud code, multi vercel and a lot of automation and agents.
- [00:53]
B
One of the things you wrote about on LinkedIn is that there are now only four jobs. Can you explain this? Before we go any further, do me a favor and check that you are subscribed on YouTube and following on Apple and Spotify podcasts. And if you want to get access to amazing AI tools, check out my bundle where if you become an annual subscriber to my newsletter, you get a full year free of the paid plans of Mobin, Arise, Relay App, Dovetail, Linear Magic Patterns, Deep Sky, Reforge, Build, Descript and Speechify. So be sure to check that out@buildle.akashg.com and now into today's episode. 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 cloud code. Today's episode is nothing like that. We are going to 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 cloud code and finally how you you can use cloud code with tools like Vercel and Cursor to actually ship updates to your code base. There is not an 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 cloud code and we will even give you the Monday morning roadmap to go talk to your engineer. So let's get into it. Andre, welcome to the podcast.
- [02:29]
A
Hi Akash, thank you very much for having me.
- [02:30]
B
So I want to 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.
- [02:40]
A
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 PowerPoint, 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. Maybe the management culture doesn't allow them, maybe they don't have the skills and the tools to be able to do it, but they're basically there 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 repositories and GitHub. You look at the Shopify CEO and his GitHub is fully green. You see entire teams that are maybe it used to be like 10, 20 people and now they're super small teams and they're all actually pushing new features, new codes to production. And I think this is 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.
- [04:16]
B
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?
- [04:27]
A
Yeah. So what I'm going to show you, just to give you context, is how I actually went from I'm not a developer, 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, it doesn't mean it's going to work for everyone, but it gave me a bit of comfort and I'll explain why. So it has basically four steps, right? The first one, and I'm going to address different tools. Again, you might be more of 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 Cloud Cold and Vercell as the infrastructure. And the fourth step is like multi cloud code, multiversal and a lot of automation and agents. All right, so that's how it works. So I'm going to show you and kind of explain what happens with each one. So let's start with 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 a code environment. It's the team at Lovable. First, they're European, so of course I'm going to be a big fan of what they're doing. And second, they built a really easy product for anyone who has never coded, who potentially is a bit afraid to just start doing this is step number one. And you can build 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, 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 going to 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 Loveable 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 code base, 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 Loveable 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 non Technical people, they don't even know they 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 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 always asking your prompts 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, 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, at least back when I was using Lovable, was still a bit limited on a few things. So I installed cloud code, right? And I installed cloud code on the cloud desktop app, right? So you start working with cloud code on the desktop app. Actually, I'm going to switch screens to the desktop app. All right, so you should be seeing Claud code desktop app, right? And you land here. And let's be honest, 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 cloud code to your GitHub. So when you connect your cloud code to your GitHub, they're linked. You can also connect your Lovable to the same cloud code and GitHub repository, so they're all synced. That means that if you actually do code on the cloud 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 cloud Lovable. Sorry, you can use Lovable as your infrastructure. What that means is that you can be pushing code on cloud code with all the flexibility on all the great things that cloud 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 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 deployments because, look, let's say that I am contributing to my loveable project, right?
- [10:17]
B
I used 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 see 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, form 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 step 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 with Amplitude on Lovable.
- [12:12]
A
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 what do you see here on the chat on the left side is Merges, right? What that means is that I'm actually using cloud code to work. I'm merging, meaning I'm sending the code to GitHub and GitHub is telling loveable. 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 going to go there next because Loveball takes care of that. So it's an accidental jobs to be done way of using Loveable that I don't think they intended, but it worked really well and it's a great bridge.
- [13:25]
B
I haven't seen anybody talk about this. So this is new Alpha. This is really exciting information for people. If somebody is just. They need that extra step of you showing them. Can you just show us exactly how to connect Lovable and Claude desktop app to the right GitHub repo? That's the same one.
- [13:43]
A
Yeah. So let me. So I need to do some, some setup. So very quickly, let's say, let's see if I can use one that I already have because yeah, I agree it's something different. So let's see if I can do this. Yeah, so what we can do is let's actually build a small tool or a small product right now. I think that's the step. Okay. But let's also do this. 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 personal one is under my name. So it's here. And this is where I'm going to basically keep all the repositories that are connected to Loveable. 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 going to 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 want to build a new product. Let's say. So I'm going to go to Lovable, and I say I want to build a mentorship. So I'm going to say a mentorship matching tool. Make it simple. So I'm going to build. So what this does is I'm actually bootstrapping the tool on Lovable, which is way easier to start than starting on cloud code if you don't have the infrastructure yet built. So let's assume you don't. So you start on Lovable, you say, I want to build something. So you explain. And then throughout the episode, I'm also going to show you how this gets significantly more advanced without actually you having to know a lot more than what I just did here. So Level 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 connect to Level. But I'll show you how you do this. So now I asked it to be simple, so it doesn't take a long time, but it's still might take a few seconds in. So we want to make sure that just to recap the flow is you have your GitHub repository, you're starting on Lovable, but you also have a cloud 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. You have your cloud code account. All right, so now what I'm going to do. Oh, and it's important to know that you also need to have your cloud code connected. So your GitHub connected to your cloud code while Lovable is building. I'm going to switch the share to my cloud code desktop app. So you should be seeing my cloud 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 going to choose your account, you're going to log in and authenticate, you're going to put your password and it's going to link. What that means is that when you go to cloud code. So if you see here, when you go to cloud code, your repository is going to show here, you'll be able to work on it. Okay. And you can choose your repository. So these are my repositories right now. So what I'm going to do is as I'm going to 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 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 cloud code because you're already okay with working with the tool. So what are you going to do is you want to make sure that you connect this to your. Okay, give me two seconds. Let's say you connect this to your GitHub. Okay? So you should be able to go to GitHub. So git GitHub and you're going to have your account. So I'm going to connect. In this case, I have multiple accounts, so I'm going to connect to my personal account. So I'll connect. What that means is now the code that Lovable built is going to go straight to GitHub. Now, important thing with Lovable, if you create your code on cloud code, send it to GitHub, you won't be able to actually port the code directly into Loveable. It doesn't work that way. You need to start on Loveable. They made the product super simple for that specific use case. All right, so this now created a new repository called Minter Match Simple. So if I actually go to my GitHub and I refresh it, you now see Meter Match simple is here. So now you go to cloud code. Remember up until now we bootstrapped the product on Loveball. We connected to GitHub. I showed you the GitHub page, and since your cloud code, you connected to GitHub, your GitHub via the connectors. Now if you actually are in cloud default and you select the repo, you'll see that now Minter matches here. Okay, so now I know I'm coding to Minter Match. So now whenever I do things here on cloud code, on cloud code desktop app, I'm going to do something. So let's say I want to 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 going to switch to Lovable and as you can see here, the tool is basically beige and red tones theme that is more on this palette and I want to change the setup. I asked Claude code to do a bit more 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 going to 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 cloud 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 life, not the actual plot code merging into that repository. But 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 going to now switch to Claude code to see what is happening there. Okay, so the tool is working and done. It says light theme, replaced orange tones, dark theme. So it basically worked on the background. And now what we're going to do is we're going to ask it to actually 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 going to 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, 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 going to 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 cloud 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 the design system to change. All right, so it's updating, so you already know that something's happening in the background. And by the way, see, this is what happened. So the design system changed. You didn't work on Loveball, 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 header. So I'm actually going to take a screenshot and I just. Screenshot. I don't know if you can see this on the screen, but I took a screenshot and what I'm going to do is I'm actually going to go and paste this on clock code and say, I really don't like the header. So now I'm going to share my cloud code. Keep in mind, you're using this format, which is what I call the bridge, is you're using Loveball as a bit of a QA infrastructure, but you're still using cloud code and everything cloud 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 Loveball 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 Cloud 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. So it's running everything, so guaranteeing that it understands what you asked, understanding the screenshot, it's going to all the context of the code. And now again, the same thing is going to happen. It's going to give the implementation, you're going to ask it to merge it and then you're going to see the change on the lovable environment. So now it's done, now it's committing, so it's actually already knowing what to do because it adapts to the way you work. And we're just going to ask it, is this merged? Because I want to make sure that this is on GitHub. If it's not on GitHub, you won't see it on Loveable. 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 cloud. The same way, yes, it's consuming tokens, but you can ask questions, you can actually ask cloud code to ask you questions so that you can improve the requirements, do things differently. I mean all of that is actually a great way of working. You can see it as interacting with your lead engineer or your 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 going to pass the recording to lovable and you'll see what happens.
- [25:15]
B
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 what engineers do, because we're just vibe coding this on our own really quick and we're just merging it to main.
- [25:56]
A
Yeah, 100%. 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. Akash just explained that you explained. 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 code or code base and cloud 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 redesign 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 Loveball 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 think it changed yet. So we'll wait for a few seconds and eventually 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 cloud 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 Loveball as your infrastructure, you still need to publish the app, right? So what happens is you're going to click Publish. You're going to click continue, going to say, oh, is this a public link or is it just for you? Let's just say that you are 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 and I'd recommend you working on this, otherwise you can just continue and boom, your app is going to 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 cloud 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. So this is a way of using lovable as infrastructure.
- [28:36]
B
Love it. So that's level two, Level one, lovable. Level two lovable plus cloud code via that GitHub integration that we just walked you through. What's level three? Show us that.
- [28:47]
A
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 going to get a bit more technical. The moment you start playing with repositories and cloud code and lovable, 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 domain and you start learning a bit about work trees. And the moment you start playing with cloud code, you'll see yourself very quickly wanting to work with multiple sessions at the same time. What that means is that you, you're going to 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 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? So I'm going to share my own. So I'll actually share the builder's 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 cloud code desktop app or you can start using an idea. 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 cloud 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 in my case personally. And I think this is going to be a bit of a spaces versus Tab in engineering which is like in cursor and I can actually show you my cursor the clock code. So I'm going to share my screen.
- [31:00]
B
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 land PM job cohort on it and honestly I'm up till 2am some days just vibing in the toll, 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 Bold at Bolt New Akash that's b o l t.n e w a K A S H Link in the show Notes 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 want to do a course that I've taken myself. The AIPM certificate ran by OpenAI product leader McDad 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 Hearn is the Build Labs leader. So you're going to live build an AI product with Pavel's feedback if you take this AIPM 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 in to today's episode.
- [32:37]
A
Claude code shows as tabs right? So you should see so you see all my tabs are up here and actually dive deep into this in a few minutes while in the cloud code desktop app. So I'm going to share my screen back to the cloud code desktop app. 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. I prefer the vertical view, so cursor became comfortable for me. But I think every single person will find their own comfort. All right? 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 going to make you feel less fear and be more focused on doing stuff. Okay, so let's go into Vercell. 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. And on the overview you can see like my product, this is builderscamp webpage, so website. 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 last hours. You can see the hours, right? So busy day in every single one of these lines. What it basically is, is a branch and inside a branch you can have a feature 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 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?
- [34:49]
B
So if I'm a non technical pm, I'm a little confused right now. Vercel kind of seems similar to Lovable. Can you just clearly go help me in my mind understand, Lovable is X, cloud code is Y, Vercel is Z. What are these exactly?
- [35:03]
A
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 over simple simplifying 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 cloud 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 cloud 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.
- [36:02]
B
All right, 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. But we're basically showing you how you go from GitHub to.
- [36:23]
A
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 Loveable 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 going to show you my cursor and how I'm using Cursor to develop which is the next level, which is like, okay, you're using cloud code or you're using cursor with cloud code. So I'm going to switch to.
- [37:08]
B
So we keep layering on the complexity for you guys. We had cloud 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 want to 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. Let's say cloud code isn't spinning up and you're unable to. To sign into cloud 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. Andres opened it up. You can paste in whatever issue you're getting, like, hey, I'm unable to turn on cloud 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 cloud code will automatically be linked up to your GitHub. So this is the next level. Start using cloud code inside cursor.
- [38:30]
A
So on this level, as you can see, what you're seeing here on top are multiple sessions. And for me, a session is, is I have an epic. Let's say you work in product and you work with epics, or you can even say there are 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 new session, I'm going to say, look, I want to tackle a specific epic. I want to work on this. Let's see how we can implement this. And cloud code is going to basically do the code for you, you're going to interact with it. I'll show you a couple examples. And the moment that you are ready, you're going to say, let's deploy this, or let's merge this, or let's open a pull request, as Akash explained, and it's going to 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 branch, the main branch, and users can now access it. All right, so this is like level three, which is you are using cloud 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 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 purple one. And again, the visual part of cursor 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 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, being able to actually ship very large epics in parallel without actually creating problems for your product and even experiment on Vercel with different approaches. So I'd say that is the last level that we can get get to.
- [40:59]
B
All right, agents, how do I build those?
- [41:01]
A
Okay, so this fourth level, the agents, the most interesting thing is, or actually, 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, they're going to do like they're going to 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 slow slop or a lot of trash. That's where a good agent infrastructure can help you. So I want to show you what I have and by the way, I want to 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 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 code, because I know the agents and the skills in my cloth 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, like, if you're spending time on solution design, you're not going to 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 Cloud md, which again is your values. I'm going to 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, ClaudMD is something that exists inside your cloud code. And every time you ask Claude something on the background, you don't see this, but on the background they're going to be reading this. And that means that all the rules, everything you decide to put here, they're going to 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 going to be thinking, thinking about that as they make decisions or as they work. CloudMD 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 on the show notes or, or to send 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 and you don't need to keep getting that error, that issue or something you don't like. 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 Claud md 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 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 pmmd, is not going to be building stuff. It's only going to take information and deciding which other agents to call because they're going to be better at doing something, right? So as you can see, I explained very specifically what the product manager orchestrator is, what they do. I even say never do the work yourself because there's going to be some agents agent better than you. You're simply orchestrating, meaning you're deciding who does what, who you go to, etc. Which honestly is a bit the work of a PM. Right? And then this lost right?
- [45:27]
B
Now, what exactly am I seeing here? I'm a non technical pm. I've never used Claude code. You just showed me Claude md. Yeah, 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 going to spin up a new Claude instance every time this agent is called? Is this agent going to be proactive? Help me understand what this agent is.
- [45:49]
A
All right, so every time you spend a new session, your Cloud 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 very important 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 going to 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 it's going to call the agent, which is the PMMD and then the
- [46:49]
B
PMMD not proactive, but because we've architected our CloudMD in this way that says always call the PM agent. CloudMD is always loaded. So then it goes to the PM agent and then it gets called.
- [47:02]
A
Exactly, exactly. And then the PM agent is going to decide which other agent are actually going to 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. 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. We have an implementer, which is the final person who's going to 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 recommendations. 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 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 a production environment. So now we are on cursor with cloud code, right? And we have a feature, right? And whenever I ask for a feature, what it's going to do is going to run my cloud MD on the background. And my cloud 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 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 asked this feature, right? And let's see, I got an answer. I'm not going to give you the whole context of the feature, but I got an answer from the engineer. The engineer found some things inside the code base 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 it tells me this is my recommendation. I'm actually going to go up because I want you to see an example where multiple, multiple agents are being called. Okay, so, 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, myself, me, Andre is not sure about the design. I'm going to 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 understanding of the code, it talks about visual experiences, it gives recommendations and even asks me questions. 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, 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 going to 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, which is when you're building something, let's say you build a functionality, you had 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 going to 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 going to 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. It's. They're working 50% of the time on improving the infrastructure, the machine itself, rather than just tweaking feature by feature, right? So if you actually now see 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 going to be improving the engineer agents and the engineer skills inside the infrastructure. The designer is going to 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.
- [53:39]
B
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, or we'll be updating the design md, the PM will be updating the PM and they all are connected into that team cloud config, is that right?
- [53:56]
A
Yeah, 100%. Everyone's going to be 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, there was an update on the teams repository of skills, please 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 AIOps team or R and 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 on that specific topic.
- [54:40]
B
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 for jobs. Can you explain this and what the future really looks like of these roles?
- [54:50]
A
Yeah, so I love this post. It wasn't me originally writing it, I like to comment on it, but 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 going to be very pragmatic and you're going to 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, 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 going to 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 going to be the person trying to guarantee that what gets done has the right scalability, is reliable, it's built the right way, etc. Etc. So that when you grow the team team when people join, so it's not that different from this reality, but now applied to multiple teams so you can easily see a full stack squad that is an owner that owns a P and L, owns an impact, owns an outcome and has this stack and the beauty about this, and I want to 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. 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 is safe. This is literally the same thing a senior engineer does when a junior engineer out of school joins an 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 going to be transitioning this way because the velocity to ship is crazy different.
- [57:27]
B
What's the flip side to this velocity though? And you even have the word slop here. How do you avoid shipping slop? How do you avoid, you know, famously like the Claude team ships like this but they have bad uptime. How do you avoid those issues?
- [57:41]
A
Yeah, I mean again the, the more you invest in inference 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 site or this is where product people investing in infrastructure should 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 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 see is this making sense? Like have you 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 cloud 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 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 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 is 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, in the end, there's no collaboration. Only PMs are in the decision, only like engineers are delivering and. And it's completely flipped up. And when you start changing this, you see acceleration deeply because then people work a lot on collaboration, 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, did 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 completely flips. But if this happens, we reduce a lot of slop and we accelerate teams a lot.
- [60:44]
B
You caught my eye a couple months ago when you made this LinkedIn post. About 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.
- [60:58]
A
Yeah, so 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, a pretty, pretty high number. You gotta see the product culture in Europe is very different. If you go to a lot of European companies, you're gonna see a large number of POs of product owners, something that you very rarely see in the US or even in the Asia market. And the product owner culture 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 tight by this product culture. And 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.
- [62:19]
B
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.
- [62:26]
A
I think it has to do a lot with 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. I truly believe a lot of this is ingrained in management. Maybe the managers, the product leaders, they haven't seen any other way, so they're kind of trickling down that format. But. 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 very different. Right. So if you have the energy, you should definitely try to influence how product is built, create that small pocket 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, 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 again, a leader where you're not, or at least a manager where you're not. And again, the title 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 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.
- [64:27]
B
So what is the answer here? How can PM start to build more themselves?
- [64:32]
A
First of all, I think you need to understand that that is not the reality that you should be aiming for 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. 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 a 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 the discovery to the last delivery and the go to market and the enablement. We want the team to be an owner of, 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. Other people should participate or even have ownership of that process. So I think making these small changes is definitely step number one. One.
- [66:53]
B
Wow, so much ground we covered here today. What's the thing a PM should go do on Monday morning? What's the Monday morning roadmap to becoming a builder pm?
- [67:03]
A
Okay, so 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 and let's assume you have a GitHub account and I would ask, look, put me as a collaborator of a low risk repository, meaning even if you can create a repository for me like that is connected to the product, a new repository, a new feature and just allow me to just do something and then go to your backlog. Pick a feature that has been on the backlog forever, like literally sort it by oldest, doesn't matter. Pick something, something that you know that is in the bottom of the backlog and it's never going to get done. Every single had a bunch of these and then ask cloud code with that requirements to build it. Right. And you can even push a branch. You're not going to merge it to production. Like the engineers are not going to 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 Monday morning. Like I heard this and this is what I would start doing.
- [68:22]
B
Amazing. Andre, People love the episode. They want to learn more, they want to get in touch with you. Where should they go to find you Online?
- [68:28]
A
I basically use LinkedIn. Feel free to connect. And if you want to know more builders, camp.com is where we run our bootcamps, where we train people to become builders. So that's basically it.
- [68:39]
B
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.
- [68:49]
A
It was a pleasure, Akash. Really appreciate the time.
- [68:51]
B
See you guys in the next episode. I hope you enjoyed that episode. If you could take a moment to double check that you have followed on Apple and Spotify podcasts, subscribed on YouTube, left a rating or review on Apple or Spotify, and commented on YouTube. All these things will help the algorithm distribute the show to more and more people. As we distribute the show to more people, we can grow the show, improve the quality of the content in the production to get you better insights to stay ahead in your career. Finally, do check out my bundle@bundle.akashg.com to get access to nine AI products for an entire year for free. This includes Dovetail, Mobin, Linear, Reforge, Build, descript, and many other amazing tools that will help you, as an AI product manager or builder, succeed. I'll see you in the next episode.