10.14 제품 관리와 디스커버리

개요와 동기

제품 관리는 무엇을 만들지와 왜 만들지를 결정하고, 그것이 동작하는지에 책임지는 규율입니다. 제품 관리자는 문제, 고객, 성과를 소유합니다. 일정, 티켓 대기열, 이해관계자가 내려보낸 기능 체크리스트는 소유하지 않습니다. 그 구별이 이 장 전체를 한 문장으로 말합니다. 제품 관리가 프로젝트 조율이나 주문 받기로 무너지면 팀은 기능 공장이 됩니다. 끊임없이 출하하고, 속도 숫자를 맞추고, 어떤 비즈니스 지표도 움직이지 못합니다. 이 역할은 바로 그것을 막으려고 존재합니다.

큰 팀에서 약한 제품 관리는 조용히 가장 비싼 실패 모드입니다. 엔지니어링이 훌륭하고 전달이 빠르며 기계 전체가 돌아가는데도, 한 해 동안 엉뚱한 것을 아주 효율적으로 만드는 데 쓸 수 있습니다. 그 비용은 엔지니어링 대시보드에 나타나지 않습니다. 정체된 매출, 이탈한 고객, 아무도 쓰지 않지만 이제 모두가 유지해야 하는 기능의 백로그로 나타납니다. 좋은 제품 관리는 목표가 명시적이고, 측정 가능하고, 실제 고객 문제에 묶여 있도록 고집함으로써 돈을 약정하기 전에 그 위험을 보이게 합니다.

기업과 정부 환경은 판돈을 올리고 일의 모양을 바꿉니다. 기업은 점점 프로젝트 운영 모델(프로젝트에 자금을 대고, 출하하고, 팀을 해체)에서 제품 운영 모델(수년에 걸쳐 성과를 소유하는 지속되는 팀에 자금을 대는 것)로 옮기고, 내부 플랫폼을 실제 고객이 있는 제품으로 다룹니다. 정부는 사용자 중심 설계라는 기치 아래 같은 교훈을 배우고 있습니다. 프로젝트가 아니라 서비스에 자금을 대고, 시민이 실제로 섬겨지는지 측정하는 것입니다. 이 장은 그 전환을 현실로 만드는 마인드셋과 메커니즘에 관한 것입니다. 파이프라인 장치를 자세히 다루는 11.1장(디스커버리 파이프라인)과 긴밀히 짝을 이루며, 여기서는 역할, 전략, 디스커버리의 일상 습관에 집중합니다.

핵심 원칙

무엇과 왜를 소유하십시오. 제품 관리자는 과업 조율이 아니라 성과에 책임이 있습니다.
산출이 아니라 성과. 출하는 비용이지 결과가 아닙니다. 결과는 변화된 고객 또는 비즈니스 지표입니다.
누구보다 고객과 문제를 잘 아십시오. 고객 접촉 없는 전략은 짐작입니다.
디스커버리는 단계가 아니라 지속적입니다. 전달과 나란히 매주 고객과 이야기합니다.
우선순위 프레임워크는 판단의 보조이지 신탁이 아닙니다. 숫자는 판단에 정보를 주지만 판단을 대신하지 않습니다.
로드맵은 날짜가 있는 약속이 아니라 의도의 진술입니다. 문제에는 확고하게, 솔루션에는 느슨하게 약속하십시오.
트리오에게 권한을 주십시오. 제품, 디자인, 엔지니어링이 함께 결정합니다. 제품 관리자 혼자 하는 결정은 나쁩니다.

권장 사항

무엇과 왜를 소유하고, 어떻게는 팀이 소유하게 한다

제품 관리가 건강한지의 가장 분명한 시험은 어느 질문을 누가 소유하느냐입니다. 제품 관리자는 어떤 문제를 풀고 있는가와 왜 지금 중요한가를 소유합니다. 디자인은 사용자에게 어떻게 느껴져야 하는가를 소유합니다. 엔지니어링은 어떻게 만드는가를 소유합니다. 제품 관리자가 솔루션, 마감, 구현을 지시하기 시작하면 제품 직함을 단 프로젝트 관리자가 된 것이며, 권한이 부여된 팀을 효과적으로 만드는 바로 그 자율을 빼앗은 것입니다(5.1장은 디자인 파트너십을, 10.7장은 애자일 전달 모델을 다룹니다).

때로 제품 트리오라 불리는 권한이 부여된 제품 팀은 제품, 디자인, 엔지니어링이 함께 일하며, 만들 기능이 아니라 풀 문제를 받습니다. 이것이 “신규 사용자의 30일 유지율을 높여라”와 “3월까지 알림 센터를 만들어라”의 차이입니다. 앞의 것은 팀이 최선의 솔루션을 찾을 권한을 주고 결과로 책임을 묻습니다. 뒤의 것은 팀을 전달 부서로 축소하고 틀릴 위험을 요구 사항을 쓴 사람에게 조용히 넘깁니다. 성과에 대한 책임을 원한다면 산출물의 통제를 내줘야 합니다.

고객에 근거한 제품 비전과 전략을 세운다

