Category: Overview

In my career, I’ve seen two types of PRDs. The first is a 40-page “Requirement Bible” that took three months to write and was obsolete the day it was finished. The second is a vague one-pager that says “Make it pop.” Neither works.

The trick isn’t to write more; it’s to write the right things for your specific context. A B2C mobile app needs a completely different definition of success than a backend data pipeline.

In this article, I provide a comprehensive list of PRD sections, and then curate specific templates for four common use cases: B2B Enterprise, B2C Consumer, Data Infrastructure, and AI Infrastructure.

What is a PRD Template?

A Product Requirements Document (PRD) template is just a checklist to ensure you haven’t forgotten anything critical. It is the container for your strategy. It aligns stakeholders, communicates vision, and provides a clear roadmap for engineering.

But remember: The template is not the product. Filling out every section of a template doesn’t guarantee a good product. Use these templates as a starting point, not a straightjacket.

---

1. B2B Enterprise (The “Heavy Lifter”)

Best for: Complex SaaS, Workflow Tools, Regulated Industries

This format is designed for products where “the buyer is not the user.” It separates the Problem Space (why we are doing this) from the Solution Space (what we are building) to prevent jumping to conclusions.

Key Characteristic: Heavy emphasis on Business Logic, Permissions, and Integrations.

Format: The Enterprise PRD

Overview

• Document Control: Product name, author, version, status, stakeholders.
• Executive Summary: High-level overview of purpose and strategic context.
• Background & Scope: Why now? What is in/out of scope?

Problem Space

• Customer Segments: Who are we solving for? (Buyer vs User personas).
• User Personas: Detailed profiles of the target users (Goals, Frustrations, Behaviors).
• Problem: Detailed articulation of the top 3 problems, ranked by severity.
• Impact Analysis: What is the cost of inaction? (Revenue loss, churn risk).
• Existing Alternatives: How do they hack this together today?

Solution Space

• Unique Value Proposition: The “Hook” – why is this different?
• Solution Features: Top features mapped directly to the problems above.
• User Stories: Functional requirements in story format (“As a [user], I want…”).
• UX/Design Requirements: Wireframes, complex flows, state diagrams.
• Technical Requirements: Security, compliance (SOC2/GDPR), integrations.
• Unfair Advantage: What makes this defensible?

Go-to-Market

• Channels: Sales enablement, partner channels.
• Revenue Model: Pricing strategy (per seat, per usage).
• Cost Structure: CAC, implementation costs.

Execution

• Key Metrics: Adoption, retention, ACV impact.
• Project Planning: Milestones, dependencies, risks.

---

2. B2C Consumer (The “Growth Engine”)

Best for: Mobile Apps, Social Networks, D2C Subscriptions

In consumer products, utility is often less important than psychology and habit formation. Users don’t “have” to use your product; they have to want to. This template focuses less on functional requirements and more on the user journey and growth loops.

Key Characteristic: Heavy emphasis on User Psychology, Virality, and Experimentation.

Format: The B2C PRD

Core Experience

• Target Audience & Personas: Who is the primary user? What is their archetype?
• The “Hook”: What is the single trigger that gets a user to try this?
• Emotional Goal: How should the user feel after using this? (e.g., “Smart,” “Connected,” “Relieved”).
• User Stories / Job Stories: Key scenarios (“When [situation], I want to [action], so I can [outcome]”).
• The Core Loop: Trigger → Action → Reward → Investment. (Reference: Nir Eyal’s Hooked).

Growth & Virality

• Acquisition Channel: Organic search, paid ads, referral?
• Viral Mechanism: How does one user bring in the next? (e.g., “Invite to collaborate,” “Share content”).
• Monetization Moment: Where is the friction introduced? (Paywall, Ad).

UX & Design (Critical)

• Visuals: High-fidelity mockups are mandatory here. Text is insufficient.
• Micro-interactions: Delightful animations or feedback loops.
• Onboarding Flow: Step-by-step breakdown of TTTV (Time to Target Value).

Experimentation

