1. 🚫 비판 및 평가 절대 금지 (No Criticism)
   내용: "그건 이미 있는데요?", "그거 비실용적인 것 같아요", "기술적으로 안 돼요"라는 말은 이 단계에서 완전 금지입니다.

이유: 비판이 시작되는 순간 참가자들은 검열을 시작하고 입을 닫아버립니다.

가이드 팁: "지금은 아이디어를 '평가'하는 시간이 아니라 '쌓는' 시간입니다. 평가는 나중 단계에서 현미경 들이대고 할 테니, 지금은 그냥 뱉어주세요."

2. 🚀 양(Quantity)이 곧 질이다
   내용: 완벽하고 세련된 아이디어를 내려고 고민하지 말고, 유치하고 사소한 아이디어라도 무조건 많이 쏟아내야 합니다.

이유: 쓸데없어 보이는 아이디어 20개가 모여야 그 안에서 진짜 보석 같은 '수요자 중심'의 아이디어 1개가 나옵니다.

가이드 팁: "세련된 기획서 말고, '아, 나 이거 진짜 귀찮아!' 같은 날것 그대로의 불편함을 많이 던져주시는 분이 오늘 모임의 MVP입니다."

3. 🛠️ 기술적 한계 지우기 (개발자 대상 주의 사항)
   내용: 개발자 참가자들은 문제를 듣자마자 "이거 API 제공 안 되는데", "DB 설계 복잡하겠는데"라며 구현 가능성(Feasibility)부터 계산하기 쉽습니다. 이 단계에서는 기술의 벽을 잠시 허물어야 합니다.

이유: 기술적 한계에 갇히면 기존에 세상에 존재하는 뻔한 솔루션밖에 생각하지 못합니다.

가이드 팁: "개발자분들, 지금 머릿속의 컴파일러는 잠시 꺼두세요. '마법처럼 다 구현 가능하다'고 치고, 저 사용자가 겪는 문제가 진짜 해결할 가치가 있는 문제인지에만 집중해 주세요."

4. 🔀 타인의 아이디어에 편승하기 (Building on Ideas)
   내용: "A님이 말씀하신 그 불편함 있잖아요? 거기에 이런 기능까지 더해지면 더 대박이겠는데요?" 하는 식의 징검다리 대화를 환영해야 합니다.

이유: 혼자만의 생각보다 타인의 아이디어가 자극제가 되어 융합될 때 예상치 못한 혁신적인 Micro-SaaS 아이디어가 나옵니다.

가이드 팁: "남의 아이디어를 뺴앗는 게 아니라 덧붙여서 키우는 겁니다. 'Yes, and...' (맞아요, 그리고 거기다 이것도!) 화법을 써주세요."

5. 🎯 '해결책'이 아니라 '문제'에 집착하기
   내용: "이런 앱 만들어요!"가 아니라, "내가 언제, 어디서, 왜 짜증이 났는지"라는 상황과 페인 포인트(Pain Point) 자체를 명확히 기술해야 합니다.

이유: 해결책(Solution)부터 정해두고 대화를 시작하면 결국 또 공급자 중심의 '뇌피셜 앱'이 탄생합니다.

가이드 팁: "우리는 오늘 멋진 앱 아이디어를 뽐내러 온 게 아닙니다. 내가 일상에서 겪는 '진짜 문제'의 정체를 고발하는 데 집중해 주세요."