The Product Builder

TL;DR

• The translation layer between product and engineering (specs, tickets, handoff meetings) is compressing to zero. The PM role is becoming the Product Builder role, and the new skillset is Prompt, Build, Eval.
• Three capabilities separate the modern product builder from the traditional PM: problem shaping (defining precise constraints for agents), context curation (feeding agents the right inputs), and taste (knowing what's shippable versus what's merely correct).
• Every product role now carries a builder expectation. Leaders who only strategise operate on borrowed intuition. At every level, building is how you earn the judgment to direct.

---

The Product Manager role was built on a translation function. You understood the user problem, wrote it down in a spec, handed it to engineers, and managed the gap between what you meant and what got built. Handoff meetings, clarification tickets, sprint reviews, stakeholder syncs: all of it existed to manage that gap.

That gap is closing. When agentic coding workflows can take a well-formed problem statement and produce working software, the translation layer loses its reason to exist. Meta PMs now vibe code prototypes in hours and demo them directly to Zuckerberg. LinkedIn scrapped its Associate Product Manager program entirely, replacing it with a "Full Stack Builder" track that teaches coding, design, and product strategy as one skillset.

These aren't experiments. They're structural signals. The role is changing, and the handbook needs to reflect that.

The translation layer is dead

For a decade, the PM's value proposition was bridging the space between customer needs and engineering execution. You translated. You prioritised. You wrote requirements that collapsed ambiguity into actionable work items. Engineers built what you described. You reviewed whether they'd captured your intent.

Every step in that chain introduced drift. What you meant versus what you wrote versus what the engineer understood versus what got built. The entire discipline of "requirements writing" existed to minimise that drift. It never eliminated it.

Agentic coding doesn't eliminate drift either, but it compresses the chain so dramatically that the PM's position in it changes. You're no longer writing specs for engineers to interpret. You're forming intent clearly enough that agents can act on it directly. The spec and the prototype are converging into the same artefact.

This changes the economics of product development. Engineering capacity used to be the binding constraint. Every prioritisation framework, every sprint ritual, every roadmap negotiation existed because there were more ideas than engineers to build them. AI-assisted prototyping doesn't remove that constraint entirely, but it loosens it for the exploration phase by an order of magnitude. When testing an idea costs hours instead of weeks, the person closest to the customer problem should be the one testing it.

The PM who built a career on stakeholder management, roadmap theatre, and translating between business and engineering without ever getting their hands dirty is in trouble. Those coordination skills still matter. They're no longer sufficient.

The new full stack: Prompt, Build, Eval

The old "full stack" meant a developer who worked across frontend and backend. The new "full stack" for product people means owning the vertical from problem identification to working prototype.

Prompt. Describing intent clearly enough that an LLM can execute it. This is harder than it sounds. It requires you to decompose a problem into achievable steps, communicate constraints and edge cases in a way a model can act on, and specify what "done" looks like. PMs who wrote clear requirements tend to be good at this. PMs who hid behind vague user stories get exposed immediately.

Build. Creating the prototype yourself. Tools like Replit, Lovable, v0, and agentic coding IDEs have collapsed the distance between "I have an idea" and "I have a working prototype" from weeks to hours. A PM who brings a functional prototype to the planning meeting has already changed the conversation from "should we build this?" to "how should we improve this?"

Eval. The part most people underestimate. When AI can generate code in volume, the bottleneck shifts from construction to evaluation. Can you define what "good" looks like? Can you write test cases that catch failure modes? Can you measure whether a prototype solves the user's actual problem or just looks impressive in a demo? Product judgment applied to working software, not to specs and mocks, is the new core competency.

Problem shaping

When agents can execute, the PM's value is knowing what to build. Problem shaping means taking an ambiguous customer pain point and articulating it with enough precision that agents can act on it directly.

A well-shaped problem has three properties.

Clear boundaries. What's in scope and what isn't. An agent given unbounded scope produces unbounded mediocrity. "Build me a dashboard" is a wish. "Build a dashboard showing weekly churn by segment for our three highest-revenue tiers, with drill-down to individual accounts" is a shaped problem.

Specific constraints. Not every possible constraint. The ones that will actually change what gets built: performance requirements, data limitations, regulatory boundaries, cost ceilings. These shape the solution space. Without them, the agent will produce something technically valid that fails on contact with reality.

A measurable definition of success. Something you can observe or measure. "Users complete the flow in under 90 seconds" is a constraint an agent can optimise for. "Users feel delighted" is not.

Vague problem statements produce vague agent behaviour. The agent will build exactly what you asked for, which is the problem, because you asked for the wrong thing and hadn't thought it through. When agents handle implementation, problem shaping is no longer one skill among many. It's the skill. Everything else is secondary.

Context curation

The quality of agent output is directly proportional to the context you provide. This relationship is absolute. An agent with a vague prompt produces vague output. An agent with rich, specific context about your users, constraints, quality standards, and history of failed approaches produces output that fits.

