The Product Team's Evolution, Stage 2: A Faster Draft for Everyone

Part 1 of a series on how non-engineering product roles change as teams climb the AI maturity curve. Each post takes one stage and follows four example careers through it: a UX designer, a product owner, a business analyst, and a product manager. It is a companion to our series on the engineer's evolution, and the curve is the same.

The conversation about AI and software jobs fixates on engineers. The bigger shift is happening one seat over, in the roles that decide what gets built and why. UX designers, product owners, business analysts, and product managers are climbing the same maturity curve as their engineering counterparts, and the destination is the same: the work moves from producing artifacts to designing and governing the systems that produce them, while the demand for judgment goes up rather than down.

We use an eight-stage maturity model, shared with the engineering series. The early stages keep your process intact and make it faster. The later stages change how the work is structured. Most product teams sit at Stage 2 today, using capable AI tools without changing much about how they work.

Two underlying shifts explain everything that follows, and they apply to product roles as cleanly as they do to engineers. The first is that design and judgment grow on top of the doing rather than replacing it. A product manager who has an AI draft a PRD still has to know whether the strategy inside it is right. The second is that practitioners move from using tools to building them, encoding their own craft into agents and the checks that catch a bad artifact before it spreads.

There is one idea worth planting now, because it carries the whole series. Every product role has a competency floor, and it is not artifact production. For a business analyst it is the ability to elicit and model a real requirement. For a product owner it is knowing what creates value and what "done" means. For a UX designer it is research rigor and design judgment. For a product manager it is strategy, market understanding, and the read on stakeholders that no model has. That floor is what lets each of them catch an output that looks polished and is quietly wrong. It does not fade as they climb. It becomes the thing they are paid for. One thing does get added to it on the back half of the curve, a working dose of technical fluency, and we will come back to why that ends up deciding how far each role can climb.

Here is the through-line of the series. AI does not shrink these roles. It broadens them, and a broader role sits on a higher floor of competence. As a practitioner climbs, their judgment stops shaping one artifact and starts shaping everything the agents produce. A single standard an owner sets, or a single gate an analyst writes, stamps itself onto hundreds of generated items at once. That is a far wider sphere of influence and a far bigger impact. It is also a heavier responsibility, because a vague opinion replicated a hundred times does a hundred times the damage. The job gets bigger. It does not get easier. The floor of competence rises to meet the size of the influence.

Stage 2: Off the Shelf

Stage 2 is where almost every product team is right now. Each person has a capable assistant and reaches for it when it saves time. The tools are impressive. The way the work flows has barely moved.

The business analyst uses AI to turn a stakeholder interview into a first-draft requirements document, to summarize a pile of meeting notes, or to sketch a process diagram. The elicitation still happens by hand, in the room, and the analyst reads every generated line to catch the places the model invented a requirement nobody stated. A good draft saves an hour. A bad one costs two, because a plausible-sounding requirement that was never actually expressed is harder to spot than a blank page.

The product owner drafts user stories and acceptance criteria from a feature idea, summarizes customer feedback into themes, and generates release notes. The prioritization, the hard calls about what is worth building, stay entirely with the owner. The assistant speeds the writing of the story. It has no opinion on whether the story should exist.

The UX designer generates copy variations, first-pass layout ideas, draft personas, and quick summaries of usability sessions. The research and the actual design decisions remain human. They know that a persona the model assembled from nothing is a liability dressed as a head start, so they treat its output as a prompt for their own thinking rather than a finding.

The product manager drafts PRDs, summarizes market and competitive research, and produces stakeholder updates faster than writing them cold. Strategy and the roadmap stay where they belong. The PM is the one deciding what the company should do, and the assistant is a faster way to write it down.

Across all four, the pattern is identical to the one engineers hit at Stage 2. The gains are real and uneven. One prompt lands, the next confidently misleads, and the practitioner absorbs that variance with their own judgment. Everything lives inside one person's head. Nothing is captured, so the next analyst, owner, designer, or PM starts over. The day still looks like the old day, with an assistant alongside.

What Stage 2 is worth, and where it stops

Stage 2 earns its keep. People build intuition for where the assistant is sharp and where it fabricates, and that intuition is the raw material every later stage depends on. The ceiling is structural. Every gain is personal and ephemeral, so the team cannot compound its learning. Two product owners write stories at two different levels of quality, and neither one's standard survives the week. The faster you push, the more attention you spend catching plausible mistakes, and attention does not scale.

The real risk at Stage 2 is quiet drift. A generated artifact that reads well and misframes the problem flows downstream with nothing watching for it, because the only check is a busy human. The move that matters is the decision to write down how you actually work and encode it, which is where Stage 3 begins and where the role visibly changes.

How each role shifts at Stage 2