The Lines Are Blurring

At Wix, product managers and designers are contributing code to the main project. The co-founder says this is the future for every company.


The Reality

There used to be a clean, simple rule in every tech company:

Developers write code. Everyone else writes documents about what the code should do.

Product managers wrote specs. Designers made mockups. Marketers wrote copy. And then they all waited for developers to turn it into reality.

That line is dissolving.

At Dazzle — a startup within Wix — something unusual is happening. Product managers and designers are pushing code directly into the main project.

“Not huge things,” says Nadav Abrami, Wix co-founder. “But if we want to change the publish dialogue, if we want to change the media gallery… this is done by the product managers and the designers, not by the developers.”

Read that again. At a $5.5 billion company, the people writing product specs are also making changes to the product itself. Not in a sandbox. Not in a prototype. In the actual codebase.

This isn’t a gimmick. It’s a preview of how every company will work in three years.


The Shift

Here’s the model Abrami describes: developers don’t disappear. They evolve.

“The developers become the gatekeepers. They’re in charge of making sure the code still makes sense in the end. But they’re not going to be the only contributors of code.”

Think about that shift. Developers go from being the sole producers to being quality controllers. Everyone else becomes a contributor. The factory model — where only certified workers touch the machinery — is being replaced by something closer to collaborative editing.

It’s the same thing Google Docs did to writing. Before cloud documents, one person “owned” the file. Now everyone edits in real time and someone makes sure it all holds together. That’s what’s happening to code.

The Old Way: Clear role boundaries. PMs write specs, developers write code. “I’m not technical” was an acceptable identity. Contributing to the codebase was exclusively an engineering function.

The New Reality: The role boundary is dissolving. PMs who understand their product’s architecture and contribute small code changes are dramatically more effective. Developers shift from sole producers to quality gatekeepers. The question isn’t whether you’re a developer — it’s whether you’re willing to understand what’s being built.

Abrami is honest about the friction: “It’s not going to be simple maybe politically — just making the organization accept that PMs are starting to put in code — but I think it’s so worth it.”

The political resistance is real. Developers feel territorial. Managers worry about code quality. PMs feel intimidated. But the productivity gain is too large to ignore.

And here’s the hidden benefit most people miss: when a PM starts understanding the codebase — even superficially — they become better at their actual job.

“It’s going to teach you how to talk to the developers better. You’re going to have a common language with the developers on the team that you never had before.”

The point isn’t to turn PMs into engineers. It’s to give them enough fluency to collaborate at a level that was previously impossible.


What To Do Next

You don’t need to start pushing code tomorrow. But you should start building the muscle.

Here’s Abrami’s practical advice: “Sit down with whatever AI tool you want that has access to your project — the actual project — and start asking it questions. Ask it for a high-level diagram.”

That’s step one. Just ask AI to explain the architecture of whatever you’re working with. Where do the files live? What does the database look like? What happens when a user clicks this button?

You’re not trying to become a developer. You’re trying to understand the machine you’ve been managing from the outside.

Step two: find one small thing. A text change. A button label. A color. Something so simple that a developer would spend more time context-switching to it than actually doing it. Make that change yourself using an AI coding tool. Get a developer to review it.

Step three: make it a habit. One small contribution per week. Over time, you’ll build fluency that makes you a fundamentally different kind of product person.

“The fact that you’re not a developer doesn’t mean that you don’t write code anymore.”


The One Thing to Remember

AI didn’t replace developers. It blurred the line between people who build and people who decide what to build. The professionals who embrace both sides of that line will be the most valuable people in any company.


This insight comes from Nadav Abrami, co-founder of Wix, on the Aakash Gupta podcast. The AI Shift curates wisdom from AI leaders for busy professionals navigating the AI era. Have you ever wished you could just make a small change to your product yourself, without waiting for a developer?

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *