In the last post, Amy Johnson asked the question of what happens when AI accelerates delivery, and but discipline of product thinking starts to erode.

Here's a perspective from a Tech Leader.

Amy shared how we tested out having our forward-deployed engineers embedded with our clients without the partnership of a product manager. The challenges shared were that without someone accountable for strategy and outcomes, the team drifted into a steady stream of enhancements and edge cases. While the work remained technically strong, focus weakened, prioritisation suffered, and burnout risk increased.

Tech Perspective: The Title Might Not Survive, But the Thinking Must

Clearly, teams are converging. Forward-deployed engineers working directly with clients already shorten the loop — adding a PM layer can feel like adding a translation gap, another point where requirements lose fidelity on their way to implementation.

But the answer isn’t to eliminate product thinking. It’s to recognise it needs to live wherever ambiguity lives. As PMs get more technical to leverage AI, engineers also need to lean into product — learning established frameworks for discovery, validation, and prioritisation. As building gets faster, more time opens up for these deeper conversations about value. Engineers who can ask the right questions, validate problems, and think beyond implementation will be the ones who thrive.

The PM title might not survive this convergence. But the discipline of being value-oriented rather than output-oriented must persist, regardless of who carries it. If you’re technical and working closer to the client or end user , invest in product skills now — the frameworks exist, and the time AI frees up is your opportunity to use them.

Tech Perspective: If PMs Stay, They Must Adapt With the Technology

If your team does keep a dedicated product manager in a fast-moving AI-powered delivery environment, the old ways of working won’t cut it. Slide decks, Miro boards, and verbal handoffs are invisible to AI-assisted development. If the AI can’t see your research, your prioritisation logic, or your domain context, it builds without it.

The PM who thrives here is one who captures andmaintains AI-friendly artefacts — structured research findings, documented decision rationale, acceptance criteria that AI can parse — and makes them accessible where AI can reach them. That might mean product artefacts living alongside the code in the repository, or surfaced through integrations like MCP (Model Context Protocol), so they inform every phase of delivery automatically.

This isn’t optional upskilling. It’s the difference between a PM who adds value at the speed the team now operates, andone who becomes the bottleneck they were brought in to prevent. The artefacts you produce need to be as connected and machine-readable as the code your engineers write.

Tech Perspective: Disovery that Compounds

The risk isn’t just that discovery stops — it’s that even when discovery is happening, the insights don’t persist in a way the system can use. An interview finding that lives in a research report but never reaches the AI context is invisible to every subsequent implementation decision.

AI is perfectly placed to continually re-evaluate new findings from the market against the product, and vice versa — surfacing contradictions, validating assumptions, and identifying where new evidence changes priorities. But it can only do this if it has access to the full picture.

The key is incorporating discovery outputs —research findings, competitive analysis, user feedback, market signals — in a centralised way that AI can leverage holistically. When that happens, discovery doesn’t just inform the next decision. It compounds across every sprint, and AI becomes a continuous sense-check against the market reality your product lives in.