• Hypothesis: “We believe that X will result in Y.”
• A/B Test Variants: Variant A (Control) vs Variant B.
• Success Criteria: Specific conversion rates (e.g., “Day 1 Retention > 40%”).

---

3. Data Infrastructure (The “Plumbing”)

Best for: APIs, Data Pipelines, Platform Migrations

Here, there are no “users” in the traditional sense. The “user” is another system or a developer. This PRD is technical, precise, and unforgiving. Ambiguity here causes outages.

Key Characteristic: Heavy emphasis on SLAs, Schemas, and Migration Plans.

Format: The Data Infra PRD

Contract & Schema

• Consumer Personas: Who are the downstream users? (e.g., Data Scientists, Dashboard Owners).
• Data Dictionary: Exact field names, types, and definitions.
• API Spec: Endpoints, request/response bodies (OpenAPI/Swagger link).
• Usage Scenarios / Stories: Key access patterns and query types supported.
• Data Freshness: Real-time vs. Batch? What is the maximum acceptable lag?

Service Level Agreements (SLAs)

• Availability: 99.9% vs 99.99%?
• Latency: p95 and p99 requirements.
• Throughput: Events per second (EPS) expectations (Peak vs Average).

Consumers & Dependency

• Downstream Consumers: Who breaks if this changes?
• Upstream Dependencies: What source systems do we rely on?
• Versioning Strategy: How do we handle breaking changes?

Migration Plan

• Backfill Strategy: How do we move historical data?
• Cutover Plan: Dual-write period? Hard cutover?
• Rollback Plan: “Break glass” procedure if data is corrupted.

---

4. AI Infrastructure (The “Brain”)

Best for: LLM Features, Recommendation Engines, Chatbots

AI products are probabilistic, not deterministic. You cannot write a requirement like “The model must answer correctly 100% of the time.” This template focuses on evaluation and guardrails.

Key Characteristic: Heavy emphasis on Evaluation (Evals), Context, and Safety.

Format: The AI Infra PRD

The Job to Be Done

• User Personas: Who interacts with the model? (e.g., End User vs Admin).
• User Intent: What is the user trying to achieve? (e.g., “Summarize text,” “Generate code”).
• Interaction Stories: Key prompts and expected model behaviors.
• Model Selection: Build vs Buy? (GPT-4, Claude, Llama, custom fine-tune?). Why?

Data Strategy

• Context Window: What data creates the prompt? (RAG strategy).
• Training/Fine-tuning Data: Source, cleanliness, and bias checks.
• Feedback Loop: How does user feedback (thumbs up/down) improve the model?

Evaluation Framework (The most important part)

• Golden Dataset: The “Test Set” of 50-100 examples we trust.
• Success Metrics:
  • Quantitative: Latency, Tokens per second, Cost per query.
  • Qualitative: “Helpfulness,” “Factuality” (measured by human review or LLM-as-a-judge).
• Acceptance Threshold: “Must be better than current baseline on 80% of Golden Set.”

Safety & Guardrails

• Refusals: What should the model refuse to do?
• Hallucination Mitigation: How do we ground the answers?
• Privacy: PII handling and data retention.

---

5. PRD Section Buffet (The “Kitchen Sink”)

This comprehensive format combines all unique sections from every PRD template. Use this as a menu to cherry-pick what you need.

All Sections

• Document Control: Product/feature name, author, version, status, last updated, key stakeholders
• Overview & Context: Executive summary, strategic context, background/history, scope (in/out)
• Problem Space: Problem definition, user pain points, impact analysis, market gaps, business case
• Target Users: Personas, use cases, user journey maps, underserved needs
• Solution: Product vision, value proposition, differentiators, alternatives rejected
• Features & Requirements: Prioritized feature list (MoSCoW), user stories, acceptance criteria, MVP set
• Technical Requirements: Architecture, performance specs, security, integration points, API contracts
• UX/Design Requirements: Wireframes, mockups, user flows, design constraints
• Go-to-Market: Launch strategy, release phases, channels, support requirements
• Success Metrics: KPIs, pirate metrics (AARRR), measurement plan
• Business Model: Revenue streams, pricing, cost structure, unfair advantage
• Project Planning: Timeline, milestones, resource requirements, dependencies
• Risk Management: Risk assessment, mitigation strategies, open questions
• AI Specifics: Model selection, evaluation set, prompt strategy, safety guardrails

