Guide: From Idea to Spec
This guide is for Product Managers. It walks you through the first three things you'll do in a Full project: writing your PRD, breaking it into requirements, and resolving blockers before handing off to design and engineering.
Step 1: Write Your PRD
Open your project and start chatting. The AI acts as a thinking partner — it won't write the PRD for you, but it will push you to clarify your thinking.
Expect questions like:
- Who are the target users?
- What problem are you solving, and why now?
- What does success look like?
- What's explicitly out of scope?
As the conversation develops, the AI drafts a PRD document in the project. You can edit it directly or keep refining through chat. The document is tagged as PRD (see Documents, Artefacts & Bugs), which tells ProdE to use it as the foundation for everything that follows.
When is the PRD done?
When the document covers the problem, target users, proposed solution, and success criteria. There's no formal "submit" — you move to the next stage when you're satisfied.
Tip: You don't need to have all the answers upfront. The AI helps you discover gaps. It's better to start with a rough idea and iterate than to wait for a perfect brief.
Step 2: Break It Down into Workstreams and Requirements
Once your PRD is ready, move to the Product Spec stage. The AI reads your PRD and proposes a breakdown:
Workstreams are the big logical chunks of work. Think of them like epics. For a project called "User Authentication Revamp," the workstreams might be:
- WS-1: Social login providers (Google, GitHub)
- WS-2: Two-factor authentication
- WS-3: Session management and token refresh
You review the proposed workstreams — rename them, merge them, or ask for a different split. Once you confirm, the AI generates Requirements for each workstream.
Each requirement gets:
- A unique ID (
REQ-1,REQ-2, etc.) - A title and detailed description
- Priority (
High,Medium,Low) - Acceptance criteria — the specific conditions that define "done"
Here's what a requirement looks like:
REQ-1: Google OAuth login
Users can sign in using their Google account. A "Sign in with Google" button appears on the login page. On first login, a new account is created automatically using the user's Google profile (name, email, avatar).
Acceptance Criteria:
- A "Sign in with Google" button is visible on the login page
- Clicking it initiates the Google OAuth flow and redirects back on success
- First-time Google users get an account created with their Google profile info
- Existing users who previously signed up with the same email are linked to their Google account
- Login fails gracefully if the user denies Google permissions
Draft → Confirmed → Out of Scope
Requirements start as Draft. As you review and finalize each one, mark it Confirmed — this signals to the rest of the team that it's ready. If something shouldn't be in this project, mark it Out of Scope.
The Product Spec stage is complete when every requirement is either Confirmed or Out of Scope.
Step 3: Resolve Blockers Before Handoff
Before your spec goes to design and engineering, run a Blocker Analysis. You can analyze the entire project, a specific workstream, or a single requirement.
The AI reviews your PRD and requirements looking for problems:
| What it flags | Example |
|---|---|
| Wrong Assumption | "The spec assumes existing sessions will migrate automatically, but the current session store doesn't support token conversion" |
| Contradiction | "REQ-2 says all social logins create new accounts, but REQ-4 says existing email users should be linked automatically" |
| Missing Context | "What happens if a user signs up with email first, then tries Google login with the same email?" |
| Unclear | "Session timeout requirements don't specify whether the timeout resets on activity" |
| Gap | "No requirement covers account deletion or unlinking a social login provider" |
Each blocker gets a severity:
- High — must resolve before proceeding
- Medium — should resolve before implementation
- Low — can clarify later
Resolving Blockers
Review each blocker and provide your answer through chat. The workflow is simple:
Open → Answered → Resolved
You can't just dismiss a blocker — you need to provide a response, which creates an audit trail. A blocker might look like:
BLK-1 (High): Google OAuth assumes existing users can be linked by email, but the current user model doesn't enforce unique emails
The spec says users who signed up with email and later try Google login with the same email should be linked. But the current system allows duplicate emails across accounts. Engineering needs to know: should we enforce email uniqueness first, or handle duplicates in the linking logic?
Your answer might be: "Enforce email uniqueness going forward. Existing duplicates should be flagged for manual resolution — don't auto-link if there are multiple accounts with the same email."
When to Hand Off
Your spec is ready for the next stages when:
- All requirements are Confirmed or Out of Scope
- All High-severity blockers are Resolved
- You're comfortable with the remaining Medium/Low blockers being resolved during design or engineering
Next: Designers pick it up from here — Guide: Designing the Experience. Or jump to Guide: Building and Shipping if your project doesn't have a UI/UX stage.