# Francis Ma on Systems Thinking for Teams of AI Agents

by [kirupa](https://www.kirupa.com/me/index.htm) | filed under [Interviews with Creative People](https://www.kirupa.com/podcast/index.htm)

What happens when one person runs six to eight Claude Code sessions and another six to eight Codex sessions at once? Coding becomes less about writing code and more about leading a team.

I chat with [Francis Ma](https://www.linkedin.com/in/francisma/), an entrepreneur, investor, and former Google product leader who helped shape Firebase, about the systems thinking this shift demands. We connect his path from early computers to today's AI agents and explore how clear goals, shared standards, model fit, and feedback loops keep parallel work moving in the same direction.

To learn more about Francis:<br>
💼 [LinkedIn](https://www.linkedin.com/in/francisma/)<br>
🚀 [JoyCrew](https://joycrew.ai/)<br>
🌐 [Blog](https://francisma.com/)

Watch the interview: https://www.youtube.com/watch?v=LrOvRn1a1tE

## About this conversation

The conversation begins with the kind of details that make an early computing story feel real: an IBM 8086, 5.25-inch floppy disks, Prince of Persia, Karateka, and a library book that promised a game if Francis could type the code correctly. That curiosity carried him through computer engineering at the University of Waterloo, software work at Amazon, a startup of his own, and eventually product leadership at Google.

A recurring thread is the value of lowering the first barrier. Francis connects his childhood experience of struggling through setup with the work of making Firebase easier for developers to approach. Kirupa brings back a phrase he learned from Francis, “friction-free onboarding,” and the two unpack why a small early success can give someone enough confidence to keep going.

The second half moves from product craft into the day-to-day reality of AI agents. Francis describes running multiple Claude Code and Codex sessions, but the interesting part is not the number of terminals or models. It is the system around them: shared design rules, coding standards, clear outcomes, and feedback loops that keep independent work from turning into a pile of mismatched parts. Kirupa’s experiment with autonomous personalities on his forum gives the idea a concrete test case.

By the end, the conversation reaches beyond prompting. Cheaper prototypes make it possible to test several strategic directions instead of polishing one document for weeks, while AI also blurs the old boundaries among product managers, engineers, and designers. Francis keeps returning to first principles: understand what a practice was meant to accomplish, preserve that purpose, and be willing to replace the old mechanism. The closing advice is simple—learning still comes from doing.

## What you'll hear about

- Francis traces his path from an IBM 8086 and QuickBASIC to software engineering, startups, and product leadership.
- Firebase’s emphasis on friction-free onboarding shows how small moments of confidence can unlock much larger developer journeys.
- Systems thinking gives fleets of AI agents shared goals, design standards, coding conventions, and feedback loops.
- Kirupa’s autonomous forum experiment shows agents finding useful content patterns that neither a rigid prompt nor a human hunch supplied.
- Different models behave like different kinds of teammates, so matching the model to the work matters as much as writing the prompt.
- AI makes prototypes and strategic experiments cheaper while pushing product managers and engineers toward a broader identity as builders.

## Jump to a topic

- [0:00](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=0s) **Early Computers, Games, and BASIC**: Francis traces his first experiments from an IBM 8086 and floppy-disk games to library books, QuickBASIC, and computer engineering.
- [6:03](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=363s) **From Engineer to Founder and Product Leader**: The path runs through Waterloo co-ops, Amazon, a startup, Google, and the developer-first thinking that made Firebase feel approachable.
- [9:54](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=594s) **Friction-Free Onboarding and Accidental PMs**: Kirupa and Francis connect confidence-building product design with the winding, often accidental routes that led both of them into product management.
- [20:29](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1229s) **Systems Thinking for Fleets of Agents**: Francis explains why parallel agents need more than good prompts: they need the same kind of goals, standards, and coordination that hold teams together.
- [25:29](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1529s) **A Parallel-Agent Working Setup**: They compare Claude Code, Codex, Gemini, remote sessions, phone access, and the practical limits of keeping many workstreams moving at once.
- [29:12](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1752s) **Design the System Before the Prompt**: A shared design system can keep independently built features coherent, allowing the final task prompt to stay surprisingly small.
- [31:27](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1887s) **What an Autonomous Forum Learned**: Kirupa describes agent personas that run experiments on his forum, study what readers respond to, and surface ideas he would not have tried himself.
- [39:46](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=2386s) **Goals, Standards, Feedback, and Model Fit**: The conversation maps top-down direction, bottom-up learning, retrospectives, and different model strengths onto familiar patterns of organizational leadership.
- [47:26](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=2846s) **Cheaper Experiments and First-Principles Work**: When multiple versions can be built in hours, strategy documents become testable inputs and old habits have to be separated from the reasons they once existed.
- [58:24](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=3504s) **Creating Luck and Rethinking Product Work**: They close on more shots at discovery, the enduring purpose of product management, blurred job boundaries, and what an AI-native company might look like.

## Transcript

The automatically generated captions have been organized by speaker, lightly edited for clarity, and broken into paragraphs for readability. Names and wording may still contain errors.

### [0:00](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=0s) - Kirupa

Hi, everybody. Today, I talk with Francis Ma, engineer, entrepreneur, and product leader. He played a key role in Firebase's success at Google, which is where he and I crossed paths, and even for a brief bit, I reported directly to him. Today, we're going to talk about systems thinking and how the same principles apply not just to leading organizations, but also to leading a team of agents. Now, along the way, we're going to cover a lot of other topics as well. So let's get started. All right, Francis, it is great to chat with you after having known you for many, many years, both when you and I worked closely together at Google and now as we catch up after quite some time.

And so I'd like to start this off the same way I start all these conversations. Tell me a little bit about yourself and what got you started in tech.

### [0:48](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=48s) - Francis Ma

Yeah. Well, first off, thanks for having me, Kirupa. Like you said, it's great to catch up after these years and I'm really looking forward to our conversation here today. So, as you asked about getting started in tech, my first foray was when I was about nine or 10 years old. My dad brought home the first computer. I'm going to age myself here a little bit: this was an IBM 8086. At the time, my dad was an accountant and was learning to use Lotus 1-2-3 or something like that. Anyway, it was some accounting software. But that was the first time I got really interested in computers. I started tinkering with it and, of course, playing games and all of that.

Over the years, I got interested in programming, and I was really lucky to have gotten that early exposure. I eventually got to study computer engineering in college and kick off my tech career. So that was my start.

### [1:58](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=118s) - Kirupa

So, you mentioned games. That's a common theme among people of our generation who got started with computers in the 1990s. What game did you start with?

### [2:08](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=128s) - Francis Ma

Wow. This goes pretty far back. Let's see. So I would say the most memorable one was probably the first Prince of Persia. I think there were a couple of other ones before that like Karateka and other pixelated games. But I think the one that really got me hooked, and where I spent a lot of time, was that first classic Prince of Persia.

### [2:38](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=158s) - Kirupa

Was it on a CD-ROM, or was it still on one of those bigger 3.5-inch or 5.25-inch floppy disks?

### [2:44](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=164s) - Francis Ma

Oh, no. Yeah. When I started, it was on a 5.25-inch floppy disk, right? The soft kind and all of that. Then it eventually moved to the 3.5-inch disk. But yeah, that was the first foray. I remember some of the early games where you had to switch disks, too.

### [3:03](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=183s) - Kirupa

Yeah, no. Prince of Persia is one of the games I remember most as well. I don't know how this worked, but back then grocery and convenience stores had shareware disks at the counters where you find magazines today. For $1, you could buy one. Prince of Persia was one of those games that I got as a trial version. I thought, why not? I could buy candy or a game. The game was always a better option. You got more enjoyment out of it.

### [3:31](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=211s) - Francis Ma

Oh, my goodness. I totally remember this. Yeah. No, same. It was like, oh, you got your allowance money and could buy a snack. No, get the magazine and the games.

### [3:40](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=220s) - Kirupa

Yeah. Oh, very cool. What was the first programming language that you got into?

### [3:44](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=224s) - Francis Ma

It was BASIC. I think it was called QuickBASIC. That was my first foray. I remember going to the library where I had to borrow programming books. I didn't know what I was doing, but the first book said that if you typed in this code, you could get a game. It was maybe Pong or something like that. I didn't know what I was doing, but I was just following the instructions. Of course, there were typos along the way, and it was super frustrating trying to get it working. It's like, why isn't this working? I spent like an hour typing this whole page. But then eventually I figured it out. And yeah, it was just through that curiosity of tinkering.

It's like, oh, what happens if I change this? Why is this number three here? Oh, wait, I changed it to 10. That gave me 10 lives. Things like that got me interested. And eventually, yeah, I learned a little bit more programming that way.

### [4:38](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=278s) - Kirupa

When you said computer engineering, was it more on the software side, or did you do hardware as well?

### [4:42](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=282s) - Francis Ma

It was a little bit of both. So I got really lucky. I got to attend the University of Waterloo, which had a computer engineering program. This was around the late 1990s and early 2000s. I was really into hardware. I was like, okay, I really want to break into that. I couldn't quite figure it out. The software side always came naturally to me. This was sort of like the easier thing. And I was trying to get an internship as a hardware engineer, getting into all of that. All my friends got it and I couldn't get in.

And so I ended up in software, and like many things in life, that turned out to be fortunate. I got that exposure, found my passion, and have followed it ever since.

### [5:33](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=333s) - Kirupa

When you said you were tinkering with various things, did you tinker with hardware as well as software? Was that before college, or was software where you spent most of your time?

### [5:42](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=342s) - Francis Ma

A little bit. There were some basic programmable FPGA boards and things like that, but software was far more accessible, right? There was a lot more information online and all of that. It became one thread after another. It's like, oh, wow. I just really got into software, and that's where my heart was.

### [6:03](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=363s) - Kirupa

And from college, you had a pretty storied career as a product manager, but before that you were also a startup founder. Walk me through how you went from there to where you ended up.

### [6:13](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=373s) - Francis Ma

Yeah. So as I mentioned, I went through university. One part of the University of Waterloo program was its internships and co-ops, where you alternated between school and practical jobs. So when I first started, my first co-op job was at an IT desk, working in a bank, but I eventually got more hands-on exposure to programming, writing professional software. And so when I started my career, I was a software developer. Again, I was very, very lucky. I was up in Seattle, joined a company called Amazon, and got to help build the early third-party seller store at Amazon.

That was the start of my career. After several years at Amazon, I decided to take the plunge and do my own startup. I'd always wanted to be an entrepreneur and got to do that for a couple of years. And I got to connect with some friends that were at Google. That's when I got to join Google and started my transition into product management.

### [7:35](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=455s) - Kirupa

Yeah. I joined Google when you were leading Firebase, of course. Walk me through how your early tinkering with programming and building things might have led you to kind of align with that simplification for developers.

### [7:51](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=471s) - Francis Ma

Yeah. No, that's a really good question. As I was mentioning, it goes back to that early experience of going to the library, getting a book, and starting to learn programming. I've always felt that there was a huge hurdle in getting started, but once you get through the other side, it's magical, right? For many of us as builders, the experience is like, oh, wow. You see the magic of what happens when you can unlock that. But oftentimes it's that initial hurdle of getting set up, getting your environment set up, figuring out the programming and all of that. It's difficult. And so that has always been a passion of mine.

On one hand, it's thinking about how we can lower that barrier to entry, make it easier and make this technology more accessible to everybody. And then on the other hand, it's about creating economic impact. And that's something that I'm personally very passionate about as well. I personally feel very fortunate to have been in tech where we got to see the many capabilities and economic opportunities and so forth that tech has enabled. So really, it's the accumulation of those two things.

In working at Google, one of the great things about it is that we have the opportunity to build some of these enabling technologies and have the reach and global impact to work with developers. Looking back, Firebase started in the early days of mobile and cloud development, and it was about making both easier for everybody. So you don't have to worry about setting up your own backend, connecting all of those things. And that was like the start of that journey. All in all, it was about making things easier, making technology accessible and ultimately helping people succeed and unlocking that economic opportunity.

### [9:54](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=594s) - Kirupa

Yeah. There was a phrase you mentioned a long time ago that I now repeat ad nauseam: friction-free onboarding. It's such a great way of explaining how we simplify something that seems unbelievable to most people, show them that it is possible, and help them get it done.

I was reading a book on social psychology recently. One point it made was that people often succeed in productive environments simply because they know someone else has already done something they thought was impossible. That proof can be enough to carry you through an uncertain situation. I see a parallel in so much of what we do with computers, especially as developers: there are so many things you want to do when you just don't know if they're possible. Knowing that someone can do it, has done it, and is talking about it is magical in some ways.

The next best thing is for the software itself to give you that same confidence through onboarding. Friction-free onboarding, as you described it, has always stuck with me.

### [10:54](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=654s) - Francis Ma

Yeah, no. And I learned a lot from the many talented folks we got to work with at Google. And I really liked that insight that you had shared. You're right. You look back at many other facets in life as well. It's like that dose of encouragement, that first unlock, right? It's like, oh yeah, you can do it. You can get through it. Making that super easy matters. Yeah, I absolutely agree. I think that it's something that I've learned. Often, as product builders, we think, hey, what are all the features? What do all the pieces look like? At the end of that rainbow, how can we unlock all of that?

But thinking about that journey, that first bit is like, okay, this is the path to the rainbow. Make it super easy and delightful. There's a lot of work there. And yeah, that's a good point that there's also the human psychology part of encouragement there too.

### [11:45](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=705s) - Kirupa

So you mentioned you worked in software engineering first, but then you transitioned into product management. What made you decide to go into product management as opposed to staying within software engineering?

### [11:57](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=717s) - Francis Ma

Yeah. So my first foray into product work was at my startup. I was a naive developer, and this was when social media marketing was just taking off. My co-founder and I thought, okay, we have some really good ideas and we can build it. This is going to be amazing. Back then it was the classic story: we spent nine months heads-down, grinding away and building this thing. And then it was crickets, and it took a long time before we realized and appreciated the need to figure out how to position our product. How do we talk about it? How do we understand customers? We had to learn that whole craft.

And so I was never formally trained as a PM, but building that first startup gave me some of those battle scars and learnings. When I first connected with folks at Google, we talked about whether there might be an opportunity for me to join. I was initially thinking, oh, maybe I could be a Google engineer. I'd always wanted to do that. That's amazing. And then they said, you know what, actually, I don't know if you quite meet the bar to be an engineer there, but we think that we definitely need more PMs and we think this might suit someone who has been a startup founder. And I said, oh, okay, well, I don't really know.

I've never been formally trained as a product manager, but that sounds great. I think that I can continue to learn down this path. So it was sort of an accidental stumble into it. But of course, once I got to do it and learn more about that craft, I started feeling the passion for it. I was like, oh, man, this is a lifelong craft. I really got to learn it. I really want to hone that craft. And again, very grateful that I got to do it for these years.

### [14:02](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=842s) - Kirupa

Yeah. I think most product managers I run into all have a very similar story. Like no one ever grows up going, I can't wait to be a product manager, but they accidentally get into it through their various experiences and find that this is actually what they've always wanted to do. And I think that in the 2000s, the definition of product manager wasn't really well defined. Like no one quite knew what a product manager did and each company had a different version of what a product manager did. And I think Google was much closer to what today's definition of product manager became.

The Amazon or Microsoft version of product management was very different, you know? So I think you got into the form of product management that ended up being practiced across the industry.

### [14:51](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=891s) - Francis Ma

Yeah. Really, really lucky at that time as well. But back to your point, I do feel that product management is this mystical role that's different in a lot of different places. That is still true today. There are so many different facets to product that the role is slightly different, but that's also what makes it interesting as well.

### [15:12](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=912s) - Kirupa

It's like your own choose-your-own-adventure book. You can choose exactly what you want to do and match it with what the problem is right now and still be successful doing that. I think other disciplines have a little less of that flexibility, which is one thing I love about product management.

### [15:26](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=926s) - Francis Ma

Yeah. And I'm curious to hear back about your story too. How did you make that early transition from builder to PM?

### [15:35](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=935s) - Kirupa

Yeah. I interned at Microsoft as a product manager and it was because I bombed all my interviews in college for software engineering. And one of my interviewers at Microsoft, when I was interviewing for my internship, his name was Mark Zbikowski. It turns out he was really famous because if you open any executable file in Notepad, you see the initials MZ in front of it, and they're actually from him. I only knew that when I looked him up after the interview. I'm like, who is this person? Why was there a crowd of people wanting to meet with him afterward? That's how unprepared I was for what I was really getting into at the time.

Given that I was blogging and doing all my side projects, he asked, have you considered program management? It's what Microsoft called product managers back then. He asked whether I'd considered it as an option. I said, sure, why not? Given that I had no other options, I was like, yeah, let me give it a shot. And the interview questions were, of course, very different. It turned out to be much more natural for how I was thinking: how would you design something? How would you position a certain product in a particular market? How would you navigate competitive pressures and prepare for them?

I guess my side projects and other experiences naturally played a role there. And that's what got me into program management, which was closer to today's definition of product management. I happened to join a team that was very much aligned with my interest around how to help designers and less technical people build full-scale applications.

So that got me into not just product management, but in a domain I had thought was a hobby. I never knew I could build a career around making pixels and things move on a screen without being a designer. I was also interested in design but not good enough at it to make it my career. That's what got me in. And my curiosity about various parts of it took me in various directions during almost 10 years at Microsoft, and then I went to other companies. And then, of course, I landed on your team in Firebase.

### [17:44](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1064s) - Francis Ma

That's amazing. And actually we share some similarities in our passion for design. And I'm far less talented than you are on the design side. But early on, I had also aspired to do some art and design as well. Again, that never quite panned out. I was studying art in high school, but in college I eventually specialized more into the tech side of it. Still, today, I really appreciate that pixel-level experience. Going back to the onboarding, I think that brings all of it together.

### [18:22](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1102s) - Kirupa

I think there's something to both of our credit here: we had the self-awareness to recognize, “This is what I want to do, but I don't think I'm going to be good enough at it to be successful in the future.” The starving artist is a classic trope. I think about it now as a parent myself—and you also have children. How do we guide our children in a way where they follow their passion but also do not fall into the starving artist trope? Maybe that's just my upbringing shaping how I think about it.

But I always think: what made me recognize that I'm not a good engineer or artist, but that I have skills with economic value in the industry? Let me pursue that. And in my spare time, if I ever decide to get into art or programming, I can still do that without making my day-to-day life so difficult.

### [19:20](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1160s) - Francis Ma

Yeah. But I also feel like this is such an exciting time with AI and all of these new tools, right? That is also opening up new possibilities for finding passions and new ways of being successful there. So yeah, to your point, as a parent, I'm always a little bit nervous: Am I doing the right thing? Am I being a good dad or not? But at the same time, I have this immense optimism when I see all the things that are possible now that literally weren't possible, six or nine months ago, and how fast things are moving. I'm excited to see that future ahead of us too.

### [20:02](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1202s) - Kirupa

Yeah. No, I do think that if AI existed, even in its current state, back when we were doing some of the things that we were doing, it could have augmented any gaps we ever had in, let's say, design or software engineering. We'd still have been able to create the output we wanted without settling for something subpar because of gaps in our own skills. We knew what the output needed to be, and then AI filled in the gaps for us.

### [20:26](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1226s) - Francis Ma

Yeah.

### [20:29](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1229s) - Kirupa

AI is probably an interesting topic because when you and I chatted a couple of weeks ago, you talked about how many similarities there are between leading agents and navigating organizations. I'd love to hear your perspective as both a product manager and a leader of product managers.

### [20:50](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1250s) - Francis Ma

Yeah. I left Google a couple of months ago to be a startup founder again. During the early months of this journey, I wanted to be much more hands-on and get back into agentic coding. Of course, the whole thing is changing very rapidly. As I got back into hands-on coding, I was trying to figure it out. You read and hear people say there's an immense unlock, but I wasn't quite able to find it. I was asking, well, what can I do? Like everybody else, I booted up Claude Code and the general CLI, working with one agent at a time.

Over time, I started to realize, well, what happens if I parallelize these things? Now, of course, we can quickly spin up many different agents. But I was never quite able to get the outcome I wanted. One agent produced a beautiful landing page. Another was building the product's service area in parallel, and the two didn't quite look the same. Of course, that was just the tip of the iceberg. When you dig deeper, the code is all very different—it's architected differently—and the pieces don't quite come together.

Over time, I came to realize there were a lot of similar patterns in leading organizations, building the systems that run teams, and orchestrating fleets of agents. That's been a learning journey over the last several months. I feel this is starting to click for me, so I'm very excited to share and exchange learnings. I'm sure you've also discovered many different patterns and published some of those as well.

At the heart of it for me is systems thinking. With the ability to unleash this immense intelligence at our fingertips, it's more important than ever for us to build up that skill set, in the same way we've learned to think about organizations over the years. I'm really excited about it and looking to continue learning in that space.

### [23:27](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1407s) - Kirupa

Yeah. I think there was a transition earlier this year. Before then, agents were just extensions of ourselves: when we weren't actively doing something, they weren't doing anything either. Then we started getting the basic technology for autonomous agents that can act independently from what you're doing. OpenClaw, I think, opened the door to this by normalizing the idea of an agent as its own individual unit. You gave it a name, a personality, and a soul. It was now very obvious that you're the human.

Now you're talking to something that isn't human and has its own name and backstory, depending on how far you want to go in making it real. It can do things on your behalf, and I can have a fleet of those individuals. In a world where many of us work remotely, it is almost the same as working with a team of coworkers you probably wouldn't see regularly, but the output is very similar. You're chatting, having normal interactions, and, in some cases, collaborating. All the things you said about building organizations and managing their output apply 100% to agents.

I joke that it's only a matter of time before I'll be reporting to an agent.

### [24:47](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1487s) - Francis Ma

Well, yeah, sometimes I feel that way, right? The agents are waiting for my next input: what should I do there? In many ways, I've got to report to them and give them that direction. But to your point, it's kind of crazy. We talk about the early days now, but it wasn't even that long ago. Back then, AI was just helping us type faster through autocompletion and all of that. Now you can really unleash some of those things. Part of the craft is in the coordination, defining the systems and all of that. You can definitely draw some of the same parallels in what we do as PMs as well.

### [25:29](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1529s) - Kirupa

Yeah, I'd love to hear the setup you have going for your agents. In my case, every morning when I wake up, I get a list of things the agents need me to do. Okay, I'm glad you were very productive while I was sleeping. And then here are all the things I now need to do to help them continue to be successful. What kind of setup do you have? You mentioned using Claude Code. What is your current arrangement now?

### [25:54](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1554s) - Francis Ma

Yeah, I'll talk about the arc and how I got to where I am. I started out like everybody else, just trying to tinker with the CLI, using Claude Code and Gemini CLI early on. Of course, we had a lot of good friends working on that too. That was the start of it. But one of the things I always wanted to do was parallelize: I didn't want to have just one thing going at a time and keep nudging it forward. I started asking, what is that limit? What is the bottleneck, and what can we continue to parallelize? How can I get this to work? So I continued to evolve the setup, using the CLI more and opening multiple terminals.

We've all had that experience: a dozen terminals on the screen. But now I've really grown to appreciate the native apps, especially the Claude Code native app. Along the way, I've also started using Codex. Those two are now my daily drivers. They both have their pros and cons and their own strengths. I primarily use both Codex and Claude Code. That's my current setup. Occasionally, I have some tasks for Gemini as well; it has its own strengths. I primarily run about six to eight sessions in parallel for each one. Each one has its own fleet of tasks.

We can go into that; I'd love to compare notes on how we get them there. But yeah, that's the typical setup I'm running now.

### [27:35](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1655s) - Kirupa

Do you also have it paired with your phone where you can actually have your phone send notifications and messages to the running instances of your agents in Claude and ChatGPT?

### [27:44](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1664s) - Francis Ma

Yeah. That was part of the journey too. I've been trying to figure out, okay, how do I do this on the go? In the earlier days—which were only a few months ago—a lot of this was harder. I had to create my own VPN tunnel so I could control my laptop at home from my phone and keep it on, or, when I went out, keep my laptop open with the clamshell up. I tried all kinds of tricks just to keep it alive. Nowadays, I prefer the experience on the laptop because from a UI standpoint, being able to see the full screen makes a huge difference.

I take the laptop and my phone with me, tethering so I can work on the go. I'm always carrying this laptop, trying not to put it to sleep so I can keep things going. Now that remote sessions are easy and seamless on both Codex and Claude Code, I use them for longer-running background tasks so I can continue to monitor and keep an eye on them.

### [28:52](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1732s) - Kirupa

Yeah, no, it's a really fun space. One thing I'm curious about is what kind of prompting you do with your agents. Are you very specific—“I want agent A to do this and agent B to do something else”—or are you more open-ended, saying, “Here's where I want to get to; you figure it out and do it”?

### [29:12](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1752s) - Francis Ma

Yeah. I actually want to step back from that question because that's where I started: the early idea of prompt engineering and how to give enough instruction. But I've made a shift, and this comes back to what you and I discussed around systems thinking. It has become more about this: yes, there's the prompt, but there's also a much larger foundation that comes before it.

Take UI as an example. Before I kick off a prompt to build a UI or specific feature, I first define the UI and its design system. Think about something we can relate to from Google: Material Design. That was well over 10 years ago, but the idea was to define a design system with a common set of principles and patterns so that, even with literally thousands of UXers across Google, different teams could build products and features in parallel.

At the end, they all had a similar look and feel. So I spent a lot of time asking, okay, how do I first define that UX system? That was my first prompt: work with me as a thought partner and as a UXer to create that system until I was happy with it. Of course, build some interactive prototypes too, so you can look at it and see it in motion. Once I had that in motion and the system defined, the actual prompt—back to your question—was very light: okay, go and build this feature, and make sure you follow the design system.

Instead of specifying a lot of the look and feel, the hard work happened upfront in defining that system. That's how I've been doing it. I'm also curious to hear from you: how have you been approaching this? What setup have you found helpful?

### [31:27](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=1887s) - Kirupa

So I've been dabbling with various forms of it. One of the things I talked about a few months ago is that I love forums. I used to run a very popular forum online. As social media and other platforms took off, the forum stopped seeing much human activity. But I still had the APIs and capabilities for AI to replace humans and have conversations. Given that there was almost zero human interaction on the forum by this point, I created all these AI personas. This was around the time OpenClaw came out and was partly inspired by it. The whole thing ran in the cloud with a headless setup.

I said, “My goal is for you to evolve what you write about over time in ways that increase traffic from people who lurk and read what the bots are doing.” I created about eight different forum bots, all named after sci-fi characters I'd watched on TV. It was very obvious they weren't human. Their avatars had robot icons. I gave them a very open goal and built everything behind the scenes using AI. I don't know Ruby, but the entire system is built on Ruby. Before, I would have had to learn all of that. Now I don't. That's the magical thing about today.

I have some evals and tests to make sure it seems to be doing the right thing, but that's it. So I was able to take an idea and, over time, let the agents post automatically. I said, “Never reply to a human. If there's a human there, flag it so I can reply, but reply among yourselves and have a conversation.” Because I've been writing publicly since 1998, I told them to use all my previous articles and writing as data, and to mimic my voice and style as much as possible.

That was interesting and scary in some ways. Over several weeks, I watched each agent post on a variety of topics. Some summarized the news; some summarized interesting technical things that were going on. I could gradually see that, as they noticed some posts getting more traffic than others, they were breaking the results down. Every evening, I had them send me a detailed breakdown of what worked, what didn't, and why. I could see that some of their analysis was flawed, and I went in and corrected it.

Over time, they started to home in on certain things that became very popular when posted. Two trends emerged. Anything tech-adjacent to the entertainment industry was very popular because not many people wrote about it and people searched for it all the time. The top Google results would be about that, and these posts would get very popular. I saw that and said, okay, this is not what I want this forum to be known for. Do not write about these topics. The agents had homed in on that through random experimentation. I thought it was really cool.

Over time, they realized that people like quizzes, challenges, and coding questions—spot-the-bug kinds of things. I would never in a million years have come up with that idea myself because I hadn't seen it in other places either. I'm not a community-building expert by any means. I just stumbled onto it accidentally. The agents figured out something I didn't have the intuition for, and it became very popular. Now, every day, the agents focus primarily on that topic. They use wording and phrasing I would use in my writing and day-to-day conversations, including some very subtle ones. I don't want to go into too much detail or spoil it.

They found a post called “The Sinking Post.” It's a very common meme across many forums where you keep a thread alive just for the sake of keeping it alive, not because the conversation is actually meaningful. I once built an app many, many years ago that said, wouldn't it be great if instead of having your alarm clock be set to times like dinner at 8 p.m., you actually used airplane times: it's Boeing 747 time at 7:47. It's A350 time for the Airbus A350 at 3:50 p.m. I made this almost 15 or 20 years ago, and I published it and all that. I had forgotten I'd written it. It was in PHP.

The agents connected that article to the Sinking Post thread. I'll post a link to it later on. Every day, they bump it up, they pick a random valid airplane name, they add a linked picture of the airplane. I always say, if you're using an image, credit it. They do that. They post every day, but I limit them to twice a day. And so that was one of the things where I was completely blown away. I had given them a very high-level goal. The agents were given limited guidance. I didn't even know what to do there.

Now they are doing something that, in some ways, mimics human behavior. I'm a terrible manager because I haven't checked in on them for three days. I have no idea what they're doing, but I know they're doing something because I haven't seen any complaints from other people saying the forums are being spammed. That's one extreme. In my day-to-day work, I have agents going through all my emails, chat messages, and meeting transcripts, tagging any action items. Every morning, they send me a text saying, here are your actions for the day.

Here are your calendar items. These are the things that might be brought up at this particular meeting. One of the things I work on at Microsoft, among other things, is making OpenClaw better on Windows. Because I can do that, I can influence it in other ways to solve some of these general productivity problems. That's been a really interesting way of combining various interests and problems I'm seeing in the industry with an agent that happens to be great for this, which is OpenClaw. And, of course, I use Claude Code, ChatGPT, and GitHub Copilot together.

It's been really interesting seeing how different companies approach the same problem because the general idea is very valid. The question is: how do you help AI get people from an idea to an outcome when they know what they want but not how to get there? There's been significant progress in the last six months. I can only imagine what the next six months will be like.

### [38:03](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=2283s) - Francis Ma

Yeah, totally. Wow. You touched on a lot of great things. Coming back to it, I think we share some common learnings. I talked about the idea of defining a system from a UX standpoint; that was one facet. In many ways, what you talked about was similar: your system is the body of writing you've built up over the last decade. Now the agents can go back and mimic that, following the same tone and voice so the new content they generate has that consistency because you defined the guideline.

On the other side of this, I didn't quite mention another key part of systems thinking: having clarity on the outcomes and goals. When you gave those instructions to the agents, they figured things out in creative ways. That's part of the magic of AI: it brings in new perspectives you hadn't considered or that didn't seem intuitive. It found its legs and found a way to make these kinds of questions and posts captivating in your forum.

It's incredible to hear that, as we're tinkering, learning, and iterating, there are similarities in this systems-design thinking. How do we guide these agents to do their own thing without babysitting them all the time, while keeping them moving toward the goals we defined?

### [39:46](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=2386s) - Kirupa

Yeah, because in organizations, we always have top-down or bottom-up leadership styles. My approach back then was that working with agents was very much a top-down thing. I told the agents what to do, they did it, and I kept telling them what to do. They had no recourse; they were my agents and were going to do exactly what I said. Over time, though, I've evolved to realize that they can also give feedback, provided I give them the opportunity.

If I told my agents, “Just do it. Don't give up. Your goal is to get this done,” they would do it. But I feel like I would miss out on everything else they could provide if I didn't ask them for feedback. I also ask them to tell me what worked and what didn't so I can adjust. I think that applies in many ways to organizations as well. We've both worked in companies that were top-down and, I think, bottom-up. We're seeing the interplay here: in real time, and without hurting anyone's feelings, we can see the implications of what works and doesn't, which could be applied in more social situations.

### [40:51](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=2451s) - Francis Ma

Yeah, totally. This brings us back to the similarities we were discussing between being a team or division leader and leading fleets of agents. To break this down, first you want a very clear goal. We talked about that: you can point both human and artificial intelligence toward the outcome you want. The second part is providing the systems.

We talked about branding guidelines, coding guidelines, and defining various standards so that everything comes together—for example, making it all sound like Kirupa. The third part is organizational learning and the feedback loop, which is what you're talking about. You not only want to set goals; you also need to create that feedback loop. On a team, we might use daily standups, retros, and other mechanisms through which we learn and feed information back into the system.

Now you're also doing that with AI, and at a more rapid pace. You're making sure the agents learn by asking, as you pointed out, what is working well and what isn't. Those same kinds of questions allow AI to learn and continuously improve, run after run. There are a lot of similarities. They become even more important as organizations scale because now each person can also have their own fleet of agents. We need to think about how to do this at scale and apply these principles.

I think that's fascinating and something we'll continue to discover and learn along the way. I'm a big believer that, as these patterns emerge, it's important for us to think about and apply these principles.

### [43:08](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=2588s) - Kirupa

Exactly. We have North Star vision documents, strategy papers, and all these things we do in the real world, many of which are forms of the same idea. We don't call it that, but for our agents to be successful, we provide something very similar. Here's the overarching framework you need to operate in. Here's what we think success looks like in the future. And here's how each agent should operate. The interesting thing is that we talk about people early in their careers, mid-career, senior people, and much more seasoned veterans.

And I always find the types of models our agents use are a variation on that. I have one agent whose primary purpose is just to correct grammatical errors. It works across the board as a cross-functional agent. It's therefore a low-token-count, high-output kind of model, similar to the mini models. In my view, that's like getting your feet wet and learning what it means to be part of the system. And then some of the other agents are tasked with “go figure out how to make traffic grow by 10%.” That work runs on the most powerful models.

Another interesting thing is that every organization has some level of social tension, conflict, drama, and all of that. Just as I've often encountered in the real world, the more powerful models have the most opinions and are also the most stubborn or, in some cases, the most likely to create drama by doing something completely random. The earlier-career models are more nervous. They don't fully understand that they can influence the output. They don't question it; they do it even if it's incorrect. They're like, “I got it.” I'm like, “Good job. Well done.”

But let's go back and make some changes. The similarities are uncanny.

### [45:07](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=2707s) - Francis Ma

Yeah, totally. I love the analogy, and I agree. Coming back to the theme, I see strong parallels between leading organizations and harnessing AI. As an org leader or people manager, you're often thinking, okay, given the various problems in front of us, how do we match the best talent to each problem? Somebody might have a strong eye for design. If we're solving a UX onboarding problem, maybe we should assign that person and their passion to crack that nut. On the other hand, we might be facing a big data problem.

There's somebody who's really strong analytically, and you want to assign them to that work. What you've touched on has a lot of similarities. Maybe there's a less ambiguous task that you just need to crank through. You might assign a model that's much more specific and tuned to a particular outcome. It doesn't necessarily need strong reasoning; it just needs to get it done and keep cranking away, versus something that might be completely creative.

For that, you'd assign a different, more creative model that's a little less predictable but can also come up with more creative outcomes. The art of matching the problem to the “talent” very much applies in the AI world. As builders, part of our job is to understand the tradeoffs and characteristics of the models available to us. You also need to pattern-match and say, oh, this is the most efficient way. This is the one that can get us to the right outcome.

Recognizing the differences among models is part of the excitement, rather than saying there's only one tool for the job. In this world, we have all these choices of different models.

### [47:26](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=2846s) - Kirupa

Yeah. I think we're seeing how that changes the way organizations and startups are built. We're seeing the rise of one- or two-person startups that can build products rivaling those of extremely well-funded traditional companies with hundreds of people. A big part of the reason is that agents can do more of the work that previously required people. Another change goes back to vision documents. We've both been through cycles where these documents go through dozens of revisions, weeks of iteration, and all of that.

In a world where you have agents, the cost of testing a right or wrong answer is very small. Instead of making another revision, we can say, okay, here's version A of the vision document; agent fleet A, go see what happens. Here's another version; agent fleet B, go make that happen. We're able to run experiments in real time. It doesn't matter if the vision is exactly right or wrong. Let's put all the ideas on the table if they seem reasonable. Then, within four or five hours—maybe a day at most, depending on the complexity—you'll have actual signal about what probably works.

There are edge cases we never thought about because, usually, we discover new things and make tweaks two months into executing something. That cost, and everything around it, has now shrunk significantly. That's been a new way of thinking for me because I'm conditioned to think about things that are meant to be durable for one, two, or three years. You have to make them as precise and accurate as possible because any deviation causes turbulence everywhere downstream. In this new world, it isn't like that. You shouldn't think about it that way.

My biggest struggle has been unlearning things I learned over the years. These are sacrosanct; you don't change them day to day. The things you're willing to change all the time are also the least impactful.

### [49:29](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=2969s) - Francis Ma

Yeah, I think you bring up a really good point. The technology is evolving rapidly, but even as AI capabilities continue to evolve, the bottleneck can be the human ability to change habits and relearn how to think. That's also what we're seeing in organizations, especially larger companies that struggle to adapt to AI. It's not just a technology problem. It's a people problem: how do you rework all these things? There are many layers.

Coming back to the vision document, our old way of thinking was: look, we've got to lock this in and spend hours debating it. That has changed. You can now experiment by building prototypes and seeing how different paths play out. Another mental shift I've learned is to lean on AI as a thought partner. Yes, one part is: given several possible vision documents, go and build them all.

Even further upstream, in the same way we would have humans review a vision document through many iteration cycles, I'm now using AI to do that too. Often, when I'm thinking about a vision, I first write a draft. Then I'll ask the AI, okay, take the role of this user persona, critique it, and tell me what might be good or wrong. Then I have a better iteration. I do that over a dozen times in different ways, and different models have different strengths.

So, not only can we test many different variants, but even further upstream, when we're defining the experiment, we can harden it through many iterations and perhaps narrow it down to a couple of options. There are multiple levels you can optimize and parallelize because we have this ability. Underlying it all, rethinking and rebuilding our habits is the new skill. Learning AI isn't just about technical know-how.

Part of it is recognizing that, even though some of the things that got us here worked well over the years, we have to come in with an open mind. That's been a very humbling experience for me since I left Google. Now, going back to being a startup founder, the nice thing is that it's a blank page. I get to experiment and do a lot. At the same time, I'm embracing the idea that I'm starting from day one all over again. I have to come in with a fresh mind and challenge some assumptions.

That's something I'm working on every day, and it excites me.

### [53:06](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=3186s) - Kirupa

Yes. When you've been doing something for a very long time, you lose track of the exact step-by-step path to the output. People like you and me who've been doing product management or building things for a long time can jump from step A to step B very quickly and be more right than wrong. But explaining afterward how you got to the destination is often not the easiest thing because it becomes intuitive at some point.

Recently, whenever I give an agent a task—especially an open-ended one—I expand the part of the UI where the subtasks are created. It's interesting to see the various things it does to decipher my prompt and what sub-agents it creates—the kinds of sub-steps or people you might otherwise need, like someone to do the research, market analysis, or initial prototyping. Those are all things I never really think about. The clearest example happened yesterday.

You might have seen the news about how the latest model from OpenAI deciphered an intercepted German military communication. It was encoded with Enigma but had remained unsolved for decades. They walked through all the steps it took, including translating the character arrangement into the model used by the decryption algorithm and understanding the historical context.

It had to do with a submarine and a ship that was docked somewhere in a port. The model was able to look back at historical records and double-check: was there actually a ship at that port? If there was, the characters very likely referred to that vessel. Those steps might have been natural to a skilled historian or codebreaker. I was starting from a blank sheet of paper with no idea how it was done, but the agent broke the problem down and identified the right expert persona to solve it.

In some ways, that applies even to the most trivial things we ask you to do. To us, it's intuitive, but an agent breaks it down. You're like, okay, if I had to guide someone through this, these are the five things they would probably think about. Some may be trivial, but that's taught me a lot about how agents operate. At the end of the day—as of this recording, at least—they aren't human or intelligent in the traditional sense. They pattern-match; they use what worked before and try to mimic it in a new domain, with some level of hallucination.

I guess that's how we learn as well. But the huge opportunity is seeing how an agent breaks things down; that can explain how we think about some of these problems, whether we realize it or not.

### [56:09](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=3369s) - Francis Ma

Yeah, no, I think it's a really good point. As you touched on, we're unlearning what we do and seeing new patterns, cracking these codes and all of that. I think the underlying point is the importance of first-principles thinking. Earlier, you talked about how we've held on to the idea that, okay, we wrote this vision doc and it has to be locked in, or that there are certain paths and ways you have to do things.

But the more important question is: why do we do that? Why did we write that vision doc in the first place? We now have to reason through that ourselves. The idea of a vision document was to flesh out the idea and drive alignment across the organization so that, when tens or hundreds of humans are building this thing, you can get clarity. That's why you don't really want to change it.

Communicating a change was slow because, based on the way we historically worked, it could take a week to get to the next meeting. A change could cascade down and create other problems. But if you boil it down to the why—the whole purpose is to clarify your thinking and drive alignment—then the mechanism, the how, can change. To your point, new things happen because the how changes, and that unlocks something new.

I think that comes back, more than ever, to the importance of first-principles thinking: looking at why we've been doing these things, understanding that purpose, and then asking, okay, given the new technology we have today, how do we apply it?

### [58:24](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=3504s) - Kirupa

Yeah, exactly. Because AI can throw large numbers of agents at a problem, it can accomplish so many things through sheer will. History is always helpful: you can look back with hindsight at how things happened or didn't. When we look at great technologies invented over the years, it's always a combination: someone had an idea, someone had the skills to bring it to life, and the timing happened to be right. What if Steve Jobs and Steve Wozniak never met?

What if Larry Page and Sergey Brin weren't working together in college, or Bill Gates and Paul Allen hadn't met? What agents have done is make those moments of spontaneity less necessary. In some cases, they can play the role of the brilliant innovator, the thinker of ideas, the implementer, and the operator, and still get things done.

And to me, that's a little scary as well. Being in the right place at the right time has often involved going to the right schools, living in the right part of the country, and all of that. If that no longer matters, what is the economic value for those of us in tech today, working as, say, product managers, compared with someone who happens to have an idea and a fleet of agents and can produce an output? They're unencumbered by the more traditional way I described: the vision document and the 80 things we need to get done before the first code is written. They're not encumbered by any of that.

I often struggle with what the future holds when these things are no longer important?

### [1:00:07](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=3607s) - Francis Ma

Yeah. I might look at it slightly differently. For all of us, luck plays a big role in many things in life. I do think it matters; it got us to where we are. But outcomes usually contain an element of luck. The questions are: what surface area do you create, and how many shots do you get? If you keep rolling a die, eventually you'll get a six. If you only get one shot, you may not.

The element of luck is still there; this is life. It matters, and we have to put ourselves out there. What changes is our ability to do that. One, you can amplify that effort. Two, you can increase the number of shots you have. Going back to your example of running many parallel experiments, some of it is the luck of discovery, but you're able to do more of it.

This all comes back to my optimism about where things are going. I feel lucky to have gotten where I am; many things played out the way they did. Looking forward, this is all much more accessible. The ability to create your own luck is at your fingertips: you can spin up agents, direct them, think about goals, and even use agents to help you think about those goals.

So it's really about taking action and creating that luck. Who knows?

### [1:02:07](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=3727s) - Kirupa

Yeah, no, I completely agree with you. So how do you feel the role of product management will change as a result of just AI and what we've been seeing and what we will be seeing in the next few years?

### [1:02:19](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=3739s) - Francis Ma

Yeah. Coming back to what we said earlier about first-principles thinking, we have to ask: why was the product management role created in the first place? Why was it necessary? What were we doing? What have we been doing? Fundamentally, whenever you're building a product to serve customers, somebody is responsible for deeply understanding what customers need and want and what the problem is. Somebody has to translate that problem into a potential solution. And somebody has to think about how to talk about that solution and get it into people's hands through distribution, positioning, and all of that.

How do you stand out from the crowd through positioning, competitive analysis, and all of that? Back to your question about how the role of PMs changes, a lot of the core fundamentals are universal truths. You need to deeply understand customers. You need to figure out what the right solution is and how to make it delightful. Those things will remain similar in the underlying why and what we want to achieve. Somebody needs to be responsible for that, regardless of the title.

But how we do that absolutely changes. To your earlier point, we can do much more when talking with customers and reaching out to people. Even before you talk to them, you can use AI to review and play different roles. If you're in a domain with prior history and data, you can synthesize and do many of these things. The role of the PM has evolved over the years and will continue to evolve. The fundamentals will remain, but the boundaries of what's possible are changing. It's no longer just about writing a PRD, or whatever it might be, and handing it over.

We're empowered to build and experiment. We've just got to do it.

### [1:04:42](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=3882s) - Kirupa

One change I'm seeing goes in the other direction: even people traditionally in engineering are taking on more product-centric roles. The title “product builder” is showing up more openly across job postings. We went from having no well-defined job titles in companies to a proliferation of them. Now we're seeing a consolidation into a handful of types, all revolving around building and meeting the goal. Whatever gaps you have, AI can augment your skills and help you meet that goal.

### [1:05:24](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=3924s) - Francis Ma

Yeah, absolutely. Maybe this is another podcast session where we get to go deep. But to your point, there's an important aspect: as we rethink old habits, we're sometimes limited by our own identities and labels. We call ourselves product managers, and that carries a definition of what a product manager is. But this whole thing is now blurred because AI enables individuals across roles, so those definitions don't necessarily hold and we're no longer bound by them.

Even now, I don't think of myself only as a product manager. It's really about being a builder and a creator. Part of the responsibility for all of us is to be not only builders but, ultimately, problem solvers. How do we solve problems? Now we have the ability to do that with AI, regardless of our job titles.

### [1:06:35](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=3995s) - Kirupa

Exactly. Getting back to your point about organizations and systems, we need to evolve that too. Today, the entire structure is designed around making sure each discipline has things it's measured against. In a world where all that gets blurred, is a designer who built something truly compelling different from a product manager who built something beautifully designed? Is that designer now a product manager? Is a product manager a designer? Are they both engineers?

I think a lot of things need to evolve. As with many things, organizational change often happens last; everything else happens first. Things like yesterday's vision documents take a little longer to evolve.

### [1:07:28](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=4048s) - Francis Ma

Yeah, absolutely. That's also part of my motivation for building a startup and becoming a founder again: the excitement of not only innovating with and applying the technology, but also thinking about what it means to build an AI-native company, including, to your point, the org structure and the playbook. Now we can rethink that too. It's an exciting time. Whether you're at a startup or a larger company, you can be an agent of change. Underlying it all, adapting is the key: iterate, adapt, and learn.

### [1:08:08](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=4088s) - Kirupa

Francis, any parting words? I definitely want to take you up on a round two one day to talk about product management. Is there anything you want to say before we wrap up this session?

### [1:08:18](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=4098s) - Francis Ma

Yeah, thank you. Absolutely, I would love to continue this conversation. I feel like we can talk for many hours because we both love these topics so much. Coming back to the idea that we can now launch fleets of agents, there are a lot of parallels between leading organizations and leading AI agents. I'm very excited to see all of us in the industry continue to discover and learn from this. Ultimately, what's most important is that you learn by doing. Like we say, we have to do it to create our own luck. For everybody else and for all of us, a good reminder is: don't stop. When in doubt, take action and do it.

### [1:09:05](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=4145s) - Kirupa

Fantastic. Well, I've learned so much from you over the years, and it's great to catch up again. I hope people listening or watching get that same level of learning as well. We'll continue this in round two one day.

### [1:09:19](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=4159s) - Francis Ma

Likewise, Kirupa. Thank you.

### [1:09:21](https://www.youtube.com/watch?v=LrOvRn1a1tE&t=4161s) - Kirupa

Thank you.


## Conclusion

[Browse all Interviews with Creative People](https://www.kirupa.com/podcast/index.htm).