Context curation means maintaining living documents that you feed to agents before any project begins.

The user, specifically. Not a persona slide. Real details: who they are, what makes them give up, what makes them pay attention. Direct quotes from calls and tickets. Their language, not your synthesis. This grounds the agent in real pain, not abstracted pain.

What good looks like. Examples your team considers well-designed. Past work, competitor implementations, adjacent products that handle similar problems well. Showing is exponentially more effective than describing.

What you've tried and why it failed. Institutional knowledge that usually lives in people's heads and dies when they leave. Without this, agents will confidently reinvent your past mistakes.

How you'll know it worked. Measurable outcomes that separate "technically runs" from "actually solves the problem."

Context documents are living artefacts, updated after every customer conversation, every failed experiment, every shift in strategy. The PM who maintains rich, current context has a compounding advantage over the one who starts every agent interaction from scratch. Living context documents matter more than prompts. The prompt is a single instruction. The context is the accumulated understanding that makes the instruction useful.

Taste

When agents can generate anything, the competitive advantage is knowing what's good.

Agents produce output in volume. Multiple approaches, multiple implementations, multiple variations, all technically functional. The product builder's job is to look at all of it and know which version to ship. Not which version runs. Which version matters.

Taste is the ability to distinguish "technically correct" from "shippable" in seconds. A feature that handles the happy path beautifully but falls apart on the edge case 30% of your users will hit. A design that's technically accessible but feels hostile. An implementation that solves the stated problem while creating two new ones. You need the intuition to spot these, and that intuition doesn't come from reading about products. It comes from building them, evaluating them, and learning what "good enough to ship" actually feels like.

Taste can't be prompted. It develops through exposure to great work, honest feedback, and hundreds of build-evaluate-iterate cycles. The PMs who've been building side projects and prototyping with no-code tools have a head start. The ones who've spent years in Jira and slide decks are starting from zero.

This is the last irreducible human skill. You can automate research, code generation, testing, documentation, and deployment. You cannot automate the judgment of what's worth shipping. When the cost of building approaches zero, the value of knowing what to build approaches infinity.

The builder-leader requirement

AI product leaders must also build. Full stop.

When you define AI strategy at the enterprise level without building experience, you're making decisions about things you haven't directly felt. You're choosing models you haven't debugged. You're pricing inference you haven't measured. You're governing systems you haven't built.

AI's failure modes are non-obvious. A hallucination doesn't throw an error. Latency spikes aren't visible in a sprint demo. Prompt drift happens slowly. Eval coverage is hard to reason about abstractly. You only develop intuition for these things by shipping systems that encounter them.

Building teaches you things strategy decks cannot:

• Multi-model orchestration is an architectural decision, not a vendor selection.
• Prompt caching can reduce costs by 90%, which changes the business model, not just the margin.
• Voice agents have latency requirements that no prototype will surface.
• Eval frameworks need to be day-one infrastructure, not post-launch monitoring.

Leaders who only strategise operate on borrowed intuition. They can't smell when a vendor demo is hiding complexity. They can't ask the right questions about latency, cost, or failure modes because they haven't encountered them firsthand.

The builder-leader identity isn't about permanently splitting your time between strategy and code. It's about deliberately building in structured periods to close knowledge gaps. The goal is earned intuition that makes you a better leader.

Career paths in the AI era

The role definitions below retain the leadership, IC, and specialist tracks from the traditional model. Each now carries a builder expectation that defines what "hands-on" means at that level. These aren't aspirational. They're table stakes for 2026.

Director of Product

The senior leader responsible for the vision, strategy, and performance of a product portfolio. Operates at the intersection of business strategy and organisational leadership.

Core focus: Portfolio vision, organisational leadership, ROI across the product portfolio.

What this role does:

• Defines long-term strategic direction and investment themes, including AI capability bets
• Builds and develops a high-performing product organisation with builder culture
• Sets frameworks for prioritisation, investment allocation, and AI quality assurance (including eval standards)
• Partners with senior leaders across engineering, design, sales, and marketing

Builder expectation: Has shipped at least one AI system to production (past or present). Can evaluate agent architectures, model selection trade-offs, and eval coverage with first-hand experience. Maintains enough hands-on fluency to challenge vendor claims and review technical proposals credibly.

Group Product Manager

Responsible for a portfolio of related products or a complex product domain. Manages a team of product managers and sits at the intersection of strategy and execution.

Core focus: Multi-product execution, team leadership, portfolio-level outcomes.

What this role does:

• Owns strategic direction across a group of products, including AI integration strategy
• Manages, mentors, and develops product managers into product builders
• Oversees roadmap execution across teams, managing cross-product dependencies and shared AI infrastructure
• Partners with engineering and commercial leaders on planning, alignment, and AI investment

Builder expectation: Regularly prototypes with agents to test portfolio-level hypotheses. Can evaluate team members' prototypes and evals, not just their specs. Coaches PMs on problem shaping, context curation, and eval design as core skills.

