Pressure-test product requests before spec writing

Pressure-test product requests before implementation

Founders and product managers blocking time BEFORE spec writing to validate that the requested feature is actually the right product.

• · Literal feature request (e.g., 'add X')
• · Selected mode: SCOPE EXPANSION | HOLD SCOPE | SCOPE REDUCTION

• · Reframed product brief with deeper analysis
• · Recommendation (Proceed | Reframe | Reject)
• · 5-8 specific features or design decisions (EXPANSION mode)

• · Feature request stated clearly
• · User selects or implicitly states mode preference

• · May expand scope beyond feasibility (EXPANSION mode)
• · Can underestimate legitimate constraints (REDUCTION mode)
• · Does not generate implementation details — review only

• · Three distinct modes with explicit switching (EXPANSION/HOLD/REDUCTION)
• · Challenges literal request with 'what is this FOR' question
• · EXPANSION mode delivers 10-star version with 5-8 specific features
• · HOLD mode identifies unstated assumptions, edge cases, error states, UX gaps, security issues
• · REDUCTION mode strips to minimum viable version