제품 전략은 어떤 고객을 섬기고, 그들에게 어떤 문제를 풀고, 똑같이 중요하게 어떤 것을 거절할지에 대한 소수의 어려운 선택입니다. 비전은 만들려는 세상의 지속되는 그림으로, 보통 2년에서 5년 앞입니다. 전략은 거기에 이르게 하는 일련의 수입니다. 둘 다 없으면 우선순위는 가장 크게 논쟁하는 사람으로 퇴화하고, 로드맵은 모두가 아끼는 기능을 스테이플러로 붙인 목록이 됩니다.

전략은 고객과 문제에 대한 깊고 직접적인 지식 없이는 불가능합니다. 고객이 누구이고, 어떤 일을 해내려 하며, 지금 어디서 어려움을 겪는지 구체적으로 설명할 수 없는 제품 관리자는 무엇의 우선순위도 정할 준비가 되어 있지 않습니다. 이것은 한 번 의뢰하는 설문이 아닙니다. 상설 접촉의 습관입니다. 최고의 제품 리더는 지난 분기의 연구 자료가 아니라 지난주의 고객 대화를 기억으로 되짚을 수 있습니다. 문제를 훤히 알면 대부분의 우선순위 논쟁은 사라집니다. 팀이 의견이 아니라 증거로 추론할 수 있기 때문입니다.

성과로 관리하고 기능 공장에서 벗어난다

기능 공장은 성공을 “출하했다”로 정의할 때 얻는 것입니다. 팀은 속도를 측정하고, 릴리스를 세고, 출시를 축하하는데, 청구서를 갚는 지표는 정체됩니다. 해독제는 성공을 성과(고객이나 비즈니스 행동의 변화)로 정의하고 만들기 전에 거기에 척도를 붙이는 것입니다. 여기서 제품 관리가 목표와 핵심 결과(11.4장)를 만납니다. 목표는 원하는 변화를 기술하고, 핵심 결과는 그것을 측정하며, “기능 X 출시”로 표현된 핵심 결과는 위장한 과업입니다.

징후를 지켜보십시오. 로드맵이 명시된 성과 없는 기능 목록이라면, 출하된 기능이 어떤 지표를 움직였는지 아무도 말할 수 없다면, 회고가 “효과가 있었는가”는 결코 묻지 않고 “출하했는가”만 묻는다면, 기능 공장에 있는 것입니다. 벗어나는 것은 대부분 규율의 문제입니다. 누군가 문제와 척도를 진술하기 전에는 솔루션으로 구성된 일을 받아들이기를 거부하십시오. 제품 분석과 통제된 실험(7.4장)은 진짜 성과와 편안한 이야기를 구별할 계기판을 줍니다.

전달과 나란히 지속적 디스커버리를 운영한다

지속적 제품 디스커버리는 매주 전달과 나란히 팀이 고객에게서 배우고 만들 계획인 것 뒤의 가정을 시험한다는 뜻입니다. 모델은 이중 트랙입니다. 디스커버리 트랙이 아이디어의 위험을 줄이는 동안 전달 트랙은 검증된 것을 만들고, 둘은 순차적 단계가 아니라 지속적으로 돌아갑니다(11.1장이 파이프라인을 자세히 다룹니다). 그 뒤의 실천적 약속은 작고 끈질깁니다. 바쁠 때도, 특히 바쁠 때, 매주 고객과 이야기하십시오.

이를 위한 유용한 뼈대는 기회-솔루션 트리입니다. 원하는 성과에서 시작해, 그것을 움직일 수 있는 고객 기회(필요, 불편, 욕구)로 가지를 뻗고, 각 기회의 후보 솔루션으로, 솔루션이 동작하는지 알려 줄 가정 시험으로 다시 뻗습니다. 이 트리는 주어진 기능이 왜 테이블에 올랐는지 팀이 정직하게 유지하게 하고, 첫 솔루션과 사랑에 빠지는 대신 기회를 비교하게 합니다. 엔지니어링을 약정하기 전에 가장 위험한 가정을 가장 싼 실험으로 시험합니다. 인터뷰, 프로토타입, 가짜 문 테스트, A/B 테스트입니다. 디스커버리의 산출물은 기능 목록이 아닙니다. 전달할 준비가 된 검증되고 측정 가능한 내기의 흐름입니다.

우선순위 프레임워크를 신탁이 아니라 판단의 보조로 쓴다

우선순위 프레임워크는 지저분한 결정에 유용한 구조를 가져오며, 그 숫자를 진실로 다루면 모두 틀립니다. RICE는 각 아이디어를 도달(Reach, 얼마나 많은 사용자), 영향(Impact), 확신(Confidence), 노력(Effort)으로 점수화하고 (도달 x 영향 x 확신) / 노력으로 순위를 매깁니다. 가중 점수는 여러 가중 기준에 대해 선택지를 평가합니다. 지연의 비용은 기다림의 매주가 얼마나 드는지 묻는데, 순서를 정하는 데 가장 날카로운 렌즈인 경우가 많습니다. 카노 모델은 기능을 기본 기대, 성능 요구, 감동 요소로 나누어, 모든 만족이 선형은 아님을 일깨웁니다.

