지속 가능한 제품 전략: 산출물에서 결과로 이동하는 방법

로드맵은 제품 전략 및 제품 관리의 핵심입니다. Yesware의 제품 담당자이자 제품 부사장으로서 저는 각 팀이 어떤 순서로 그리고 긴 시간 내에 무엇을 제공할 것인지에 대한 논의를 완전히 수용하지 못했습니다. 결과 중심의 제품 로드맵은 잘못된 확신을 제공하는 동시에 제품 작업을 몇 가지 큰 베팅으로 제한합니다.

나는 Marty Cagan의 저서, 특히 그의 책 Inspired 와 Teresa Torres의 워크샵 및 팀 코칭을 통해 배운 것을 바탕으로 제품 관리에서 출력 또는 기능 기반 로드맵이 과거의 일이었음을 확인하고 싶습니다. 제품 관리는 결과 기반 제품 계획으로 이동하고 있습니다. 단순히 기능 A와 B를 제공하는 것이 아니라 메트릭 A와 B를 이동하는 것을 목표로 합니다.

산출물 기반 계획

출력 기반 제품 로드맵은 시간이 지남에 따라 그리고 각각 엔지니어링 팀을 나타내는 여러 스윔 레인에 걸쳐 주어진 기능 세트를 시퀀싱하기 위해 난잡하고 협상하는 것처럼 보입니다.

제품 관리자와 팀은 거의 항상 다양한 데이터, 시장 및 사용자 통찰력을 기반으로 로드맵을 알려줍니다.

그런 다음 내부 이해 관계자로부터 피드백을 요청하여 계획에 정보를 제공 합니다. 다양한 이해 관계자가 기능 제안을 둘러싸고 로비를 합니다. 이상적으로 이해 관계자는 기능 우선 순위를 지정하는 방법과 기능이 제공되면 달성할 수 있는 기능에 대해 정보에 입각하고 조사된 관점을 가지고 테이블에 옵니다. 때때로 그들은 더 본능적인 제안을 하거나 가장 먼저 생각하는 문제를 지나치게 강조합니다.

다른 경우 에는 경영진이 로드맵 계획에 대해 알리고 각 초점 영역에 대한 제품 로드맵의 대략적인 개요를 작성합니다 . 작년 초, 결과 기반 계획으로 전환하기 전에 Yesware의 리더십 팀은 오프사이트에서 사고 연습을 했습니다. 우리는 쌍으로 나뉘었고 각 쌍은 특정 초점 영역을 따라 기능 로드맵을 개발했습니다. 모든 주제를 종합하면 대략적인 연간 로드맵을 볼 수 있습니다.

매년 기능 중심의 로드맵을 보는 것에는 잘못된 확신이 아닐지라도 확신할 수 있는 것이 있습니다 . 계획은 전달 경로의 첫 번째 단계입니다. 방향으로 정렬할 수 있습니다. 제품이 향하는 방향의 미래에 판매할 수 있습니다. 고객의 표현된 요구 사항이 우선시된다는 확신을 현재 고객에게 제공할 수 있습니다. 영업 교육을 만들고 몇 달 전에 예정된 기능 출시에 대한 시장 출시 계획을 준비할 수 있습니다. 미래의 요구 사항과 투자 분야에 대한 예측을 통해 필요 사항과 기술을 중심으로 팀을 고용하고 직원을 구성할 수 있습니다.

민첩하고 빠르게 변화하며 경쟁이 치열한 환경에서는 출력 중심의 제품 계획으로 달성할 수 없는 경우가 많지만 원하는 사용자 및 비즈니스 결과 입니다. 출력 중심의 로드맵은 몇 번의 큰 베팅이 홈런이 된다고 가정합니다. 실제로 사용자 요구에 대한 우리의 이해가 발전하고 시장 환경이 변화하며 위험을 감수하는 실행에 집중하여 새로운 아이디어나 실험을 미루고 있습니다. 계획된 작업은 실망스러운 결과를 보여줍니다. 새로운 위험과 기회가 생깁니다. 사용자는 긴 대기열의 끝에 아이디어와 제안이 추가되도록 피드백을 제공합니다("3분기 내에 고려할 것"). 작업을 수행하는 팀은 더 이상 사용자 요구 사항을 충족하지 않는 솔루션을 실행하게 되며 더 이상 우선 순위가 아닌 작업을 실행하는 데 몇 달을 보냅니다.

결과 기반 계획

Yesware에서 지난 6개월 동안 우리는 점진적으로 결과 기반 제품 계획으로 전환했습니다. 다음은 산출물에서 결과 기반 계획으로 전환하는 동안 중요하다고 발견한 7가지 교훈입니다.

1. 회사의 비전과 방향에서 출발