Principal Product Manager

A senior IC who acts as a force multiplier for product excellence. Leads high-impact, cross-cutting initiatives across multiple teams, domains, or platforms.

Core focus: Strategic, cross-cutting initiatives that shape the product direction.

What this role does:

• Identifies and frames complex opportunities spanning teams and platforms
• Develops multi-year product strategies that guide investment, including AI platform and agent strategies
• Takes full accountability for complex, cross-team initiatives
• Informally mentors other PMs on builder skills and contributes to evolving product practices

Builder expectation: Uses agents daily for prototyping, analysis, and exploration. Maintains and shares context documents that other PMs and agents can build on. Defines eval standards for cross-cutting initiatives. Produces working prototypes, not decks, to communicate strategic recommendations.

Senior Product Manager

Leads strategy, delivery, and continuous improvement of a critical product line or complex domain.

Core focus: Strategic roadmap and delivery for a critical product line.

What this role does:

• Defines and leads a multi-quarter product roadmap aligned with business objectives
• Leads end-to-end discovery initiatives using agent-assisted prototyping
• Leads cross-functional teams through the development lifecycle
• Defines and tracks success metrics, including AI-specific measures (eval pass rates, cost per task, escalation rates)

Builder expectation: Prototypes every major feature before sprint planning. Maintains living context documents for their domain. Writes eval criteria for AI features as part of the definition of done. Can demonstrate taste through a portfolio of shipped work, not just a list of features managed.

Product Manager

The strategic core of a product team. Owns and delivers value within a defined product or feature set.

Core focus: Product discovery, delivery, and optimisation for a single product or capability.

What this role does:

• Defines and maintains a focused, outcome-driven roadmap
• Leads structured discovery using agent-assisted prototyping to test hypotheses rapidly
• Aligns stakeholders across the business with working prototypes, not slide decks
• Establishes success metrics and continuously iterates on existing features

Builder expectation: Builds functional prototypes weekly. Writes clear, structured prompts. Curates context documents for their product area. Can evaluate agent output against product criteria (not just technical criteria). Developing taste through deliberate reps.

Technical Product Manager

Responsible for technically complex products: APIs, data platforms, AI infrastructure, and developer tools. Sits at the intersection of engineering and business.

Core focus: Platform performance, developer experience, and business enablement.

What this role does:

• Owns strategy for technical products and shared AI infrastructure
• Defines API contracts, data schemas, and platform capabilities that other teams build on
• Manages model selection, prompt architecture, and orchestration patterns for the platform layer
• Partners with engineering on performance, cost optimisation, and reliability

Builder expectation: Builds and maintains eval suites for platform capabilities. Prototypes integrations and developer workflows with agents. Directly tests model performance, latency, and cost trade-offs rather than relying on vendor benchmarks. Contributes to prompt libraries and context templates that the broader team uses.

Product Delivery Manager

A specialist focused on effective and predictable execution. Owns the rhythm, coordination, and transparency of work from planning through release.

Core focus: On-time delivery, team flow, stakeholder visibility, and continuous improvement.

What this role does:

• Manages delivery cadence across teams working on AI and traditional features
• Tracks and reports on AI-specific delivery metrics (eval coverage, model performance regressions, cost per deployment)
• Identifies and removes blockers, including those unique to AI development (data quality, model availability, eval gaps)
• Facilitates continuous improvement with data on cycle time, quality, and delivery predictability

Builder expectation: Uses agents for delivery reporting, risk analysis, and dependency tracking. Can interpret eval results and model performance dashboards well enough to identify delivery risks. Builds automated workflows that surface blockers and track delivery health without manual status meetings.

Behaviour table

Anti-pattern: the spec-only PM

The team is building a new AI feature. The PM writes a detailed spec. Fourteen pages. Every edge case documented. Acceptance criteria for each user story. A stakeholder alignment deck. A risk register.

The spec goes to engineering. Questions come back. Clarification meetings happen. Two weeks pass. The first build is reviewed. It's technically correct but misses the user's actual problem because the spec described the solution, not the pain point. Another iteration cycle begins. Three more weeks.

Meanwhile, a product builder on another team spent forty minutes writing a context document: who the user is, what they said in their own words, what's been tried before, what good looks like. They pointed an agent at the problem, reviewed three different approaches in an afternoon, picked the one that felt right, and shipped a prototype by end of week. Engineering made it production-grade the following sprint.

Same company. Same engineering talent. Same tools. One team shipped in two weeks. The other is still in spec review.

The spec-only PM isn't bad at their job by the standards of 2020. They're thorough, detailed, and organised. But thoroughness in documentation is no longer the bottleneck. Knowing what to build, shaping the problem precisely, curating the right context, and having the taste to evaluate the output: that's where the leverage sits now.

The spec isn't the product anymore. The prototype is. And the PM who can't build one is bringing a document to a shipping fight.