---

Deep Dive: The Living Document

A PRD is not a statue; it’s a living organism. The biggest mistake I see is teams treating the PRD as “Done” once development starts.

The PRD should be the Single Source of Truth (SSOT). When requirements change (and they will), update the PRD. If you make a trade-off decision in a Slack thread, copy it back to the PRD. If the PRD drifts from reality, it becomes useless trash.

Pro Tip: Add a “Decision Log” section at the bottom of your PRD to track why changes were made during development.

---

Why This Matters

Standardizing your PRD structure (or at least having a thoughtful one) reduces cognitive load.
1. Speed: Stakeholders know exactly where to look for “Success Metrics” or “Risks.”
2. Completeness: You won’t wake up 2 days before launch realizing you forgot to define the “Error States.”
3. Alignment: It forces the hard conversations early, when they are cheap to fix, rather than in code, when they are expensive.

---

How to Use With AI

AI is the world’s best PRD drafter. It removes the “Blank Page Syndrome.” But you must drive it.

Pro Tip: Store your chosen PRD template as a markdown file (e.g., prd_template.md) in a context/ or docs/ folder within your code repository. This keeps your requirements version-controlled alongside your code and makes it easy for engineers to reference the “Single Source of Truth” without leaving their IDE.

1. Drafting: Don’t say “Write a PRD.”
   • Prompt: “Act as a Senior Product Manager. I am building a [B2C Fitness App] for [Busy Parents]. Based on the transcript of my user interviews below, draft the ‘Problem Space’ and ‘User Personas’ sections of the PRD. Focus on psychological triggers.”
2. Critique: Use AI as a hostile stakeholder.
   • Prompt: “Act as a cynical Engineering Lead. Review this ‘Solution’ section for technical feasibility and edge cases. What am I missing? What is too vague?”
3. Expansion: generating edge cases.
   • Prompt: “List 10 potential error states or ‘unhappy paths’ for this user flow that I should account for.”

Guardrail: Never let AI define your Strategy or Success Metrics. Those require human judgment and accountability.

---

Conclusion

There is no “Perfect PRD.” The best PRD is the one that gets your team to build the right product with the least amount of friction.

If you are a 3-person startup, a bulleted list in Notion is fine. If you are building a banking platform, you better have that Data Infra template locked down.

Pick the template that fits your stage, your user, and your risk profile. And then, get to work.

What templates does your team use? Do you have a specific “AI” section yet? Comments are gladly welcome.

Over the past 15 years, I have found that the biggest cause of friction in product teams isn’t a lack of talent or effort. It is a lack of context. It all starts with the Mission: Why does the company exist? When that answer isn’t clear, everything downstream suffers. Engineers argue about features because they don’t see the strategy. Product managers argue about strategy because they don’t see the vision. And executives wonder why the roadmap doesn’t move the needle on the company goals.

We often talk about “alignment,” but alignment is impossible if we don’t have a shared map of where we are going and why.

In developing the overall strategy for a company to provide context for the product strategy, one best practice is to express the components at different levels in a Strategy Pyramid. This simple visual framework has been what works best for me to get everyone—from the CEO to the newest intern—on the same page.

Critically, this framework is not meant to be onerous or slow things down. It is meant to provide clarity so you can move faster. The amount of detail should depend on your context. If you are a solopreneur, your entire Strategy Pyramid might be a half-page Google Doc. It is still helpful. At a larger company, it will need to be more detailed, with clear communication to the various teams.

What is a Strategy Pyramid?

A strategy pyramid lays out the key components of the strategic planning process for 5Ps Of Product. The concept draws on the classic strategic planning hierarchy described by authors like Michael Porter and Roger Martin, adapted here to create a product-focused process.

