discovery

PM conducts interview following this flow:

• PM owns the conversation and spec at all times
• PM asks the customer only what is necessary to set direction, define must-haves, and avoid product-level mistakes
• Dispatch Researcher only when the answer depends on outside evidence:
  • the client asks for reference apps, competitor examples, or "what do similar products use?"
  • the PM needs grounded options for login, payments, chat, maps, search, analytics, CMS, or vendors
  • pricing, licensing, regional availability, compliance, or platform support affects the requirement
  • a vague preference needs real-world examples before the PM can ask the next question
• PM sends Researcher a bounded question, project constraints, and the decision it should unblock
• Researcher returns a concise brief with options, recommendation, evidence, and open unknowns
• PM translates that brief into client-language choices and updates the spec

Round 1 — Big Picture:

• "What does this app/service do? Describe it in one sentence."
• "Who will primarily use it?"
• "What's the core value? Why would someone use this?"
• "Any reference apps or websites you'd like to point to?" → Understanding Check: PM summarizes Big Picture back to client in 2-3 sentences. Client confirms or corrects before proceeding.

Round 2 — Features (one at a time):

• For each user type: "What does this type of user mainly do?"
• "What should happen when this feature encounters an error?"
• "Please separate must-have features from nice-to-have features." → Understanding Check: PM summarizes feature priorities back to client. "Here's what I understand: [core features A, B, C] are must-haves, [D, E] are for later. Is that correct?"

Round 3 — Constraints (one at a time):

• "Web? Mobile? Both?"
• "Design feel? (a) Minimal (b) Rich/decorative (c) Reference app if you have one"
• "Is login required? What method?"
• "Do you need payment functionality?"
• "Do you need real-time features? (chat, notifications, location tracking, etc.)" → Understanding Check: PM summarizes technical constraints.

Round 4 — Validation:

• Compile all answers into spec.md (using templates/spec.md)
• Show the customer a concise summary only if a final business-level confirmation is needed
• Resolve any critical mismatches
• Record remaining non-critical unknowns as assumptions, internal validation targets, or QA checks

Round 5 — Pre-Handoff Question Generation (NEW):

• PM anticipates questions the Design team (CTO + Designer) will have:
  • Technical ambiguities: unclear data flows, missing integration details
  • UX ambiguities: unspecified user flows, missing edge-case behaviors
  • Business ambiguities: priority conflicts, unclear scope boundaries
• PM attempts to answer from interview knowledge; unresolvable ones go to CEO
• CEO triages: answer internally or ask client ONE focused question
• Resolved questions are appended to spec.md as "Design Team Pre-Brief" section

Spec Completion Check:

• Count critical customer-owned questions in spec
• If > 0: continue interview
• If = 0: proceed to internal approval

Approval Flow: a. CEO reviews spec (dispatch forge:ceo agent) b. CEO confirms scope is feasible and safe to advance internally c. If no customer-owned blocker remains, update state.json: phase=2, phase_id="design", phase_name="design", spec_approved=true d. Update company runtime for the next gate:

• node scripts/forge-lane-runtime.mjs set-company-gate --gate design_readiness --gate-owner cto --delivery-state in_progress e. Only ask the customer again if a true business blocker remains unresolved

PM defines the session brief for the next handoff:

• current_session_goal
• session_exit_criteria
• next_session_goal
• next_session_owner
• session_handoff_summary
• Preferred helper: node scripts/forge-lane-runtime.mjs set-session-brief --goal "Close design readiness gate" --next-owner cto --handoff "{summary}"

Save spec to .forge/spec.md

Create rollback tag: git tag forge/v1-spec

Transition to Phase 2 (forge:design)