분명한 사실을 되풀이하기 위해 리더십 팀은 회사의 비전과 방향을 설정해야 합니다 . 여기에는 핵심 사용자 정의, 사용자의 "해야 할 작업" 설명, 회사 차별화 방법 식별이 포함됩니다. 모든 것이 이 비전에서 흐릅니다.

2. 높은 수준의 회사 결과 정의

그런 다음 리더십 팀은 회사가 달성하고자 하는 주요 비즈니스 결과와 이상적으로는 해당 비즈니스 결과의 성공을 나타내는 선행 지표인 하나의 North Star 지표에 맞춰 조정해야 합니다 . 비즈니스 결과는 종종 재정적(예: "50% 수익 성장")이고 영향의 후행 지표인 반면, North Star 지표는 비즈니스가 사용자에게 제공하는 가치를 반영하는 영향의 선행 지표입니다. 올바른 North Star 메트릭을 정의하면 제품 팀의 핵심 작업인 기회와 솔루션 공간을 확보할 수 있으므로 리더십 팀의 가장 전략적인 작업 중 하나입니다.

Yesware에서 우리는 먼저 출력 정의에서 몇 가지 주요 결과 정의로 전환했습니다. 비즈니스에 대해 하나의 North Star 메트릭으로 이동하는 것은 너무 급격한 변화였기 때문입니다. 따라서 우리는 비즈니스 초점의 각 주요 영역에서 높은 수준의 사용자 결과를 정의하는 것으로 시작했습니다. 각 영역에는 추진하고자 하는 주요 사용자 결과가 있었습니다. 따라서 다음에 Yesware 리더십 팀이 오프사이트를 위해 모일 때 Q1에 "다음을 수행하는 보고서를 제공"할 계획을 세우는 대신 결과에 중점을 두었습니다. 보고의 가치" 및 "고객이 고객과 예약하는 회의 수를 늘리십시오."

몇 가지 주요 결과로 전환한 후 우리는 하나의 North Star 메트릭을 정의하는 데 더 잘 대처할 수 있었습니다. 결과를 설정하고 이를 향한 추진력이 강화되기 시작했기 때문입니다.

3. 작업을 수행하는 팀이 특정 결과를 개선할 수 있도록 허용

각 초점 영역(북극성 지표에 대한 주요 입력)에서 작업하는 팀이 함께 모여 그들이 책임져야 하는 특정 결과를 수정하고 조정하는 것이 핵심이었습니다. 리더십 팀이 북극성을 설정하고 북극성을 구동하는 입력에 대한 프레임을 설정하는 동안 작업을 수행하는 팀(예: 제품 관리자, 디자이너, 엔지니어)은 정의된 기간 내에 특정 결과에 서명합니다. 이것은 더 큰 소유권과 책임을 가져옵니다. 목표에 더 많은 정보를 제공할 수 있습니다. 전술적으로 이것은 "고객과의 회의 수를 늘리십시오"와 같은 목표를 팀에 전달한 다음 "1분기 말까지 매주 평균 10,000개의 고객 회의를 달성하십시오"와 같은 목표로 구체화하는 것을 의미합니다.

4. 솔루션에 뛰어들기 전에 기회를 정렬하십시오.

우리의 경험에 따르면 , 작업을 수행하는 팀과 주요 이해 관계자는 정의된 결과를 달성하기 위해 탐색할 가장 중요한 기회에 정렬하는 것이 중요합니다 . 이 논의는 특정 솔루션이 아니라 기회 수준에서 진행하는 것이 가장 좋습니다. 기회는 다양한 가능한 솔루션이 있는 중요한 사용자 요구 사항입니다. 회의 예약 예에서 "사용자가 고객과 더 많은 회의를 예약할 수 있도록 지원"에는 두 가지 다른 기회가 있을 수 있습니다.

1. 사용자가 회의를 효율적으로 설정하고
2. 예약된 회의가 실제로 발생하는지 확인합니다.

반대로 수신자에게 회의 알림을 보내는 회의 도구는 특정 솔루션입니다. 다양한 기회의 우선 순위를 맞추지 않으면 팀과 내부 이해 관계자 간의 마찰이 발생합니다. 초점을 맞추지 않은 기회와 일치하는 솔루션을 많이 듣는 경우 불일치가 발생할 수 있습니다. 이러한 경우 제품 관리자는 자신의 작업(진행 중인 고객 발견에서 얻은 데이터 및 통찰력)을 보여줄 수 있어야 하며, 이를 통해 기회 우선 순위를 정하고 이해 관계자와 협력하여 불일치를 유발하는 요소를 이해할 수 있어야 합니다.

5. 유사한 솔루션 비교 및 ​​대조