The idea is simple: strategy is a hierarchy. You can’t decide what to do today (Action Plans) if you don’t know how you plan to win (Strategy). And you can’t define a winning strategy if you don’t know why you exist (Mission).

The Components

Let’s walk through the pyramid from the top down. Each layer provides the constraints and context for the layer below it.

1. Mission

The “Why”

At the very top is the Mission. Why does the company exist? This is your core purpose. It rarely changes. It is the North Star that guides the ship through storms and calm waters alike.

Crucially, a Mission is not just “to make money.” Making money is a result, not a purpose. Your Mission is the positive change you want to bring to the world.

If your mission is “to organize the world’s information” (Google), that tells you immediately that you probably shouldn’t be building a toaster (unless it’s a very smart toaster).

2. Values

The “How” (Principles)

Right below the mission are your Values. These are the timeless guiding principles that dictate how you behave as you pursue your mission.

Think of Amazon’s famous “Customer Obsession.” It isn’t just a slogan; it is a mechanism that allows them to make decisions like offering free returns, even when it costs them money in the short term.

I have seen many companies treat values as posters on a wall. That is a mistake. Real values are decision-making tools. If one of your values is “Move Fast,” you might accept more bugs in production than a company whose value is “Reliability First.” Neither is wrong, but they lead to very different products.

3. Vision

The “Where”

The Vision is a compelling image of the ideal future. If the Mission is the “Why,” the Vision is the “Where.” What does the world look like in 5 or 10 years if you succeed? I dive deeper into crafting a vision that actually drives decisions in a separate article.

A classic example is Microsoft’s original vision: “A computer on every desk and in every home.” It was concrete, ambitious, and at the time, completely revolutionary. It painted a picture of the destination so everyone knew what they were aiming for.

4. Goals

The “What”

Now we get specific. Goals are the key financial and operational metrics that tell us if we are making progress toward the vision. These are usually time-bound.

The ultimate example is JFK’s goal for NASA: “Land a man on the moon and return him safely to the Earth before this decade is out.” It wasn’t vague. It was binary. You either did it or you didn’t.

Goals ground the lofty Vision in reality. They give us a scorecard.

5. Strategy (Business & Product)

The “Game Plan”

This is the pivot point of the pyramid. This is where many teams get stuck.

• Business Strategy: This is the overall “game plan” for the company’s success. It includes sales strategy, marketing strategy, operational strategy, and yes, product strategy. Tesla’s “Secret Master Plan” is a perfect example: Build a sports car -> Use that money to build an affordable car -> Use that money to build an even more affordable car.
• Product Strategy: This is the specific plan for the product’s future state and how it will help the business win. Think of the original iPhone launch: Drop the physical keyboard to enable a full-screen, adaptable interface. That was a strategic choice to win by changing the rules of the game.

Notice that Product Strategy sits inside or alongside Business Strategy. It serves the business goals. A great product strategy that bankrupts the company is a bad business strategy.

6. Initiatives

The “How” (Tactics)

Initiatives are operational tactics organized into key themes. These are the big rocks you are moving.

When Netflix decided to pivot to original content (starting with House of Cards), that was a massive Initiative. It wasn’t just “buy more movies”; it was a fundamental shift in how they operated to support their strategy of becoming a global TV network.

Initiatives group your efforts so you aren’t just reacting to random requests. They focus your energy on the areas that matter most for the Strategy.

7. Action Plans

The “Now”

Finally, at the base of the pyramid, we have Action Plans. These are the detailed plans with owners, timelines, and Key Performance Indicators (KPIs). This is the roadmap. This is the sprint plan. This is the JIRA ticket—often written as a user story—you are working on today.

For that Tesla engineer working on the Model S, the Action Plan wasn’t just “design a door handle.” It was “design a flush door handle that reduces drag (Strategy) to increase range (Goal) so we can prove electric cars are viable (Vision).”

A Concrete Example: ProjectFlow