가정을 드러내고 상충을 논의할 수 있게 하려고 쓰되, 결정을 포기하는 데 쓰지 마십시오. RICE의 확신 항과 가중 점수의 추정은 산수로 위장한 판단이며, 거짓 정밀이 나쁜 내기를 객관적으로 보이는 순위 목록으로 세탁할 수 있습니다. 숫자를 돌린 뒤 순위가 전략과 고객 지식에 맞는지 물으십시오. 맞지 않으면 판단을 믿고 입력을 추궁하십시오. 프레임워크는 사고의 보조입니다. 옳아야 하는 것은 여전히 여러분입니다.

로드맵을 의도의 진술로 다룬다

특정 분기에 특정 기능을 약속하는 날짜 있는 로드맵은 모두가 서명하고 아무도 지킬 수 없는 허구입니다. 디스커버리가 계속 배우려는 바로 그것(솔루션)을 고정하기 때문입니다. 지금 / 다음 / 나중 로드맵을 선호하십시오. 지금 하는 것, 다음에 할 것 같은 것, 나중에 고려하는 것을 날짜가 있는 확정된 기능이 아니라 문제와 성과로 표현합니다. 이는 증거가 도착함에 따라 솔루션을 바꿀 자유를 보존하면서 방향을 정직하게 전달합니다.

근본적인 움직임은 문제와 성과에는 확고하게, 솔루션에는 느슨하게 약속하는 것입니다. 날짜가 확실한 기능 약속을 요구하는 이해관계자는 보통 예측 가능성을 요청하는 것이며 이는 합리적입니다. 아직 검증하지 않은 구체적 기능의 수준이 아니라 성과와 기간의 수준(“이번 반기에 온보딩 이탈을 의미 있게 줄일 것”)에서 그것을 주십시오. 어쩔 수 없이 확정된 날짜를 줘야 한다면 가치 있는 성과에 묶고, 10.6장이 프로젝트 전달에 권하듯 솔루션의 범위를 유연하게 두십시오.

바람직함, 실행 가능성, 구현 가능성, 사용성을 검증한다

실제 투자를 약정하기 전에 제품 아이디어는 네 가지 위험을 통과해야 합니다. 바람직함: 고객이 정말 원하는가? 사업성: 비즈니스(법무, 재무, 브랜드, 영업)에 통하는가? 구현 가능성: 엔지니어링이 가용한 시간과 기술로 만들 수 있는가? 사용성: 사람들이 실제로 쓸 수 있는가? 트리오는 이를 덮도록 만들어졌습니다. 제품이 사업성을, 디자인이 사용성을, 엔지니어링이 구현 가능성을 이끌고, 바람직함은 모두의 문제입니다. 하나를 건너뛰면 고객이 무시하거나, 법무가 막거나, 엔지니어링이 출하할 수 없거나, 사용자가 알아낼 수 없는 출시로 돌아옵니다.

이것은 구축, 구매, 파트너 결정의 틀이기도 합니다. 역량이 차별화의 핵심이라면 만드십시오. 필요하지만 차별화되지 않는다면(청구, 인증, 이메일 전달) 사거나 파트너를 맺는 쪽을 강하게 선호하십시오. 만드는 모든 기능은 유지 보수, 보안 표면, 인지 부하의 영구적인 꼬리를 지니기 때문입니다. 최소 기능 제품(MVP)은 가장 위험한 가정을 시험하는 가장 싼 것이지, 출하하고 잊는 축소된 1.0 버전이 아닙니다. 무엇을 출시할지만이 아니라 무엇을 배울지 물어 정직하게 유지하십시오.

제품-시장 적합을 알고 제품 운영에 투자한다

제품-시장 적합은 제품이 강한 시장 수요를 충족하는 순간이며, 증명하기 전에 대개 느낍니다. 유지율 곡선이 영으로 떨어지는 대신 평평해지고, 사용이 입소문으로 늘고, 고객이 제품을 잃으면 정말 속상해하고, 수요를 만들기보다 따라가기 바빠집니다. 적합 이전에는 할 일이 그것을 찾는 것이고 거의 다른 어떤 것도 중요하지 않습니다. 적합 이후에는 할 일이 그것을 확장하고 지키는 것으로 바뀝니다. 두 단계를 혼동하는 것(적합이 없는데 확장하거나, 적합이 있는데 여전히 찾고 있는 것)은 고전적이고 비싼 실수입니다.

제품 팀의 수가 늘면 제품 운영에 투자하십시오. 많은 팀이 각자 재발명하지 않고 디스커버리를 잘하게 하는 공유 연구, 데이터, 도구, 실천입니다. 제품 운영은 고객 인터뷰 주기에 인력이 배치되고, 분석이 신뢰할 만하고, 로드맵 형식이 일관되고, OKR 리듬이 돌아가게 합니다. 제품 운영 모델로 옮기는 기업과 내부 플랫폼에 실제 내부 고객이 있는 제품으로서의 플랫폼 조직에서, 제품 운영은 모델이 지역 습관으로 파편화되지 않고 수십 개 팀에 걸쳐 일관되게 유지되게 합니다.

장단점

