For years, we structured teams around separation. Product understood the user and translated that understanding into specs, wireframes, and roadmaps. Those moved through approval cycles before design created mocks, which moved through more approvals before engineering scoped the work and estimated delivery. That separation made sense when building was slow and iteration cycles were measured in weeks. Documentation and handoffs were the bridge because the distance between thinking and building was wide and slow. AI has compressed that distance. Prototypes can now happen immediately, often directly in code, and increasingly in ways that align with real architectural patterns instead of disposable demos. The gap between idea and implementation has narrowed, and when that gap narrows, the handoffs between disciplines become visible and expensive.
This is already changing what product and engineering roles look like. A PM in this era is not just writing specs and reviewing mockups. They are shaping implementation directly. Great PMs have always been good at synthesizing user motivations, product goals, business constraints, design considerations, and technical trade-offs into something coherent. That skill maps directly onto working well with AI. Good prompts are not clever one-liners. They are structured intent. They reflect user motivations, product goals, business constraints, edge cases, priorities, and trade-offs. Prompting is less about phrasing and more about framing. Engineers bring something equally important. They understand system boundaries, performance implications, failure modes, and architectural coherence. They know how to encode rules and evaluate whether a solution will hold under real-world pressure. Even in testing, the boundaries blur. Some of the best user acceptance testers I’ve worked with were PMs, because they hold the full shape of the product in their head. They understand the user’s intent, the form factor, the constraints, and the likely edge cases. Yes, we can automate testing with agents. We’re getting better at automating frontend testing. But there are judgment calls, gut instincts, and empathy layers that still matter. The advantage is shifting toward people who can move between intent and implementation, not those who stay isolated in one layer.
This is not theoretical. If you are a PM, start reviewing pull requests and asking why certain architectural decisions were made, even if that feels outside your lane. Make small changes yourself so you understand how the system behaves in practice, not just on a roadmap. If you are an engineer, go beyond implementing the ticket by advocating for the user, suggesting design improvements, and questioning the flow when something feels off. Sit in on user interviews. Understand how the product is positioned and how decisions are framed, then bring that context back into the code. The goal is not to replace the discipline next to you. It is to become fluent enough to remove friction and improve decisions across the boundary. This is the beginning of a deeper focus on the product and engineering intersection, because that intersection is where roles are expanding and contracting at the same time. Pure product and pure engineering were artifacts of a slower era. That era is closing. If this hasn’t shown up in your org yet, it will. Better to expand into it now than react to it later.