SERVICE PLANNING
웹서비스 기획은 기능 목록이 아니라 실행 루프부터 시작한다
새 서비스를 시작할 때 가장 먼저 만들어야 하는 것은 거대한 기획서가 아니다. 반복해서 나타나는 문제를 발견하고, 누군가의 실제 행동으로 확인하며, 다음 개선으로 이어지는 작은 루프다.
좋은 아이디어는 대개 한 번의 번뜩임보다 반복되는 장면에서 나온다. 고객이 같은 질문을 하고, 팀이 같은 정보를 옮기고, 커뮤니티에서 같은 어려움을 공유한다면 그곳에 서비스의 출발점이 있다. 이때 필요한 것은 “무엇을 만들까”라는 기능 목록보다, 누구의 어떤 반복을 더 낫게 만들 수 있는가를 확인하는 일이다.
작은 서비스가 자라는 네 단계
문제는 기능 요청보다 장면으로 기록한다
“예약 기능이 필요하다”보다 “고객이 전화와 메시지로 희망 시간을 보내고, 운영자는 빈 시간을 다시 확인하느라 예약을 놓친다”가 더 좋은 출발점이다. 장면에는 사용자, 계기, 현재 방식, 손실, 원하는 결과가 들어 있다. 이 다섯 가지가 정리되면 첫 웹앱의 화면과 데이터도 자연스럽게 좁혀진다.
- 누가 이 문제를 반복해서 겪는가.
- 문제가 생기는 순간은 언제인가.
- 지금은 어떤 우회 방식으로 해결하는가.
- 시간, 돈, 신뢰 중 무엇이 가장 많이 새는가.
- 첫 버전이 바꿔야 할 행동은 하나로 무엇인가.
콘텐츠와 대화는 홍보 이전에 수요 탐색 장치다
문제를 설명하는 글, 커뮤니티의 질문, 워크숍 사전 설문은 마케팅 재료이기도 하지만 더 먼저는 제품 연구 자료다. 어떤 문장에서 반응이 오는지, 어떤 업종이 같은 표현을 쓰는지, 무엇을 묻는지 기록하면 제품을 추측으로 만들지 않게 된다. 콘텐츠는 트래픽을 모으는 채널이면서, 다음 기능의 우선순위를 알려주는 인터뷰 기록이기도 하다.
첫 웹앱은 완성품이 아니라 운영 가능한 질문
첫 버전에는 모든 기능이 필요하지 않다. 예약 서비스라면 신청과 상태 확인, 견적 서비스라면 옵션 선택과 문의 접수, 콘텐츠 서비스라면 상품 탐색과 구매 의사 확인처럼 하나의 핵심 흐름을 운영할 수 있으면 된다. 로그인, 데이터 저장, 테스트 결제, 운영 화면은 이 흐름을 실제로 관찰하기 위한 기반이다.
사례가 쌓이면 템플릿이 아니라 판단력이 쌓인다
비슷한 문제를 여러 번 해결하면 재사용할 수 있는 화면과 흐름이 생긴다. 그러나 더 중요한 자산은 어떤 요구를 먼저 구현하고, 어떤 위험은 뒤로 미루며, 어떤 데이터가 다음 결정을 가능하게 하는지에 대한 판단이다. 사례는 복제할 대상이 아니라 다음 고객의 맥락을 더 빨리 이해하기 위한 기준점이다.