제품

만들 것을 정하는 일에는 오랫동안 이름이 없었습니다. 회사에는 파는 사람과 만드는 사람이 있었고, 무엇을 만들지는 대개 파는 쪽이 들고 온 요구를 만드는 쪽이 받아 적는 식으로 정해졌습니다. 소프트웨어를 한 번 팔고 끝내던 시절에는 그래도 됐습니다. 계약서에 적힌 것을 기한까지 납품하면 그 거래는 끝났으니까요.

매달 돈을 받는 구독 서비스로 바뀌면서 이 방식이 버티지 못했습니다. 고객은 언제든 해지할 수 있고, 그래서 한 번 판 뒤에도 계속 쓸 만한 물건이어야 했습니다. 요구를 받아 적는 것만으로는 그 상태에 닿지 못합니다.

당시 회의는 늘 같은 모양이었습니다. 영업이 "이 고객이 엑셀 내보내기를 원합니다" 라고 적어 오면 개발팀이 들어온 순서대로 만들었고, 반년 뒤에 그 기능을 쓰는 고객은 세 곳뿐이었습니다. 요청한 사람도 만든 사람도 자기 일을 제대로 했는데 결과만 틀려 있었습니다. 요청을 모아 무엇을 먼저 만들고 무엇을 만들지 않을지 판단하는 자리가 아무에게도 없었기 때문입니다.

제품이라는 이름은 그 빈자리에 붙었습니다. 만들 것을 정하는 일을 따로 떼어, 책임질 사람과 판단의 근거와 남길 문서를 붙인 영역입니다. 그래서 이 축의 용어 대부분은 만드는 기술이 아니라 정하는 과정에 관한 말입니다.

제품 축에는 용어 52개가 있고 열한 갈래로 나뉩니다. 갈래를 가르는 기준은 결정이 흘러가는 순서입니다. 누가 정하는지(역할), 어디로 갈지(전략), 그게 맞는지 확인하고(발견), 정한 것을 적고(정의·문서), 순서를 매기고(우선순위), 작게 만들어 보고(제품 형태), 내보내고(출시), 재고(지표), 돈을 받고(수익화), 그 제품이 얹힌 틀(제품 구조)과 시간에 따른 위치(생애주기)를 봅니다.

역할은 이 일을 누가 맡는지를 가르는 갈래입니다. 가운데에 프로덕트 매니저가 있고, 스크럼이라는 개발 방식을 쓰는 팀에서는 만들 후보 목록의 순서를 최종적으로 정하는 프로덕트 오너가 그 자리를 맡습니다. 나머지는 담당 영역으로 갈린 변형입니다. API 처럼 개발자가 쓰는 기술 제품을 맡으면 테크니컬 프로덕트 매니저, 가입과 재방문 같은 숫자를 맡으면 그로스 프로덕트 매니저, 사내 다른 팀이 쓰는 도구를 맡으면 플랫폼 프로덕트 매니저입니다. 숫자를 파서 판단 근거를 만드는 프로덕트 애널리스트와 출시 메시지를 만드는 프로덕트 마케팅 매니저가 옆에 붙고, 제품 조직 전체를 책임지는 경영진 자리가 최고 제품 책임자입니다.

전략은 어디로 갈지를 정하는 갈래입니다. 먼 목표를 한 문장으로 세운 것이 제품 비전이고, 거기 닿으려고 무엇을 하고 무엇을 안 할지 고른 것이 제품 전략입니다. 전략은 대상이 있어야 서기 때문에 공략할 고객 집단을 좁히는 타깃 시장, 그 시장의 경쟁 제품을 기능과 가격으로 늘어놓고 빈틈을 찾는 경쟁 분석이 함께 붙습니다. 이 판단이 맞아떨어져 만든 것이 시장의 수요와 맞물린 상태를 제품 시장 적합성이라 부르고, 전략을 시간 축 위에 올려 언제쯤 무엇을 낼지 보여 주는 계획표가 제품 로드맵입니다.

