Product Managers Are Becoming Product Builders

For years, product management sold itself as the discipline of the middle. We sat between users, business, design, engineering, data, support, compliance, sales, and leadership. We translated. We aligned. We wrote the documents. We turned chaos into something a team could build.

That work still matters. But the market is asking a harder question now: after you align everybody, can you actually move the product forward?

This is why LinkedIn's move matters. In December 2025, LinkedIn's Chief Product Officer Tomer Cohen discussed the company's shift toward a "full stack builder" model on Lenny's Podcast. The reports around that episode say LinkedIn is replacing its Associate Product Manager program with an Associate Product Builder program, teaching coding, design, and product skills together. That is not a small symbolic edit. That is a company saying the entry-level product path should produce builders, not just coordinators. I expanded this argument into the full Product Managers Are Becoming Product Builders field book for readers who want the practical operating system behind the shift.

This Is Not The Death Of Product Management

Every time the role changes, someone writes the obituary. Product management is dead. Agile is dead. Roadmaps are dead. PRDs are dead. Most of these takes are useful for engagement and useless for practice.

The PM role is not dying. The lightweight version of the role is dying. The PM who only forwards Slack messages, updates Jira tickets, schedules meetings, and writes documents without evidence is in trouble. But the PM who can understand users, shape strategy, evaluate technical tradeoffs, prototype quickly, test assumptions, read data, and help teams make better decisions is not dying. That person is becoming central.

The word "builder" is important because it changes the expectation. It says you are not merely close to the work. You are part of the work.

Why This Feels Scary

If you are an aspiring PM, this can feel unfair. You were told to learn personas, wireframes, PRDs, Jira, Agile, stakeholder management, and interview frameworks. You finally understand the language, then the industry changes the exam. Now everyone is talking about AI agents, prototypes, code assistants, API fluency, analytics, and "show me what you built."

If you are a mid-level PM, the fear is different. You already have a job. You know how to run discovery, manage engineers, write specs, and talk to leadership. But you can feel the ground moving. Engineers are using AI to move faster. Designers are prototyping more independently. Founders are asking for leaner teams. Suddenly the question is not whether you know product management. The question is whether your version of product management still compounds.

If you are a senior PM or product lead, the fear is even more uncomfortable: what if the team no longer needs as many layers of coordination? What if the best ICs can now handle more of the product loop themselves? What if your value is no longer in being the person who knows where the document is, but in being the person who raises the quality of decisions?

That is the real anxiety underneath this conversation. Not "will AI take my job?" but "will the parts of my job that made me feel useful still matter?"

Why This Is Happening Now

AI collapsed the distance between idea and artifact. A PM can now use tools like ChatGPT, Claude, DeepSeek, Perplexity, Codex, Claude Code, Cursor, v0, Lovable, Figma Make, Replit, and Postman to do work that previously required waiting for several specialists to become available.

That does not mean PMs should replace engineers. Please, let us not use AI excitement to invent new organisational problems. What it means is that PMs can now arrive at engineering conversations with more than vibes. They can bring a working prototype, a clearer API contract, a tested user flow, a sharper experiment plan, or a data-informed argument.

In the old world, a PM could hide behind process. In the new world, the artifact exposes the thinking.

What Product Builders Actually Do

A product builder does not need to be the strongest engineer, the best designer, or the deepest data scientist. That is not the point. The point is fluency across the system.

• They can turn a vague customer pain into a sharp product problem.
• They can sketch the user journey before asking design to polish it.
• They can prototype enough of the experience for people to react honestly.
• They can read API documentation and understand integration risk.
• They can use Postman to test whether an assumption survives contact with reality.
• They can define success metrics before the launch becomes a celebration of output.
• They can talk to engineering without pretending complexity is negativity.
• They can talk to sales and GTM without turning every request into a roadmap emergency.

This is why the role is becoming more demanding. The market does not merely want PMs who can explain product management frameworks. It wants people who can move from ambiguity to evidence to decision.

What To Do If You Are Just Starting

If you are trying to enter product management, stop building a portfolio that only proves you can write templates. A PRD is useful, but a PRD alone is not enough anymore. You need a small body of work that shows you can move through the full product loop.

Start with one real problem. Not "an AI app for students" or "a fintech dashboard" because those sound nice. Start with a painful workflow you can observe. A WhatsApp ordering problem. A small business inventory problem. A course onboarding problem. A clinic appointment problem. A creator payment problem. Something real enough that you can interview people without pretending.

Then build proof in layers:

• Write the problem brief: who has the pain, when it happens, what it costs, and why existing solutions fail.
• Sketch the user journey in Figma, Excalidraw, or FigJam.
• Create a simple prototype in Lovable, v0, Figma Make, Bolt, Replit, or even no-code.
• Define the API or data flow, even if you are not building production code.
• Run five user conversations and document what changed in your thinking.
• Set success metrics: activation, task completion, retention, revenue, support reduction, or time saved.
• Write the launch note: audience, channel, positioning, risks, and what you will measure first.

That portfolio tells a better story than "I completed a course and made a PRD." It tells a hiring manager: this person can learn, build, test, and communicate.

What To Do If You Are A Mid-Level PM

