The Product Builder Is Showing Up in Berlin. Here's What We Know — and What We Don't.
A new title is appearing in Berlin product teams. Not everywhere, and not yet with a stable definition. But enough companies are posting for it that it is worth taking seriously.
They are calling it a Product Builder: someone who can own the product direction, design the UX, and ship code to production. One person. Three disciplines. AI as the infrastructure that makes the breadth possible.
I have been pulling this thread for a few weeks. I sat with Guannan Li, Director of Product Growth & Design at ablefy, who is actively hiring for this role and has screened more than 200 applications. These are some reflections from that conversation and from what the market is already showing.
What we already know
Ablefy has a live job posting for this role right now. Mid-to-senior design experience, strong product thinking, and enough technical reach to build product components in production. The expectation: 80% independent ownership, AI tools as the infrastructure that makes the breadth possible. That is not a whitepaper. That is a job posting with a salary attached.
Zoom out and the signal gets louder. LinkedIn had its decade-long APM program: the most copied entry path into product management in the industry. They scrapped it in December 2024. The replacement is an APB: Associate Product Builder. No resume accepted. Candidates submit a working product and a 60-second demo. LinkedIn stopped selecting for credentials and started selecting for the artifact.
Linear has been running a version of this for years without calling it anything. No product managers, one Head of Product, teams that assemble around a project and disperse when it is done. Typically one designer and two engineers. Profitable for two years. $35,000 spent on paid marketing in the entire history of the company. The model is not theoretical: it has a track record.
At the other end of the scale, Walmart filled all their agent builder roles internally. Every single one. Their CPO confirmed it publicly. And at Meta, PMs are already calling themselves AI builders without any title change. The title stayed the same. The output changed.
A few kilometres away, Nick Mulder at Hypofriend posted something even more direct. A team of fewer than 20 people, rebuilding a mortgage broker AI-native from scratch. The role: Junior AI Product Manager. His note: “The title doesn’t matter.” The application: build something with Claude and show us. Fresh out of university is fine.
This should not surprise anyone. The Product Manager role has had the same problem since the beginning. At some companies a PM writes code and sits in engineering sprints. At others they never open a Figma file. At others still they are project managers with a better title. The label has always landed differently depending on stage, size, and what the founder decided mattered. The Product Builder is inheriting that same ambiguity on day one. Hypofriend wants someone who can ship from zero. Ablefy wants a senior specialist who has been quietly crossing disciplines on their own time. Both call it the same thing. What sits underneath both definitions is the same question the PM role never fully answered: can you decide what to build, build it, and know if it worked?
What this means if you’re hiring
The ROI case for this role has two parts. The first is communication overhead: three people doing one job spend more time transferring context than most companies admit. Think about the simplest case: a customer reports a minor UX issue on mobile. As a PM, you validate it, write a ticket, brief the designer, wait for the solution, brief the engineer, wait for the build, then validate again with both. Five or six touches to fix one small thing. A Product Builder sees the issue and ships it. Two fewer people to bring into context. No back-and-forth on whether the brief was understood correctly.
The second part is accountability. The user does not experience your spec, your design, or your code. They experience the integrated thing. When three people own three separate pieces, accountability is distributed across the seams between them. When one person owns all three, there is a clear owner for what the customer actually encounters: the full experience, not a handoff.
And the expectation is not that this stays rare. The companies running this experiment are not building around one exceptional person:
“We do not expect this to go into one person as a hero. We actually expect the majority of people will become product builders” — including engineers who can own a problem end-to-end, from customer feedback to shipped fix.
The hiring approach that seems most honest right now is running two parallel bets: promote one person internally, hire one externally, and see which model works better. The internal bet is on expandability: someone who already knows the product, the users, and the context, and can grow their craft into adjacent disciplines. The external bet is on someone who has already crossed disciplines on their own time, through their own projects, out of their own curiosity. The real interview is not a whiteboard: it is a case study. Identify the problem, connect it to business metrics, audit the UX, improve the design on brand, ship something. Show the artifact, not the slide.
“You do not have to prove you can draw, or use Figma. But you need to prove that you can create a user-friendly product yourself.”
The portfolio is now non-negotiable — not just for designers, but for product managers and engineers applying for this role too. That is a structural shift in how candidates are evaluated.
But the harder implication is the one nobody writing about this role seems to surface. The first friction when moving someone into a Product Builder role is not capability. It is time. PM work is organised around availability: many meetings, constant stakeholder contact, scattered attention across many parallel conversations. Design and engineering require the opposite: deep focus, sustained craft time, the ability to hold a problem in your head for hours without interruption.
“Skill is not the only benchmark.”
Which means that before you hire or promote a Product Builder, you have to decide whether you are willing to restructure how that person’s time works. If you are not, you are giving someone a new title and the same impossible calendar. This is why Linear’s model works. The whole organisation is designed to protect focus time. The structure is what makes the role possible, not just the person in it.
One more risk worth naming: what breaks when the Product Builder is not exceptional? In a traditional triad, a weak PM gets caught by the designer or the engineer. In a team of one PB and two engineers, the gap has no one to catch it. The risk concentrates instead of distributing.
What six months of preparation actually looks like
At ablefy, one person has already been successfully transitioned into the role. It took six months. The story of how it went wrong before it went right is more useful than the outcome.
The first problem was not the person being transitioned. It was the engineers reviewing their work. When a designer starts submitting code, the PRs are rough. They do not follow internal engineering standards, naming conventions, or the review processes the rest of the team has spent years internalising. It was slow, it created friction, and some of that friction came from something more uncomfortable than code quality: engineers worried that the industry was changing in ways that were not good for them.
What helped was treating the transition as a two-sided problem. Engineering training for the product and design team: workshops, knowledge sharing, learning how to use AI to review your own code before submitting so you are not dumping half-baked PRs on engineers who feel like they are babysitting. And on the other side: volunteer engineers who stepped up to give educational feedback on early PRs rather than simply rejecting them. Both sides had to move.
There was also a technology factor: an Anthropic model release in late 2025 meaningfully improved the quality of AI-generated code, making it easier for non-engineers to produce work that engineers could actually review without wincing.
Six months in, it works. The resistance that felt structural turned out to be time-based. The team needed to see it working before they stopped pushing back.
What this means if you’re looking for a job
The question worth asking yourself: is your career built on coordination that is disappearing? A lot of senior PM careers were built on moving work through the system: aligning research, design, and engineering, managing the handoffs, holding the context across three separate calendars. That work is genuinely valuable when the roles are separate. When one person owns all three, the coordination layer compresses dramatically. What remains visible is the craft itself.
Roger Wong wrote something sharp about this. The senior people succeeding in Full Stack Builder roles at LinkedIn almost all spent years as a specialist first. They developed taste through depth in one discipline, then crossed into others sequentially. The profiles that stand out are the ones who are already senior in one domain and have spent the last six to twelve months expanding into adjacent skills on their own.
If you are trying to make this transition yourself, the threshold is not vibe coding. It is whether you have good taste: do you know what good UX looks like? Can you use a product and feel when something is off, before anyone tells you? That does not require a design background. It requires having built enough things, used enough products, and cared enough about the experience to develop an eye for what works. That gap does not close through a course. It closes through building things and being wrong enough times that you start to recognise the pattern before it happens.
On salary: the market has not caught up yet. Companies are not paying significantly more than senior PM. The harder question is seniority. If the role is genuinely new, how do you evaluate it? Do you need to be senior across all three disciplines to earn a senior title? If yes, almost nobody qualifies. Most companies are working around it by using the PB path as a promotion track for senior PMs who have hit the ceiling of their current band. The financial case is real: but it is a career structure argument, not a market premium.
Speed was never the problem
AI compresses the execution layer. That is visible now. What remains is judgment about what to build and why.
This is where the Product Builder framing gets partially wrong. The excitement is mostly about execution capability: one person can design, ship, and iterate without waiting on three separate calendars. That is real. But it says nothing about whether that person has the critical thinking to decide what is worth building in the first place.
Leah Tharin put it plainly recently: most teams now ship the wrong things, faster. AI did not solve the speed problem. It exposed the direction problem that was always there. The PM wrote a spec. The designer interpreted it. The engineer built something adjacent to both. Each translation lost a little fidelity. The Product Builder does not fix this by being faster. They fix it by being the only person in the room who has to live with all three decisions at once.
Speed without direction is just chaos with better tooling. [Epic sentence Leah!]
One view on where leadership lands: the role bifurcates into product strategists who focus on direction and product builders who own execution end-to-end with a small team. Fewer layers in between. It is a compelling hypothesis for now.
What is already visible is that more small teams running in parallel does not mean fewer meetings. The coordination problem moves but does not disappear. More teams means more alignment surface. AI has not helped with this part yet.
What I do not know yet
The Product Builder at its best is a return to an older shape of the role: one person who sees the problem, designs the solution, and builds it. Before companies got large enough to justify splitting those three into three headcount, that was just called building a product.
What I do not know is whether that role, inside a company that is not yours, can develop the same sharpness that founders develop. The founder’s critical thinking gets honed by something specific: the knowledge that if you build the wrong thing, it costs you everything. That is not a capability you develop from a job description, however well written. It comes from skin in the game.
There is a second thing founders have that the Product Builder inside a company does not: control over their own calendar. The focus that makes good craft possible is not a personality trait. It is a structural condition.
And there is a third thing worth sitting with. What happens to the people who are genuinely good at this and start to feel the pace as accumulation rather than progress? AI makes you produce more. But more for whom, and at what cost? The Product Builder model assumes that removing friction in the handoff is a clean win. I am not sure it accounts for what happens when there is no one else in the room to slow you down, and whether the time you used to spend in those handoffs was also, sometimes, the time where the thinking happened.
LinkedIn is running the experiment at scale. Berlin startups are running smaller ones. In a year or two, we will know more.
Sources
Daniele Ronca — Founder, Productlab
Guannan Li — Director of Product Growth & Design, ablefy
 | A guest post by
|