/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 id