The Rise of Product Engineering

#engineering #productengineering #techleadership #ai

Originally published on BlockSimplified — 4 min read

Something I told every new engineer who joined my team: "You are not a frontend engineer. You are not a backend engineer. Those are just tags for the domain where you have depth. You are a product engineer."

Most of them looked confused. Some pushed back. But the ones who got it became the strongest engineers I have worked with.

Marcin Roszczyk wrote something recently that put words to what I have been saying for years: AI is not killing software engineering. It is exposing what engineering actually is. For the past two decades, we called millions of people software engineers, but most of the work was implementation. Assembling systems, translating requirements into code. Now that AI can implement faster than any of us, the gap is visible.

I agree. And I have seen this play out firsthand leading teams of 10 to 14 engineers as a Tech Lead and Principal Engineer.

For years, our industry rewarded implementation volume. Ship tickets. Close sprint points. Move fast inside your lane.

When implementation stops being scarce, judgment becomes the scarce asset. And that is what is happening right now.

Product engineers, not label engineers

Frontend and backend are domain tags, not identity. They are not excuses to ignore the rest of the user journey.

If you are on frontend and the integration is painful, saying "the API is wrong" is not engineering. Explain why it is wrong. Show the contract problem. Propose a better shape for the response. Make it easier for both the client and the system.

If you are on backend, payload size is your problem too. A heavy response hurts parse time, rendering performance, and perceived speed in the browser. Engineering means optimizing the whole path, not just your endpoint benchmarks.

The role trap early-career engineers fall into

I see this often: new engineers rush to lock identity around FE, BE, or DevOps.

Specialization is good. Role tribalism is not.

Real engineering comes from curiosity about how the full application behaves end to end. You do not need to be a jack of all trades. You do need enough context to make decisions that help the product, not just your layer.

A real example from my team

We were building local-first software. On first launch, the app needed to sync a large dataset and configure the local environment. We had already stripped initialization to the bare minimum, but the setup still took long enough that users bounced before seeing any value.

The obvious fix was a loading spinner or progress bar. But that just tells users "wait." It does not solve the actual problem: the user has no reason to stay.

Two backend engineers proposed something different. Instead of an empty loading state, show interactive marketing slides that teach users how the product works and what they can do with it. At the bottom, display clear messaging about exactly what the system is doing and why it takes time. The user gets oriented and sees value before the app is even ready.

The constraints were real: the slides had to load instantly from bundled assets (no network dependency during setup), the progress messaging had to be accurate (not a fake progress bar), and the transition to the live app had to feel seamless. They prototyped it, tested the timing, and shipped it.

NPS went up. Bounce rate during onboarding dropped.

The best part: two backend engineers drove this from idea through execution. They did not say "that is a frontend problem." They saw a product problem, understood the user experience constraint, and built a solution that worked across the stack.

That is product engineering.

A necessary caveat

None of this means specialization is dead. AI still makes junior engineers dramatically more productive at implementation. There are domains like performance-critical systems, security, and compliance where deep specialists are exactly what you need. Not every team needs product engineers. Some need someone who knows memory allocation patterns better than anyone alive.

The point is not "everyone should do everything." The point is that curiosity beyond your lane is what separates engineers who grow from engineers who plateau.

Final take

AI is rewarding engineers who are curious beyond their lane. The next generation of strong teams will be built by people who can reason across boundaries, communicate trade-offs clearly, and care about outcomes more than labels.