접근	장점	단점
권한이 부여된 제품 팀(성과)	결과를 소유. 더 나은 솔루션을 찾음. 동기 부여됨	시니어 인재와 진짜 신뢰 필요. 위에서 지시하기 어려움
기능 팀 / 주문 받기 모델	예측 가능한 산출. 관리하고 계약하기 쉬움	엉뚱한 것을 효율적으로 출하. 결과를 소유하는 사람이 없음
지속적 디스커버리	매주 내기의 위험을 줄임. 빠른 학습. 적은 낭비	연구 역량과 규율 필요. 일정 잡기 어려움
무거운 선행 요구 사항	자금 제공자에게 안도. 분명한 범위	검증되지 않은 가정. 늦은 피드백. 일괄 위험
지금/다음/나중 로드맵	불확실성에 정직. 학습을 보존	날짜가 있는 기능 약속을 원하는 이해관계자를 좌절시킴
날짜가 있는 기능 로드맵	예측 가능해 보임. 소통하기 쉬움	알 수 없는 것을 약속. 성과보다 산출에 보상
프레임워크 점수에 의한 우선순위	구조적이고 논의 가능하며 정치를 줄임	거짓 정밀. 나쁜 내기를 객관적으로 세탁할 수 있음

중심 긴장은 약속 대 학습입니다. 예산, 계약, 경영진은 확고한 약속을 원하며, 이는 날짜가 있는 기능 로드맵과 선행 요구 사항 쪽으로 당깁니다. 좋은 제품은 발견할 여지가 필요하며, 이는 성과와 지속적 실험 쪽으로 당깁니다. 이 가이드 전체에서처럼 푸십시오. 문제, 성과, 기간에는 확고하게 약속하고 구체적 솔루션은 느슨하게 쥐십시오. 그러면 팀이 아직 검증하지 않은 기능을 약속하게 하지 않으면서 리더십이 실제로 필요한 예측 가능성(중요한 것들에 대한 측정 가능한 진전)을 얻습니다.

팀과 논의할 질문

