McKinsey & Company has published a new piece, "When AI becomes part of the workflow: Redesigning how software gets built," arguing that capturing value from AI in software development requires reworking how engineering organizations actually operate — not simply licensing copilots and waiting for productivity gains.

The article's core framing will feel familiar to any product leader who has watched a tool rollout stall: the technology is the easy part. The hard part is redesigning the surrounding workflow — roles, handoffs, review processes and metrics — so that AI assistance compounds instead of adding friction.

What does the piece argue?

The full text is available on McKinsey's site. Based on the published title and framing, the piece sits in McKinsey's ongoing body of research on AI and software engineering productivity, which has consistently made one claim: gains from AI coding assistance are real but uneven, and they concentrate in organizations that change the work itself.

For practicing product managers, the implication is direct. If AI changes how fast engineers produce and change code, it also changes:

• How you scope and sequence roadmap items, since iteration cost drops
• Where bottlenecks move — often toward product decisions, review capacity and integration risk rather than raw coding time
• How you measure engineering throughput, since legacy velocity metrics can mislead when AI generates large volumes of code quickly

Why workflow redesign, not tool adoption?

The distinction matters because most AI-in-development programs fail on process, not tooling. Adding an assistant to an unchanged workflow produces localized gains — an individual developer moving faster on a boilerplate task — while the end-to-end delivery timeline stays fixed, because the constraint sat elsewhere. McKinsey's framing pushes leaders to map the full software delivery value chain and identify which steps AI actually accelerates before promising roadmap-level speedups.

The failure mode is symmetric: redesign workflows around assumptions about AI capability that the current models don't meet, and you've traded known friction for new coordination overhead.

What should product teams take from it?

Read the full McKinsey article for the specifics — the piece is aimed at engineering and technology leaders, but product managers own several of the levers it concerns:

• Re-baselining capacity assumptions in quarterly planning rather than carrying pre-AI velocity figures forward
• Re-examining where human review and judgment remain the constraint, and staffing for that instead of code production
• Communicating to stakeholders that workflow redesign is a change-management project measured in quarters, not a tooling switch measured in sprints

As AI assistants become default infrastructure in software teams, expect the differentiator to shift from who has access to the tools to who has redesigned their delivery model around them — a question product organizations will answer in their roadmaps, not just their tool budgets.