<div id="readability-page-1" class="page"><div id="main-content" data-pagefind-body="">   <article id="article"> <h3 id="intro">Intro</h3>
<ul>
<li>tails.com 리텐션 개선 과제
<ul>
<li>서비스 초기 90일간의 고객 유지율이 장기 유지율을 결정하는 중요 지표라는 것을 발견</li>
<li>90일이 너무 길어서 유지율을 5일까지 줄여보았으나 이것이 장기 유지율의 선행 지표가 아닐 수도 있다는 우려
<ul>
<li>유지율이 5일로 단축되면서 실험은 빨라졌지만 비지니스 성과는 모호</li>
</ul>
</li>
<li>고객 인터뷰 진행
<ul>
<li>고객 이탈(churn) 원인
<ul>
<li>모든 고객이 맞춤형 사료의 가치를 제대로 이해하고 있지 않다</li>
<li>일부 개들은 이 사료를 좋아하지 않았다</li>
</ul>
</li>
<li>-&gt; 고객 인터뷰를 통해 당장 측정 가능하고 실행 가능한 두 가지 제품 성과 지표(product outcomes) 도출
<ul>
<li>맞춤형 사료의 인지 가치를 높이고</li>
<li>더 많은 개들이 사료를 좋아하게</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>결과중심사고(Outcome Mindset)으로 전환할때의 어려움
<ul>
<li>하나의 지표를 선택하는 것만으로 충분하지 않음</li>
<li>결과 목표가 주어지면, 어떻게 측정해야 할지, 어떻게 영향을 미칠지, 심지어 그것이 올바른 결과인가를 모를때가 많다.</li>
<li>90일 유지율(결과 목표)처럼 시간이 오래 걸리는 지표를 사용하면 빠른 실험 사이클을 운영하기 어렵다.</li>
</ul>
</li>
<li><strong>프로덕트 팀은 제품 결과(product outcome)와 비지니스 결과(business outcome) 사이의 연결고리를 찾기 위해 어느 정도의 사전 조사(discovery)가 필요</strong>
<ul>
<li>비지니스 결과 -&gt; 실제 실행 가능한 제품 결과로 전환</li>
</ul>
</li>
</ul>
<h3 id="왜-결과outcomes인가">왜 결과(Outcomes)인가?</h3>
<ul>
<li>결과로 관리한다는 것은 팀에게 자율성, 책임감, 그리고 주도성을 부여하는 것
<ul>
<li>정해진 기능(feature)들을 특정 시점까지 개발하라는 전통적인 로드맵 방식 대신, 고객 문제를 해결하거나 비지니스 니즈를 해결하라는 문제 정의가 주어짐</li>
<li>진정한 Continuous-Discovery Team 이라면, 프로덕트 트리오는 고객과 기술에 대한 깊은 이해를 갖추고 있어 특정 문제를 해결하는데 있어서 의사결정 우위를 가지고 결과 관리 전략은 불확실성을 허용
<ul>
<li>고정된 로드맵은 마치 우리가 무엇을 만들어야하는지 완벽히 알고 있는 듯한 ‘거짓된 확신’을 전달한다.</li>
<li>반면, 결과는 <strong>“이 문제를 해결해야 한다는 것은 알지만, 어떻게 해결하는지가 확실치 않다.”</strong> 는 점을 강조</li>
</ul>
</li>
<li>결과로 관리한다는 것은 성공을 어떻게 측정해야 하는지가 명확</li>
</ul>
</li>
<li>그렇다면 과연, 결과 주도가 정말 좋은 것인가?</li>
</ul>
<h3 id="다양한-유형의-결과-탐색">다양한 유형의 결과 탐색</h3>
<ul>
<li>결과 중심 관리는 결과 자체의 질에 따라 달라진다.</li>
<li></li>
<li>세가지 유형의 결과
<ul>
<li>비지니스 결과 (Business Outcomes)
<ul>
<li>주로 재무적 지표 (매출 증가, 비용 절감)</li>
<li>대부분 후행 지표</li>
<li>ex) 90일 유지율, 한달 후 연장율</li>
</ul>
</li>
<li>제품 결과 (Product Outcomes)
<ul>
<li>제품이 비지니스를 전진시키는 정도</li>
<li>제품 결과는 제품 트리오가 통제할 수 있는 범위
<ul>
<li>비지니스 결과는 여러 부서의 협업이 필요</li>
<li>제품 결과는 제품 팀이 직접적으로 영향을 미칠 수 있는 지표</li>
</ul>
</li>
<li>ex) 개들이 사료를 좋아하게 하는 지표, 제품 자체 만족도나 관련 지표</li>
</ul>
</li>
<li>트랙션 지표 (Traction Metrics)
<ul>
<li>특정 기능이나 작업흐름에 대한 사용량 측정</li>
<li>트랙션 지표는 결과보다 더 한정적인 범위를 가지며, 종종 제품 결과 대신 특정 기능 활용도를 최적화하는데 사용
<ul>
<li>“개들이 사료를 좋아하도록 하는 것” 대신, “전환 캘린더 사용량 증가” 라는 트랙션 지표를 목표로 잡으면, 고객이 캘린더를 원하지 않는다면, 팀은 다른 해결책을 모색할 자유가 없다. 즉, 트랙션 지표를 결과처럼 설정하면 사실상 산출물(출력물)에 집착하는 셈</li>
</ul>
</li>
<li>주니어 팀 활용</li>
<li>성숙한 제품이라면, 이미 유용성이 입증된 기능의 최적화에 트랙션 지표 활용</li>
</ul>
</li>
</ul>
</li>
</ul>
<h3 id="결과는-양방향-협상의-산물이다">결과는 양방향 협상의 산물이다</h3>
<ul>
<li>팀의 결과 설정은 프로덕트 리더(C레벨, 팀/부서장)과 프로덕트 트리오 간의 양방향 협상이 되어야 한다.</li>
<li>프로덕트 리더
<ul>
<li>조직 전반의 시각을 제공, 비지니스 차원에서 지금 무엇이 가장 중요한지 전달</li>
<li>리더가 솔루션을 강제해서는 안된다.</li>
<li>대신, 트리오가 집중할 적절한 제품 결과를 제안해야 한다.
<ul>
<li>리더의 전략적 의도를 전달하는 좋은 방식
<ul>
<li>“개들이 사료를 더 좋아하게 만드는 것” -&gt; 그대로 집중 또는 비지니스 전략적 필요에 따라 세그먼트를 좁힐 수 있음</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>프로덕트 트리오
<ul>
<li>고객과 기술에 대한 지식을 바탕으로 주어진 기간 안에 해당 지표를 얼마나 개선할 수 있는지 현실적 제안 (이 시점에 어떤 솔루션을 만들지 결정할 필요 없음)
<ul>
<li>세그먼트가 있다면, 이전 히스토리를 파악하여 몇% 목표를 달성할 수 있을지</li>
</ul>
</li>
</ul>
</li>
<li>비즈니스가 더 큰 임팩트를 요구할 경우 팀은 더 야심찬 전략을 세워야 하며, 리더는 이러한 높은 목표가 더 큰 실패 가능성을 수반함을 이해</li>
<li>프로덕트 팀에 필요한 것
<ul>
<li>결과에 대한 전략 학습 시간</li>
<li>안정적으로 집중하는 팀 구조</li>
</ul>
</li>
<li>리더와 트리오가 협력해 결과를 설정하는 것은 조직적 지식을 최대한 활용하는 동시에, 팀이 목표 설정에 참여하게 함으로써 주도성과 성과를 높이는 효과
<ul>
<li>결과 설정에 참여한 팀이 그렇지 않은 팀보다 더 많은 주도성과 성과를 보임</li>
</ul>
</li>
</ul>
<h3 id="smart-목표가-필요한가">SMART 목표가 필요한가?</h3>
<ul>
<li>SMART
<ul>
<li>Specific (구체적)</li>
<li>Measurable (측정 가능한)</li>
<li>Achievable (달성 가능한)</li>
<li>Relavant/Realistic (현실적이고 관련된)</li>
<li>Time-bound (기한이 있는)</li>
<li><a href="https://www.tableau.com/ko-kr/learn/articles/smart-goals-criteria">https://www.tableau.com/ko-kr/learn/articles/smart-goals-criteria</a></li>
<li>‘구체적이고 도전적인 목표를 세운 팀은 그렇지 않은 팀보다 뛰어난 성과를 보인다. 도전적인 목표는 집중력을 강화하고, 노력과 지속성을 이끌어내며, 조직에 숨겨진 관련 지식을 이끌어낸다. 하지만 전제 조건도 있다. 팀은 목표 달성 가능성을 믿어야 하고, 목표에 몰입해야 하며, 진척도를 지속적으로 피드백받아야 한다. 이는 팀이 결과 정의에 참여해야 하고, 목표는 측정 가능해야 한다는 점을 뒷받침한다’</li>
</ul>
</li>
<li>SMART 목표의 효과성 연구 대부분이 단순한 과업에 기반
<ul>
<li>도전적인 목표는 팀이 이를 달성할 전략을 갖추지 못햇을 때 오히려 성과를 떨어뜨릴 수 있다.</li>
<li>적절한 전략이 식별되기 전에는 성과 목표 대신 학습 목표를 설정하는 것이 더 효과적일 수 있다.
<ul>
<li>새로운 결과에 직면한 프로덕트 트리오가 먼저 학습 목표부터 시작해야한다는 점을 시사
<ul>
<li>ex) 학습 목표: ‘참여를 높일 수 있는 기회를 발견하기’, 성과 목표: ‘참여율 10% 증가’</li>
<li>-&gt; 결과를 측정하는 최적의 방법을 모를때 여기서부터 시작</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>처음부터 완벽한 지표를 정의하려고 애쓰기보다 우선 고객 이탈 원인을 파악하고, 그 후에 결과 지표를 조정하는 접근이 더 효과적
<ul>
<li>익숙한 결과 지표를 다룰때 SMART는 여전히 유용하며, 상황에 따라 먼저 학습 목표 설정 후, SMART 성과 목표로 발전시켜 나가는 것도 좋은 방법</li>
</ul>
</li>
</ul>
<h3 id="프로덕트-트리오를-위한-가이드">프로덕트 트리오를 위한 가이드</h3>
<ul>
<li>프로덕트 트리오의 결과 설정 상황
<ul>
<li>아예 결과 없이 산출물만 전달하라는 요청을 받는 경우(가장 흔함)</li>
<li>프로덕트 리더가 팀의 의견 없이 결과를 정해주는 경우</li>
<li>프로덕트 트리오가 리더 의견 없이 독자적으로 결과를 정하는 경우</li>
<li>이 장에서 설명한 대로 프로덕트 리더와 트리오가 결과를 협상하는 경우</li>
</ul>
</li>
<li>이런 상황을 위한 Tip
<ul>
<li>아예 결과 없이 산출물만 전달하라는 요청을 받는 경우(가장 흔함)
<ul>
<li>프로덕트 리더가 새로운 솔루션을 지시할 때, 비즈니스 맥락에 대해 더 물어본다.</li>
<li>이 솔루션의 대상 고객은 누구인가?</li>
<li>이 솔루션으로 달성하려는 비즈니스 결과는 무엇인가?</li>
<li>왜 이 솔루션이 해당 결과를 이끌 것이라 생각하는가? (왜라는 질문은 리더에 따라 방어적으로 느낄 수 있으니 주의)</li>
<li>이 비즈니스 결과와 연결될 수 있는 제품 결과가 있는지 점검하라. 해당 솔루션이 어떤 제품 결과를 개선하며, 그 제품 결과가 비즈니스 결과의 선행 지표로 작용하는지 확인해보자.</li>
</ul>
</li>
<li>프로덕트 리더가 팀의 의견 없이 결과를 정해주는 경우
<ul>
<li>비즈니스 결과를 요구받았다면, 그 결과를 이끌어낼 수 있는 제품 결과를 제안하고 리더에게 피드백을 구하자.</li>
<li>제품 결과를 요구받았다면, 비즈니스 맥락을 더 물어보자. “우리가 이 제품 결과로 달성하려는 비즈니스 결과는 무엇인가요?”와 같이 묻는다.</li>
<li>양측이 합의된 기간 안에 어느 정도 성과를 낼 수 있을지 명확히 전달하자.</li>
</ul>
</li>
<li>프로덕트 트리오가 리더 의견 없이 독자적으로 결과를 정하는 경우
<ul>
<li>결과를 정하기 전 프로덕트 리더에게 비즈니스 맥락을 더 물어본다.</li>
<li>지금 비즈니스에 가장 중요한 것은 무엇인가? 이 대화를 비즈니스 결과 관점에서 진행해보자.</li>
<li>다른 고객 세그먼트보다 중요도가 높은 세그먼트가 있는가?</li>
<li>우리가 알아야 할 전략적 이니셔티브가 있는가?</li>
<li>이 정보를 토대로 가장 중요한 비즈니스 결과와 이를 뒷받침할 제품 결과를 매핑하고 리더의 피드백을 받는다.</li>
<li>팀이 가장 크게 기여할 수 있는 제품 결과를 선택한다.</li>
</ul>
</li>
</ul>
</li>
<li>유의사항
<ul>
<li>팀은 비즈니스 결과나 트랙션 지표가 아니라, 제품 결과를 받고 있는가?</li>
<li>트랙션 지표를 할당받았다면, 그 지표가 고객이 원하는 행동을 반영하는지, 이미 검증되었는지 확인하자.</li>
<li>새로운 지표를 처음 다루는 경우라면, 도전적인 성과 목표 전에 학습 목표를 먼저 설정하는 게 어떨까?</li>
<li>해당 지표에 대한 경험이 있다면, 구체적이고 도전적인 목표를 설정했는지 확인하자</li>
</ul>
</li>
</ul>
<h3 id="흔한-안티-패턴-피하기">흔한 안티 패턴 피하기</h3>
<ul>
<li>너무 많은 결과를 한 번에 추구하기
<ul>
<li>한 번에 하나의 결과에 집중하기</li>
</ul>
</li>
<li>결과 사이를 핑퐁하듯 왔다갔다 하기
<ul>
<li>하나의 결과에 장기간 집중하기</li>
</ul>
</li>
<li>프로덕트 트리오가 아닌 개인별 결과 설정
<ul>
<li>포지션별 다른 목표 X -&gt; 목표는 팀 단위로 설정</li>
</ul>
</li>
<li>산출물을 결과로 설정하기
<ul>
<li>의도는 결과인데 산출물을 결과로 착각하는 경우가 많음</li>
<li>숫자로 표현한다고 해서 결과가 되는게 아님
<ul>
<li>숫자 표현이 의무도 아니고 숫자 표현이 무조건 참도 아님</li>
<li>플랫폼상의 강좌 리뷰 수 증가x -&gt; 리뷰가 포함된 강좌 조회 수 증가</li>
</ul>
</li>
</ul>
</li>
<li>한 가지 결과에만 집중하고 나머지를 무시하기
<ul>
<li>웰스 파고 사례</li>
<li>주 목표 외에 Health Metric 모니터링 필요</li>
<li>고객 획득에 집중한다면, 동시에 고객 만족도 지표를 감시</li>
</ul>
</li>
</ul>
<h2 id="discovering-oppotunities">Discovering Oppotunities</h2>
<ul>
<li>고객에 대해 현재 알고 있는 바를 시각화한 경험 지도(Experience Map)를 만든다. (4장)</li>
<li>경험 지도에 따라 고객 인터뷰를 진행하고, 각 인터뷰에서 얻은 통찰을 인터뷰 스냅샷(Interview Snapshot)에 기록한다. (5장)</li>
<li>발견한 기회들을 기회-솔루션 트리(Opportunity Solution Tree)에 구조화하고, 이 트리를 활용해 기회 공간을 평가하고 우선순위를 정한다. (6장, 7장)</li>
</ul> </article> <hr> <a href="https://github.com/satnaing/astro-paper/edit/main/src/data/blog/2025-03-continuous-discovery-outcomes.md" target="_blank" rel="noopener noreferrer"><svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path stroke="none" d="M0 0h24v24H0z" fill="none"></path><path d="M7 7h-1a2 2 0 0 0 -2 2v9a2 2 0 0 0 2 2h9a2 2 0 0 0 2 -2v-1"></path><path d="M20.385 6.585a2.1 2.1 0 0 0 -2.97 -2.97l-8.415 8.385v3h3l8.385 -8.415z"></path><path d="M16 5l3 3"></path></svg><span>Edit page</span></a> <ul> <li> <a href="/tags/product/" data-astro-transition-scope="astro-36ssibgs-2"> <svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path stroke="none" d="M0 0h24v24H0z" fill="none"></path><path d="M5 9l14 0"></path><path d="M5 15l14 0"></path><path d="M11 4l-4 16"></path><path d="M17 4l-4 16"></path></svg>
&nbsp;<span>product</span> </a> </li> </ul> <section aria-labelledby="related-posts-heading">  <ul> <li> <a href="/posts/2025-03-continuous-discovery-framework"> <span> 2. A Common Framework For Continuous Discovery </span> <span> Teresa Torres의 기회 솔루션 트리 개념을 정리하며 비즈니스 성과와 고객 기회를 연결하고 의사결정을 구조화하는 Continuous Discovery 프레임워크를 소개. Intro 비지니스 요구사항과 고객의 요구사항이 충돌 미국 웰스파고 은행은 크로스 셀링(cross... </span> </a> </li><li> <a href="/posts/2025-03-continuous-discovery-notes"> <span> 지속적인 제품 발견의 습관 (Continuous Discovery Habits - Discover Products that Create Customer Value and Business Value) - 정리중 (WIP) </span> <span> 지속적인 제품 발견의 습관 (Continuous Discovery Habits Discover Products that Create Customer Value and Business Value) 정리중 (WIP) Part 1 지속적인 제품 발견이란 무엇인가? 1. The What And... </span> </a> </li><li> <a href="/posts/2025-03-continuous-discovery-why"> <span> 1. The What And Why Of Continuous Discovery </span> <span> Continuous Discovery가 필요한 이유와 역사, 필수 마인드셋, 주간 고객 접점을 유지하는 실무 정의를 요약하고 프레임워크를 팀에 적용할 힌트도 메모했다. Intro 모든 제품 팀은 일련의 활동을 통해 무엇을 만들지 결정한 다음, 그것을 만들고 제공하기 위해 또 다른 일련의... </span> </a> </li> </ul> </section>    <hr>   </div></div>

flowkater's data;

flowkater

결과 중심 사고로 전환하는 방법을 바탕으로 비즈니스·제품·트랙션 지표 차이, 리더와 팀의 목표 협상, SMART·학습 목표 활용 시 주의점을 정리했다.

3. Focusing On Outcomes Over Outputs

댓글