제품 관리자는 성과를 소유합니까, 백로그를 소유합니까? 이것이 팀이 실제로 어떻게 운영되는지에 대해 가장 많은 것을 드러내는 단일 질문입니다. 제품 관리자가 로드맵 출하, 이해관계자 요청 쫓기, 스프린트 채우기로 측정된다면, 제품 직함을 단 프로젝트 조율자가 있는 것이고, 일이 지표를 움직이는지 실제로 책임지는 사람은 없습니다. 증거를 가져오십시오. 제품 관리자의 마지막 산출물 셋을 보고 각각이 어떤 고객 또는 비즈니스 성과를 바꿔야 했는지, 누군가 확인했는지 물으십시오. 큰 조직에서는 판돈이 복리로 쌓입니다. 산출을 향한 단일 팀이 시연에서는 잘 시험되지만 프로덕션에서는 아무것도 바꾸지 않는 기능을 만드는 데 여러 분기를 태울 수 있기 때문입니다. 답은 제품 관리자를 무엇으로 측정하는지와 팀에게 솔루션의 통제를 얼마나 줄 의향이 있는지를 재구성해야 합니다. 아무도 성과를 소유하지 않는다면 로드맵을 논쟁하기 전에 그것을 고치십시오.
이 팀의 누군가가 마지막으로 고객과 이야기한 것은 언제이며, 이번 주였습니까? 지속적 디스커버리는 이 습관에 살고 죽으며, 전달 압박이 오를 때, 곧 가장 필요할 때 가장 먼저 잘리는 것입니다. 고객과 이야기하기를 멈춘 팀은 눈이 멀었음을 알아채지 못합니다. 내부 의견과 오래된 연구로 추론하기 시작해 더 자신 있고 덜 정확해집니다. 실제 기록을 가져오십시오. 최근 기능 열 개 중 몇 개가 이해관계자의 입에서 곧장 백로그로 간 것이 아니라 문서화된 가정과 만들기 전의 싼 시험을 거쳤는지 세어 보십시오. 하나의 어긋난 이니셔티브가 여러 팀-분기를 낭비하고 공공 부문에서는 실제 공적 신뢰까지 낭비할 수 있는 기업과 정부 팀에서는, 매주의 고객 접촉을 살려 둘 책임자의 이름을 정하십시오. 정직한 답이 “이번 주는 아닙니다”나 “잘 모르겠습니다”라면, 가정 위에서 날며 그것을 전략이라 부르고 있는 것입니다.
프로젝트 운영 모델에서 제품 운영 모델로 옮기려면 무엇이 필요하며, 무엇이 막고 있습니까? 많은 기업이 여전히 임시 프로젝트에 자금을 대고, 인력을 두고, 출하하고, 팀을 해체하는데, 이는 좋은 제품 일이 의존하는 지속되는 소유권과 고객 지식을 파괴합니다. 수년에 걸쳐 성과를 소유하는 지속되는 팀으로의 이동은, 실제 고객이 있는 제품으로서의 내부 플랫폼을 다루는 것을 포함해, 직함의 변경이 아니라 자금, 조직 설계, 거버넌스의 변경입니다. 증거를 가져오십시오. 현재 이니셔티브 하나가 어떻게 자금을 받고 인력이 배치되는지 추적하고, 프로젝트가 끝나고 팀이 흩어질 때 쌓인 학습이 어떻게 되는지 물으십시오. 경쟁하는 고려는 실제입니다. 연간 프로젝트 예산과 조달 규칙은 정당한 책임의 이유로 존재하고, 무시하지 말고 충족해야 합니다. 답은 전체 포트폴리오를 전환하려 하기 전에 모델을 입증하는 가장 작은 구체적 단계(안정적 예산으로 하나의 성과를 소유하는 하나의 지속되는 팀)를 식별해야 합니다(10.1장).
우선순위 프레임워크를 돌릴 때, 그것이 결정에 정보를 줍니까, 아니면 이미 내린 결정을 승인할 뿐입니까? RICE, 가중 점수, 지연의 비용은 가정을 드러내게 한다는 바로 그 점에서 유용하며, 숫자가 생각을 멈출 핑계가 되는 순간 부식적으로 변합니다. 경쟁하는 고려는 실제입니다. 프레임워크는 정치를 줄이고 큰 조직이 정말 필요로 하는 방어 가능한 기록을 주지만, 확신과 영향 항은 산수로 위장한 판단이어서 나쁜 내기를 객관적으로 보이는 순위로 세탁할 수 있습니다. 최근 우선순위 결정 몇 개를 가져와 두 가지를 확인하십시오. 전략이나 고객 지식이 동의하지 않을 때 누군가 점수를 뒤집은 적이 있는지, 가장 높은 연봉자의 선호가 순위를 낳은 입력을 조용히 정했는지입니다. 점수가 매겨진 백로그가 운영 위원회와 감사자에게 보이는 산출물이 되는 경우가 많은 기업과 정부 환경에서는, 누가 어떤 근거로 숫자를 뒤집을 수 있는지 이름을 정하십시오. 아무도 뒤집을 수 없는 프레임워크는 사고의 보조이기를 멈추고 고무 도장이 되었기 때문입니다.
이해관계자에게 날짜가 있는 기능으로 무엇을 약속했으며, 신뢰를 잃지 않고 그 약속을 성과로 다시 진술할 수 있습니까? 날짜가 있는 기능 로드맵은 예측 가능해 보이지만 대개 허구입니다. 디스커버리가 계속 배우려는 솔루션을 고정하기 때문이며, 큰 조직에서는 그런 모든 약속이 의존하는 팀, 마케팅 계획, 경영진의 기대로 파급됩니다. 긴장은 정당합니다. 자금 제공자와 이해관계자는 예산과 책임의 이유로 확실성을 원하므로 단지 약속을 거절할 수는 없습니다. 검증되지 않은 기능이 아니라 성과와 기간의 수준에서 예측 가능성을 줘야 합니다. 현재 로드맵을 가져와 각 항목을 약속할 수 있는 성과인지, 짐작하는 구체적 솔루션인지 표시하고, 짐작을 지금/다음/나중 문제로 어떻게 다시 진술할지 초안을 잡으십시오. 연간 예산과 조달 마일스톤에 묶인 기업과 공공 부문 팀에서는 어떤 약속이 진짜 계약상의 것이고 어떤 것이 단지 습관적인 것인지 식별하십시오. 습관적인 것은 거짓 정밀을 정직한 방향과 맞바꿀 수 있는 곳이고, 계약상의 것은 약속을 기능이 아니라 성과로 협상해야 하는 곳입니다.
차별화되지 않는 역량을 사거나 파트너를 맺을 수 있는데 만들고 있는 곳은 어디이며, 누가 결정합니까? 만드는 모든 기능은 유지 보수, 보안 표면, 지원 부하의 영구적인 꼬리를 지니므로, 청구, 인증, 이메일 전달을 직접 만드는 것은 여러분을 차별화하지 않는 일에 가장 희소한 역량을 쓰는 것입니다(10.4장). 경쟁하는 고려는 “구매”가 속도와 낮은 소유 비용을 대가로 통제와 적합을 내주며, 때로 범용이라 가정한 역량이 실제로는 우위의 핵심이므로, 바람직함-사업성-구현 가능성-사용성 렌즈를 선호의 구실이 아니라 정직하게 적용해야 한다는 것입니다. 팀이 현재 사내에서 만들고 있는 것의 목록을 가져와 각각을 핵심 차별화 요소와 차별화되지 않는 배관으로 표시하고, 배관의 지속적 소유 비용을 벤더 대안에 대해 추정하십시오. 기업과 정부 맥락에서는 조달 규칙, 데이터 거주와 보안 요구 사항, 벤더 종속과 퇴출 조건을 반영하십시오. 거기서 구축-구매-파트너 결정은 단지 엔지니어링의 상충이 아니라 컴플라이언스와 책임의 상충이며, 그것을 소유하는 사람은 감사자에게 선택을 변호할 수 있어야 하기 때문입니다.

분야별 관점

스타트업. 런웨이가 짧으면 디스커버리는 프로세스가 아니라 생존입니다. 한 창업자가 제품 모자를 쓰고, 의례 없이 매주 고객과 이야기하고, 엔지니어 한 명이라도 만들기에 약정하기 전에 가능한 가장 싼 시험(가짜 문 버튼, 다섯 번의 인터뷰)을 돌립니다. 무거운 프레임워크와 날짜가 있는 로드맵은 건너뛰십시오. 회사 전체가 전략을 머릿속에 담을 수 있으니, 누군가 문제와 지표를 진술하기 전에는 큰 소리의 요청을 만들기를 거부하는 데 규율을 쓰십시오.