To make the discussion more concrete, let’s pick a specific example. Imagine a company building a project management tool called “ProjectFlow.” They are a small startup trying to break into a crowded market.

Here is how their Strategy Pyramid might look:

• Mission: To help teams build better things together.
• Values:
  • Simplicity over power: We will remove features if they make the product harder to learn.
  • Transparency by default: Everyone sees everything unless explicitly hidden.
• Vision: A world where no project fails due to miscommunication. We want to be the default “operating system” for modern creative teams.
• Goals: Reach 1,000 paying teams by the end of the year. This gives us the revenue to hire our next two engineers.
• Business Strategy: Win the SMB market by undercutting enterprise tools on price and beating them on ease of use. We will rely on product-led growth (PLG) rather than a sales team. (This is where your Go-to-Market strategy lives.)
• Product Strategy: Build the fastest, most intuitive interface in the market. Focus on “zero-setup” collaboration so a team can start working in seconds, not days. We explicitly choose not to build complex reporting or permissioning features yet.
• Initiatives:
  • “Instant Onboarding”: Reduce time-to-first-project to < 1 minute.
  • “Mobile First”: Full feature parity on iOS/Android to support remote teams.
  • “Viral Loops”: Build “guest access” features that encourage users to invite external clients.
• Action Plans:
  • PM: Write specs for “One-click Google Sign-in” to support Instant Onboarding.
  • Eng: Refactor the database for faster mobile sync to support Mobile First.
  • Design: Simplify the “New Project” modal to remove mandatory fields.

See how it flows? If a designer proposes a complex, powerful feature like “Gantt Chart Dependencies” that requires manual setup, the PM can point to the Values (“Simplicity over power”) and the Strategy (“Zero-setup”) and say, “That’s a great idea, but it doesn’t fit our current strategy. We are optimizing for speed, not complexity.”

The Product Strategy Bridge

I want to highlight the Product Strategy component specifically. In my experience, this is often the missing link.

Teams often have high-level Goals (“Make money”) and low-level Action Plans (“Build feature X”), but nothing in between. They lack the “connective tissue” that explains why feature X leads to making money.

The Product Strategy provides that bridge. It translates the financial language of the Business Strategy (“Capture 20% market share”) into the language of the product (“Build a viral loop through free guest access”).

Why This Matters

Using a Strategy Pyramid isn’t just about filling out a template. It is about communication.

When I join a new team, I often ask people to draw this pyramid for their product. Usually, the top is fuzzy (“Something about making the world better?”) and the middle is missing. Everyone knows the Action Plans (the bugs they are fixing today), but they have no idea how it connects to the top.

By explicitly writing this down, you give your team a tool to make decisions. You empower them to say “no” to things that don’t fit the strategy. You give them the context they need to be autonomous.

How to Use With AI

Gen AI is surprisingly good at the part of strategy work that teams hate: turning scattered context into a clean draft. Use it like a tireless facilitator, not a CEO. Feed it your raw inputs, ask it to propose a first-pass Strategy Pyramid, then review it live with the team and force the hard choices in the open. The goal isn’t to let AI decide your mission. It’s to compress the “blank page” phase and spend more human time on the debates that actually matter.

Draft the first pyramid from messy inputs: give it your last 3 strategy memos, a recent roadmap, and notes from customer calls, then ask for a one-page Mission → Values → Vision → Goals → Strategy → Initiatives → Action Plans draft.

Stress-test alignment: ask it to flag contradictions (example: “Simplicity over power” vs “enterprise permissioning initiative”) and list the decisions you’re implicitly making.

Generate a “strategy narrative” for comms: have it produce a one-minute version for execs, a one-pager for the org, and a team-level “what changes Monday” summary.

Turn the pyramid into an operating cadence: ask for a quarterly review agenda and the top 10 questions each layer should answer.

Guardrail: never accept AI wording for Mission/Values blindly. Those are identity choices. Use AI for synthesis and clarity, then make the final call as humans.

Conclusion