팀이 사용자 기회에 대한 명확한 초점을 갖게 되면 솔루션에 대한 가장 심도 있는 논의가 이루어 집니다. 산출물 기반 제품 계획과 관련하여 솔루션에 대한 대화가 지연되는 것처럼 보일 수 있습니다. 그러나 정렬을 둘러싼 모든 작업을 통해 유사한 요구 사항을 충족하는 솔루션을 비교할 수 있습니다. 극적으로 다른 요구 사항을 충족하는 솔루션을 비교하고 우선 순위를 지정하는 대신 이제 솔루션이 특정 기회와 결과에 어떤 영향을 미칠지 평가하고 있습니다. 한 솔루션에 즉시 집중하고 실행으로 바로 옮기는 대신 팀은 사용자 요구를 충족하는 다양한 솔루션을 제시하고 이를 서로 비교하고 있습니다. 검증을 위해 하나의 솔루션을 제공하는 것보다 많은 유사한 옵션을 비교 및 ​​대조할 때 내부적으로나 고객과 트레이드 오프 및 우선 순위 지정 논의가 더 쉽습니다.

6. 솔루션의 위험을 제거하여 먼저 작은 베팅을 하십시오.

솔루션 공간을 좁힐 때 대규모 수개월 프로젝트를 수행하는 대신 작은 베팅으로 시작하는 것이 중요하다는 것을 알게 되었습니다 . 특히 결과에 큰 영향을 미칠 솔루션 내에서 가장 높은 위험 영역을 식별하고 위험을 제거하는 방법을 배우고 있습니다. 우리는 또한 위험하지 않거나 잘 알려진 것, 즉 그냥 구축할 수 있는 것을 테스트하는 데 시간을 낭비하지 않으려고 노력합니다.

위험을 평가할 때 프로젝트의 위험을 식별한 다음 실제로 무엇이 방해가 될 수 있는지 결정하는 것이 도움이 됩니다. 다음과 같을 수 있습니다.

• 기술 또는 실행 가능성 위험 (예: 정의된 시간 내에 이를 실행할 수 있습니까? 확장할 수 있습니까?)
• 사용자 위험 (예: 이것이 얼마나 바람직한가? 솔루션이 직관적입니까? 사람들이 그것에 대해 더 많은 비용을 지불할 의향이 있습니까?).

솔루션의 위험을 제거하는 방법은 사용자 테스트, 기술 개념 증명 또는 제품 내 간단한 테스트를 통해 수행할 수 있습니다. 예를 들어, 우리는 수신자의 위치를 ​​기반으로 답장 가능성을 높이는 방식으로 사용자가 이메일을 보내기에 가장 좋은 시간을 식별할 수 있도록 하는 "보내기 가장 좋은 시간" 기능에 대한 수요를 테스트하고 싶었습니다. 마케팅 사이트에 유사한 도구가 있습니다. 제품 내에서 도구의 원활한 통합을 구축하는 대신 제품의 마케팅 도구를 iframe하고 참여 수준을 측정하여 추가 투자 여부와 방법을 결정했습니다. 최고의 사용자 경험은 아니었습니다. 그러나 여전히 사용자 요구를 테스트하려고 하는 경우 최고의 사용자 경험을 구축해야 하는 이유는 무엇입니까?

7. 계속해서 결과로 돌아오십시오.

마지막으로 팀은 목표 결과에 어떻게 영향을 미치는지 지속적으로 모니터링할 수 있는 올바른 도구가 필요합니다 . 북극성과 이를 구동하는 입력을 설정할 때 이동하는 데 몇 달이 걸리거나 드물게만 측정될 수 있는 후행 결과에 비해 정기적으로 변경될 수 있는 결과를 갖는 것이 중요합니다. 작업에 대한 결과의 응답성이 높을수록 추적 및 모니터링이 더 쉬워집니다. 매주 측정할 수 있는 결과를 얻는 것이 중요하다는 것을 알았습니다. 또한 우리가 Amplitude에서 생명을 측정하는 데이터인 Yesware에서 자동화된 방식으로 계측을 설정함으로써 투명성이 높아졌습니다. 전술적으로, 작업을 수행하는 팀과 회사 전체의 이해 관계자는 주요 제품 결과를 측정하는 대시보드에 중앙 집중식으로 액세스할 수 있습니다. 이런 식으로 팀은 필요한 경우 코스를 수정할 수 있고 놀라움을 최소화할 수 있습니다.

산출물에서 결과로 이동하는 것은 장기적으로 작동하는 제품 개발 전략입니다

결과 중심의 계획으로 전환하는 것은 궁극적으로 고객의 요구를 중심에 두고 제공되는 기능에 대한 확인란을 선택하지 않고 고객 요구에 대한 영향을 측정하는 로드맵을 만드는 것입니다. 조정과 조직 변경이 필요한 프로세스이지만 투자할 가치가 있습니다. Yesware에서 이 여정을 계속하게 된 것을 기쁘게 생각합니다.