발견은 만들기 전에 만들 값어치가 있는지 확인하는 갈래입니다. 이 확인 활동 전체를 제품 디스커버리라고 부릅니다. 기본 수단은 사용자를 만나 묻고 쓰는 모습을 지켜보는 사용자 리서치이고, 거기서 얻은 것을 정리하는 도구가 셋 있습니다. 고객이 제품을 고용해 끝내려는 일이 무엇인지로 수요를 보는 할 일 이론, 흩어진 사용자 집단을 한 사람처럼 구체화한 페르소나, 알게 되고 쓰고 떠나기까지의 흐름을 한 줄로 그린 고객 여정 지도입니다. 이미 들어와 쌓인 불만과 요청을 모아 쓰는 쪽은 고객의 소리입니다.

정의·문서는 정한 것을 남에게 넘길 수 있는 형태로 적는 갈래입니다. 가장 큰 그릇이 PRD로, 무엇을 왜 만들고 어디까지 되면 끝인지를 적습니다. 그 안에서 요구를 사용자 관점 한 문장으로 쪼갠 단위가 유저 스토리이고, 아직 손대지 않은 후보를 순서대로 쌓아 둔 목록이 제품 백로그입니다. 화면과 동작을 구현할 수 있을 만큼 내려 적으면 명세 문서, 어떤 상황에서 제품이 어떻게 굴어야 하는지를 못 박으면 제품 정책입니다. 배경과 제안을 한 장으로 줄인 원페이저와 왜 그렇게 정했는지 남기는 의사결정 기록은 안쪽에서 돌고, 이번에 바뀐 내용을 사용자에게 알리는 릴리스 노트와 그 이력을 시간순으로 쌓은 체인지로그는 바깥으로 나갑니다.

우선순위는 만들 것이 만들 시간보다 항상 많다는 조건에서 순서를 정하는 갈래입니다. 용어는 우선순위 결정 하나뿐이지만 실무에서 가장 자주 부딪히는 자리입니다. 백로그에 마흔 건이 쌓여 있고 이번 분기에 여섯 건을 만들 수 있다면, 고른 여섯 건보다 미룬 서른네 건을 설명하는 데 시간이 더 들기 때문입니다.

제품 형태는 완성품을 내기 전에 작게 만들어 보는 갈래입니다. 넷이 크기와 목적으로 갈립니다. MVP는 가설 하나를 확인할 수 있는 최소한의 제품이라 실제 사용자에게 내보내 반응을 받습니다. 프로토타입은 반응만 보려고 임시로 꾸민 것이라 버튼을 눌러도 안에서 아무 일이 일어나지 않아도 됩니다. 개념 증명은 기술적으로 가능한지만 작게 확인하는 시도이고, 파일럿은 다 만든 것을 고객 몇 곳에만 먼저 열어 운영해 보는 시험 도입입니다.

출시는 만든 것을 사용자 앞에 내놓는 갈래입니다. 한 번 내보내는 행위가 릴리스이고, 전체에 한꺼번에 열지 않고 1퍼센트에서 시작해 이상이 없으면 범위를 넓히는 방식이 점진적 출시입니다. 언제 누구에게 어떤 경로로 알리고 팔지까지 묶은 계획은 고 투 마켓이라 부릅니다. 반대쪽 끝에는 더 쓰이지 않는 기능이나 제품의 제공을 끝내는 제품 일몰이 있습니다.

지표는 내보낸 것이 잘 돌아가는지 숫자로 재는 갈래입니다. 전체를 부르는 말이 제품 지표이고, 그 아래에서 얼마나 많이 쓰는지를 보는 묶음이 사용량 지표입니다. 시간 순서로 보면 가입한 사람이 제품의 쓸모를 처음 체감하는 지점이 활성화이고, 그 뒤로 계속 돌아오는 정도가 리텐션입니다. 100명이 가입해 30명이 넉 달 뒤에도 남아 있으면 리텐션이 30퍼센트입니다. 숫자로 잡히지 않는 느낌은 설문으로 직접 묻는 만족도 지표가 맡습니다.

수익화는 제품에서 돈이 나오게 하는 갈래입니다. 값을 얼마로 매길지 정하는 일이 가격 책정이고, 사람 수대로 받을지 쓴 만큼 받을지처럼 돈을 받는 구조 자체가 과금 모델입니다. 무료로 쓰다가 결제해야 넘어갈 수 있게 막아 둔 지점이 페이월이고, 이미 들어온 고객이 자리를 늘리거나 상위 플랜으로 옮기면서 늘어나는 매출이 확장 매출입니다.

