Subscribe
Share
Share
Embed
Product managers who vibe code. Engineers who make product decisions. Designers shipping prototypes without handoffs. The roles are blurring, and it's not just because AI makes it possible - it's because staying in your lane might be what kills your company. Else Van Der Berg has been crossing domains for 15 years, and now she's watching the convergence accelerate at AI-native companies like Wave Terminal and SwitchUp.
In this episode, we explore why natural convergers have always existed (but were told to "stick to their lane"), how AI-native startups are staying impossibly small while scaling revenue, and why product-market fit collapse means every company is pre-PMF again.
---
GUEST
Else Van Der Berg - Product Lead & Solopreneur
Else has 15 years of product experience and currently works with two AI-native companies: Wave Terminal (an AI-native terminal and dev tool) and SwitchUp (AI-native internal tools). She's spent the past nine months vibe coding, building AI agents, and exploring the convergence of product and engineering firsthand. As a "natural converger," she's been pushing domain boundaries long before it had a name.
Find Else:
- LinkedIn: https://www.linkedin.com/in/dr-else-van-der-berg-42b8b6a2
---
TIMESTAMPS
00:00 Introduction and Guest Backgrounds
07:30 How PM, Design, and Engineering Roles Are Evolving
16:59 Why AI Makes the Convergence Real (Beyond the Hype)
19:38 Can Legacy Tech Companies Adapt to This Shift?
25:25 Scaling Culture: Why AI-Native Companies Stay Small
34:04 Real Examples: Unsend, Wave Terminal, and the Iteration Factory
40:09 Product-Market Fit Collapse: Why Everyone's Pre-PMF Again
44:46 M-Shaped People: Masters of None or Cross-Domain Advantage?
55:35 Why Over-Specialization Is Anti-Agile
01:01:32 Wrap-Up
---
KEY TAKEAWAYS
1. Natural convergers have always existed - that 1973 journal proved developers worked directly with clients. We artificially specialized and now we're going back.
2. AI-native companies are the new anti-flex - Cursor: $100M ARR with 12 people. Mid-Journey: $200M ARR with 40 people. Growing headcount isn't cool anymore.
3. Product-market fit collapse is real - Stack Overflow got destroyed overnight by ChatGPT. Every company is pre-PMF now because AI competitors can appear instantly.
4. The handoff tax is more expensive than learning - product trios sound nice until the developer can't make the interview and the designer is "too busy with sprint work."
5. Delivery is discovery now - at Wave Terminal, they shipped a full app builder in 3 weeks just to validate if people would use it. Building is cheaper than talking about building.
---
CONNECT WITH PRODUCT ENGINEERS
Host: Peppe Silletti
LinkedIn: https://www.linkedin.com/in/peppesilletti/
Product Engineers Community:
Newsletter: https://productengineers.com
LinkedIn: https://www.linkedin.com/company/product-engineers
---
SUPPORT THE SHOW
If this episode made you question whether you're a natural converger who's been told to stay in your lane, share it with someone who needs permission to cross boundaries. Drop a comment below with your take on the convergence trend.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit
Product Engineers is the podcast about the convergence of product and engineering in the AI era: what's breaking, what's working, and the craft of doing both well.
[rock music] I've been working side by side with engineers for 15 years, but I cannot code, nor can I read code, nor can I judge the quality of code, of code.
I have been heavily vibe coding for the past nine months, I would say. Um, I'm also an avid user of Claude Code. I use it mainly for non-coding purposes, so for, um, um, analyzing unstructured data.
Um, I'm now also loving the PostHog MCP, so unstructured, um, analyzing quantitative data. Um, so I use AI agents quite a lot. I've also vibe coded my own AI agents for my product work. Um, and I am a solopreneur.
I'm currently working with two AI native companies, um, in different ways. So one of them is Wave Terminal, which is an AI native terminal, really kind of on the forefront, cutting edge kind of stuff, um, dev tool.
Um, and the other one is Switch Up, which does not have an AI, um, AI-driven consumer-facing product, but we're building AI native internal tools, and we're very much hiring for these convergent roles.
Um, so I'm a little bit in a bubble, very much in a bubble, so I think that kind of colors the way I'm gonna talk about this. Yeah, thanks.
So I mean, for people that are first, first time on this podcast, um, uh, I'm Peppe Siletti. Actually, Giuseppe is my full name, but everyone calls me Peppe.
So I am a software engineer by trade, so I've been doing that for the last 10 years, and worked mainly in startups and scale-ups.
And in the last, I would say three years, I've been really getting into this product engineering mindset and first it started with more as being like a more product minded and trying to get engineering more involved in product decisions and not just, you know, being at, at the end of the assembly line implementing Jira tickets.
But I mean, uh, as, as also with the AI e-evolving and
also looking at how certain companies are working with engineers, I'm focusing more and more on, on the actual product engineer role, which is way more than just being product minded,
owning product problems end to end, and that's why we're here to, to talk about the convergence, um, because it's very interesting how engineers are getting more involved in, in product decisions and in product work.
On the other w- um, but also product managers and even designers are getting more and more technical and more involved into something that before AI they couldn't do.
Yeah, so I think we're gonna have a lot to talk about, so I'm gonna spin this wheel and let's see where, where it takes us. Okay, so I think I can just put full screen. Yes. Spin. Exciting.
[chuckles] Nice touch, Peppe. Oh. I wanted it to land on the other one. [laughs] No. We're gonna get there. We're gonna get there. Okay. Okay. So the first one is gonna be about the evolving PM design engineering roles.
That kind of comes, like, at the right time. We were talking about this. Do you want to start or want to start? You start. You can start. Go for it. Okay. I'll, I'll start. Right. So yeah. How are these role evolving?
I think, so at least let, let's go in order. So at, at least for engineers, I've seen this trend, uh, k- uh, this trend not really in the, in the last, uh, couple of years with AI.
I think it, it started even before that. So seeing how engineers wanted to have a bit more impact in the wo- in the, in the work they were doing.
So I think that's how I also got into this kind of new way of working because I really wanted to have more impact in my, in my job, not just coding without understanding how my, my work was going to impact people lives.
And so I think it started, I f- I think there are some companies that are always working like this, um, most of all in the startup environments and, um, one of them, for example, is, is PostHog.
So they started, I think they were,
they, they, they've been created in, uh, 2020, and they had already product engineers back then, and they already have had this very, uh, strong o- uh, culture of ownership where engineers were solving problems end to end.
They never had PMs, at least for the la- the, the first two years. And then as the company scaled up and they started to, um, having a bigger context to manage, they needed PMs to kind of working as a, as a, um...
What's the English for that? Like, to, to give direction to engineers- Mm-hmm... so they could, could make better product, uh, product decisions.
So I think for engineers, this kind of, this kind of involvement in product and in, into design choices has been growing for a bit. It's been very niche. But now with AI, I think it's been accelerated way more.
For PM and designers, I think it's been a bit slower because before AI, they really couldn't use any gen AI tools to, to create code or to vibe coding any, any of that. So they were a bit more limited in that sense.
Maybe there were some no-code tools which were even, like, maybe not super powerful, but sometimes a bit complex.
But yeah, the, the, um, the kind of advantage that gen AI brought to PMs and designer, I think has been the possibility to spin up prototypes very quickly.
And, and now what I'm seeing is PMs and designers that are, instead of just waiting for an engineer to create a prototype, they can just go on one of the platforms and create the prototype by themselves and then use that to continue the, the research they're doing, the customer interviews.
But the interesting thing for me, the most interesting thing is that the product, the more traditional product roles are de-developing an engineering mindset.
Because it's, it's, um, all, all the good, uh, software engineering practices, for example, working in small increments, continuous delivery, and, you know, testing continuously,
they are also important with vibe coding, even if you don't see the code that you- Yeah... that you're, that you're writing. So I really like this kind of awareness that product people are having because- Yeah...
we are kind of, uh, we, we can finally understand each other. We-- there is more empathy from their side. Uh, so I think it's... they c- they can only come good things out of this. Yeah, so that's, that's what I think.
Yeah. Um, I think firstly, obviously, there have been natural convergers forever, right? There's always been these people who couldn't stick to their lanes, right?
Like I think you and I were both these people even before maybe there was an official word for it.
Um, I very much struggled before with the product role because in my first product role in 2016, I was constantly talking to sales and customer support and marketing, trying to understand, like, what are you guys doing and what message are you putting out there because that needs to correspond with what the product is and who are we building for.
Like, are we talking to the same audience? And I was constantly cut off and told, like, "Stick to your lane. You are product. You just take business requests and you translate them into Jira tickets."
So I was already going out into different domains and was told, "This is not what a product manager does."
And later, thanks to Marty Cagan, yes, it is what a product manager is supposed to do, but I-- that, that came later, right?
So, and I think in backlog refinement meetings, there has always been a couple of engineers who are going like, "How did we validate this? Is this really the right way? Who did you talk to?
Um, what does this feature solve?" Um, so these people have always been there, and I think a lot of people are natural convergers.
Um, and I think that's something that's really important to understand when we talk about the main argument that people raise against this being that you can't be an expert in multiple domains, right?
You should be a specialist because if you try to become a generalist, you become a master of none. The cognitive load is too high. It's not possible. Um, I think yes and no.
In German, they have a word jein, right, which I very much like.
Yes and no because there are these natural convergers who are just more comfortable holding more domains in their heads, and I think I am one of them, you are one of them.
Um, so actually having this artificial distinction is much harder.
Um, I found a LinkedIn post the other week, uh, where somebody pasted like a piece of a journal from 1983 describing what an engineer should do, and it basically says, it-- So it had already been in use since 1973.
This was the model. "Developers themselves have a close relation with the clients. This results in high motivation, flexibility, and low overhead."
So developers speccing things out, developers being in touch with clients, this was the norm in 1973. Um, somehow we evolved from that to having these very strict cut-off specializations, but
it doesn't have to be that way, right? Um, of course, I have been accused of shiny new object syndrome, which is also a little bit true, right?
Because it's, it is very exciting as a PM to be able to vibe code and do all kinds of stuff. But so what, a little bit of shiny new object syndrome, right?
If it leads us to try new things out and form a real opinion on our own, then why not lean into a little bit of playing- Yeah... a little bit of shiny new object syndrome. There's, of course, a danger.
I'm not gonna deploy what I vibe code to production where there's like thousands of users.
But there is so much power in having engineers, designers, and product people being able to identify problems, come up with solutions, build these solutions, and start validating assumptions, start learning on their own, right?
Because I think the only thing that matters in a startup or a scale-up is speed of learning. We've been talking about this for ages. So I think this convergence is the way there. Yeah. Yeah.
No, I like y- your last point because, like I've, I've seen...
Since, since all this AI thing like, uh, kind of boomed, I've seen a lot of people I were following before that kind of got obsessed about bashing against AI because AI is bad and the code generates is bad.
Like they really f- fixated on a very small scope, which is their own technical world.
But I, I f- I'm finding that is, it's way more useful to think about the impact of AI a bit more holistically, so on end to end, from like the, the discovery part to the, to the actual implementation.
And as you said, there is nothing wrong about trying things. Why not? Okay, it could be just, could be a fad eventually, but I don't think it's a fad.
But you have to try, you try yourself, just really push the limits- Yeah... and see where you can get. But I think we, we also we're gonna need a bit more time to kind of prove it.
We need years to see, okay, what's been the impact of using these tools on production systems. It's a bit too early to, to say that.
I mean, there's a lot of research, or like a lot of articles about how especially enterprise companies have not seen any ROI on AI projects, and that lots of things are stuck in pilot phase, and that, um, this X promise is not actually happening.
People are actually not getting more productive. There's a lot of research about that. But then I look at my own work, right, and what I do. I use AI all the time, right? I'm constantly talking to Claude or to Gemini.
I'm constantly in some interface talking to an LLM. Um, the impact is massive, right? Maybe I'm not even necessarily faster, but I'm way more critical in my thinking. Mm-hmm.
I think the, the key there is being able to handle the vast amount of output that LLMs generate- This is, I think, a problem that we need to tackle in our brains.
We need to be able to handle a lot more input without getting exhausted and being able to judge what is good. I think the, the trick is to know what to discard and what to build upon. Um, it's kind of an art form.
But I do that a lot, right? So through conversing with AI, I feel for sure my thinking has gotten much clearer. I don't, I do not outsource my thinking.
I use my own brain, but I use LLMs to sharpen everything, to poke holes. Um, and I for sure feel like the work I deliver now is much, much better than what I did five years ago. I don't care what any report says.
Um, and also having vibe coded for nine months, the leaps that AI has made are just insane, right? It's just insane what it can do now- Yeah... versus what I did, what it did six to nine months ago. So
of course, people are predicting it will never replace engineers, it will never replace PMs, it will... I honestly don't know. Like, I really, I have no, I don't know what will happen.
I'm amazed, a bit scared, but honestly I'm also thinking new roles will occur, right? Which is already the case.
Yeah, I find it just, it's, it's impossible to predict where this stuff is going, but it is possible to look at your own experience today, right? And, and mine is just- Yeah... amazing. Yeah. Agree.
So let's spin the wheel again. Let's see where it takes us now. This is one of your favorites. [laughs] Yes, it is. Yes. [laughs] So can legacy tech companies adapt? I find this a very interesting one.
I had this question somebody was asking at a meetup the other day of like, okay, how are the new AI native companies operating today? Think Lovable, Perplexity, Linear, whoever. Like how are these companies working?
A lot of, lot of this has to do with much more flat hierarchies, a lot of convergent roles, founders explicitly talking about how they want to hire for these convergent, more M shaped people versus a legacy tech company like HelloFresh or Zalando or any of the cool companies, the cool tech logos that we wanted on our CV for a very long time.
Can these adapt?
And my thinking is it's gonna be very, very difficult for them slash impossible because if you have a beast of an organization with a very classical org chart, with a lot of middle management layers, um, and a lot of people sitting there who are not necessarily convergent and also would like to push against it, because I, I talked a bit earlier about natural convergers.
I also know the opposites. I think you've met them too, is the people who say, "This is my turf. Don't touch my turf." Like that product manager who says, "Hey, you're an engineer. Sit down and code.
Please do not ask any questions about why this is important. It's because I said so. I did the research. Do you not trust me?" Takes it as a personal attack.
Um, and the other way around, of course, the engineers that say like, "What are you doing vibe coding? It's all slop. Um, just go back to, to writing specs." Like, "Stay out of my turf, stay out of my turf. This is mine.
This is yours. Don't touch." This is extremely common. I think I've met in, in every organization, so many of these people are sitting there. In the worst case, these are in the leadership team.
Um, if 50% of the leadership team is people who would love to hold on to these strict specializations, which is not unlikely because these are the people who climbed the ranks in this game,
it's gonna be near impossible to change that culture.
You're gonna have to do something similar to what Brian Chesky did with Airbnb in like 2019, not related to, um, being AI native, but he at some point noticed that the company was shipping much slower and was not delivering a lot of value and made a very hard cut.
Um, let go of a lot of people to really change the culture. That is a very expensive, difficult choice to make and a, and a big bet.
Um, so I doubt that many legacy tech companies are going to do that, um, and they're gonna probably lose because of it. Right.
Uh, do you think these big companies may experiment with these new approaches on maybe new products?
'Cause I, I can imagine like a company like Google, for example, they have a lot of legacy, huge products, and the people are working on those products probably will be still the traditional r- uh, having the traditional roles, but maybe on new products that they could treat more like a internal startup.
Do you think that could be a way to start experimenting that and maybe then cross-pollinates across the companies?
Yeah, I think Google is a pretty different kind of legacy tech company because we know that, I mean, we've seen Gemini 3. Google is able to keep up. Um, took a while.
I think at some point everybody, everybody was like, "Where's Google in this? Where's Google?" And now, okay, yes, we see them. They're here. Um, so clearly they can afford, um, top talent quite easily.
They can bring in whoever they need, um, and they have already a culture of building fast, experimenting fast, and, and discarding what doesn't work. I think you're probably familiar with Google Graveyard.
This has always very much been Google's culture, so maybe not the best example for this. I've seen some scale-ups try to have a small island of people who work in this different way.
It's very hard to make this work, right? Because you cannot enforce a real cultural shift in one island that is embedded within the larger organizations.
Companies love to have a small task force or like a small, right, to try to get out of this, these tentacles, but it often doesn't work because this task force is somehow linked to the legacy organization and, and slowed down because of it.
Um, so possibly it can work, but I've seen it fail more often than not. You today actually, uh, published this article about AI, AI native startups that have a specific way of operating.
For example, Lovable is a very good example. So once these startups start... scaling up and they become bigger and bigger, uh, is this culture going to change or is this going to happen at all?
Are they going to scale a- as in the past or are, are they going to stay small? I think a hallmark of these companies has been their small size.
And I think if you compare them, so in this article I also put a, a small comparison. Cursor, 100 million ARR with 12 people. Mm-hmm. Midjourney, 200 million ARR, 40 people. Yeah.
Bolt went from z- near zero to 40 million ARR in five months with about 20 people. Linear, less than 50 people. ElevenLab, like, they're all small companies, right? Um, so that is a super clear pattern.
I doubt that all of the sudden they're gonna shout from the rooftops, "This year we're gonna grow with 300%." That is not the flex that it was before. I think it's an anti-flex now.
Um, so they will probably need to grow headcount at some point, but they're not going to... I, I expect they're not going to grow headcount for the sake of growing headcount. Yeah. Um, only...
So they're gonna be much more sparing. Of course, they will have to scale to some extent, so they definitely- Mm-hmm... will have this problem of how do we do that without losing this culture.
I mean, scaling up is extremely difficult always when it comes to preserving these very important principles.
There are a variety of ways to do it, um, but I, I doubt we will see them scaling as rapidly as was seen as necessary or cool before. Also, simply because people are much more effective thanks to gen AI tools. Right.
Right. So yeah, I think another example is, I mean, I always mention them, PostHog. So they have 150 employees, I think, more or less, or, or maybe a bit more.
But yeah, it, it's still a lot of people, and they work like this. They, they have a, just a few PMs, but it's more like, um, PMs are not involved like in the, like in traditional PMs in all product decisions.
I think when, when we t- when we think about scaling up, like scaling up, it could be, it can mean, uh, it can mean different way, right? With different things. So it could be like that we have a very
high amount of people, even like in the thousands of people. It could be that we have very big systems in place, so m- I'm gonna think about Facebook. That could be a idea of the size.
Uh, so, uh, like at, at this, at this scale, I think the operations become a bit more, more, more complex, right? So how do... I'm thinking how do product engineers, for example, fit in this, in this context?
Because the, the, um, there is a way much more context to, to, to handle for, for a single person and to also influence a product decision. So I would, I would think like
on a product like Facebook, for a single engineer to take a full feature end-to-end pr- probably is gonna be quite difficult. Mm.
So that's something I've been, I've been kind of thinking for a bit, and the only idea I have is that the same as PM, so I, I make this comparison, product engineer can maybe have a influence on a smaller part of the system, so like on a, on a small scope and trying to influence just that part of the system instead of the whole thing of course.
And even if we think about, uh, teams, ev- every team i- in a, in a company can still kind of act as a, as a small startup where these kind of values and way of working can be preserved.
And then you will need some kind of role to coordinate between all the teams when there is a, maybe a decision that needs to involve multiple stakeholders. But yeah, I'm just thinking out loud here.
That's a bit like Spotify tribes. Is that kind of what you're thinking about? Yeah, it could be. Yeah. 'Cause if I think about like systems that have a high load, that have a lot of users, where- Mm-hmm...
product engineers do a lot of the driving and there aren't any PMs, Lovable is now hiring their first product person. Right. They have a lot of users, right?
So I think there is absolutely no reason why an engineer cannot s- use, learn the skill set that a PM has. Mm-hmm. Right? S- It's not rocket science. [laughs] Yeah.
So it's, there's absolutely no reason why they couldn't also do that, um, especially with a to- a tool like PostHog or Lovable, where it's very close to what an engineer uses themselves, so it's kind of like home turf.
It might be more complex if you're saying we're gonna build some B2B software for harbors, like, like something really niche and weird that an engineer has absolutely no touch points with.
Um, but especially something like PostHog or Lovable, I totally see why a product engineer could make very good decisions, um, also about larger parts of the product with a lot of users.
And of course, if they ship a change, they wouldn't ship it to 100% of the users, right? They would use proper product pra- practices of first shipping it to 0.5% of traffic, and then 1% of traffic, and then 1.5.
Um- Mm-hmm... so these engineers, they will hopefully learn proper product management practices and validate with qualitative tests first, and then like have a limited blast radius by
rolling it out to a small section of traffic first and seeing what happens. So even with a high user load, I think product engineers can pretty safely impact big features that touch everyone. Yeah. Yeah.
Yeah, I think, I think the, the, the challenge could be only in, in, in the coordination with other teams, for example. So that, that could be one.
So if you have, I don't know, uh, maybe this is more in, in the enterpr- enterprise world, you have this big... software that are made of different services. Mm-hmm.
So usually an engineer works only on one of those services, not on, doesn't touch all of them. But there could be some f- some feature that are kind of, kind of can touch multiple these services.
And for example, this is where staff engineers w- work usually across all these teams.
So in, in that sense, I think in startups, of course, it is, it's less likely it happens because usually systems are newer and smaller.
Um, but yeah, as, like, th- these actual software and products grow in size, there are way more actors in place. So I think it's more about
a, a challenging coordination and holding the, the context on the, on the product level about, like, all the services together. So like system thinking- Yeah... this is very important here.
But I, I think this is, this is where a product manager is, is very useful at the end of the day, right? Still remains very useful.
And I wonder if it's, i- in the future, instead of having product managers, we're gonna have lead product engineers that are going to do a bit of both.
So they're gonna be more on the product side, the same as a tech lead now, but it is gonna be i- in the middle, uh, to, to help with coordination and, but both on the product and also technical side. Okay.
Let's, let's go to the next topic. Example of companies. Well, yeah, you, you have already listed a few. These are the...
I, I don't know if they actually hire product engineers as, as a title or maybe they also have, like, software engineers that kind of work like product engineers, I guess, right?
Yeah, and there's also quotes by their, like Lenny Rachitsky does a nice podcast that I think all of you will know, and there's a lot of episodes with, of course, people from these companies who talk about how they specifically hire for convergent M-shaped people, whether they call it a product engineer or whatever, and that everybody is supposed to be able to identify problems and start coming up with solutions and crafting those solutions.
Okay. So I'll, um, I'll tell you about my favorite company at the moment, uh, 'cause I, I just interviewed the, the CEO, uh, a couple of weeks ago, and it's called Unsend. Mm-hmm.
And they are a, a Swedish company that developed this AI agent to help, I think, freelancers with their relationships on, on different social platforms as a way to make human-driven sales.
I think it's something like that. [laughs] Hopefully I didn't mess it up. But yeah, the, the thing I like about it is that th- they have this concept of iteration factory.
So of course, everyone is a product engineer there, and they, they, they, they meet up every day, and they use, uh, the stand up to understand what experiments they have to drive that day, and they call it the daily sprint.
So they ditched completely Scrum, and they said, "Okay, now we're gonna have daily sprints," because they, they ship so fast that they can run these experiments every day,
uh, both on the product side, so for a new feature, also for, like, on the, on the technical side, maybe they have, uh, an experiment about changing the algorithm that they use.
So everything they, they, they talk about, they never talk about features, they talk about, uh, hypothesis. So they just run them every day, and then they have a weekly reflection meeting.
And instead of having quarters for goals, they have, uh, they do it every three weeks. So they, they kind of keep it, like, shorter. But I, I really like this, this way of working and the, the name Iteration Factory.
Uh, they were just kind of, it goes against the, the feature factory. Um, and, um, yeah, so that, that, that's, that's my, my favorite company at the moment, the, the way they're working. Do, do you have one?
I mean, Switch Up and Wave obviously. No, but it's interesting what you say, and I think I've been saying for a long time that you shouldn't treat delivery as something other than experimentation, right?
Like shipping a feature, delivery is experimentation. It is actually the probably strongest experiments, right?
You're shipping an MVP version or you're shipping a slightly more evolved version of a feature or a product to learn, right? Launch data is test results. Mm-hmm. Um, so it makes absolute sense.
It just, it's much faster and much cheaper now to, to generate that kind of stuff.
And I- like, interesting what I found at Wave, I used to before really preach that you should validate stuff before you build because building is expensive and building causes product bloat.
Um, and now we just build a lot basically to, to validate because in the end we're doing something kind of futuristic, so it's quite difficult to validate it without just putting it in the world and seeing what happens.
We try. I still run the qualitative tests that I've always been running. So I, I run, um, landing page tests where I put different value propositions against each other and I see how people respond.
I do interviews to look for hair on fire problems. We do all of that. But in the end, the strongest evidence comes from shipping something, and we are operating so much more on conviction than I did before.
Gut feeling seems to be back in trend, um, because we, we can do that because it's kind of, it's a lot cheaper for us to be wrong.
We just relatively quickly, within like two or three weeks, we shipped a full app builder, basically a lovable inside the terminal. We were like, "Is this a good idea? Maybe. It could be really cool. Will people use it?
Will people know what to use it for? Oh, I don't know." So we did like a couple of interviews, but you can't really get there. So we're like, "Let's just build this."
And three weeks later it was there, and now we can just see if people use it. Doesn't mean I don't have to run other qualitative tests to understand do people understand it? Is it usable? Do people find it?
But because shipping is so much faster and cheaper, I do a lot more of it. So that definitely changed how I approach discovery and, and even more so on the idea that just shipping code, delivery is- Discovery 100%, yeah.
And d-d-do, do you think this would also work, uh, in, um, like, um, more established products that don't require maybe as much experimentation?
I mean, I think at the end of the day, you still need to ship the thing and see if it works. But I think more...
Th-there's gonna be more money in this, this context to pour in, and failure is a bit more accepted, um, something like that. You mean failure is more accepted at larger companies? I don't think so.
If you, if, um, if they don't experiment in, in that sense, so if they don't do it, if they f-follow more, like, planned way of working and eventually they,
they fail, um, there is a risk because we know that waterfall is a risk of failure because you do these things in steps, but you don't validate along the line. So there, there is a risk to, to actually fail.
But in that sense, a bigger company probably can survive that failure a bit more. Mm? Yeah, although I feel like that has changed, right? Mm-hmm. I've, I've been reading a lot about product market fit collapse.
Brian Balfour of Reforge wrote a very nice essay about it. Elena Verna, who does growth at Lovable, talks about it a lot. Mm.
So it used to be pre-AI era, we talked about pre-PMF and post-PMF, and pre-PMF, everything was fuzzy.
You're trying to figure out a problem that's important to solve and the right solution for it, and we don't really know what we're doing. It's very hacky.
It doesn't have to scale, and, and it's like crazy experiments to figure out what we're doing, and then we hit product market fit.
Wow, and now we can coast because we have product market fit, and we will likely keep product market fit. But now we're gonna focus on optimizing what we have. We do not need to innovate as much.
We don't need to figure out. Something clicked, we just optimize it.
I think that world is gone, and not just for AI-native companies, but for all companies, because even if you are not AI-native, some AI-native company is coming for you. Mm-hmm.
I think the first product market fit was first described a lot for any company that revolved around user-generated content like Stack Overflow.
Because, of course, all of a sudden people were typing into ChatGPT instead of going to Stack Overflow, and they just saw numbers collapse, right?
From having, like, pretty, you know, everything fine to really bam, um, and this happened to a lot of non-AI companies. Um, for AI-native companies, it can happen also very quickly, right?
Because all of the sudden you've built your whole company around something not existing, and all of a sudden Anthropic builds it, and yeah, you're gone. Um, right?
So product market fit collapse is, is very important and also for, for income-incumbents, they cannot coast anymore on the idea that they are just safe.
Um, and I think this is where they're in deep, deep trouble because the only way to keep product market fit is kind of to stay on this treadmill. You have to keep running. You have to keep innovating.
You have to keep coming with big, innovative, exciting ideas, and the only way you can do that is to have this pretty different org structure that AI-native companies do have with all of these M-shaped convergent people who are bringing so many diverse ideas to one problem.
We don't have just the PMs and the business side staring at a problem, but we have the whole organization excited about where everything is moving, staring at problems, trying to understand the zeitgeists, where are we at, bringing all of these diverse, exciting, bold ideas, and they're able to test them, validate them so much faster, and the cost of them being wrong
is not that high because they, they know how to experiment, and they can execute so fast.
So this is a huge problem for these larger companies who have relied on having PMF and maintaining PMF because it could just get eaten, and they don't have the learning velocity needed to keep up. Right.
So I guess it's gonna get a bit more exciting for people working in, in those companies with established products. They can go back and... Yeah. I mean, everybody always told me- We can. We can... like, "Oh, you're so...
You're too focused on pre-PMF companies. You should focus on growth stage companies because you'll earn a lot more money." And it's like, but I really like the pre-PMF world of uncertainty. I'm good at it.
I've been doing it my whole career. I, I, I enjoyed this phase, and now I'm like, "Ha ha, you're all pre-MF now, pre-PMF now, guys." Let's keep spinning. Sweet. Oh, we go to your favorite one.
So M-shaped people, are they masters of none? I'll let you start. Yeah, I think-- So this is the, the main counterargument, right? Like, uh, I was also told, "You're a product manager.
Focus on what you are good at, right? Strength. Use LLMs to strengthen your strengths. You are good at product discovery. You have business acumen.
You understand finance, so go deep on that and do not try to cross over to different territories because you will never be good enough to be like a senior engineer who can actually ship production-grade code, so just don't touch it at all."
I think you and I both see the value of having an understanding of technical concepts even without getting to the point of being as good as a senior engineer, and I know that I have learned so much in the last
six to nine months through vibe coding and building agents and talking to Claude Code and being in these environments. I am not you, right? I am not an engineer. I still cannot judge whether code is good.
I understand so much more, um, and especially when building an, an AI product, you cannot really pull them apart.
I feel like what the technology can do and what users expect and what the product is, they are so intertwined.
It's very artificial to say, "Here's one person writing a spec and the other person executing the spec, and they do not understand each other's jobs." With an AI-native product, it just- Doesn't make sense, right?
Because they're extremely intertwined. But of course, there is a risk of the cognitive load just being too high, um, and you're just spreading yourself too thin.
Of course, you could say, "Okay, it's easier to upskill because of AI." You can spar with Claude Code, where of course you need to be aware of sycophancy and being very much in an echo chamber with yourself.
We are aware of that. We know that. Plus the wall of output, right? I like to... I sometimes think of myself as Neo from The Matrix.
I don't know if you've loved this movie as much as I did, but like they need to learn how to drive a helicopter, and it's like zzz, and then they can drive a helicopter, right?
It's a little bit like that, except for the fact that it doesn't go into my brain.
It's just on my laptop screen, and I still need to get it from there inside my brain, and that is very hard, and I still need to judge whether the output is good and whether this is something I should be putting into my brain or not.
So obviously there are risks. Nonetheless, I do think it is much easier for us to upskill ourselves.
Before, I could not lock our senior systems architect into an, a meeting room and go like, "Please explain everything to me," and I have a thousand stupid questions. But now I can do that with Claude Code,
um, and it's pretty decent at giving me answers. So again, it's a yes and no, but I think also th-there's these people who are natural convergers, who naturally gravitate into other lanes.
So not doing it seems absolutely silly, right? I feel like the cognitive load is almost higher when you're not allowed to drift into the other lane and, like, have to try to stay in your own lane.
So I absolutely see the risk, but I do not think it necessarily has to be the case. Yeah. There's, um... I, I remember when you, you started to share with me, like, your adventures on a repl-replit, and I, I...
It was very good for me to see how you were think- you started to think about developing with the, like, your, your SaaS. And like, yeah, "I'm going on GitHub.
I'm going to look for the right libraries, checking if they work and the, the, the stars and if they are maintained." I said, "Oh, that's great. That's exactly what I would do." So- [laughs]...
it, it, it comes naturally. So there are all, all these, let's say, more meta activities around building a software that
I think that those are the easier, easier, easiest, easier to, to learn, uh, for, uh, for product people.
I think the, the hardest part s- for sure is gonna be the, the coding part, uh, because that, that will require some time to, to, to learn and to, to do. Talk-talking about risks, I think there is one, one, um,
one, uh, thing that experts may have more than, let's say, generalists, like amateur people, which is, um, mental representations. This is, this is a concept that comes, like, from, um, a book that I read.
It's called Peak. Uh, it's from the, like the, um... It, it's from a research that, a researcher that studied deliberate, deliberate practice.
So mental representations means that you are, are put into a, um, a situation, and as an expert, your brain knows already automatically how to handle it.
So I don't know, like, uh, climbers know how to put their hands automatically on, on the, on the, on the thingies, right? I, I, I... For, for us it's the same. So, like, as an engineer, I...
When I see, when I read code, when I see a, a software system, I can identify immediately, or with some time, but quite fast, uh, if something is wrong, um, because I've seen it many, many times.
And maybe it's the same way for a UX designer. They can spot some- that an interaction is bad because they've seen it- Yeah... many, many times. So I think that's something that
could be lacking in people that started to upskill now. But- Yes. But. Exactly.
But I think for me, like, as we were saying at the very beginning, it could be an opportunity also to explore how we can create this mental representation faster,
and so how to create better learning practices so that we can be exposed more and more and more to this kind of, to dif- to different problems and solve them.
And as I was chatting with the, the C-CEO, Ansend, we were actually talking about this. I thought there are a lot of, a lot of UX designers that suffer of the same problems, and engineers suffer.
So we have code monkeys, they have pixel monkeys. So they just have to implement these, these things, you know, without doing maybe no research or just develop this UI, whatever.
But le-let's say product engineers, they would be owning the process end to end. I think they would be exposed way more to the whole process and in a shorter period of time.
So I think they could potentially be learning way faster maybe than someone that has been doing only UX designer designing- Yeah... for a long time because of the way the industry has made, has made us work.
But this is, yeah, this is my, my idea. I also think I like this, what you said about mental models. That's good but also bad sometimes, right?
Because you're so stuck in your box that you always just do the same thing because that's what you do- Yeah... over and over.
But there's beauty in this cross-domain, domain way of working where you're like, "Hey, if I apply that theory that comes from this domain to this totally different domain, what happens?" Right?
If we muddle these boundaries, actually beautiful things happen. And also if we have people who stretch the entire context, I think obviously they can make better decisions here if they also know what happens here.
Um, an example of somebody who crosses domains quite quickly is, is Elon Musk, for example, who you may or may not be a fan of.
That aside, the man has built successful companies, and he's done that, like, that you're like, "What?"
It's just this guy who first built electric cars is now doing rockets, and now he's doing a, a social media platform. What?
So he, he is a person who jumps from domain to domain very quickly- Can somehow very quickly understand what is important and kind of push through norms, push through boundaries with knowledge, like, I guess first principles thinking, and knowledge from different domains to do impressive things in a way.
It's a bit of a hard one to talk about, but you know what I mean. Yeah, yeah. No, yeah, definitely. It's, um, aside all the political stuff, I think- Yeah... it's been always very fascinating how it could innovate even,
uh, in, in, in such industries where that kind of disruption was, you know, never thought before. Like- Exactly... with, um, destroying, uh, rockets like that, one after the other, just to test.
But it's what we do with MVPs every day. Exactly. So that's really cross-domain thinking, right? That's- Yeah... if you come from that industry, you would never do that.
I'm also not sure if it's a good or a bad thing, that aside, right? But this is really not having the mental model for the win. Yeah. Yeah, yeah. Um, I mean, that, that book I read, it was more about, um,
like practical skills, so like, I don't know, could be music, drawing. In that sense, of course, it makes sense to have these mental representations because your hands need to be in the right place.
But yeah, at least, yeah- But these practical skills we need less and less also, right?
I feel like these practical skills are kind of fading more and more, and what is left, what is important, is the creativity and the- Yeah... human intelligence. Yeah.
And that's exactly the thing where maybe sometimes having this cross-domain perspective is really good, is better. Yeah. Agreed. So
agile is something that in the, among software developers is something that we all try to, to strive to, for. And
the, the, the thing is, when you have all these overspecialized roles and where everyone is in their own lane doing their own things, producing their own outputs, it, it's nearly impossible to be, to be agile because, of course, you have this kind of pipeline of, of steps where the PM has to divide the tickets.
I mean, the, the, that kind of PM, let's say, has to like do discovery, write the tickets in Jira, and then talk with the engineers, get an estimation, talk with the designer for looking for a wireframe, and then the, the, the engineer gets the wireframe.
And even if, like these, these roles work in a trio like, uh, as like Teresa Torres, uh, books, unless you work in the same room, like a, like a kind of pairing or in a mob- Yeah...
multiple times a day, you're still gonna have these, these handoffs and these delays. So I think that's where it becomes anti-agile. While I think if you, if you want to be truly agile, you need to own the whole process
because then you don't have, you immediately remove the handoffs of course, and things can move, can move faster.
Um, yeah, so th- that's, that's something that I think agile has been failing a bit, and also because we've been really focusing about agile on, on the software development side, on the, on the delivery side, and a lot of companies
have all these nice development teams working like that, and then the, the rest of the company is, uh, still making very long-term plans, uh- Always. Yeah... yeah.
So working in agile in that sense doesn't really make any sense in my opinion. No. But now w- with
these new roles you, you are, we are also converging the business side to more the product is part of business at the end of the day. So we are converging these two things, so we're gonna speed things up. Yeah.
I think agile got a bit of a nasty aftertaste for no fair reason, not because of agile's fault- Yeah... but it became a little bit uncool because it was just so painful, I think- Yeah...
for a lot of people to work in Scrum and pretend to be agile, as you say, in a waterfall organization where we have yearly planning and like basically every feature is already planned out for the next year or so. Yeah.
Why are we delivering value in incremental steps to get feedback, [laughs] right? We're just gonna do it anyway, right? So I think most of us have felt this.
I, so I was, I was very interested in this, in this journal that I read that, that was very much about developers being close to customers already in 1973, and how we moved away from that, and I was also looking into why we moved away from that.
And my understanding, you can correct me if I'm wrong, that the web, the internet as it came out was relatively simple. Mm-hmm.
It was very possible technically for one person to handle everything, but it grew more and more complex technically. Yeah. So we kind of needed to have these specializations to be able to maintain this beast, right?
We needed to have DevOps people and backend engineers and front end engineers, and then we needed to have product people to do something else because it just grew so large and we needed these specializations.
And the question is whether that is not the case now or less the case now, right?
I think there definitely has been a trend to simplifying things more to the point that I can use Replit and I can code and deploy and have a, a database and everything is just in there in a nice package and there's a bow around it, and I just hit publish and it's done, right?
So, so I think there's definitely a move back to simplification. Um, and then also people being able to upskill themselves into other territories with, um, friends like Claude.
So I think we are able to move back in that direction that obviously makes more sense. But I think for a long time we kind of needed these specializations because things were just very complicated otherwise.
But this handover tax that you're talking about is real. I've been working in product trios- Yeah...
for a long time, and it was always like, okay, we're gonna have this product trio to break through this problem, and we're gonna have engineers and designers and product people, and they will all have the same context and they will sit into interviews together.
But then the reality is the developer cannot show up. The developer sits into one or two interviews out of 10 because the developer has to write code.
The developer is in a sprint, and I want to run a cool landing page test, and I'm saying to the designer, "Please do me this landing page." And they're like, "No, I'm doing production grade designs for the sprint."
Um, so it's very nice that we can finally break through that. Yeah, 100%.
Yeah, I think we, as engineers, I think we also kind of affected the complexity of these systems because a lot of us really enjoy complex systems, so we made things way more complex than they should be.
Like think about on microservices, and that's been a, a trend that is improving fortunately.
But yeah, I think we can, um, I know you have to go, so we can wrap this up, and else it's been- Yeah, sorry, I was just telling somebody we're coming. [laughs] No, no worries, no worries.
Um, so yeah, so it's been pleasure, uh, running this, this chat with you. Um- Thank you. Thank you for having me, and speak soon. Speak soon. Bye bye. Bye.