managing-product

name	managing-product
description	Extracts product requirements and produces a PRD. Use when a user wants to build software and needs to define what to build before architecture or implementation, when scoping an MVP, or when translating a vague idea into a buildable specification.

Managing Product

Defines what to build before any architecture or code: translates an understood idea into a structured, prioritised PRD that agents can execute against without ambiguity.

Position: understanding-the-ask (clarify problem) → solutioning (choose direction) → managing-product (define what to build) → architecting-software (design how).

Inputs: a clear problem statement, a chosen solution direction ("we will build software"), and the user's domain knowledge accessible through conversation.

Output: PRD.md with five essential elements — problem statement, target users, success criteria, scope (MoSCoW-prioritised plus explicit out-of-scope), and requirements as user stories with testable acceptance criteria.

Not covered: problem clarification or solution direction (upstream), technical architecture (architecting-software), chunk enrichment, roadmapping, sprint planning, rollout strategy.

Workflow

Step 1: Establish Starting Context

Check whether you already have a clear problem statement, an identified audience, and any stated constraints. If the user arrives with problem and audience clear (e.g. "I want to build a habit tracking app for myself"), confirm inline and proceed — upstream skills are not required. If either remains vague after confirmation, return to understanding-the-ask.

State what you understand so the user can correct it before extraction begins:

"Before we define what to build, let me confirm: we're solving [problem] for [user type]. Does that match your intent?"

Step 2: Extract Product Knowledge Through Structured Questioning

Pull out the five essential elements through focused, sequential questions — one at a time, never a form or a list of questions at once.

A. Target users (if not already clear):

• "Who specifically will use this? Can you describe a typical person — their situation, what they're trying to do?"
• "Is there more than one type of user with different needs, or mainly one audience?"

B. Core problem and current alternative:

• "What does this person do today when they have this problem? What's their workaround?"
• "What's the most important thing this software needs to do for them?"

C. Success definition:

• "How would you know this worked? What would be different for the user after using it?"
• Probe for measurability: "If someone used this for a month, what specific change would tell you it was successful?"

D. Feature exploration:

• "Walk me through what a user would do with this, step by step."
• "What would make it genuinely useful, even if it only had two or three features?"

E. Boundaries:

• "What are you deliberately not trying to do with this version?"
• "Are there things you could imagine adding later but don't need right now?"

Redirect solution-focused input to outcomes. "It needs a React frontend" → "What does the user need to be able to do? We can decide the technology once we know what it needs to accomplish." "It needs a database with relational tables" → "What information needs to be stored and retrieved? We'll leave the technical decisions to the architect."

Pacing: you are looking for the five essential elements, not an exhaustive feature list. A simple project needs one short conversation; a complex one (multiple user types, integrations) needs follow-ups per sub-area. Stop when you can draft a PRD — not when the user has exhausted every idea.

Step 3: Challenge and Sharpen Acceptance Criteria

Before drafting, challenge any criterion that cannot be tested objectively:

Vague statement	Clarifying question
"It should be easy to use"	"How would you test that? What would a new user be able to do within their first session?"
"It needs to be fast"	"Fast compared to what? Is there a specific action that needs to respond within a certain time?"
"It should be secure"	"What specifically needs to be protected? User data, transactions, access control?"
"It needs to scale"	"How many users are you planning for? Is scalability a day-one requirement or a future concern?"
"It should handle edge cases"	"Which edge cases? Let's name the ones that matter."

The test: each acceptance criterion must be answerable with pass or fail. The outcome is not always a number — "a user who has never seen the app can complete a purchase without asking for help" is testable without being quantitative.

Step 4: Prioritise and Scope the MVP

Apply MoSCoW to the requirements from Step 2:

• Must have (P0): without this, the product fails to deliver its core value. The MVP.
• Should have (P1): important but not the core; defer if needed.
• Could have (P2): nice to have; explicitly deferred.
• Won't have: explicitly out of scope for this version.

Won't Have vs Non-Goals: "Won't Have" lists specific features considered and set aside; "Non-Goals" states broader boundaries about what the product is not trying to be ("this is not a social platform"). Both are needed; they should not duplicate each other.