This framework is what has worked for me to bring order to chaos. It pushes you to be disciplined about your thinking. You can’t just hand-wave the strategy if you need to write it down in a box that sits between Goals and Initiatives.

This is not a cookie-cutter template. You will need to adapt these specific labels to your context. Maybe you call “Initiatives” “Themes” or “Bets.” That’s fine. The important thing is the hierarchy of context.

What do you think? Does your team have a clear path from Mission to Action? Comments are gladly welcome.

Early in my career, someone asked me what a product manager does. I gave a ten-minute answer that involved strategy, roadmaps, customer research, cross-functional alignment, stakeholder management, and agile ceremonies. When I finished, they said, “So… you go to meetings?” I laughed, but the question stuck with me. If I could not explain my own job in a sentence, maybe I did not actually understand it yet.

It took me years to get to a simple answer. The core job of product management is to figure out the most important customer problem to solve — and then determine the best thing to build to solve it. That is it. Everything else — the roadmaps, the specs, the stakeholder updates — is scaffolding around that central act of judgment.

What Is Product Management?

Product management is the discipline of discovering what to build and why, so that engineering, design, and the rest of the organization can focus on building the right thing well.

The PM does not write the code. The PM does not design the screens. The PM does not sell the product. But the PM is responsible for making sure the thing that gets built is worth building in the first place.

Marty Cagan, in his book Inspired, frames this as the PM being responsible for ensuring that what gets built is valuable (customers want it), usable (they can figure it out), feasible (engineers can build it), and viable (the business can sustain it). Of those four, value and viability are squarely the PM’s territory.

Ken Norton, in his influential essay How to Hire a Product Manager, described the PM as someone who combines elements of engineering, design, marketing, and business — a leader who earns authority through judgment rather than title. I think that captures something essential: you are responsible for the outcome, but you control almost none of the inputs.

The Two Spaces

The simplest way I have found to explain what a PM does day-to-day is to split the work into two spaces.

The Problem Space

This is where you figure out what problem to solve. You talk to customers. You study the data. You map the market. You understand what people need, what frustrates them, and what they are trying to accomplish. Teresa Torres calls this continuous discovery — the habit of maintaining weekly touch points with customers so you always have fresh data when decisions need to be made.

The problem space is where most PMs underinvest. It is tempting to skip ahead to solutions because solutions feel productive. But a beautifully executed solution to the wrong problem is still a failure. Understanding who your customers actually are and what they struggle with is the foundation of everything that follows.

The Solution Space

This is where you figure out what to build. You write the spec. You work with design on the experience. You scope the work with engineering. You make trade-offs about what to include and what to cut.

The solution space is where most people think the PM job lives. And it does — partly. But the solution space only works if the problem space did its job first. The order matters: problem first, then solution. Always.

Cagan calls this “product discovery” — the process of testing whether your proposed solution actually solves the problem before you commit engineering resources to building it. The best PMs I have worked with spend at least half their time in the problem space, even when everyone around them is pressuring them to “just ship something.”

The Core Responsibilities

If the two spaces define what a PM thinks about, here is how they spend their time. Lenny Rachitsky, in his newsletter, breaks the PM role into three areas: shape the product, ship the product, and synchronize the people. I would frame it slightly differently.

Decide What to Build

This is the heart of the job. Given limited resources and unlimited possibilities, what should the team work on next? This requires understanding the customer, the business, the technology, and the competitive landscape — and then making a call. As Ben Horowitz wrote in his classic memo on product management, a good PM takes ownership of the product’s direction and makes decisions based on customer needs, not internal politics.

Prioritize and Sequence

Deciding what to build is hard. Deciding what to build first is harder. Every feature request sounds reasonable in isolation. The PM’s job is to see all of them together and choose the sequence that creates the most value fastest. This is where the Strategy Pyramid becomes essential — it gives you a framework to evaluate whether a given feature serves the strategy or just sounds like a good idea.

Align the Team

A PM who makes the right decision but cannot get the team to execute on it has accomplished nothing. You need engineering to understand why they are building this. You need design to understand the customer pain. You need leadership to understand the trade-offs. This is not about slides and status updates. It is about giving people enough context to make good decisions on their own.

