개발이 팔할이 됐는데 소개 페이지의 첫 문장을 쓰지 못한다. 현장 관리자에게는 사진 보고 도구이고, 본사 승인자에게는 결재 도구이며, 대표에게는 현황판이라고 한다. 세 약속을 다 지키려니 설정과 권한은 복잡해지고 가장 중요한 첫 흐름은 느려진다. 마케팅을 제품 전에 시작한다는 것은 광고를 미리 만든다는 뜻이 아니다. 누구에게 무슨 변화를 약속할지 고르고, 그 약속에서 멀어지는 기능을 개발 전에 포기하는 일이다.
핵심 누구의 어떤 문제를 어떤 약속으로 풀 것인지 정하는 일은 홍보가 아니라 제품 범위를 결정하는 초기 설계입니다.
먼저 보면 좋은 점
- 가치제안을 개발 전 제품 가설로 다룹니다.
- 고객을 정하면 필요한 기능과 증거도 달라집니다.
- 출시 메시지를 초기 사용자 검증 도구로 활용합니다.
소개 문구가 범위의 모순을 보여준다
"누구나 쉽게 모든 업무를 관리하는 도구"는 넓어 보이지만 제품 판단에는 거의 도움이 되지 않습니다. 혼자 일하는 사람과 승인 절차가 많은 조직은 필요한 권한, 알림, 보고 방식이 다릅니다. 모두를 한꺼번에 만족시키려 하면 설정은 복잡해지고 첫 사용은 어려워집니다.
반대로 "현장 사진을 사무실 승인 담당자에게 당일 전달하는 도구"처럼 대상과 일이 구체적이면 첫 버전에 필요한 흐름이 보입니다. 촬영, 업로드 상태, 승인 알림이 중요해지고 복잡한 프로젝트 대시보드는 뒤로 미룰 수 있습니다.
약속에는 믿을 근거가 필요하다
제품이 시간을 절반으로 줄인다고 말하려면 어떤 과정이 사라지는지 보여줄 수 있어야 합니다. 자동화 기능이 있어도 사용자가 매번 결과를 고쳐야 한다면 약속은 오래가지 못합니다. 소개 문구는 희망사항이 아니라 제품이 실제로 지켜야 할 성능 기준에 가깝습니다.
기획 단계에서 가치제안과 증거를 함께 적으면 개발 항목도 달라집니다. 빠른 처리를 약속한다면 평균 처리 시간과 실패 시 복구가 중요하고, 안전한 보관을 약속한다면 권한·백업·삭제 정책이 핵심 요구사항이 됩니다.
출시 전부터 설명해 본다
작동하는 제품이 없어도 문제 장면과 해결 방식은 설명할 수 있습니다. 간단한 소개 페이지나 화면 모형을 보여주고, 대상 사용자가 자신의 문제로 알아보는지 확인합니다. 관심을 보였다는 말보다 현재 해결 방식, 바꾸기 어려운 이유, 실제로 시작하려면 필요한 조건을 묻는 편이 낫습니다.
이 과정에서 설명이 계속 길어진다면 문구를 다듬기 전에 제품 가설을 다시 봐야 합니다. 명확한 제품은 모든 기능을 말하지 않아도 누구를 어떤 상태로 데려가는지 설명할 수 있습니다.
가치제안이 요구사항으로 내려오는 과정
"현장 관리자가 사무실에 돌아오지 않고 점검을 끝낸다"는 약속을 정했다면 요구사항은 사진 업로드에 그치지 않습니다. 현장에서 입력할 정보의 양, 통신이 끊겼을 때 저장 방식, 관리자가 확인한 상태, 수정 요청을 다시 받는 경로가 함께 필요합니다. 약속을 이루는 끝단부터 거꾸로 요구사항을 찾습니다.
각 요구사항 옆에는 약속과의 연결 이유를 한 줄로 남깁니다. 연결이 약한 항목은 삭제 대상이라는 뜻이 아니라 기반 작업, 규정 대응, 미래 확장 중 어느 이유로 필요한지 따로 분류합니다. 이 구분이 없으면 모든 기능이 고객 가치라는 이름으로 같은 우선순위를 요구하게 됩니다.
제품과 출시 메시지를 함께 검토한다
출시 준비 회의에서는 소개 문구 담당자만 문장을 검토하지 않습니다. 개발자는 약속한 속도와 안정성이 실제 조건에서 가능한지, 디자이너는 첫 사용 흐름이 약속을 보여주는지, 운영자는 예외 상황을 감당할 수 있는지 확인합니다. 문구의 과장이 제품 위험을 드러내기도 합니다.
반대로 제품팀이 자신 있게 말할 수 없는 장점은 아직 고객에게 전달할 준비가 안 된 것입니다. 증거가 부족하면 표현을 낮추거나 출시 범위를 좁힙니다. 메시지와 제품을 같은 약속으로 관리하면 출시 뒤 "홍보가 잘못했다"거나 "제품이 덜 만들었다"는 책임 공방도 줄어듭니다.
시장 약속과 제공 구조를 함께 시험한다
고객 인터뷰와 소개 페이지는 수요만 확인하는 도구가 아닙니다. 약속한 결과를 만들려면 어떤 운영, 지원, 데이터와 파트너가 필요한지도 동시에 적어야 합니다. 관심은 높지만 매번 사람이 대신 처리해야 한다면 아직 제품의 반복 가능한 가치 구조를 찾은 것이 아닙니다.
초기 검증표에는 문제의 절실함, 첫 가치 행동, 반복 사용, 제공 비용을 함께 둡니다. 대상 고객이 행동으로 약속을 확인하지 않거나 제공 비용이 쓸수록 커진다면 홍보 확대를 멈추고 고객 또는 제공 방식을 다시 좁힙니다.
개발 전에 완성할 약속 검증표
현장 점검 웹을 예로 들면 대상은 “하루 세 곳 이상을 돌며 사진 보고서를 보내는 시설 관리자”, 약속은 “사무실에 돌아오지 않고 현장에서 점검을 끝낸다”입니다. 증거는 모형을 사용한 8명 중 6명이 도움 없이 전송을 마치고 기존 25분 작업이 10분 안으로 줄어드는 것입니다. 한 건당 사진 확인과 예외 처리에 드는 내부 시간도 재서 제공 비용을 3천 원 이하로 둡니다. 대상·약속·행동 증거·제공 비용이 한 행에서 이어져야 소개 문장이 제품 가설이 됩니다.
전송 성공률이 높아도 데이터 손실이 한 건이라도 생기거나, 절반 이상을 운영자가 대신 처리하거나, 건당 제공 비용이 고객이 낼 금액을 넘으면 홍보 확대를 중단합니다. 오늘 할 일은 진행 중인 제품 하나에 대상, 문제 장면, 약속한 결과, 믿을 증거, 건당 제공 비용, 중단선을 한 줄씩 작성하는 것입니다. 어느 칸이든 근거 없이 채워지면 개발 항목을 늘리기 전에 그 빈칸을 확인할 관찰이나 모형 시험을 먼저 잡습니다.
메모
- 개발 전에 대상 고객과 해결할 장면을 합의했는가?
- 제품의 약속을 증명하는 기능과 품질 기준은 무엇인가?
- 소개가 어려운 이유를 문구 문제가 아니라 범위 문제로 검토했는가?