Andrew Ng: the slow part of product work is now the talking between people

The relay race is breaking down. For years, product work moved in a straight line: PM writes the spec, designer makes the screens, engineer ships the code, and everyone waits their turn. AI just made building cheap, and now that neat line is starting to cost you more than it saves. Let me catch you up.

The deep cut

• Cheap building makes judgment the scarce part. When Zapier ships a PRD in minutes, deciding what to build is the work that is left.
• Friction was where the thinking happened. John Cutler warns that automating the steps between a call and a ship strips out the moments people used to pause and say no.
• The junior queue was a training ground, not a chore list. Patrick Neeman shows the tasks AI now eats were how new designers learned craft.

The handoff got expensive

Building used to be the slow part, so you spent weeks getting the spec right before anyone wrote code. That trade made sense when engineering time was scarce. It does not anymore. The Product Journey lays it out plainly: when building gets cheap, the wait between deciding and doing turns into the bottleneck.

Andrew Ng put a number on the reversal. If one PM decides and one engineer builds, the talking between them is now the slow link. The fix is not turning everyone into a coder. It is shrinking the distance between a decision and real evidence. LinkedIn swapped its Associate Product Manager program for an Associate Product Builder track, and the final interview now asks candidates to build something end to end, live. The signal they want is judgment, not tooling.

When the friction was doing the thinking

Here is the catch nobody put on the roadmap. Those slow steps between a customer call and a shipped feature were not just drudgery. John Cutler calls it positive friction: each time you had to reshape a note into a takeaway, then a takeaway into a plan, you were forced to stop and think. Automate all of it and you can go from five calls to 80 opportunities to 400 tasks, and never once ask if any of it is real.

His rules are worth stealing. Keep original feedback linked back to its source. Label how much AI touched each artifact. Do not let a tool become a dumping ground just because it can process anything. And pick depth over breadth, because when everything changes at once, your customer says "I can't keep track of what you're doing."

The training ground you're auto-deleting

The trap sits one level down, in who learns craft. Patrick Neeman points out that transcript tagging, first-pass wireframes, and competitive audits were worthless as output and priceless as practice. Tagging a transcript is how a junior learns that "it's fine" means someone gave up. AI does that task well now, so it left the junior queue, and nobody wrote down what else it taught.

The numbers are already in. Erik Brynjolfsson's payroll study found employment for 22-to-25-year-olds in AI-exposed jobs sitting 19% below where it should be, with no gap for experienced workers. AI substitutes for the codified knowledge and complements the tacit kind, the kind you only build by doing. Neeman's move: let juniors make the reversible calls, run the live session themselves, and hand in the critique instead of the summary. Grade the catch, not the polish.

What still can't be handed off

Underneath all of it, the thing that holds value is depth of understanding. Hubert Palan argues that domain knowledge, not AI fluency, is the real edge. Cursor wins its crowded field because developers built it for developers. A generic tool writes a decent summary; it does not know your team shelved that same feature two quarters ago.

That is why Zapier's own answer to AI mandates is worth copying. Instead of forcing usage, Wade Foster grades people on mindset, strategy, building, and accountability. His line: you can delegate the work, but not the accountability. At Zapier, people label how much effort went in, "I've done a quick skim" versus "I stand by every statement." And he says only 1 PM in 40 should hit the top rating, because being "transformative" all the time usually means you are tweaking systems instead of shipping.

Design's job moved up, not out

Speed to a clickable prototype is now trivial, so it stops being the point. Figma's Paige Costello frames the new work as three questions a pretty prototype can't answer: is this the best direction or the first, does it feel like us, and is it worth building at all. The gain is going broad before you commit, checking the empty states and the cancellations a single happy-path demo hides.

The role is getting more strategic, not smaller. Figma's VP Design Noah Levin notes that on his team of 60, only 20 could code hi-fi interfaces before; Code Layers gave the other 40 the same reach. And Luke Wroblewski pushes the frame one step further: stop asking whether you're building a tool, and ask whether you can just deliver the outcome the tool was supposed to produce.

Three questions for your team

• Which entry-level tasks left our junior queue in the last 18 months, and what did each one teach the person doing it? Run Neeman's inventory with your seniors in the room before you conclude nothing was lost.
• Where in our workflow did the old friction force a real decision, and did we automate that step away? Pick one loop and add a labeled human gate back in.
• Do we grade people on how much AI they use, or on the judgment and accountability behind the work? If it's usage, steal Zapier's rubric before your next review cycle.