Guest
Product Lead working with AI-native companies, including Wave Terminal and SwitchUp
I wanted to close out the year by going deep on the topic that started this whole community: the convergence of product and engineering roles. Else Van Der Berg has been living this from the product side, vibe coding for nine months and working with AI-native companies. We spun a wheel of topics and let chance guide the conversation.
The Natural Convergers
Else made a point that reframed how I think about this trend:
“There have always been natural convergers, right? There’s always been these people who couldn’t stick to their lanes.”
She described her first product role in 2016, where she kept reaching out to sales, customer support, and marketing to understand what messages they were putting out there. The response? “Stick to your lane. Your job is to take business requests and translate them into Jira tickets.”
“Later, thanks to Marty Kagan, yes, it is what a product manager is supposed to do, but it came later.”
And in every backlog refinement, there were always a few engineers asking: How did we validate this? What does this feature solve? Who did you talk to?
The main argument against convergence is that you can’t be an expert in multiple domains because the cognitive load is too high and you become a master of none. Else’s response:
“Yes and no. There are these natural convergers who are just more comfortable holding more domains in their heads. Actually having this artificial distinction is much harder.”
This kind of cross-domain thinking is exactly what system thinking enables.
1973 Called
Else found a journal from 1983 describing engineering practices from 1973:
“Developers themselves have a close relation with the clients. This results in high motivation, flexibility and low overhead.”
Developers speccing things out and talking to clients directly. This was the norm fifty years ago, but somewhere along the way, we over-specialized.
The web grew more complex. We needed DevOps, backend engineers, frontend engineers, product managers. The systems got too big for one person to handle everything.
But now tools are simplifying again. Replit, Lovable, Supabase put everything in a nice package with a bow around it. You hit publish and it’s done.
“I think we are able to move back in that direction. Not just because things are simpler, but because people can upskill themselves into other territories with friends like Claude.”
Can Legacy Companies Adapt?
I asked about established companies. Can they adopt this way of working?
Else was skeptical:
“If you have a beast of an organization with a very classical org chart, with a lot of middle management layers, and a lot of people sitting there who are not necessarily convergent and also would like to push against it... it’s going to be very, very difficult, slash impossible.”
She’s met the opposite of natural convergers. The people who say “this is my turf, don’t touch my turf.” The PM who takes it personally when an engineer asks why something is important. The engineer who mocks designers for vibe coding.
“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 going to be near impossible to change that culture.”
The only path? Something like what Brian Chesky did at Airbnb in 2019. A hard cut. Let go of people. Fundamentally change the culture. That’s a big bet most companies won’t make.
The Small Team Advantage
We looked at the numbers from AI-native companies:
Cursor: 100 million ARR with 12 people
Mid-Journey: 200 million ARR with 40 people
Bolt: Zero to 40 million ARR in five months with ~20 people
Linear: Less than 50 people
“I doubt that all of a sudden they’re going to shout from the rooftops ‘this year, we’re going to grow headcount by 300%.’ That is not the flex that it was before. I think it’s an anti-flex now.”
These companies will grow, but not headcount for the sake of headcount. People are just more effective with AI tools.
M-Shaped People and the Master of None Problem
The counter-argument came up during our conversation: aren’t you spreading yourself too thin?
Else admitted the cognitive load is real:
“There is the risk of the cognitive load just being too high. The wall of output, right? I sometimes think of myself as Neo from the Matrix. They need to learn how to drive a helicopter and then they can drive a helicopter. It’s a little bit like that, except 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.”
But before AI, she couldn’t lock a senior systems architect into a meeting room and ask a thousand stupid questions. Now she can do that with Claude Code.
“I absolutely see the risk, but I do not think it necessarily has to be the case. The cognitive load is almost higher when you’re not allowed to drift into the other lane.”
Product Market Fit Collapse
Here’s what really got my attention. Else talked about how the concept of “post-PMF” might be dying:
“It used to be pre-AI era, we talked about pre-PMF and post-PMF. Pre-PMF everything was fuzzy. Then we hit product market fit. Wow. And now we can coast. We don’t need to innovate as much. Just optimize what we have.”
That world is gone.
“Even if you are not AI native, some AI native company is coming for you.”
Stack Overflow had product market fit, and then people started typing into ChatGPT instead. Their numbers collapsed.
“The only way to keep product market fit is to stay on this treadmill. You have to keep running. You have to keep innovating. And the only way you can do that is to have this pretty different org structure with all of these M-shaped convergent people who are bringing so many diverse ideas to one problem.”
Legacy companies relying on maintained PMF are in trouble. They don’t have the learning velocity to keep up.
Is Over-Specialization Anti-Agile?
We ended on something I’ve been thinking about for a while. When you have specialized roles with handoffs between them, true agility becomes nearly impossible.
PM does discovery, writes tickets, talks to designer, designer creates wireframe, engineer gets the wireframe. Even if they work as a “trio,” unless they’re literally in the same room multiple times a day, you get delays.
“I’ve been working in product trios for a long time and it was always like, okay, we’re going to have engineers and designers and product people all with the same context. But then the reality is the developer cannot show up. 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 this landing page. And they’re like, no, I’m doing production grade designs for the sprint.”
The only way to be truly agile is to own the whole process yourself and remove the handoffs entirely.
As Else put it: everyone always told her to focus on post-PMF companies because you earn more money. She liked the uncertainty of pre-PMF work.
“Ha ha, you’re all pre-PMF now, guys.”
