Check out the conversation on Apple, Spotify, and YouTube.
Intro (00:00)
Aakash: 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. Andre Albuquerque runs Europe’s largest product builder school with over 4,000 students. And in today’s episode, he is giving you everything for free.
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 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 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 and building up your knowledge from zero. So if you’re a non-technical PM and you watch till the end, I guarantee you will feel more confident using Claude 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.
Andre: Hi Aakash, thank you very much for having me.
The biggest problem non-technical PMs face today (02:27)
Aakash: 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?
Andre: 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 them not knowing how. 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.
When we look at a lot of AI-native organizations or even new companies moving super fast, you see that’s not the reality. You see product managers, technical or not, actually contributing and building stuff. You see CEOs contributing to repositories in GitHub. You look at the Shopify CEO and his GitHub is fully green. You see entire teams that used to be like 10-20 people, and now there are super small teams and they’re all actually pushing new features, new code to production.
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. I think you want to completely transform the way you see your role inside the team, which then will influence everyone else in the team to rethink their own roles and transform the squads entirely.
Aakash: So transformation is a big goal. Can you go ahead and share your screen and show people how they get started with this new way of working?
The 4-level builder PM framework (04:50)
Andre: 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” to building. Now, this has multiple steps 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.
It has basically four steps. The first one, and I’m going to address different tools. 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.
The four levels were:
- First with Lovable
- The second step was a mix of Lovable and Claude Code
- The third step is Claude Code and Vercel as the infrastructure
- The fourth step is multi-Claude Code, multi-Vercel, and a lot of automation and agents
Level 1 – Why you start with Lovable (05:28)
Andre: 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. 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.
You can build really simple tools. My recommendation is you start with something personal. You don’t start with something in your professional environment because that allows you to actually explore the tool. For example, my family has a summer vacation home, 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. This is not commercial, this is for the family. So I started actually building my first product on Lovable as this simple tool to manage the availability of people.
This is actually a great way to start because there’s no risk. You’re not contributing to the company’s repository. You don’t even need access because this is just for you. You can do mistakes. The codebase doesn’t need to be beautiful because who cares at this level. It’s fine.
The beauty about Lovable is that they bring a lot of the stack so that you don’t actually need to care or think about it – databases, authentication, all the type of things that often non-technical people don’t even know matter. If you spend a bit of time on product or engineering, you know what authentication is, you know what these flows are. But when you have never worked there, you don’t even know that’s something important. With Lovable as a step one, it actually doesn’t matter.
One really cool way to gain feedback is always asking your prompts if you’re missing out on something. If you’re not questioning or asking or prompting something, you should. You’ll always get feedback back like you’re working with a senior engineer, which for now AI is a senior engineer to you. They’ll give you feedback and it’s actually a great way to learn.
Level 2 – The Lovable + Claude Code bridge (08:04)
Andre: Then step number two, which is actually an accidental evolution but worked really well for me. I wanted to be able to do more, and Lovable, at least back when I was using Lovable, was still a bit limited on a few things. So I installed Claude Code on the Claude desktop app.
You land on Claude Code desktop and let’s be honest, it’s a bit scary. 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.
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. You connect your Claude Code to your GitHub. 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. They’re all synced.
That means if you actually do code on the Claude Code desktop app and you update your repository on GitHub, Lovable will also get that update. 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 Lovable as your infrastructure. What that means is you can be pushing code on Claude Code with all the flexibility and all the great things Claude Code offers, but you can still see the evolution of your product on Lovable with all the easiness of the Lovable platform.
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.
Live demo – Connecting Lovable to Claude Code via GitHub (16:26)
Aakash: This is new alpha. This is really exciting information for people. If somebody needs 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?
Andre: Let me show you. You need to have your GitHub repository. Let’s say you have your GitHub under your name. This is where I’m going to 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 going to have their own repository. They need to give you access, but we’ll go to that a bit later.
Let’s say I want to build a new product. Let’s say a mentorship matching tool. Make it simple. So I’m going to build. What this does is I’m bootstrapping the tool on Lovable, which is way easier to start than starting on Claude Code if you don’t have the infrastructure built yet.
While Lovable is building, I’m going to switch the share to my Claude Code desktop app. So you should be seeing my Claude Code. 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. When you’re connecting this, 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.
When you go to Claude Code, your repository is going to show. You’ll be able to work on it. You can choose your repository. These are my repositories right now. As I’m going to be creating a new repository on this new Lovable tool, I’ll then open it up here.
Let’s go back to Lovable. It’s called mentor match. We have something that was built. This is what I call the bootstrap. The bootstrap is you start with a prompt – however big, however simple, however complex, it doesn’t matter. You’re bootstrapping the product.
Now let’s say you want to continue on Claude Code because you’re okay with working with the tool. You’re going to connect this to your GitHub. So I’ll connect to my personal account. What that means is now the code that Lovable built is going to go straight to GitHub.
Important thing with Lovable: if you create your code on Claude Code and 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.
This now created a new repository called mentor match simple. If I actually go to my GitHub and I refresh it, you now see mentor match simple is here. Now you go to Claude Code. Remember up until now we bootstrapped the product on Lovable. We connected to GitHub. Since your Claude Code is connected to GitHub via the connectors, if you are in Claude default and you select the repo, you’ll see that now mentor match is here. So now I know I’m coding to mentor match.
Whenever I do things here on Claude Code desktop app – let’s say I want to change the design system to green. I’m just asking it to change. Keep in mind we started on Lovable. So I’m going to switch to Lovable. As you can see here, the tool is basically beige and red tones, a theme that is more on this palette. I want to change the setup. I asked Claude Code to do a bit more green. What will happen is I’m actually coding into the repository. 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.
For a non-technical PM, they might be intimidated by merge and branch and pull request. Here’s the simplest explanation. There is a main branch. What you typically do when you’re 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 the basics. I’m oversimplifying it.
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.
Aakash: 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.
Level 3 – Cursor + Vercel for real production (28:37)
Aakash: That’s Level 2. Level 1 Lovable, Level 2 Lovable plus Claude Code via that GitHub integration that we just walked through. What’s Level 3?
Andre: Level 3 for me is I got off Lovable. I wanted to start working faster. 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 Claude Code and Lovable, if you’re curious you start understanding a bit more of things. 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 work trees. The moment you start playing with Claude Code, you’ll see yourself very quickly wanting to work with multiple sessions at the same time. That means you’re going to start building multiple features at the same time.
You need to have an infrastructure that allows you to work safely with multiple branches at the same time, where when you branch you can deal with conflicts, where you can see stuff in a reliable environment. For that, I transitioned from Lovable as my infrastructure – and by the way, Lovable isn’t supposed to be an infrastructure product, I just use it that way – to Vercel, which is way more known as the typical way of working.
You can then decide one of two things. You can keep on Claude Code desktop app or you can start using an IDE. Let’s say 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. 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.
Why Andre prefers Cursor (33:53)
Aakash: Andre gave you a couple reasons why he likes Cursor – the vertical visual tabs. I would add 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 you have with Claude Code. 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 the top right. You can paste in whatever issue you’re getting like “Hey, I’m unable to turn on Claude Code.” And the free Cursor agent will help you debug any issues.
Reason two is 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.
Mental model – Lovable vs Cursor vs Vercel (35:40)
Aakash: 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 help me in my mind understand: Lovable is X, Claude Code is Y, Vercel is Z. What are these exactly?
Andre: Important to say that I’m using Lovable in the most atypical way possible because Lovable is an 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. I’m oversimplifying on purpose: it’s 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. Then you have the place where the code lives, which is GitHub. Then you have Vercel, which is your bridge between your GitHub – your repository – and users. You need to have this connection, the bridge. What you’re doing is you’re pushing the code from Claude Code to your repository, and then you’re telling Vercel “now make the code I just created available to users.” That’s basically it.
Aakash: 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 users.
Andre: 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 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 compare my usage with technical folks, it has absolutely nothing to do with that, but it works for me. That is the best skill you can develop right now as a non-technical PM who wants to start building.
Level 4 – Agents, skills, and CLAUDE.md (41:17)
Andre: The last level – level four – is agents, having agents and skills and creating your own process. 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 creating problems for your product, and even experiment on Vercel with different approaches.
The biggest fear a lot of people have is “oh, vibe coded code is bad code” or when you’re building with agents or vibe coding, they’re going to create a lot of complexity, a lot of lines of code. Thinking like this is not wrong. 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.
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. 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, because I know the agents and the skills in my CLAUDE.md will take care of that for me.
The CLAUDE.md memory file (42:50)
Andre: CLAUDE.md is something that exists inside your Claude Code. Every time you ask Claude something, in the background you don’t see this, but they’re going to be reading this. That means 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.” You know that your team is going to be thinking about that as they make decisions or as they work. CLAUDE.md works exactly the same.
In my case, I have a default behavior. I have rules. I have agent strategy. I have architecture. I have specific things that happen depending on the feature that I’m asking. All of these rules are here. Basically this is the memory. These are the rules and these are the values that we care about.
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 or that issue or something you don’t like.
The PM orchestrator agent (45:24)
Andre: I have a very specific agent that I use a lot and this is called the PM agent. 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.
The PM, which is a pm.md, is not going to be building stuff. It’s only going to take information and decide which other agents to call because they’re going to be better at doing something. I explain 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 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.
Aakash: What exactly am I seeing here? I’m a non-technical PM. I’ve never used Claude Code. You just showed me CLAUDE.md, which seems pretty complex. And now you’re in the agents folder pm. What exactly are these agents? 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?
Andre: Every time you spin a new session, your CLAUDE.md is loaded. Everything that you have inside that folder – the .claude folder, which includes your agents and your skills – they’re also there. They always exist whenever you spin up a new session. When you start a new session, when you ask something to Claude, it goes to the CLAUDE.md. 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.
On my CLAUDE.md, I have a very important rule. Rule number one: for every task, call the PM agent. It’s like if you’re the CEO and the first thing you’re going to do as CEO is you go to the PM and say “I’m the CEO, we’ve 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.
Aakash: So CLAUDE.md is always loaded. Then it goes to the PM agent and then it gets called.
Andre: Exactly. The PM agent is going to decide which other agents are actually going to do the work. We have multiple agents here. You have a researcher, which does what user research typically does in the team. We have discovery, which is a very specific agent. We have a designer, which is very knowledgeable about design systems and best practices of UX. We have an engineer, which is an agent that is preventing my code from being bad code. We have an implementer, which is the final person who’s going to actually write the code and implement stuff.
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 – how they work, what they care about, how they decide. Write that down and make them the agents. One of the worst things you could do is go on X or go on LinkedIn and see all 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 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.
How AI-native teams work (53:26)
Andre: When something goes wrong – 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 “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. 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: 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 – they’re working 50% of the time on improving the infrastructure, the machine itself, rather than just tweaking feature by feature.
If you actually now see an AI-native team, what you’ll see is you can have two or three people. You can still have the typical trio like a product manager, engineer, a designer, but they’re all builders, meaning 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. 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.
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.
The 4 jobs of the future (00:53 in conversation)
Aakash: One of the things you wrote about on LinkedIn is that there are now only four jobs. Can you explain this and what the future really looks like of these roles?
Andre: 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 at a new startup, like I worked for a while in VC investing in early stage. Those early stage teams, they’re super small. They’re going to be very pragmatic. You’re going to have maybe three founders, and you have typically one founder who’s significantly more commercial, one founder who’s significantly more technical, and one founder who’s significantly more product oriented.
If you think about these four roles, it’s what those founders look like in their inception. You have the commercial one – the GTM 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, 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. 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, is built the right way.
The beauty about this – and I want to highlight specifically the security or infra – 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. 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 it is safe. This is literally the same thing a senior engineer does when a junior engineer out of school joins a software development organization. It’s not new. The difference is now the junior engineer is a non-technical person using AI to vibe code new functionality.
How to avoid shipping slop (00:24 in conversation)
Aakash: What’s the flip side to this velocity? And you even have the word “slop” here. How do you avoid shipping slop? How do you avoid those issues like, famously, the Claude team shipped like this, but they have bad uptime?
Andre: The more you invest in infra and security, the more likely are you to prevent situations like that, because you create friction. 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 side – and this is where product people investing in infrastructure should be putting their time. 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 skill based on Teresa Torres’s amazing book, and I have a MoSCoW skill which goes for the “must, should, could, won’t” prioritization technique. What it does is it creates three Notion pages on that requirement, on that PRD, that explores those three frameworks. I want people to read through them and see “is this making sense, have we dedicated enough time, can we check and go to the next phase of solution building” – 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. I don’t want people building the solutions until that becomes part of the initial process. And it’s not just PMs or non-technical PMs doing that. Engineers do that. Designers do that, because we’re all builders. It completely changes what you decide to build.
That’s the two ways you prevent slop: in the beginning and the end.
One of the things that decelerates people, teams, companies the most is collaboration. This sounds contrarian, but the fact that you have people having to collaborate is what slows everything down. 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. You get people together deciding, working on the problem. In the end you get people actually having the product in their hands and helping push it to the market.
But in reality, what’s happening is collaboration is happening on the execution. It’s happening on dependencies. It’s happening on “I do this, you do that.” It slows everything down. Then in the beginning and the end there’s no collaboration – only PMs are in the decision, only engineers are delivering. It’s completely flipped. When you start changing this, you see acceleration deeply. People work a lot on collaboration on decision-making, and then every single person, teams of one, can execute by themselves. They come back in the end and collaborate on “did this make sense, can we merge this, is this working with the product?” Together they deliver the product to the user. If this happens, we reduce a lot of slop and we accelerate teams a lot.
Why 90% of European PMs are non-technical (61:33)
Aakash: 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.
Andre: Even though I’m not 100% sure of the number – if it’s 90, 99, or something in between – it’s going to be a pretty high number. 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 – product owners. Something that you very rarely see in the US or even in the Asian market. The product owner culture in Europe focuses a lot on a bit of a glorified delivery manager without the actual technical skills. 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 project management work within these teams, but unfortunately your hands are a bit tied by this product culture.
I think this is one of the biggest problems we see in a lot of tech or software development in Europe – 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.
Aakash: 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?
Andre: It has to do a lot with your personal energy. I don’t think you should move because that’s your reality. If you have the energy, you should try to fight to make it a better reality. 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. 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. 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. 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 for the team.
One thing I notice in a lot of companies that I work with: when you have a product owner, what the team is unconsciously or consciously seeing is that that person alone owns the product. 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. You at the same time, again unconsciously or not, feel like you’re the owner of the product, which makes you a leader where you’re not, or at least a manager where you’re not. The title is breaking all of this. You end up seeing in a lot of European organizations squads or teams or pods which are completely disempowered. 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. It feels like the teams are all siloed. In my opinion, it actually starts with the fact that there is a product owner rather than a team feeling owner of the product.
Aakash: So what is the answer here? How can PMs start to build more themselves?
Andre: First of all, you need to understand that’s not the reality that you should be aiming for. There are other ways to do it. 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. You need to understand that there is great food out there. There are other, better ways of building product.
Number two: get some coaching or get some mentorship from people who are maybe inside companies who are building this way. Spend a bit of time, if you can, asking them: how does it work? What am I supposed to do? When you read content online, content that you post, you see how other people think, how they build, how they interact with their teams, how they set up their own design. Start there. Start by understanding what great food looks like so you can start cooking it internally.
Number three: 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 you want to start getting allies with your team – your engineering team, your design team, your AI team. Explain to them: “look, we don’t want you to be at 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 discovery to the last delivery and the go-to-market and the enablement. We want the team to be an owner of the entire process.”
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. That means you need to also change a few of the rituals. 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. If you’re doing all the decisions of scope and requirements and design decisions, that is already a problem. Other people should participate or even have ownership of that process. Making these small changes is definitely step number one.
The Monday morning move (67:45)
Aakash: 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?
Andre: This is ambitious. It depends a lot on your team. If I was getting started on this and I went through the levels and I’m getting to level three and I’m feeling comfortable, I would definitely go to my engineer. Let’s assume you have a GitHub account. I would ask: “look, put me as a collaborator of a low-risk repository.” Even if they can create a repository for you that is connected to the product – a new repository, a new feature – and just allow me to do something.
Then go to your backlog. Pick a feature that has been on the backlog forever. Literally sort it by oldest. It doesn’t matter. Pick something that you know is at the bottom of the backlog and is never going to get done. Every single PM has a bunch of these. Then ask Claude Code, without requirements, to build it. You can even push a branch. You’re not going to merge it to production – 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. That would be my Monday morning. I heard this and this is what I would start doing.
Closing (69:07)
Aakash: 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?
Andre: I basically use LinkedIn. Feel free to connect. If you want to know more, builderscamp.com is where we run our boot camps where we train people to become builders. That’s basically it.
Aakash: 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.
Andre: It was a pleasure, Aakash. Really appreciate the time.
Aakash: See you guys in the next episode.