소기업. 전담 제품 관리자가 없으니 제품 사고는 주인이나 리드 엔지니어가 다른 업무와 함께 지니는 습관입니다. 대부분의 구축 대 구매 판단을 구매 쪽으로 구성하십시오. 예약, 결제, 이메일 같은 차별화되지 않는 역량은 벤더의 몫이고, 희소한 주의는 고객을 실제로 얻는 한두 가지에 갑니다. 공식 로드맵보다 가벼운 지금/다음/나중 목록을 유지하고, 완전한 OKR 장치 대신 하나의 선행 지표(재구매, 노쇼)를 성과로 다루십시오.

대기업. 일은 모델이 파편화되지 않게 하면서 많은 제품 팀을 조율하는 것입니다. 성과를 소유하는 지속되는 트리오, 일관된 로드맵 형식, 수십 개 팀에 걸쳐 인터뷰 주기, 분석, OKR 리듬을 일관되게 유지하는 제품 운영입니다. 거버넌스와 감사는 추적 가능성을 원하므로, 위원회는 만족시키지만 영향보다 산출에 보상하는 날짜가 있는 기능 약속으로 돌아가는 대신 성과, 우선순위 근거, 중단 결정을 읽을 수 있게 만드십시오. 조직 설계와 예산 편성은 직함보다 느리게 변하므로 프로젝트 자금에서 제품 운영 모델로의 전환을 의도적으로 관리하십시오.

정부. 조달 규칙, 투명성, 공적 책무가 모든 선택을 형성합니다. 고정 범위 프로젝트가 아니라 지속되는 서비스 팀에 자금을 대고, 성공을 감독 기관이 검증할 수 있는 시민 성과(신청까지의 시간, 셀프서비스 완료)로 정의하고, 사용자 중심 설계와 접근성 표준을 보조 기술 사용자를 포함한 실제 신청자로 시험하는 필수 요구 사항으로 다루십시오. 정밀 조사가 공공 가치를 보도록 성과와 진행을 평이하게 공개하고, 오늘의 공급자 선택이 십 년의 종속이 되지 않도록 구축 대 구매와 벤더 계약을 데이터 이식성과 퇴출 중심으로 구성하십시오.

사례

스타트업. 독립 클리닉을 위한 예약 도구를 만드는 여섯 명의 스타트업은 시끄러운 고객 셋이 계속 요청하는 큰 “온라인 예약” 기능을 만들고 싶은 유혹을 거부합니다. 창업자 겸 제품 관리자가 대신 한 주의 디스커버리를 돌립니다. 클리닉 주인 다섯 명 인터뷰, 마케팅 사이트의 가짜 문 버튼, 하나의 선행 지표(노쇼로 끝나는 예약의 비율)입니다. 증거는 예약이 아니라 노쇼가 진짜 고통임을 말하며, 그래서 팀은 단일 성과(이번 분기 파일럿 클리닉의 노쇼를 10% 아래로 줄이기)를 구성하고, 가장 위험한 가정을 시험할 작은 보증금-알림 MVP를 출하하고, 코드를 한 줄 쓰기 전에 예약 기능을 접습니다. 로드맵은 날짜가 있는 계획이 아니라 지금/다음/나중 목록이며, 팀 전체가 지난주의 고객 통화를 기억으로 되짚을 수 있습니다.

기업. 한 소매 은행이 결제 그룹을 프로젝트 모델에서 제품 모델로 옮깁니다. 하나의 지속되는 트리오(제품, 디자인, 엔지니어링)가 일련의 승인된 프로젝트가 아니라 안정적인 연간 예산으로 “일상 결제가 즉각적으로 느껴진다”를 상설 성과로 소유합니다. 팀은 매주 고객 인터뷰를 하고 기회-솔루션 트리를 유지하며, 후보 솔루션의 순서를 정하는 데 RICE를 쓰되 지연의 비용 분석이 지연 시간 수정이 더 중요함을 보이면 순위를 뒤집고, 이해관계자에게 날짜가 있는 기능 약속 대신 지금/다음/나중 로드맵을 공개합니다. 제안된 두 기능이 선행 지표를 움직이지 못해 디스커버리에서 죽어, 추정 두 분기의 구축 노력을 절약하고, 제품 운영이 은행의 열다섯 개 제품 팀 전반에서 인터뷰 주기와 분석을 신뢰할 만하게 유지합니다.

정부. 급여 신청을 현대화하는 한 국가 기관이 디지털 서비스 팀들이 옹호하는 공공 부문 제품 마인드셋을 채택합니다. 고정 범위 프로젝트가 아니라 지속되는 서비스 팀에 자금을 대고, 성공을 전달된 모듈이 아니라 시민 성과(신청까지의 중앙값 시간을 40분에서 15분으로 줄이고 성공적인 셀프서비스 완료를 55%에서 85%로 올리기)로 정의합니다. 사용자 중심 설계는 협상 불가입니다. 팀은 매 릴리스 전에 보조 기술 사용자를 포함한 실제 신청자와 진행자가 있는 사용성 테스트를 하고 접근성 표준을 필수 요구 사항으로 다룹니다. 로드맵이 성과로 구성되고 팀이 수년에 걸쳐 서비스를 소유하므로, 감독 기관은 지출 보고서 대신 측정 가능한 공공 가치를 보고, 기관은 하나의 먼 가동에 모든 것을 걸지 않고 쓸모 있는 역량을 일찍 출하할 수 있습니다(11.1장, 5.1장).