If you already work as a PM, your next advantage is not collecting more frameworks. It is increasing your surface area of usefulness. Pick one product area and become more technical, more analytical, and more commercially grounded inside that area.

If your team works with APIs, learn to read the docs and test flows in Postman. If your product has onboarding problems, learn funnels, cohorts, activation, and qualitative drop-off analysis. If your roadmap depends on AI, learn enough about RAG, embeddings, evaluation, latency, hallucination risk, and build-vs-buy tradeoffs to stop treating AI as a magic feature category. If your team struggles with launches, learn GTM, release comms, rollback planning, support readiness, and sales enablement.

The goal is not to become a replacement engineer, data scientist, designer, and marketer. That is how people burn out and build bad products. The goal is to become the PM who can reduce uncertainty before other specialists spend serious time on the wrong thing.

What To Do If You Are Senior

Senior PMs and product leaders should be careful. The builder conversation can easily become an excuse to overload teams and romanticise solo heroics. That is not leadership. Serious products still need strong engineering, design, research, data, compliance, security, support, and GTM. Marty Cagan is right to separate product creation from mere facilitation, but he is also clear that most serious products need a range of skillsets.

Your job is to redesign the operating model, not just tell everyone to use AI tools. Create standards for what counts as a good prototype. Define when an AI-built demo is enough for discovery and when engineering must take over. Teach PMs how to evaluate product risks: value, usability, feasibility, viability, safety, and ethics. Build review rituals that make AI work visible, auditable, and useful.

A strong product leader in this era does not ask, "How do I get fewer people to do more work?" A strong product leader asks, "How do I help talented people learn faster without lowering the quality bar?"

A 30-Day Product Builder Starter Plan

If this whole thing makes you feel behind, good. That means you are awake. But do not respond with chaos. Use thirty days to rebuild your confidence with evidence.

Week 1: Pick a real problem

Choose one problem you can access directly. Interview five people. Write a one-page problem brief. Do not build yet. Your goal is to understand the pain, the current workaround, and the cost of doing nothing.

Week 2: Prototype the smallest useful version

Use Figma, Lovable, v0, Figma Make, Replit, Bolt, or another tool to make the workflow visible. Do not chase beauty. Chase clarity. Can someone understand the value in thirty seconds?

Week 3: Add technical and measurement thinking

Map the data you would need. Sketch the API flow. Define events. Write acceptance criteria. Add the analytics plan. If there is AI involved, write how you would evaluate output quality, latency, cost, and failure cases.

Week 4: Package it like a product person

Write the PRD, but make it earned. Add screenshots, assumptions, user quotes, metrics, GTM plan, risks, and what you would do next. Publish it as a portfolio case study. That is how you turn fear into proof.

The Skills That Now Compound

Product builders are not just people who know more tools. They are people whose judgement improves because the tools let them touch more of the product system. These are the skills I would bet on:

• Product sense: knowing what problem is worth solving, what experience feels right, and what tradeoff matters.
• Technical fluency: APIs, data models, environments, latency, reliability, security, and integration constraints.
• AI fluency: prompt design, RAG basics, evaluation, hallucination management, agent workflows, and governance.
• Analytics judgement: funnels, cohorts, retention, segmentation, experiment design, and when not to trust a metric.
• Prototype craft: using tools to make ideas testable without confusing a demo for a product.
• GTM thinking: positioning, launch channels, sales enablement, onboarding, pricing, and adoption loops.
• Communication: explaining complexity without hiding behind jargon.

The important part is not learning all of this at once. The important part is choosing one weak edge and strengthening it every month.

The African PM Opportunity

This shift is especially important for product managers in Nigeria and across Africa. Many teams here are smaller, messier, and more resource-constrained than the case studies we borrow from Silicon Valley. In those environments, a PM who waits for perfect structure will wait forever.

The product builder posture fits the reality better. You may need to validate a WhatsApp workflow before design has capacity. You may need to understand payment failures before engineering can prioritise the bug. You may need to prototype a merchant dashboard, test a signup funnel, explain a regulatory constraint, and prepare a sales enablement deck in the same week.

That is not glamorous. That is the job becoming honest.

What This Means For Learning Product

It means product education has to change. A product course that only teaches personas, roadmaps, and user stories is no longer enough. Those things matter, but they are table stakes. The next generation of PM education needs to include APIs, analytics, AI prototyping, GTM strategy, release thinking, technical architecture, experimentation, governance, and the craft of making decisions under uncertainty.

That is why I keep pushing the AI PM Intensive toward a product builder curriculum. Each day should become a chapter. Each chapter should tell a story. A launch that worked. A product that failed. An engineering constraint that changed the roadmap. A GTM decision that looked smart in the deck and collapsed in the market. A metric that exposed the truth nobody wanted to hear.

People do not become product builders by memorising frameworks. They become product builders by repeatedly learning how reality punishes lazy thinking.

The New PM Standard

The future PM is still a strategist. Still a communicator. Still a customer advocate. Still a person who makes sense of ambiguity. But the future PM is also expected to build enough to learn, test enough to challenge assumptions, and understand enough technical detail to make better tradeoffs.

So no, product management is not over. It is being upgraded.

And if you are learning product now, that is the opportunity. Do not train for the PM job as it was described in 2018. Train for the product builder role that companies are quietly rewriting around AI, speed, and evidence.