제품 구조는 이 제품이 어떤 틀에 얹혀 있는지를 보는 갈래입니다. 설치 없이 웹으로 접속해 매달 구독료를 내고 쓰는 형태가 SaaS이고, 개인에게 파는지 기업에 파는지로 나눈 구분이 사업 유형입니다. 웹인지 모바일 앱인지 API 인지처럼 사용자에게 닿는 껍데기를 가리키는 말은 제품 형태인데, 앞의 제품 형태 갈래가 완성 전에 만들어 보는 시험용 물건을 뜻하는 것과는 다른 말입니다.

생애주기는 이 제품이 시간 축 위 어디쯤에 있는지를 보는 갈래입니다. 시장에 나와 자리를 잡고 저물기까지를 도입·성장·성숙·쇠퇴로 끊어 보는 것이 제품 수명주기입니다. 그 초반에는 새것을 먼저 써 보는 소수 사용자와 검증된 것만 사는 주류 시장 사이에서 수요가 뚝 끊기는 구간이 나오는데, 이 골을 캐즘이라 부릅니다.

"그건 제품에서 정할 문제 같아요. 지현한테 넘길게요."

만들지 말지와 언제 만들지를 판단할 책임이 특정 역할에 있다는 뜻입니다. 여기서 제품은 만들어진 물건이 아니라 그 결정을 맡은 사람들을 가리킵니다.

"이번 분기 제품 목표는 활성화예요. 매출은 그다음입니다."

여러 숫자 중 하나를 골라 이번 분기의 기준으로 삼았다는 선언입니다. 순서를 미리 밝혀 두면 나중에 무엇을 뺄지 다투는 시간이 줄어듭니다.

"요구사항 문서가 아직 안 나와서 디자인은 다음 주부터 붙습니다."

정하는 일이 끝나야 만드는 일이 시작된다는 뜻입니다. 앞 단계가 밀리면 뒤 단계가 통째로 밀린다는 말이기도 합니다.

페이지덱에서 이 말이 가장 많이 오가는 자리는 분기 계획 회의입니다. 대표인 규원이 이번 분기에 무료 사용자의 유료 전환을 올리자고 방향을 걸면, 지현이 그 방향을 실제로 만들 것들로 바꿔 옵니다. 고객 인터뷰에서 나온 이야기와 이탈 지점의 숫자를 함께 놓고, 후보 열댓 개 중 넷을 골라 나머지를 왜 미루는지까지 적어 옵니다.

그다음은 각자의 일로 갈립니다. 민서가 화면을 그리고 태오가 구현 범위를 따져 일정을 붙입니다. 세일즈인 수아는 기업 고객에게 언제 말해도 되는지 시점을 확인하고, 현우는 출시 시점에 맞춰 어떤 사용자에게 먼저 알릴지 준비합니다. 회의에서 제품이라는 말은 이 전체 흐름의 출발점을 가리킬 때 쓰입니다.

제품을 기능 만드는 일과 같은 말로 읽는 경우가 가장 많습니다. 밖에서 보이는 산출물이 화면과 기능뿐이니 자연스러운 오해입니다. 하지만 이 영역의 산출물에는 만들지 않기로 한 결정도 똑같이 포함됩니다. 요청 마흔 건 중 여섯 건을 고르는 일에서 실제로 무게가 실리는 쪽은 미룬 서른네 건입니다. 이걸 놓치면 제품 조직은 요청을 받아 적는 창구가 되고, 로드맵은 계획이 아니라 밀린 요청 목록이 됩니다.

제품 결정이 감각이나 아이디어 싸움이라고 보는 것도 흔합니다. 유명한 제품의 이야기가 대개 창업자의 직관담으로 전해져서 그렇게 보입니다. 실제로는 근거를 만드는 절차가 따로 있습니다. 만들기 전에 사용자에게 확인하고, 낸 다음에는 활성화나 리텐션 같은 숫자로 맞았는지 되봅니다. 이 절차 없이 가면 회의에서 목소리가 큰 사람의 의견이 이기고, 반년 뒤 결과가 나빠도 무엇이 틀렸는지 짚지 못해 같은 판단을 다시 하게 됩니다.