비즈니스 사례: 동기, ROI, TCO

진짜 제품 관리의 수익은 피한 낭비가 지배합니다. 대형 기술 회사의 통제된 실험 프로그램은 만든 기능의 상당 부분, 흔히 절반 안팎으로 인용되는 것이 측정 가능한 개선을 낳지 못하거나 목표 지표를 적극적으로 해친다는 것을 거듭 발견합니다. 팀 역량의 4분의 1만이라도 지속적 디스커버리가 싸게 죽였을 아이디어에 간다면, 이 규율은 여러 번 비용값을 합니다. 일주일의 고객 인터뷰와 가짜 문 테스트는 한 분기의 엔지니어링과, 아무도 쓰지 않는 기능의 영구적 유지 보수에 비하면 거의 아무것도 들지 않습니다. 기능 공장의 주된 비용은 출하하는 기능이 아닙니다. 움직이지 못한 성과의 기회비용입니다.

총소유비용 측면에서 출하된 모든 기능은 상설 부채입니다. 유지 보수, 테스트, 보안 표면, 지원 부하, 제품을 탐색해야 하는 모두에게 지우는 인지적 무게입니다(10.4장). 제품 관리는 두 가지로 그 비용을 낮춥니다. 나쁜 아이디어를 디스커버리에서 죽여 구축만이 아니라 소유의 전체 꼬리를 피합니다. 그리고 구축-구매-파트너 결정을 차별화되지 않는 역량을 사는 쪽으로 이끌어, 팀의 유한한 역량이 실제로 차별화하는 것에 가게 합니다. 프로젝트 운영 모델에서 제품 운영 모델로의 전환은 더 미묘한 수익을 더합니다. 지속되는 팀은 프로젝트 팀이 해체하고 다시 꾸릴 때마다 버리는 고객 지식과 코드베이스 맥락을 유지합니다.

리더십을 설득하려면 대화를 “얼마나 많이 출하하는가”에서 “중요한 지표를 얼마나 움직이는가”로 바꾸고, 아무것도 움직이지 못한 비싼 기능의 구체적 사례 두세 개를 보이십시오. 도입 비용은 소박합니다. 연구 역량, 디스커버리 주기, 성과 기반 로드맵, 만들기 전에 성공을 정의하는 규율입니다. 투자하지 않는 위험은 조용하고, 집계되지 않고, 복리로 쌓입니다. 기능 공장은 비즈니스가 움직이지 않았음을 알아채기 직전까지 생산적으로 보이기 때문입니다.

안티패턴과 함정

기능 공장: 성공이 “출하했다”로 정의되고 속도가 축하받는 동안 비즈니스 지표는 정체됨.
프로젝트 관리자로서의 제품 관리자: 문제와 성과 대신 일정과 티켓 대기열을 소유하는 것.
기능 비서로서의 제품 관리자: 문제나 척도 없이 이해관계자 요청을 백로그에 옮겨 적는 것.
날짜가 있는 기능 약속으로서의 로드맵: 아직 검증할 수 없는 특정 분기의 특정 솔루션을 약속하는 것.
일회성 단계로서의 디스커버리: 앞서 한 번의 디스커버리 스프린트를 하고 이후 고객 접촉 없이 몇 달을 만드는 것.
HiPPO 주도 우선순위: 가장 높은 연봉자의 의견이 증거를 뒤엎고 프레임워크가 그것을 승인하는 연극이 되는 것.
프레임워크 숭배: RICE나 가중 점수를 진실로 다뤄 거짓 정밀이 나쁜 내기를 세탁하게 두는 것.
차별화되지 않는 인프라 구축: 벤더가 더 낫고 더 싸게 제공할 청구나 인증을 직접 만드는 것.
제품-시장 적합 전의 확장: 시장이 아직 강하게 원하지 않는 제품의 성장에 돈을 쏟아붓는 것.
제품 소유자 없는 내부 플랫폼: 플랫폼 팀이 내부 고객이 필요로 하는 것이 아니라 흥미롭게 여기는 것을 만드는 것.

성숙도 모델

