Why This Field Matters

Linear’s engineering openings carry the title Product Engineer. The senior and staff bands use it, the AI team role uses it, and a separate fullstack engineer posting sits right next to them. That separation is the point: this is treated as a different job, not a rebranded one. Replit hires under the same title.

The difference is scope. A product engineer does not start from a spec document. You find out what is awkward for users, pick which of those things to fix, draw the screens, ship it, and two weeks later read the numbers to grade your own call. It does not mean there is no PM or designer. It means you are at the table when the decision gets made.

The reason these roles are multiplying now is that implementation time has collapsed. When agents produce code faster, the bottleneck moves upstream to knowing what is worth building. OpenAI’s own research on AI at work describes adoption as widening the range of what people do rather than narrowing it. David Jones, who built an advertising holding group, told the Financial Times that machines now handle 95 percent of the work in his company. There is a more cautious read alongside that. A Stanford SIEPR policy brief argues for separating the hype from the measured employment effect using actual data. Titles are moving first and the statistics are still catching up.

Required Skills

• Choosing the problem. You run user conversations yourself. The harder half is deciding what not to build, and being able to defend crossing three items off the request list.
• Finishing the design. Empty states, loading, errors, unauthorized views, drawn without waiting for a designer. Shipping the happy path and handing off the rest is half the job on this track.
• Instrumentation. Design the event schema before you ship. Bolt analytics on afterward and you never learn whether your call was right.
• Fullstack and deploy. Frontend through data model, migrations and rollout. Owning a feature end to end is what earns the decision rights.
• Delegating to agents, then verifying. Push implementation to tooling and spend the recovered hours on judgment. Without the eye to review what comes back, you only get to the wrong answer faster.
• Short writing. A one page spec, a five line release note. Skip it and the same argument reappears in six months.

Career Path

In the junior band you take one feature from problem statement to release by yourself. What you learn there is not syntax, it is the feeling of having picked the wrong problem. As a senior you own a product area and shape priorities alongside the PM rather than receiving them. In the staff or lead band you decide what the team will not touch at all, and turn that judgment into the hiring bar.

In the US market this track sits mostly in product led startups: Linear, Replit and companies that keep teams deliberately small. Big tech keeps a sharper split between PM, design and engineering, so the equivalent work there hides inside senior IC roles rather than a title. Either way the resume signal is the same. A list of shipped features reads as generic. One paragraph about a feature you argued against, and what the retention numbers did afterward, reads as this job.

If you prepare one thing for interviews, prepare a five minute breakdown of a feature you built that users never adopted, and why you got it wrong. Everyone brings the wins. Almost nobody has taken a loss apart.