A Concrete Example: ProjectFlow

To make the discussion more concrete, imagine a company called ProjectFlow that builds a project management tool for creative teams. They have 50 customers and a team of eight.

The PM at ProjectFlow gets a request from their biggest customer: “We need Gantt chart dependencies.” The sales team is excited. The customer is excited. It seems obvious.

But the PM steps back into the problem space. She asks: what problem are dependencies solving? After three customer interviews, she discovers the real issue is not dependencies — it is that team leads cannot see when one person’s delay will affect someone else’s deadline. The customer said “Gantt chart” because that is the tool they know. The problem is visibility into blockers.

Now in the solution space, the PM works with design on three options: full Gantt dependencies (six weeks of engineering), a simpler “blocked by” tag on tasks (two weeks), or an automated daily digest showing at-risk deadlines (one week). She evaluates each against ProjectFlow’s product vision — “every team ships with confidence” — and their strategy of simplicity over power.

She chooses the daily digest. It solves the real problem, ships in a week, and aligns with the strategy. The customer is happy. The sales team is happy. And the PM protected six weeks of engineering time that can now go toward the next most important problem.

That sequence — hear the request, dig into the real problem, explore multiple solutions, choose based on strategy — is product management in practice.

What Product Management Is Not

One of the most persistent confusions is between product management and project management. The names are similar. The work sometimes overlaps. But they are fundamentally different disciplines.

A project manager asks: How do we deliver this on time and on budget? A product manager asks: Should we be building this at all?

Project management is about execution. Product management is about direction. Both are valuable. But confusing them leads to PMs who spend all their time tracking tickets and running standups, and none of their time talking to customers or questioning whether the roadmap is right.

If you find yourself spending most of your week on timelines, status reports, and coordination — and almost none of it on customer problems and strategic choices — you might be doing project management with a product management title. That is not a judgment. It is a signal that the role might need to be redefined.

Why This Matters

Product management matters because someone has to own the “why.” Engineers own the “how.” Designers own the experience. Sales owns the revenue. But the PM owns the question that precedes all of those: why are we building this, and why now?

Without that function, teams drift toward building what is easy, what the loudest stakeholder wants, or what competitors already have. They ship features without conviction. They fill roadmaps without strategy. And they discover, months later, that nobody wanted what they built.

A good PM is the person who prevents that drift. Not by having all the answers, but by asking the right questions at the right time and making sure the team solves problems worth solving.

How to Use With AI

AI is useful for the parts of product management that eat up time without requiring deep judgment. Think of it as a research assistant that never gets tired.

Synthesize customer feedback at scale: paste a batch of support tickets, NPS comments, or interview transcripts into an AI tool and ask it to group the top five themes with representative quotes. What used to take a full day of reading now takes minutes. The PM still decides which theme matters most — that is judgment — but the sorting is mechanical.

Stress-test your prioritization: describe your top three priorities and ask the AI to argue the case for each one, then argue against each one. This surfaces blind spots you might miss when you are attached to a particular direction.

Draft the spec, not the strategy: AI can write a solid first draft of a product requirements document given a clear problem statement and constraints. Use it to compress the blank-page phase, then edit for nuance and context that only a human with product judgment can add.

Guardrail: Never let AI make the prioritization call. Deciding which problem to solve is the PM’s core judgment. AI can inform that decision with data, synthesis, and alternative perspectives. But the final call — what to build and what to say no to — must come from someone who understands the customer, the business, and the team.

Conclusion

Product management is not about having all the answers. It is about asking the right questions. What is the most important problem our customers have? What is the best thing we could build to solve it? And what should we do first?

If you get those questions right, the roadmap writes itself. If you get them wrong, no amount of execution will save you.

This is not a formula. You will need to adapt these ideas to your context — your company size, your market, your team. But the core remains: problem space first, solution space second, and always, always own the “why.”

What do you think? Comments are gladly welcome.