1단계, 시작: 제품 관리가 주문 받기이고 반응적입니다. 날짜가 있는 기능 로드맵이 내려오고 성공은 그것을 출하하는 것입니다. 명시된 성과도, 정기적 고객 접촉도 없고, 일이 지표를 움직였는지에 책임지는 사람도 없습니다.
2단계, 발전: 기본적인 제품 실천이 나타나지만 팀마다 일관되지 않습니다. 일부 팀에 성과와 OKR이 있지만 목표는 흔히 산출 모양이고 로드맵은 여전히 기능 목록입니다. 디스커버리는 가끔, 대개 선행 단계로 일어나고, 우선순위는 프레임워크를 쓰되 때로 가장 큰 목소리의 구실로 씁니다.
3단계, 표준화: 권한이 부여된 트리오가 성과를 소유하며, 실천이 문서화되어 조직 전체에 기대됩니다. 로드맵은 지금/다음/나중의 의도 진술이고, 지속적 디스커버리는 문서화된 가정 시험이 있는 인력이 배치된 주간 습관이며, 우선순위 프레임워크는 판단을 대체하지 않고 정보를 주고, 제품-시장 적합은 지역 습관이 아니라 공유된 표준으로 이해되고 추적됩니다.
4단계, 관리: 실천이 기준선에 대해 측정되고 통제됩니다. 각 팀이 명시된 기준선에 대해 선행 및 후행 성과 지표를 추적하고, 출시 후 모든 기능은 의견이 아니라 증거로 시행되는 중단 임계값이 있는 사전 등록된 성공 지표에 대해 점검됩니다. 디스커버리 건강도 계측됩니다(인터뷰 주기 충족, 만들기 전에 시험한 가정, 디스커버리에서 죽은 아이디어 대 출하된 것). 유지율 곡선과 사라지면 속상해할 비율 같은 제품-시장 적합 신호가 수량화되고, RICE 확신 같은 프레임워크 입력은 내기가 실제로 어떻게 되었는지에 대해 보정됩니다.
5단계, 오케스트레이션: 제품 운영 모델이 포트폴리오 전반에서 돌아가며 자금과 전략에 통합되어 지속적으로 개선됩니다. 지속되는 팀이 수년에 걸쳐 성과를 소유하고 내부 플랫폼은 제품으로 관리되며, 디스커버리와 전달이 지속적으로 순환하고, 성과 데이터가 투자를 이끌어 포트폴리오를 적응적으로 재균형하고, 제품 운영이 규모에서 실천을 일관되게 유지하며, 리더십은 증거와 시장이 이동함에 따라 내기를 일상적으로 폐기하고, 범위를 다시 정하고, 우선순위를 다시 매기며 성과의 포트폴리오를 관리합니다.

논의를 위한 아이디어

현재 로드맵을 보십시오. 측정 가능한 성과를 진술한 항목과 기능과 날짜만 있는 항목이 각각 몇 개입니까?
팀에서 누가 지난주의 대화를 기억으로 되짚을 수 있을 만큼 고객 관계를 소유합니까?
가장 위험한 가정에 싼 실험을 먼저 돌렸다면 최근 기능 중 어느 것을 접었겠습니까?
사거나 파트너를 맺을 수 있는데 차별화되지 않는 역량을 만들고 있는 곳은 어디이며, 그것이 얼마나 비용이 듭니까?
제품-시장 적합이 있습니까? 가정하는 대신 실제로 어떻게 알겠습니까?
제품 운영 모델을 향해 취할 수 있는 가장 작은 단계는 무엇이며, 어떤 거버넌스 장애물이 가로막고 있습니까?

핵심 요점

제품 관리는 무엇과 왜를 소유하며, 과업 조율이나 요청 옮겨 적기가 아니라 성과에 책임이 있습니다.
만들기 전에 성공을 고객이나 비즈니스 행동의 측정된 변화로 정의해 기능 공장에서 벗어나십시오.
전달과 나란히 지속적 디스커버리를 운영하십시오. 매주 고객과 이야기하고 가장 위험한 가정을 가장 싼 실험으로 시험하십시오(11.1장).
우선순위 프레임워크(RICE, 가중 점수, 지연의 비용, 카노)는 신탁이 아니라 판단의 보조로 쓰십시오.
로드맵을 의도의 진술(지금/다음/나중)로 다루십시오. 문제와 성과에는 확고하게, 솔루션에는 느슨하게 약속하십시오.
트리오에게 권한을 주고 투자하기 전에 바람직함, 사업성, 구현 가능성, 사용성을 검증하십시오(5.1장).
기업과 정부에서는 프로젝트 운영 모델에서 제품 운영 모델로 옮기고, 프로젝트가 아니라 서비스에 자금을 대고, 제품 운영에 투자하십시오(10.1장, 11.4장).

참고 문헌과 더 읽을거리

Marty Cagan, Inspired and Empowered (empowered product teams, the product operating model).
Marty Cagan and Chris Jones, Transformed (moving to a product operating model).
Teresa Torres, Continuous Discovery Habits (opportunity-solution trees, weekly customer contact).
Melissa Perri, Escaping the Build Trap (outcomes over outputs, product operations).
Roman Pichler, Strategise (product vision, strategy, and roadmaps).
C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors, Product Roadmaps Relaunched (now/next/later roadmaps).
Dan Olsen, The Lean Product Playbook (product-market fit).
Eric Ries, The Lean Startup (minimum viable product, build-measure-learn).
Noriaki Kano et al., “Attractive Quality and Must-Be Quality” (Journal of the Japanese Society for Quality Control, 1984): origin of the Kano model.
Melissa Perri and Denise Tilles, Product Operations (scaling product practice).
U.S. Digital Service, Digital Services Playbook; UK Government Digital Service, Government Design Principles and Service Standard (public-sector, user-centred product delivery).