피봇팅과 중간심의 준비
피봇팅은 실패가 아니라, 설명해야 하는 변경임.
- 본과정에서 방향을 바꾸는 일은 자연스러움.
- 문제는 피봇 자체가 아니라, 왜 바꿨는지 팀이 설명하지 못하는 것임.
피봇을 검토하는 기준
| 기준 | 질문 |
|---|---|
| 문제 | 우리가 풀려는 문제가 더 선명해졌는가? |
| 사용자 | 새 방향에서 사용자가 더 구체적으로 보이는가? |
| 실행 | 남은 기간 안에 만들고 보여줄 수 있는가? |
| 설명 | 기획심의 피드백과 연결해서 말할 수 있는가? |
피봇은 “이게 더 좋아 보여서”가 아니라 “이전 방향의 어떤 한계를 확인했고, 그래서 어떤 기준으로 바꾸었는지”로 설명되어야 함.
중간심의 준비 순서
중간심의는 “우리가 열심히 했음”을 보여주는 자리가 아님.
-
처음 피드백 이후 무엇을 배웠는지 보여줘야 함.
-
무엇을 줄였고, 무엇을 구현했고, 다음 단계에서 무엇을 검증할지 보여줘야 함.
-
피드백에 대한 검증: 기획심의에서 받은 피드백이 실제로 어떤 리스크였는지 확인함.
-
변경 내용 정리: 실제로 바꾼 기획, 기능, 데이터, 타깃을 적음.
-
구현 결과 제시: 현재까지 구현한 화면과 API를 보여줌.
-
남은 리스크 공개: 아직 검증하지 못한 리스크를 솔직하게 적음.
-
전달: 남은 검증 범위와 일정, 다음 발표에서 보여줄 내용을 명확히 말함.