The one-page heuristic: if the MVP requirements don't fit on a page, the scope is too large (split into phases) or the problem is not yet clear (return to Step 2). Diagnostic, not rigid rule.

Split into phases when the P0 list exceeds 8–10 requirements, different user types have substantially different workflows, or deliverable value exists in a subset (ship that first). Split only on real sequencing logic, never just to shorten the document; produce a separate PRD per phase.

Common mistakes to catch: everything is P0 ("If you could only ship one feature, which would it be?"); scope creep during definition (log new ideas as P2/Won't have, don't expand P0); technical gold-plating ("must use microservices" belongs in Constraints, not Requirements).

Explicit non-goals are as important as explicit goals. For AI-assisted development, anything not explicitly excluded is fair game for the implementing agent. Name what you are NOT building.

Step 5: Produce the PRD

Write the PRD from the template below. Fill all sections — mark genuine unknowns as open questions rather than omitting them. For a simple project, skip "Should Have"/"Could Have" only if they would be empty.

Validation before presenting:

• All five essential elements present and non-empty
• Every P0 requirement has a testable acceptance criterion
• Non-Goals names at least one explicit exclusion
• No requirement specifies implementation detail (that belongs in Constraints)
• Open questions logged, not silently omitted

Then read back the key decisions:

"Here's what I've captured: the MVP will do [X, Y, Z] for [user type], with success defined as [criteria]. It will not include [explicit non-goals]. Does this match your intent?"

Adjust on feedback, then save as PRD.md in the project directory.

PRD Template

# [Product Name]

**Status:** Draft
**Date:** YYYY-MM-DD
**Version:** 1.0

---

## Problem

[2–4 sentences. What specific problem are we solving? Who has it? Why does it matter?
What do they do today instead, and why is that insufficient?]

## Target Users

[Who is this for? Describe the primary user in concrete terms: their situation,
goal, and what they currently do. One or two sentences per user type. Max two types for an MVP.]

## Success Criteria

How we will know this worked:

- [Specific, testable criterion — e.g. "A first-time user can complete [core action]
  without asking for help"]
- [Measurable outcome — e.g. "Users report that [X problem] no longer requires
  a workaround"]
- [At least one criterion per primary user type]

## Requirements

### Must Have (P0 — MVP)

- As a [user], I want to [capability] so that [outcome]
  - Acceptance: [specific, testable condition]

[Repeat for each P0 requirement. 3–7 for a focused MVP.]

### Should Have (P1 — next iteration)

- [Requirement] — [one-line rationale for deferral]

### Could Have (P2 — future consideration)

- [Requirement] — [one-line rationale for deferral]

### Won't Have (this version)

- [Requirement] — [brief reason or "outside product scope"]

## Non-Goals

This version will NOT:

- [Explicit boundary 1 — broader product direction, not a specific feature]
- [Explicit boundary 2]
- [Add as many as needed. When in doubt, name it explicitly.]

## Constraints

- **Platform / environment:** [Web app, mobile, CLI, API — or "TBD for architect"]
- **Tech stack:** [If specified by user; otherwise "TBD for architect"]
- **Existing system:** [What already exists, if extending. "Greenfield" if new.]
- **Performance:** [Any specific requirements, or "none specified"]
- **Security / data:** [Any specific requirements, or "none specified"]

## Open Questions

- [Question] — Owner: [who] — needs answer before [phase]

Edge Cases

User conflates "what" with "how": keeps specifying schema or framework choices. Redirect to actions and outcomes; record genuine technical constraints (must use existing infrastructure) in Constraints, not Requirements.

User cannot describe success criteria: offer prompts — "Imagine a user coming back after a week. What would they tell you about it?" If still blocked, draft a criterion and ask them to confirm or correct.

Scope inflation during conversation: do not suppress ideas — log them as P2 or Won't have immediately and continue; confirm the P0 boundary still holds afterwards.

Overlap with understanding-the-ask: that skill clarifies intent and context; this one extracts product-specific detail (features, users, success, exclusions). If you are still clarifying intent, step back to understanding-the-ask.