§0제품 정체성 + 최상위 가치
고객사의 모호한 문제와 커뮤니케이션 기록을 구조화된 디스커버리 질문 파이프라인으로 전환해 요구사항 합의를 이끄는 의사결정 지원 플랫폼
- 최상위 가치
- 커뮤니케이션 모호성 제거를 통한 프로젝트 요구사항 정합성 확보
- 한 마디 테스트
- too-broad'의사결정을 위한 도구' — 노션·엑셀·지라 같은 기존 협업 도구와의 차별점을 설명하기 어려워요. '요구사항을 명세화·조율하는 파이프라인'이라는 날카로운 쐐기가 가려져요.
- 명확도
- 정체성 부분 · 최상위가치 부분
- 렌즈 영향
- 정체성이 특정 액션이 아닌 거시적 '의사결정'으로 설정돼, 가입 초기 유저가 첫 30초에 어떤 기능을 써야 할지 모르는 인지적 공백이 생겨요.
§1인풋 성숙도 진단
- 종합 등급
- 부분 — 3/10 작성됨
- 증거 수준
- direct 0 · document-claim 3 · unverified 0
3/10 작성됨 · 이슈 8
| 구성 요소 | 상태 | 비고 |
|---|---|---|
| 정체성 | ✓작성됨 | 큰 방향은 있으나 어느 가치사슬을 긁는지 미조율 |
| 문제 맥락 | ✓작성됨 | 요구사항 조율·반복 기능 파악 맥락 합리적 |
| 페르소나 | ✗공백 | 타겟 기획자·PM 업무 행동 분석 부재 |
| 문제·기능 | ✗공백 | — |
| 수익 | ✗공백 | — |
| UX | ✗공백 | — |
| 디자인 | ✗공백 | — |
| 마케팅 | ✗공백 | 광고비 100만원 소진 데이터는 있으나 채널·가치 정렬 전략 부재 |
| 기술 | ✗공백 | — |
| 핸드오프 | !있음 · 보강 필요 | 게이트 2/5 다음 구현 참조 가능한 스택·스키마 제약 정리됨 |
§2보존 체크리스트
구글 계정 → 팀(Tenant) 로그인 연동과 Project-Discovery-Meeting 관계 구조가 이미 운영 중이라, 개편할 때 이 연결이 깨지지 않도록 보존해야 해요.
- 기존 UX 흐름 — 구글 계정 → 팀(Tenant) 자동 생성·귀속 로그인 연동 흐름
- 로직·계약 — Project-Discovery-Meeting 관계 구조(관계형 DB 모델)
- 유저 보호 항목 — LangGraph·pgvector·RLS 핵심 기술 아키텍처
§3인풋 분류 + 점검 범위
- 인풋 분류
- service-and-development — 서비스 설계 + 개발 설계
- 점검 모드
- full-review — 비즈니스/서비스 정체성·경쟁 정합 축 전수 점검 우선
§4팀 역량 진단
추천 경로
founder 컨설팅
복잡한 현장 문제를 도출하고 고도화된 기술 파이프라인으로 구현하는 엔지니어링 역량은 최고 수준이지만, 유저 초기 장벽을 해소하고 경쟁 도구와의 마찰을 우회해 스무스한 유입을 만드는 '서비스 경험 모델링'·'그로스 인지 설계' 역량이 부재해요.
✓강점 — 살릴 것
- B2B 실무 PM 현장에 대한 뛰어난 직관과 밀도 높은 도메인 지식
- LangChain·LangGraph 기반 지능형 디스커버리 파이프라인·프롬프트 에이전트 조율 실천력
△역량 gap — 채울 것
- 노션·지라 등 거대 경쟁 생태계와의 데이터 정합 관계를 풀어내는 채널 정합적 서비스 설계 능력
- 초기 설정 장벽 전에 가치부터 느끼게 하는 Wow Surface 경험 기획력
코치 노트팀이 설계한 기술 아키텍처는 흠잡을 데 없이 탄탄해요. 다만 이 훌륭한 엔진을 진입 30초 만에 맛보게 하려면 '행정 업무(기록)'가 아닌 '정답 자판기(Wow)'의 탈을 씌워야 해요.
§5근본 원인 체인
맨 위 뿌리에서 시작해 아래로 증상이 번져요 — 뿌리를 잡으면 아래가 연쇄로 풀려요.
뿌리
추상적 정체성 정의
2
경쟁 차별성·가치사슬 타겟팅 부재
3
입력 지연·이중 입력 마찰
4
핵심 의사결정 도출 전 초기 이탈
5
선행 지표·비즈니스 모델 정합성 상실
최종 증상- 정체성 영향
- 정체성이 구체적 액션이 아닌 거시적 '의사결정'으로 설정돼, B2C 관점 초기 유저가 첫 30초에 어떤 기능으로 문제를 풀지 모르는 인지적 공백이 발생해요.
- 살릴 강점
- B2B SI 현장의 요구사항 모호성·합의 지연이라는 현실 페인포인트를 완벽히 타겟팅LangGraph 기반 디스커버리 파이프라인 — 단순 요약을 넘어 합의 유도 질문을 지능적으로 생성
§6핵심 이슈 8
높음C1가치사슬 내 경쟁 정합 전략 및 Notion/Slack 대응 차별화 실종발견 7
- 근본 원인
- 이미 점유된 노션·지라·슬랙 대비 Discov만의 진입 쐐기(Wedge)를 정의 못 해, 단순 추가 입력 도구로 인식됨.
- 제안
- 기존 도구와 경쟁하는 대신 '데이터를 흡수해 질문을 도출하는 쐐기'로 진입점을 전면 수정하세요.
- 태그
높음C2시장 위치와 경쟁 승리 조건을 먼저 고정해야 해요발견 7
- 근본 원인
- 가치사슬 구간, 직·인접 경쟁자, 이길 기준이 하나의 판단 근거로 닫히지 않았어요.
- 제안
- 핵심 고객의 가치사슬·대체재·소유할 가치 구간·승리 조건을 한 장으로 정리하세요.
- 태그
보통C3가이드라인·필수 입력 흐름이 사용자 부담으로 남아 있어요발견 3
- 근본 원인
- 필수 입력·기본값·작성 난이도·다음 행동 안내가 닫히지 않아 진입 장벽이 높아요.
- 제안
- 필수/선택 입력을 분리하고 기본값·템플릿·다음 행동 추천을 여정 기준으로 정의하세요.
- 태그
보통C4의사결정 '합의' 지점 부재 및 맥락 보존 모델 한계발견 7
- 근본 원인
- 질문·답변 생성에 치우쳐 최종 '승인 상태'·'근거 객체'가 누락돼 이력이 파편화됨.
- 제안
- 각 스레드의 최종 합의 상태를 Lock하고 Rationale을 아카이빙하는 '의사결정 합의 객체'를 추가하세요.
- 태그
보통C5데이터 동기화 부재 및 객체 결합 위험성발견 5
- 근본 원인
- Scope 정보와 스냅샷 문서 간 동기화 단절 + 조직 구조 미고려한 Project-Person 하드코딩 결합.
- 제안
- Scope 변경 시 하류 문서에 노티파이 전파·동기화하는 무결성 로직 + Person 역할 분리.
- 태그
보통C6의사결정 확신 지표 미비 및 구독 과금 구조 모호성발견 4
- 근본 원인
- 불확실성 감소(선행) 대신 활동량(후행)을 측정하고, 과금 단위도 연동 안 됨.
- 제안
- 지표를 '요구사항 모호성 감소 지수'로 전환하고 연동된 Usage 과금 단위를 명확화하세요.
- 태그
보통C7Phase 범위와 변경 근거를 결정 로그로 닫아야 해요발견 4
- 근본 원인
- 취소선·다음 Phase 이월·포함 여부가 명시적 근거 없이 섞여 구현 기준이 흔들려요.
- 제안
- 각 항목의 포함/제외/이월 결정·이유·구현 영향·재검토 조건을 decision log로 남기세요.
- 태그
보통C8기술 선택을 요구사항과 운영 기준에 연결해야 해요발견 4
- 근본 원인
- 스택·인프라 선택이 나열됐지만 요구사항·trade-off·장애/확장 기준과 미연결.
- 제안
- 각 기술 선택의 요구사항·대안·선택 이유·실패 조건·운영 수용 기준을 ADR로 정리하세요.
- 태그
§7해소 경로
- 기반 연결 26
- 정체성을 '의사결정 일반'에서 '요구사항 모호성 합의'로 좁히고 타 도구(노션·지라)의 플러그인으로 가치사슬을 정렬하면, 입력 마찰·이탈 관련 26개 지표가 동시 해소돼요.
- 별도 처리 15
- 취소선·DISCUSS로 남은 기술 스택 결정, 페이지네이션 엣지, 프롬프트 자산 유출 방어 등은 엔지니어링 오너가 백로그로 이관해 독립 선결해요.
§8발견 전수 41
보통[1] 의사결정 도구라는 정체성과 기록 위주 기능 간의 불일치C2axis 39
- 관점 축
- 39 · Value Chain 경쟁 정합
- 핵심
- 의사결정 도구와 정보 구조화 기능의 간극
- 근거
- 제품은 의사결정 지원을 표방하나 기능 목록은 기록/관리 위주입니다. 유저가 기록을 하는 것만으로 의사결정에 도달할 수 있다는 논리적 가교가 비어 있어, B2C 초기 유저가 가입 후 기록만 하다가 이탈할 위험이 매우 높습니다.
- 제안
- 기록/관리 기능을 의사결정 결과 도출과 직접 연결하는 '의사결정 가이드' 기능 우선 배치
- 시나리오
- B2C 초기 사용자기대 — 작성한 회의록이 의사결정에 어떻게 쓰이는지 안내받음
실제 — 데이터 기록에서 종료되고 의사결정은 여전히 사용자의 몫으로 남음 - 왜 중요
- 기록이 의사결정으로 이어지지 않는 도구는 대체재(노션 등)가 너무 많기 때문
보통[2] 구독 모델 도입을 위한 가치 지표 미수립C5axis 36
- 관점 축
- 36 · 표면 단계화 전략
- 핵심
- 구독 가치를 증명할 데이터 기준점 부재
- 근거
- 다음 단계로 구독 모델 도입을 고려 중이나, 현재 Discovery Questions 생성/답변 과정에서 유저가 얻는 효용(의사결정 단축 등)을 측정할 지표가 정의되어 있지 않아 유료 전환 논리가 약합니다.
- 제안
- 무료/유료 구간을 나눌 기준인 '의사결정 완료 경험'에 대한 로그 측정 지표 설계
- 시나리오
- 서비스 PM기대 — 우리 제품을 쓰면 의사결정이 빨라진다는 데이터를 확인하고 유료 전환
실제 — 제품을 써도 의사결정이 빨라졌는지, 데이터를 얼마나 쌓았는지 알 수 없음 - 왜 중요
- 유료 전환의 근거가 없으면 BM 정합성이 깨지기 때문
높음[3] 가치사슬 내 경쟁 정합 전략 누락C1axis 39
- 관점 축
- 39 · Value Chain 경쟁 정합
- 핵심
- 기존 의사결정 방식 대비 고유 우위 정의
- 근거
- 의사결정을 돕는 제품이지만, 경쟁 제품이나 사용자의 기존 의사결정 방식 대비 차별점을 정의하는 Value Chain 분석이 누락되어 있습니다. 초기 유저가 왜 이 제품을 써야 하는지 논리가 부족해 보입니다.
- 제안
- 경쟁사 대비 사용자의 의사결정 가치사슬 단계를 분해하고, 우리가 점유할 핵심 구간을 정의하세요.
- 시나리오
- SI 에이전시 PM 최은진기대 — Discov를 통해 의견이 상충하는 3가지 파트에 대해 AI가 유도한 명확한 디스커버리 질문을 전송하여 단 하루 만에 합의를 완료함
실제 — Notion에 기록하는 것과 Discov에 기록하는 것에 경험 차이가 없어 기존에 익숙한 Notion에만 계속 적고 Discov를 방치함 - 왜 중요
- 기존 범용 문서 도구의 장악력을 깨뜨리고 Discov의 첫 진입을 유도하는 생존적 경쟁 전제이기 때문이에요.
보통[4] 기술 아키텍처 내 미확정 의사결정(DISCUSS) 방치C6axis 38
- 관점 축
- 38 · 기술 자산 보호 정합
- 핵심
- 기술 명세의 미확정 항목은 구현 리스크를 높입니다.
- 근거
- 설계 패키지 내 기술 및 비즈니스 결정 사항 곳곳에 'DISCUSS'가 남아 있어, 팀이 구현 단계에서 의사결정 지연이나 혼선을 겪을 가능성이 높습니다.
- 제안
- 모든 DISCUSS 마킹 항목에 대해 팀 내 즉각적인 결정을 내리고 문서를 확정하세요.
- 시나리오
- 개발자기대 — 명확한 사양에 따라 s3 저장 방식 확정
실제 — DISCUSS 마킹을 보고 구현 방향을 결정하지 못해 대기 - 왜 중요
- 명세의 모호함은 구현 생산성을 직접 저해합니다.
보통[5] 대용량 데이터 필터링 기능과 페이지네이션 누락의 상충C6axis 2
- 관점 축
- 2 · 엣지
- 핵심
- 페이지네이션 없는 필터링은 대규모 데이터에서 성능 저하를 초래합니다.
- 근거
- 고객 관리 기능에서 이름/이메일 필터링이 가능하다고 명시했으나, 페이지네이션은 다음 Phase로 미루었습니다. 데이터가 수천 건이 넘어가면 필터링 결과 반환 시 시스템 부하가 발생할 수 있습니다.
- 제안
- 현재 구조로 대용량 데이터 필터링 시 부하 문제를 감당할 수 있는지 검토하고, 필요시 최소한의 페이지네이션을 선제 도입하세요.
- 시나리오
- 관리자기대 — 빠른 필터링 결과 확인
실제 — 데이터 전체 로딩으로 인한 성능 저하 - 왜 중요
- 성능 저하는 사용자가 제품을 '신뢰할 수 없는 도구'로 인식하게 만듭니다.
보통[6] 기술 스택 선택 및 설계의 불확실성 방치C6axis 38
- 관점 축
- 38 · 기술 자산 보호 정합
- 핵심
- 불확실한 기술 스택 선택의 의도적 방치
- 근거
- Architecture 섹션 내 HTMX/Alpine과 React/Inertia가 혼재되어 있고, 사용 기술이 취소선으로 표기되어 있어 개발 방향성 결정이 유보된 상태입니다. 개발자가 구현을 시작하려 할 때 기술 기반을 결정하지 못해 런타임 오류나 재작업이 발생할 수 있습니다.
- 제안
- 개발 팀 내 기술 스택 결정 회의를 통해 단일 스택으로 명확히 확정하고 선택 근거를 문서화해야 합니다.
- 시나리오
- 개발자기대 — 정의된 기술 스택으로 환경 구성
실제 — 문서 내 상충된 기술 스택 확인 후 결정 지연 - 왜 중요
- 기술 스택은 아키텍처의 기초로 불확실성은 구현 생산성을 직접 저해함
보통[7] 프로젝트별 고객 할당 제약 조건의 모호성C6axis 2
- 관점 축
- 2 · 엣지
- 핵심
- 프로젝트당 고객 할당 제한 정책 모호함
- 근거
- Project 관리 기능에서 고객 할당 제한(최대 10개)이 취소선으로 처리되어 있습니다. 제한이 없다는 것인지, 혹은 추후 정의한다는 것인지 불분명하여, B2B 고객의 프로젝트 규모에 따라 시스템 성능과 로직 대응을 준비할 때 예외 처리를 어디까지 해야 할지 기준이 없습니다.
- 제안
- 프로젝트당 고객 할당 수 제한 정책을 확정하거나, 제한이 없다면 성능 최적화 계획을 명시하세요.
- 시나리오
- 운영 관리자기대 — 설정된 정책에 따라 고객 할당 처리
실제 — 제한 정책 확인 불가로 인한 로직 구현 망설임 - 왜 중요
- 고객사별 프로젝트 규모 산정에 영향을 미치는 비즈니스 규칙임
낮음[8] 대화형 미팅 노트 편집 기능의 논리적 모순C6axis 1
- 관점 축
- 1 · 일반
- 핵심
- 대화형 미팅 데이터 편집 가능성 모순
- 근거
- Meeting Note 기능에서 dialogue 타입 데이터의 편집이 '불가능하다'고 명시되어 있으나 취소선 처리되어 있습니다. 대화형 데이터의 신뢰성을 보장하기 위해 편집을 제한한 것인지, 아니면 기능 구현의 복잡도 때문인지 모호하여 운영 시나리오상 오해의 소지가 있습니다.
- 제안
- 대화형 미팅 데이터의 편집 정책을 명확히 하고 UI/UX 반영 계획을 문서화해야 합니다.
- 시나리오
- 사용자기대 — 편집 시도 및 수정 반영
실제 — 편집 불가 정책 확인 후 정보 정정 어려움 - 왜 중요
- 기록의 신뢰성과 사용자 편의성 간의 균형 문제임
높음[9] 가치사슬 내 경쟁자 침투 방어 전략 미수립C1axis 39
- 관점 축
- 39 · Value Chain 경쟁 정합
- 핵심
- 업무 흐름을 침해하지 않는 침투형 인터랙션 수립
- 근거
- 이미 슬랙이나 노션 등에서 요구사항을 주고받는 SI PM 입장에서, Discov는 추가적인 입력 품을 요구하는 경쟁 도구일 뿐임. 사용자가 현재 쓰고 있는 도구의 워크플로우를 침범하지 않거나, 그 위에서 더 강력한 정합성을 제공하는 전략 없이는 도입 자체가 불가능함.
- 제안
- 기존 업무 도구(Slack, Notion)에서의 임포트 기능 우선 개발 혹은 웹훅 연동 전략 수립
- 시나리오
- 프리랜서 PM 박지훈기대 — Slack이나 이메일 기록을 그대로 연동하여 Discov 내부 질문 템플릿이 자동으로 파싱되게 설계되어 마찰이 전혀 없음
실제 — 회의록 텍스트 파일을 일일이 긁어서 복사 붙여넣기 한 뒤 가이드라인을 수동 매핑하라는 경고에 지쳐 사용을 중단함 - 왜 중요
- SI PM들은 업무 부하가 매우 높아 1분의 추가 작업(Homework) 발생으로도 채택을 즉각 포기하기 때문이에요.
보통[10] 디스커버리 가이드 입력의 높은 진입 장벽C2axis 11
- 관점 축
- 11 · 가치 전달
- 핵심
- 모호함을 풀러 온 유저에게 역으로 가이드를 요구하는 논리적 모순
- 근거
- 사용자는 모호한 문제를 해결하고 싶어서 찾아왔는데, 서비스를 쓰기 위해 '디스커버리 가이드'를 사용자가 직접 작성하게 함. 이는 도구가 제공해야 할 핵심 가치(구조화된 의사결정)를 사용자가 이미 어느 정도 구조화할 수 있어야 한다는 모순된 가정을 포함하고 있음.
- 제안
- 기본 템플릿(SI, 기획, 마케팅 등)을 사전 로드하여 사용자가 직접 가이드를 작성하지 않고도 '선택'만으로 시작할 수 있는 경험 설계
- 시나리오
- 기획자 이사원기대 — 프로젝트 유형 선택 -> 추천 질문 생성 -> 디스커버리 진행
실제 — 가이드라인을 입력하라는 빈 폼을 마주하고, 어떤 가이드를 써야 할지 몰라 창을 닫음 - 왜 중요
- 가이드라인 작성을 모르는 사용자에게 서비스를 사용할 자격이 없음을 선언하는 것과 같음
보통[11] 디스커버리 폼 입력 시점과 의사결정 도구의 가치 인지 불일치C2axis 39
- 관점 축
- 39 · Value Chain 경쟁 정합
- 핵심
- 질문 생성 입력 폼이 아닌 의사결정 시뮬레이션 환경이 먼저 필요함
- 근거
- 유저는 '의사결정'이라는 최종 결과를 위해 가입했으나, 초기 환경이 '질문을 입력하는 가이드 생성기'로 설정되어 있어 B2C 유저의 기대치를 충족하지 못하고 즉시 이탈할 확률이 높아요. 도메인 전문성이 없는 초기 유저에게는 입력 단계 자체가 진입장벽이 돼요.
- 제안
- 초기 유저에게 질문 생성 가이드 입력을 강제하지 말고, 미리 정의된 '디스커버리 템플릿'을 통해 즉시 의사결정 결과를 확인하는 예시 환경을 제공하세요.
- 시나리오
- 초기 가입한 비즈니스 기획자기대 — 비즈니스 문제에 대한 구조화된 의사결정 결과물을 바로 보고 싶음
실제 — 디스커버리 가이드(질문 생성 설정)를 입력하라는 빈 폼을 마주함 - 왜 중요
- 가장 먼저 마주하는 화면에서 가치를 느끼지 못하면 리텐션이 0이 됨
낮음[12] 구독 플랜의 과금 단위(Usage Unit) 정의 미비C5axis 16
- 관점 축
- 16 · 비즈니스
- 핵심
- 프로젝트 수, 디스커버리 스텝, 문서 생성 중 과금 기준 선정이 필요함
- 근거
- 구독 모델 도입을 논의 중이나 과금 단위가 정의되지 않았어요. 프로젝트 수 기반인지, 디스커버리 질문 생성 스텝 수인지, 문서 생성 수인지에 따라 유저의 사용 패턴이 완전히 달라져요. 초기 설계 단계에서 이를 명확히 하지 않으면 향후 과금 체계 변경 시 유저 이탈이 발생해요.
- 제안
- 현재 유저의 Core Feature 사용 패턴(Discovery Step 수 vs 문서 생성 수) 데이터를 기반으로 유저 가치를 가장 잘 대변하는 사용 단위 하나를 선정하여 플랜 구조를 설계하세요.
- 시나리오
- 수익 모델 검증 팀원기대 — 내가 사용하는 만큼 합리적인 가격 정책을 확인하고 싶음
실제 — 어떤 기능 제한인지, 사용량 제한인지 불명확한 플랜 정책을 봄 - 왜 중요
- 수익 모델은 비즈니스 지속가능성의 핵심임
보통[13] 프로젝트 범위(Scope)와 문서화 간의 동기화 단절 위험C4axis 17
- 관점 축
- 17 · 문서 생태계
- 핵심
- 프로젝트의 변경된 Scope가 생성된 문서들에 자동으로 반영되지 않음
- 근거
- Project의 Background, Objectives, Scope는 프로젝트 전체의 진실(Truth)인데, 이를 기반으로 생성된 개별 문서들은 생성 시점의 스냅샷으로 존재해요. 프로젝트 Scope가 업데이트되어도 이미 생성된 문서에는 반영되지 않아 '오래된 문서'로 남을 위험이 커요.
- 제안
- Project Scope 변경 시 해당 Scope와 연결된 문서들을 '업데이트 필요' 상태로 마킹하고 재생성을 유도하는 알림 메커니즘을 설계하세요.
- 시나리오
- 프로젝트 PM기대 — 변경된 Scope가 반영된 최신 문서 내용을 확인하고 싶음
실제 — 이전 Scope로 생성된 구버전 문서 내용만 조회됨 - 왜 중요
- 문서 정합성이 깨지면 의사결정 플랫폼으로서의 신뢰도가 하락함
보통[14] 요구사항 명세 업무와 의사결정 도구의 인지적 간극C2axis 9
- 관점 축
- 9 · 인지
- 핵심
- 행정 업무가 아닌 빠른 발견 효용으로 정비
- 근거
- 사용자는 '의사결정'을 원하는데 시스템은 '구조화된 폼 작성'을 요구하여 사용자가 과제(Homework)를 수행한다는 느낌을 받게 됩니다. 가입 초기 유저가 30초 내에 이 서비스를 통해 무엇을 얻는지 명확하지 않으면 이탈이 가속됩니다.
- 제안
- 작성 중심의 UI를 의사결정 지원 중심의 요약/분석 UI로 전환하고, 유저가 가장 궁금해하는 '불확실성 리스트'를 먼저 보여주도록 UX 순서 재조정
- 시나리오
- 초기 창업팀 PM 강하늘기대 — 한 줄짜리 아이디어를 던지자마자 AI가 '개발 단계에서 2배의 비용을 초래할 모호한 구절 2가지'를 콕 집어 디스커버리 퀘스천을 반환함
실제 — 디렉토리 구조와 담당자 메일 주소, 워크스페이스 명칭 설정 단계를 순차적으로 작성하라는 선행 폼이 가로막음 - 왜 중요
- 초기 유저 획득 퍼널의 30초 경험이 광고 효율 및 잔존율을 실질적으로 결정하기 때문이에요.
보통[15] AI 생성 대화록의 수정 불가 정책과 의사결정 신뢰성 충돌C4axis 18
- 관점 축
- 18 · 운영
- 핵심
- 오류 포함 가능성이 있는 AI 결과물의 비수정 정책
- 근거
- 오디오에서 생성된 Dialogue는 틀릴 가능성이 있는데, 이를 수정할 수 없도록 설계했습니다. 의사결정의 근거(Truth)가 틀린 정보라면 전체 프로젝트 의사결정의 신뢰도가 붕괴됩니다.
- 제안
- 오디오 기반 재생성은 유지하되, 텍스트 형태의 Dialogue 편집 기능을 반드시 추가하여 사용자가 의사결정 근거를 스스로 교정할 수 있도록 보장
- 시나리오
- 프로젝트 매니저기대 — 틀린 용어를 확인하여 올바른 전문 용어로 수정
실제 — 수정 불가함을 확인하고 해당 내용의 답변 생성 오류 발견 - 왜 중요
- 의사결정 지원 플랫폼에서 잘못된 정보를 근거로 제시하면 플랫폼 신뢰도가 즉시 하락함
높음[16] 외부 협업 도구와의 단절로 인한 고객 데이터 중복 관리 부담C1axis 39
- 관점 축
- 39 · Value Chain 경쟁 정합
- 핵심
- 고객이 기존 도구에 저장한 데이터를 수동 복제해야 하는 이중고
- 근거
- 고객 데이터와 프로젝트 정보를 직접 관리하도록 강제하면, 이미 Notion/Jira에 정보가 있는 고객들은 Discov에 정보를 복제하는 과정을 거치지 않습니다. 이는 가치사슬 내 경쟁 정합성에서 치명적인 약점이 됩니다.
- 제안
- Notion/Jira 등 기존 협업 도구와 고객 데이터 및 프로젝트 정보를 연동(Sync)하는 API 우선 개발
- 시나리오
- PM/기획자기대 — Notion의 정보를 끌어와서 프로젝트 참여자로 자동 등록
실제 — Notion에는 있는 리스트를 Discov에 일일이 다시 입력/등록 - 왜 중요
- 이러한 반복 입력 과정은 초기 정착률을 급격히 떨어뜨리며, 가치 전달 이전에 사용자가 중도 이탈하는 핵심 원인임
보통[17] 의사결정 목적과 문서화 업무 간의 가치 불일치C2axis 11
- 관점 축
- 11 · 가치 전달
- 핵심
- 의사결정 플랫폼이나 실제는 문서화 업무가 강조됨
- 근거
- 사용자는 빠르게 의사결정을 내리고 싶어 하지만, 매 단계마다 Guideline을 직접 입력하고 질문을 관리해야 하는 구조는 사용자에게 '의사결정 지원'이 아닌 '가이드라인 작성 업무'라는 과도한 인지적 부담을 줌.
- 제안
- 사용자가 가이드를 직접 입력하는 단계를 최소화하고, 초기 프로젝트 맥락만으로 자동화된 질문 세트를 제공하는 방식으로 밸류 체인 순서를 조정할 것.
- 시나리오
- 프로젝트 PM기대 — 프로젝트 맥락을 넣으면 즉시 필요한 질문 세트가 제공됨
실제 — 가이드라인을 직접 입력하고, 질문 세트를 생성하는 과정을 반복해야 함 - 왜 중요
- PM은 의사결정이 급한데 도구가 문서화 작업을 요구하면 즉시 이탈함.
보통[18] 단계별 Discovery 진행 시 의사결정 맥락 휘발C3axis 32
- 관점 축
- 32 · 결정 근거 완결성
- 핵심
- 질문 기반의 파편화로 의사결정의 근거가 휘발됨
- 근거
- Discovery 단계를 나눌 수는 있으나, 이전 단계에서 내린 결정과 그에 대한 rationale(근거)이 다음 단계 질문 생성 시 명시적으로 연결되지 않아, 단계가 진행될수록 최초의 의사결정 방향성과 어긋날 위험이 큼.
- 제안
- 각 스텝의 Discovery Q&A 저장 시 결정의 근거(Rationale)를 필수 필드로 정의하고, 다음 질문 생성 시 이전 단계의 Rationale를 AI 컨텍스트에 포함할 것.
- 시나리오
- 프로젝트 팀원기대 — 이전 결정의 맥락을 확인하고 합리적으로 수정함
실제 — 데이터는 남아있으나 당시 의사결정의 rationale이 없어 수정을 망설임 - 왜 중요
- 결정의 근거가 없으면 변경 시 신뢰도가 낮아짐.
보통[19] 타 업무 도구와의 단절로 인한 데이터 이중 관리 부담C1axis 27
- 관점 축
- 27 · 도구 생태계
- 핵심
- 기존 업무 도구와의 연동 부재로 수동 작업 비용 과다
- 근거
- 고객은 이미 Slack, Notion, 화상 회의 도구에 정보를 기록 중임. Discov에 정보를 재입력하거나 대화록을 파일로 변환하여 업로드하는 구조는 기존 워크플로우를 방해하여 채택률을 저하시킴.
- 제안
- 수동 입력 방식 대신 Notion 등 외부 도구 연동 API를 우선 고려하거나, 최소한 대화록 내용을 클립보드에서 바로 분석할 수 있는 간편 입력 창을 제공할 것.
- 시나리오
- 프로젝트 PM기대 — Notion 내에서 바로 연동하여 채움
실제 — Notion 내용을 복사하여 파일로 저장하거나 직접 입력함 - 왜 중요
- 도구가 업무 효율을 방해하면 가장 먼저 버려짐.
보통[20] Discovery Step과 Meeting Note 데이터 간의 동기화 논리 모순C4axis 33
- 관점 축
- 33 · 교차 문서 모순
- 핵심
- 의사결정 근거를 생산하는 두 기능 간 데이터 버전 제어 미비
- 근거
- Meeting Note에서 Discovery Q&A를 생성/수정할 때, 기존 Discovery Step의 버전을 업데이트하는지 혹은 별도의 Step을 생성하는지에 대한 논리가 부재하여 의사결정의 이력이 파편화됨.
- 제안
- Meeting Note에 의한 Discovery 업데이트가 신규 Step 생성인지 기존 Step 수정인지 명확히 정의하고, 변경 이력(Revision) 관리 정책을 수립하세요.
- 시나리오
- 프로젝트 PM 김대리기대 — 회의록 생성 -> Q&A 업데이트 -> Discovery Step 버전에 반영됨
실제 — 회의록 생성 -> Q&A 업데이트 -> 어느 버전의 Discovery가 업데이트되는지 불명확하여 데이터 충돌 발생 - 왜 중요
- 결정 근거가 되는 Discovery 데이터가 정확하지 않으면 의사결정 플랫폼으로서의 신뢰가 완전히 무너짐
보통[21] 로드맵 기능 파편화를 야기하는 '다음 Phase' 표현의 모호성C6axis 34
- 관점 축
- 34 · 참조 버전 무결성
- 핵심
- 기능 우선순위의 기준이 되는 'Phase' 개념의 정의 부재
- 근거
- 문서 곳곳에 '다음 Phase'가 반복되지만, 이것이 시간 순서인지 기능 우선순위인지에 대한 정의가 없어, 개발자가 특정 기능의 개발 시점을 결정할 때 혼란을 겪음.
- 제안
- Phase를 시간적 로드맵(예: v1, v2) 또는 마일스톤 단위로 정량화하고, 각 기능 명세마다 구현 시점을 명확히 매핑하세요.
- 시나리오
- 개발자기대 — 명세서를 보고 언제 개발할지 확인 -> 해당 시점에 개발
실제 — 명세서에 '다음 Phase'라고만 적혀 있어 이번에 개발해야 할지 다음으로 미뤄야 할지 결정할 수 없음 - 왜 중요
- 팀 구성원이 스스로 의사결정을 내릴 수 없어, 1인 4역을 하는 리더의 의사결정 개입을 유도하게 됨
보통[22] 추후 구현 예정인 조직 관리와 현재 Person/Project 구조 간의 아키텍처 결합 위험C4axis 29
- 관점 축
- 29 · 보존 위험
- 핵심
- 미래 기능을 위해 현재 구조를 유연하게 관리할 필요성
- 근거
- 내부 조직 관리 기능이 추후 구현될 예정이나 현재 구조에 조직 관계(상위/하위)가 반영되어 있지 않아, 추후 구현 시 관련 객체(Person, Project 등)와의 관계 재설계로 인한 대규모 수정이 예상됨.
- 제안
- 현재 구조에서 조직(Organization)과 사람(Person)의 연결 고리를 추후 유연하게 변경 가능하도록 중간 계층(Entity Mapping)을 설계하세요.
- 시나리오
- 설계자기대 — 현재 데이터베이스 구조에서 확장하여 기능 추가
실제 — 현재 Person이 Project에 직접 연결되어 있어, 조직 구조 변경 시 Project 참여자와 Organization 멤버 간의 데이터 정합성을 맞추기 위해 전체 재설계가 필요함 - 왜 중요
- 보존해야 할 초기 데이터 구조가 나중에 더 나은 기능 구현을 가로막는 기술 부채가 됨
보통[23] 의사결정 확신 점수가 아닌 활동량 위주의 지표 설정C5axis 35
- 관점 축
- 35 · 선행·후행 지표 구분
- 핵심
- 수량이 아닌 합의 도달 점수로 성공 정의
- 근거
- 현재 서비스는 회의록 개수나 Discovery 질문 개수 등 '활동성(Lagging)' 지표를 성공의 척도로 삼고 있습니다. 의사결정 도구라는 본질은 유저가 얼마나 빠르게 불확실성을 해소했는지(Leading)에 있는데, 이 지표가 설계에서 완전히 누락되었습니다. 이는 유저가 첫 30초 내에 왜 이 도구를 써야 하는지 느끼지 못하게 만드는 핵심 원인입니다.
- 제안
- 각 Discovery 단계를 거치며 유저의 '의사결정 확신 점수(Confidence Score)'가 변하는 과정을 지표화하고 이를 대시보드의 leading indicator로 설계하세요.
- 시나리오
- B2B SaaS 개발사 리드 PM 최현우기대 — Discov가 '고객 합의도 95% 도달, 잔여 리스크 1건 해결'이라는 대시보드를 띄우며 결론 도출에 대한 강력한 확신을 줌
실제 — 단순히 '생성된 질문 45개, 총 메모 12개'라는 단순 활동 건수 통계만 화면에 유지됨 - 왜 중요
- 수량 지표는 가치 증명이 약해 전환 유도가 불가능하고, 선행 지표가 정의되어야 유저의 유료 결제 정당성이 서기 때문이에요.
보통[24] 가치사슬 전환 단계에서 의사결정의 명확성 지표 부재C5axis 35
- 관점 축
- 35 · 선행·후행 지표 구분
- 핵심
- 디스커버리에서 의사결정으로의 전환 신호 측정
- 근거
- 가치사슬 내에서 'Discovery 정보 수집' 단계와 '의사결정 도출' 단계는 별개의 가치를 가집니다. 현재는 이를 분리하지 않고 모든 기록을 동등하게 취급합니다. 유저가 언제 '질문 단계'를 벗어나 '결정 단계'로 넘어갔는지, 그 전환 신호를 포착하는 지표가 없기에 유저는 단순히 기록을 쌓는 숙제만 하는 기분을 느끼게 됩니다.
- 제안
- Discovery 질문 세트 종료 시점이 아닌, 유저가 특정 솔루션을 선택하거나 가설을 채택한 시점을 '결정 포인트'로 정의하고, 이 전환율을 가치 지표로 설계하세요.
- 시나리오
- 프로젝트 리드기대 — 누적된 데이터를 바탕으로 팀이 최종 합의를 도출하고 그 결정을 대시보드에 기록함
실제 — 정보만 계속 쌓이고 실제 합의된 결정을 관리할 곳이 없어 다시 다른 메신저나 문서 도구로 돌아감 - 왜 중요
- 가치사슬의 핵심인 전환 단계(결정)가 지표로 가시화되지 않아 유저가 서비스 내에서 합의를 완료했다는 경험을 하지 못함
보통[25] 기존 업무 도구와의 경쟁 전략 부재C1axis 39
- 관점 축
- 39 · Value Chain 경쟁 정합
- 핵심
- 기존 도구와 동일 선상에서 경쟁 중
- 근거
- 사용자들은 이미 Notion이나 Jira를 사용하여 요구사항과 문서를 관리하고 있습니다. 단순히 기록을 저장하는 것은 경쟁 우위가 되지 않으며, 의사결정 파이프라인으로 전환하는 차별화 지점을 경쟁 환경과 연결해야 합니다.
- 제안
- Notion/Jira와 같은 기존 업무 도구와의 가치사슬 내 위치를 재정의하고, 이 도구들과의 통합 또는 전용 워크플로우를 통한 차별화 포인트 재수립
- 시나리오
- 프로젝트 리더 김 팀장기대 — Notion에 없는 의사결정 파이프라인의 명확한 가치 확인 후 전환
실제 — Discov 가입 후 기존 Notion과 똑같은 기록 위주 사용 경험을 함 - 왜 중요
- 경쟁 도구와 기능이 중복되면 유저에게 전환 비용만 발생시키는 도구로 인식되어 즉시 이탈함
낮음[26] 첫 가치 경험(Wow Surface)을 가로막는 설정 단계C2axis 36
- 관점 축
- 36 · 표면 단계화 전략
- 핵심
- 설정 단계가 가치를 체감하는 속도를 저해함
- 근거
- 가입 후 바로 디스커버리를 수행하는 것이 핵심 가치임에도, 팀/프로젝트/고객/담당자 등 4~5단계의 설정을 완료해야만 디스커버리를 시작할 수 있습니다. 이는 유저의 인내심을 테스트하는 과도한 초기 관리 단계입니다.
- 제안
- 초기 가입 시 즉시 Discovery를 시작하고 프로젝트 설정은 나중에 채우는 온보딩 방식(Soft-onboarding)으로 개선
- 시나리오
- PM 박대리기대 — 가입 후 1분 안에 질문지 생성
실제 — 가입 -> 팀 생성 -> 프로젝트 생성 -> 고객 등록 -> 담당자 연결 -> 디스커버리 가능 - 왜 중요
- 첫 30초 내에 핵심 기능을 보지 못하면 유저는 가치를 느끼지 못하고 이탈함
보통[27] 광고 효율 저하와 실제 서비스 사용 행태의 괴리C1axis 37
- 관점 축
- 37 · GTM-검증 정합
- 핵심
- 마케팅 타겟과 실사용 목적이 불일치
- 근거
- 마케팅은 의사결정 도구로 홍보하지만, 유저는 미팅 노트/녹취록 관리자로 서비스를 이용하고 있습니다. 유저가 원하는 가치와 홍보하는 가치가 일치하지 않으므로 광고 효율이 낮고 고객 확보 비용(CAC)만 낭비하고 있습니다.
- 제안
- 현재 유저들이 기록 용도로 사용 중인 행태를 데이터화하여, 기록 기반의 의사결정 파이프라인으로 자연스럽게 진입하게 하는 UX 연결(기록 후 디스커버리 생성) 구현
- 시나리오
- 기획자 최 대리기대 — 미팅 노트 작성 후 자동 의사결정 도출
실제 — 미팅 노트 작성 후 기록만 남음(기록 도구로서 사용) - 왜 중요
- 유저가 인식하는 서비스 가치가 마케팅 메시지와 다르면 장기 유지(Retention)가 불가능함
보통[28] 핵심 로직의 외부 노출 위험성C6axis 38
- 관점 축
- 38 · 기술 자산 보호 정합
- 핵심
- 의사결정 프로세스 로직의 자산화 필요
- 근거
- Langchain과 Langgraph 기반의 Discovery 파이프라인은 Discov의 핵심 기술 자산입니다. 시스템이 구조를 너무 투명하게 보여주면, 타 도구들이 해당 프로세스를 그대로 복제하여 자사 서비스에 내장하는 것이 쉬워질 수 있습니다.
- 제안
- Discovery 파이프라인 로직의 핵심 파라미터와 질문 생성 모델 구조를 로컬 모델 혹은 독자적인 구조화 엔진으로 격리 관리
높음[29] 이해관계자 의견 조율 및 합의 프로세스 부재C1axis 39
- 관점 축
- 39 · Value Chain 경쟁 정합
- 핵심
- 요구사항 합의를 위한 stakeholder 커뮤니케이션 도구 부재
- 근거
- B2B SI 현장에서는 회의록 기록보다 고객사/내부 조직 간의 의견 충돌을 조율하고 합의를 기록하는 것이 실질적인 '의사결정' 과정입니다. 현재 시스템은 기록과 답변 생성에만 집중되어 있어 실제 PM의 업무 핵심인 '합의 관리'를 지원하지 못합니다.
- 제안
- 요구사항에 대한 이해관계자별 피드백 트래킹 및 의견 조율 프로세스를 Discovery 과정에 추가 고려
- 시나리오
- B2B SI PM 김대리기대 — Discov 내에서 의견 대립 상황을 기록하고 해당 항목을 '합의 대기' 상태로 관리
실제 — Discov 내에는 의견 대립을 별도로 관리할 공간이 없어 이메일이나 슬랙으로 논의를 옮김 - 왜 중요
- Discov가 '의사결정 도구'로서의 신뢰성을 잃게 만드는 치명적인 워크플로우 단절
보통[30] 회의록 정보 부재 시 정보 에스컬레이션 경로 부재C3axis 11
- 관점 축
- 11 · 가치 전달
- 핵심
- 데이터 기반의 자동 답변 생성 시 에러 대응 메커니즘 부재
- 근거
- Meeting Note에 답변에 필요한 정보가 없을 경우, 시스템이 이를 인지하고 PM에게 질문을 던지거나 부족한 정보를 파악하도록 유도해야 합니다. 현재 설계는 '모든 정보가 기록에 있다'는 가정 하에 작성되어, 실무의 정보 누락 상황을 방치합니다.
- 제안
- 답변 생성 실패 시 '정보 부족(Need more info)' 상태를 플래그하고 PM에게 추가 확인을 요청하는 루프 설계
- 시나리오
- B2B SI PM 김대리기대 — Discov가 답변 생성에 실패했음을 알리고, 부족한 정보를 추가 입력하도록 PM에게 안내함
실제 — 시스템이 모호한 답변을 생성하거나 '정보 없음'으로 처리하고 프로세스가 멈춤 - 왜 중요
- PM의 의사결정 속도를 높이려는 가치가 오히려 수동적인 정보 검색 업무로 전락함
보통[31] 기록 도구와 의사결정 도구 사이의 경험적 괴리C2axis 9
- 관점 축
- 9 · 인지
- 핵심
- 기록 자체가 곧 의사결정이 되지는 않음
- 근거
- 사용자는 의사결정을 빨리 내리고 싶어서 가입했는데, 시스템은 회의록 기록과 정보 입력만 요구하고 있음. 30초 내에 사용자가 '내가 결정을 내릴 수 있는 환경'이라고 느끼게 할 장치가 부족함.
- 제안
- 기록 중심의 대시보드 대신, 첫 진입 시 '현재 고민 중인 문제'를 바로 선택하고 답변을 생성하는 의사결정 중심 뷰로 재구성
- 시나리오
- 초기 가입 유저기대 — 가입 후 바로 문제 선택 및 의사결정 도출
실제 — 회의록을 작성하고 질문지를 입력해야 함 - 왜 중요
- 가장 먼저 이탈하는 지점이며, 정체성 오해를 불러일으킴
보통[32] 문서 가이드라인 작성의 높은 진입 장벽C2axis 11
- 관점 축
- 11 · 가치 전달
- 핵심
- 사용자에게 전문가 수준의 설계를 요구함
- 근거
- 현재 설계는 사용자가 직접 Guideline을 입력하고 관리해야 함. '어떻게 할지 모르는' 문제를 해결하러 온 고객에게, 문제를 해결하기 위한 틀(Guideline)까지 짜라고 요구하는 것은 솔루션 제공자의 가치 전달 방식이 아님.
- 제안
- 사용자가 Guideline을 직접 작성하는 대신, 업계 표준 템플릿(예: PRD, 요구사항 명세서)을 선택하면 AI가 이를 최적화해주는 '가이드라인 추천 엔진' 도입
- 시나리오
- B2C PM 초보 유저기대 — 템플릿 선택 및 가이드 생성
실제 — 빈 화면에 직접 Guideline 작성 - 왜 중요
- 직접 입력의 부담은 첫 가입 유저의 핵심 이탈 원인임
보통[33] 대화록 기반 Q&A 생성의 의사결정 맥락 휘발C3axis 32
- 관점 축
- 32 · 결정 근거 완결성
- 핵심
- 정보 요약은 의사결정 도출이 아님
- 근거
- 회의록을 기반으로 Discovery 답변을 자동으로 채우는 것은 '정보의 요약'이지, 결정을 내리기 위한 '의사결정 도출'이 아님. 사용자는 요약된 텍스트만 보고 결정을 내릴 수 있는 확신을 얻지 못함.
- 제안
- 답변 채우기 기능 수행 시, 단순히 내용을 요약하지 말고 '이 답변이 내린 결정의 근거가 무엇인지'를 사용자가 검토할 수 있도록 원문 근거 링크 제공
- 시나리오
- 의사결정권자기대 — 요약 내용을 보고 바로 결정
실제 — 회의 원본 내용과 대조 확인 후 결정 - 왜 중요
- 요약에 대한 불신은 시스템 전체의 신뢰도로 직결됨
보통[34] Person 객체 역할 정의의 중첩 및 혼재C4axis 39
- 관점 축
- 39 · Value Chain 경쟁 정합
- 핵심
- Person 객체의 역할 범위를 명확히 분리해야 함
- 근거
- 현재 Person은 User, 참여자, 고객사 담당자 등으로 중복 정의되어 있습니다. 요구사항 도출 단계와 CRM 관리 단계에서 해당 객체의 역할이 충돌할 경우 향후 권한 관리나 데이터 정합성 이슈가 발생해요.
- 제안
- Person 객체를 시스템 내 역할에 따라 (내부 사용자/외부 담당자)로 명확히 서브 타입화하거나 구분 필드를 추가하세요.
- 시나리오
- B2B 서비스 기획자기대 — 프로젝트 참여자 명단에서 대상 확인 후 인터뷰 요청
실제 — Project 참여자 리스트와 고객사 담당자(CRM) 리스트가 혼재되어 검색 시 혼란 발생 - 왜 중요
- 도구 사용 시 도메인 객체 간의 관계가 모호하면 의사결정 맥락을 추적하기 어려워요.
보통[35] Document Guideline 관리 기능의 가치 제안 파편화C2axis 11
- 관점 축
- 11 · 가치 전달
- 핵심
- 의사결정 도구에 필요한 최소한의 가이드라인 제공 필요
- 근거
- 문서 생성 Guideline을 직접 관리하도록 하는 기능은 범용 문서 도구의 성격이 강합니다. 의사결정 지원 도구라는 핵심 정체성과 맞지 않게 기능이 파편화되어 사용자의 인지적 부하를 높이고 있습니다.
- 제안
- 사용자 직접 관리보다는 의사결정을 위한 템플릿/가이드라인을 사전 제공하고, 이들이 어떻게 의사결정에 기여하는지 강조하는 방식으로 기능을 좁히세요.
- 시나리오
- B2B 서비스 기획자기대 — 자동으로 의사결정 요약이 포함된 문서 생성
실제 — 사용자가 직접 Guideline을 입력/선택하는 단계에서 문서 도구 사용 피로감 발생 - 왜 중요
- 사용자는 도구 설정이 아니라 결과물을 원해요.
보통[36] 의사결정 '합의(Commitment)' 지점의 부재C3axis 11
- 관점 축
- 11 · 가치 전달
- 핵심
- 기록 요약을 넘어선 확정 합의 주체 정의
- 근거
- 제품은 의사결정 지원 도구를 표방하지만, 현재의 기능은 질문(Questions)과 답변(Answers) 기록에 멈춰 있습니다. 사용자가 도출한 결론을 확정하거나, 팀 내 합의를 표시하는 '의사결정 객체'가 없으므로 도구의 본질적 가치 전달이 이루어지지 않습니다.
- 제안
- Discovery 세션의 결과를 바탕으로 '최종 의사결정 제안(Decision Proposal)'을 작성하고 팀원이 승인하는 '합의(Commitment)' 기능을 설계에 추가하세요.
- 시나리오
- SI 외주사 대표 윤성현기대 — Discov에서 '2026-05-21 14:00 고객사 담당자 이민정 승인 완료' 뱃지가 박힌 암호화된 Rationale PDF 증적을 바로 출력하여 증명함
실제 — Q&A 게시판 형태의 단순 질문 답변 글 타임라인만 있어 고객사가 언제 동의했는지 구조적 증명 주체가 없어 발뺌을 허용함 - 왜 중요
- B2B 합의 도구로서 실질적 최종 가치를 전달하는 유일한 신뢰 요소(Reassurance)이기 때문이에요.
보통[37] 의사결정 승인 권한 계층의 부재C6axis 18
- 관점 축
- 18 · 운영
- 핵심
- 개별 Discovery와 팀 의사결정 간 권한 계층 부재
- 근거
- 모든 리소스를 팀 기반으로 귀속시키지만, 팀 내부에서 누가 의사결정을 최종 승인하는지에 대한 워크플로우가 없습니다. 합의가 중요한 의사결정 도구에서 승인권자(Approver)와 승인 상태(Approval Status)가 없는 것은 운영 상의 불완전함을 초래합니다.
- 제안
- 팀 내 승인 권한(Role)을 설정하고, 최종 의사결정 도출 시 승인권자의 확인을 거치도록 워크플로우를 설계하세요.
- 시나리오
- PM 김대리기대 — 팀 리더가 시스템상에서 승인(Approval)을 클릭하여 최종 확정 상태로 변경함
실제 — 김대리가 결정을 공유하고 팀 리더가 구두로 'OK'를 하지만, 시스템상으로는 누가 확정했는지 기록되지 않음 - 왜 중요
- 책임 소재 없는 의사결정은 나중에 왜곡될 가능성이 큽니다.
보통[38] 선형적 폼 입력 구조와 비선형적 대화 의사결정의 괴리C3axis 9
- 관점 축
- 9 · 인지
- 핵심
- 선형적인 폼 입력이 실제 의사결정 맥락을 파괴
- 근거
- 사용자가 디스커버리 폼을 순차적으로(Step 1, Step 2...) 채워야 다음 정보를 생성할 수 있는 구조는 실제 의사결정 대화의 비선형성을 지원하지 못합니다. 고객과의 대화 중에 중요한 결정이 내려졌음에도 폼을 끝까지 채우기 전까지는 완료 처리를 할 수 없는 것은 심각한 인지적 비효율을 발생시킵니다.
- 제안
- 선형적 단계 입력뿐만 아니라, 대화 기록에서 즉시 결정 사항을 추출하고 합의 지점을 만들 수 있는 비선형적 인터페이스를 검토하세요.
- 시나리오
- PM 김대리기대 — 즉시 해당 합의 지점을 '최종 결론'으로 기록하고 완료 처리함
실제 — 폼의 나머지 Step들을 다 채워야만 시스템적으로 진행 가능하여, 일단 대충 입력하거나 중단함 - 왜 중요
- 실제 의사결정은 정해진 Step대로 흐르지 않기 때문입니다.
높음[39] 의사결정 가치와 문서화 기능의 인지적 단절C2axis 39
- 관점 축
- 39 · Value Chain 경쟁 정합
- 핵심
- 의사결정 도구와 문서 작성 도구 간 가치 연결 부재
- 근거
- 사용자는 '의사결정'을 위해 도구를 찾지만 시스템은 '문서 작성 완료'를 목표로 설계되어, 사용자가 왜 이 도구를 써야 하는지(의사결정의 이점)를 경험하지 못함.
- 제안
- 문서 생성 기능을 '결과물'이 아닌 '의사결정 요약' 관점으로 재정의하고, Discovery 단계별 의사결정 요약본을 대시보드로 상시 노출하도록 설계 수정.
- 시나리오
- 프로젝트 PM기대 — 생성된 문서를 보고 의사결정이 명확해져 팀 공유
실제 — 문서는 생성했으나, 이 문서가 의사결정을 앞당겼다는 체감보다는 단순 문서 작업의 효율화로 느껴짐 - 왜 중요
- 도구의 핵심 목적을 사용자가 망각하게 되어 이탈로 이어짐
보통[40] 페르소나 객체 설계의 의사결정 활용도 저하C3axis 23
- 관점 축
- 23 · 학습 + 유저 모델
- 핵심
- 엔티티 연결 위주 설계로 실질적인 페르소나 의사결정 지원 부재
- 근거
- Person 객체가 단순 참여자로 연결만 됨. 의사결정 시 '누가 반대하는가', '누가 승인해야 하는가'를 페르소나 관점에서 추적/역산할 수 있는 기능이 설계에 부재함.
- 제안
- Person 객체에 '의사결정 권한' 및 '제약사항(Constraint)' 속성을 추가하여, 요구사항 정합성 판단 시 페르소나 기반 역산이 가능하도록 정보 모델 확장.
- 시나리오
- 프로젝트 리더기대 — 참여자의 제약사항을 근거로 의사결정을 내림
실제 — 단순 연락처 관리와 역할 구분만 되어 있어 실질적인 의사결정 영향력 확인이 불가함 - 왜 중요
- 요구사항 정합성을 보장하는 핵심 지능이 결여됨
보통[41] 의사결정 이력의 재사용 및 지식 자산화 경로 부재C3axis 32
- 관점 축
- 32 · 결정 근거 완결성
- 핵심
- 의사결정 과정의 구조화는 있으나 지식 재사용 전략 부재
- 근거
- Discovery를 반복 관리하고 근거를 제공한다고 했으나, 과거의 의사결정 패턴(실패/성공)을 현재 요구사항에 어떻게 재사용/연계할지에 대한 구체적 설계가 없음.
- 제안
- 의사결정 레코드에 '결정 패턴' 태그 시스템을 도입하고, 유사 프로젝트 생성 시 이전 프로젝트의 결정 근거를 가이드라인으로 자동 제안하는 피드백 루프 설계.
- 시나리오
- 신입 PM기대 — 과거 프로젝트의 의사결정 패턴을 참조하여 가이드라인 수립
실제 — 과거 Discovery 내용을 일일이 조회해야 함 - 왜 중요
- 지식 자산화가 되지 않아 가치사슬 내 경쟁력을 잃음
§8.75의존성 지도
- 막는 것 · 먼저
- 정체성을 '요구사항 모호성 합의'로 좁히기 (C1·C2)막는 것 — C3 입력 흐름 · C4 합의 모델 · C6 지표·과금가치사슬 경쟁 정합 고정 (C2)막는 것 — C3 진입 장벽 · C6 BM 정합
- 근본 원인
- 추상적 정체성 정의 (C1)파생 — 26건 foundation 대부분이 여기서 파생
- 함께 성립
- C4 합의 객체 ↔ C5 데이터 동기화합의 상태 Lock은 Scope 동기화 무결성과 함께여야 성립
- 수정 효율
- 정체성 좁히기(C1) 하나를 닫으면 foundation 26건 중 다수가 연쇄 해소 — 개별 대응보다 뿌리 우선이 압도적으로 효율적이에요.
§9다음 행동
최상위 — 서비스 설계 정체성
정체성을 '요구사항 모호성 합의'로 좁히기
- 첫 행동
- 도메인 owner와 1~2시간, 고객 앞 첫 마디 한 문장 도출
- 왜 지금
- 이 한 문장이 페르소나·가치·GTM을 재정렬하는 뿌리
기반 — 경쟁 정합
가치사슬·경쟁·승리 조건 한 장 정리 (C2)
- 첫 행동
- 노션·지라 대비 Discov만의 진입 쐐기 정의
- 왜 지금
- 차별화 논리 없이는 첫 진입 전환이 안 됨
Wow Surface 진입 훅 설계 (C11·C26)
- 첫 행동
- '파일 업로드→첫 질문 자동 생성' 30초 경험 프로토타입
- 왜 지금
- 리텐션은 첫 가치 체감에서 갈림
후속 — 지표·데이터·기술
선행 지표 + Usage 과금 단위 정의 (C6)
- 첫 행동
- '모호성 감소 지수' 로그 이벤트 설계
- 왜 지금
- 유료 전환 근거 확보
- 전문가 판단 지점
- 정체성 한 문장 도출은 도메인 owner의 현장 언어가 실마리예요 — 전문가 세션에서 함께 뽑는 게 가장 빨라요.
§10개발 착수 준비 게이트
2/5 통과
- ✗고심각도 0건
- ✗제품 정체성 clear
- ✗경쟁 정합·승리 조건 정의
- ✓핵심 기술 아키텍처 검증 가능
- ✓데이터 스키마 제약 정리
아직 통과 못한 것
정체성이 too-broad — 좁히기 전 하류 설계가 계속 흔들려요
경쟁 차별화(Wedge) 미정의 — 진입 전환의 전제
§11핸드오프 메시지
받는 사람에 맞는 버전을 골라 그대로 복사해서 보내요.
팀원에게
우리 제품 정체성을 '의사결정 도구 일반'에서 '요구사항 모호성 합의 파이프라인'으로 좁히기로 했어요. 다음 스프린트 1순위는 (1) 노션·지라 대비 진입 쐐기 한 장 정리 (2) '파일 업로드→첫 질문' 30초 Wow 프로토타입입니다. 사전 관리 정보 입력은 뒤로 미뤄요.
AI 에이전트에게
이 프로젝트의 최상위 결정: 정체성 = '요구사항 모호성 합의 파이프라인'. 구현 시 (a) 온보딩 첫 화면은 무거운 Customer/Org 생성이 아니라 파일 업로드→질문 자동생성 (b) 노션/지라 데이터를 흡수하는 쐐기 관점 (c) 지표는 활동량이 아니라 '모호성 감소'. 취소선·DISCUSS 항목은 결정 로그로 먼저 닫아주세요.
직접 수정할 때
먼저 도메인 owner와 1~2시간 대화해 '고객 앞 첫 마디' 한 문장을 뽑으세요. 그 문장으로 페르소나·가치 제안·GTM을 재정렬한 뒤, 30초 Wow 진입을 프로토타입하고 다시 점검하면 foundation 26건이 얼마나 줄었는지 확인할 수 있어요.