파일 목록으로

Palantir for Individuals - Implementation Handoff

날짜: 2026-03-14
상태: Draft
문서 목적: discovery 문서를 실제 제품 개발로 넘기기 위한 구현 순서, milestone, dependency를 고정한다.

1. 이 문서의 역할

현재 브랜치에는 PRD, 시장, 가격, wedge, trust, ontology, schema, user flow가 있다. 다음 단계에서 필요한 것은 더 많은 아이디어가 아니라 실행 순서다.

이 문서는 세 가지를 명확히 한다.

  • 무엇을 먼저 만들 것인가
  • 무엇은 아직 만들지 않을 것인가
  • 어떤 기준을 만족하면 다음 단계로 넘어갈 것인가

2. 구현의 기본 원칙

2.1 Chat product가 아니라 workflow product로 구현한다

핵심은 예쁜 대화 UI가 아니라 질문 -> state assembly -> option comparison -> memo라는 워크플로다.

2.2 Generic assistant를 만들지 않는다

초기 제품은 founder/operator용 decision memo + weekly reality check에 고정한다.

2.3 데이터 연결보다 첫 가치가 먼저다

연결 가능한 source 수를 늘리기 전에, Gmail + Calendar + Notes 만으로 강한 memo를 만드는 것이 먼저다.

2.4 Deterministic layer를 먼저 만든다

LLM은 해석과 표현에 쓰고, state estimation의 핵심 지표는 규칙 기반으로 계산한다.

3. V1 Product Slice

초기 구현 범위는 하나의 질문과 하나의 반복 루프를 안정적으로 푸는 데 집중한다.

포함

  • Gmail context ingestion
  • Calendar ingestion
  • Notes/document ingestion
  • personal operations graph 최소 구현
  • state estimator 최소 구현
  • one-shot decision workflow
  • decision memo output
  • weekly reality check

제외

  • full health integration
  • autonomous agent execution
  • broad CRM replacement
  • team collaboration
  • mobile-first experience
  • continuous passive recording

4. Product Architecture Handoff

4.1 Core layers

  1. Connectors
  2. Normalization
  3. Graph store
  4. State estimation
  5. Scenario engine
  6. Decision memo agent
  7. Review surfaces

4.2 Minimum data contract

첫 구현에서는 아래 entity만 있으면 된다.

  • person
  • goal
  • project
  • task
  • commitment
  • relationship
  • conversation
  • document
  • calendar_event
  • financial_event
  • decision
  • option
  • metric
  • evidence

4.3 Minimum computed metrics

  • free calendar hours this week
  • deep work blocks available
  • commitment load
  • open follow-up count
  • cash runway months
  • recent decision pressure indicators

5. Milestones

M0. Discovery Signoff

목표:

문서 세트 기준으로 팀이 같은 제품을 상상하고 있는지 정렬한다.

필수 산출물:

  • PRD
  • market landscape
  • business model
  • ICP and wedge
  • trust/privacy requirements
  • ontology and MVP schema

진입 조건:

  • 문서 간 메시지 충돌이 없어야 한다
  • 첫 wedge가 founder/operator로 합의돼야 한다

M1. Concierge Prototype

목표:

수동 또는 반수동으로 decision memo를 만들어도 사용자가 실제 가치를 느끼는지 검증한다.

필수 기능:

  • Gmail/Calendar/Notes ingest or manual import
  • baseline state summary
  • simple option comparison
  • memo export

성공 기준:

  • 초기 사용자 중 반복 memo 요청 비율
  • memo 후 실제 행동 변화 보고
  • interview에서 강한 pain confirmation

M2. Internal Alpha Product

목표:

memo 생성을 수동 워크플로에서 제품 워크플로로 바꾼다.

필수 기능:

  • source connection
  • normalization pipeline
  • graph persistence
  • decision creation UI
  • memo generation pipeline

성공 기준:

  • 내부 사용자 기준 memo 생성 안정성
  • source sync 실패율
  • factual error / evidence missing rate 추적

M3. Closed Alpha

목표:

10~20명의 외부 founder/operator에게 주기적으로 써보게 한다.

필수 기능:

  • onboarding flow
  • weekly review entry point
  • decision archive
  • minimal trust controls

성공 기준:

  • 2주차, 4주차 반복 사용
  • second memo generation rate
  • source expansion rate
  • interview quality signals

M4. Paid Beta

목표:

유료 전환과 PMF 신호를 함께 본다.

필수 기능:

  • billing
  • gating and packaging
  • usage instrumentation
  • PMF survey

성공 기준:

  • paid conversion
  • PMF score
  • retention
  • referral / share behavior

6. Recommended Build Order

Step 1. Data assembly

먼저 Gmail, Calendar, Notes를 가져오는 경량 ingestion을 만든다.

왜:

이 세 source만으로도 질문 대부분이 풀린다.

Step 2. State estimation

다음으로 현재 상태를 계산하는 deterministic layer를 만든다.

왜:

이게 없으면 memo가 단지 그럴듯한 텍스트가 된다.

Step 3. Decision workflow

question intake -> options -> scenario -> memo 흐름을 만든다.

왜:

이게 첫 제품 가치다.

Step 4. Weekly review loop

반복 사용을 만드는 low-frequency retention loop를 붙인다.

Step 5. Follow-up intelligence

relationship/context 기반 sticky loop를 붙인다.

7. Team Responsibilities

Product / Research

  • ICP interviews
  • JTBD validation
  • memo format validation
  • pricing and packaging tests

Engineering

  • ingestion connectors
  • graph and schema implementation
  • state estimator
  • memo orchestration pipeline

Design

  • trust surface
  • memo readability
  • onboarding and source permission UX

Ops / Legal

  • privacy policy boundaries
  • data retention assumptions
  • sensitive data posture

8. Technical Dependencies

Hard dependencies

  • Google APIs or import-based fallback
  • persistent graph or relational storage
  • evidence and provenance model
  • LLM provider with controllable prompting and citations

Recommended early simplifications

  • OAuth보다 import-first를 일부 허용
  • background sync보다 one-shot sync 우선
  • multi-platform surface보다 web 우선

9. What Not to Build Yet

다음은 매력적으로 보이지만, 초기에 넣으면 제품이 흐려질 가능성이 크다.

  • broad life dashboard
  • generic daily chat assistant
  • health diagnosis
  • autonomous actions across apps
  • team shared workspace
  • mobile app before memo quality

10. Instrumentation Requirements

초기 구현부터 반드시 이벤트를 박아야 한다.

  • source_connected
  • source_sync_completed
  • decision_created
  • option_added
  • memo_generated
  • memo_viewed
  • memo_shared
  • follow_up_created
  • weekly_review_completed

11. Exit Criteria for Discovery

이 브랜치를 implementation handoff 상태로 간주하려면 아래를 만족하면 된다.

  • 제품 서사가 일관적이다
  • 초기 wedge가 명확하다
  • build order가 정의돼 있다
  • PMF를 어떻게 측정할지 정해져 있다
  • trust boundary가 문서화돼 있다

12. 추천 결론

다음 구현 브랜치는 generic AI life assistant를 만들면 안 된다. founder/operator용 decision memo system을 만드는 것부터 시작해야 한다.

그 기준으로 보면, 가장 먼저 만들어야 할 것은 챗 UI가 아니라 ingestion + state estimation + memo workflow다.

0 / 207