MVP와 피드백 루프

MVP의 핵심은 많은 기능을 넣는 것이 아니라, 핵심 기능만으로 빠르게 써보고 고치는 구조를 만드는 것임.

• 완성도를 높이기 전에 먼저 피드백을 받을 수 있어야 함.
• 기능을 줄이는 이유는 적게 만들기 위해서가 아니라, 더 빨리 검증하기 위해서임.

최소 요건을 만족하기

• MVP를 만들 때는 가능한 잘게 쪼개야 함.
• 기능마다 우선순위를 만들고, 핵심 기능만 남겨야 함.
• 중간심의와 최종심의에서 중요한 것은 기능 개수가 아니라, 사용자가 어떤 문제를 겪고 있고 우리가 그 문제를 어떻게 줄였는지임.
• 소마 팀은 보통 만들고 싶은 것이 많음.
  • 검색, 추천, 랭킹, 커뮤니티, 대시보드, 관리자 기능, AI 기능까지 한 번에 넣고 싶어짐.
  • 하지만 남은 기간 안에 보여주고 검증할 수 없다면 MVP의 범위를 줄이는 편이 맞음.

Dog Fooding

• 우리가 만든 서비스를 우리가 직접 써보면서 개선하는 것이 제일 빠름.
• 직접 써보면 사용자가 겪을 불편함을 가장 먼저 발견할 수 있음.
• 기능이 멋있어 보이는지보다, 실제 사용 흐름에서 계속 쓰게 되는지가 더 중요함.

피드백 루프

• 첫 MVP는 별로일 수밖에 없음.
  • 다만 그 상태를 오래 붙잡고 있으면 배울 수 있는 것이 줄어듦.
  • 빠르게 사용자나 테스터에게 보여주고, 다음 개선점을 찾는 편이 더 중요함.
• 검증은 거창할 필요 없음.
  • 사용자 인터뷰
  • 프로토타입 테스트
  • 내부 사용 기록
  • 경쟁 서비스 비교
  • 테스터 피드백
• 중요한 것은 “우리가 좋다고 생각한다”에서 멈추지 않는 것임.
• MVP 범위가 작아지는 것은 후퇴가 아님.
  • 남은 기간 안에 실제로 보여주고, 써보고, 고칠 수 있는 단위로 바꾸는 일임.