<div id="readability-page-1" class="page"><article id="article"> <h3 id="intro">Intro</h3>
<ul>
<li>모든 제품 팀은 일련의 활동을 통해 무엇을 만들지 결정한 다음, 그것을 만들고 제공하기 위해 또 다른 일련의 활동을 수행
<ul>
<li>무엇을 build 할지 결정하는 작업을 <strong>Discovery (발견)</strong></li>
<li>제품을 build 하고 출시하는 작업을 <strong>Delivery (배송)</strong></li>
</ul>
</li>
<li>많은 회사들이 약속한 시간과 예산에 맞춰 제품을 Delivery(배송)했는지 여부에 초점을 맞추는 반면, 제대로 build 했는지 평가하는 것을 잊고 Discovery(발견)에 대한 투자는 소홀. 이러한 불균형을 바로잡는 것을 목표</li>
<li>Discovery 는 1회성 활동이 아니다.
<ul>
<li>디지털 제품은 절대 완성되지 않는다.</li>
<li>계속 진화할 수 있고 진화해야 한다.</li>
<li>=&gt; 이 책에서는 팀이 새로운 제품을 발견하고 기존 제품을 반복적으로 개선할 수 있는 Continuous Discovery (지속적인 발견) 프레임워크를 소개</li>
</ul>
</li>
</ul>
<h3 id="the-evolution-of-modern-product-discovery">The Evolution of Modern Product Discovery</h3>
<ul>
<li>역사
<ul>
<li>초창기
<ul>
<li>소프트웨어 초창기에는 비지니스 리더가 발견을 주도하여 무엇을 build 할지 결정</li>
<li>Discovery 는 1년에 한 번씩 연간 예산 프로세스에서 이루어졌으며, 일정이 정해진 프로젝트가 특정 엔지니어링 팀에 할당</li>
<li>Product Manager 가 작업, 예산, 일정만을 관리 (때론 비지니스 요구 사항을 제품 요구 사항으로 전환하기 했지만..)</li>
<li>소프트웨어 개발은 예측 불가 (예산 초과 기한 초과)</li>
<li>비지니스 요구사항이 고객의 요구사항보다 우선시되는 경우가 많음</li>
<li>제품이 출시된 후에야 고객이 자신이 만든 제품에 만족하지 않는다는 사실을 인지 =&gt; 많은 비용의 낭비</li>
<li>=&gt; 이런 유형의 팀이 <strong>Delivery 팀 (배달 팀)</strong></li>
</ul>
</li>
<li>애자일 선언문 시대
<ul>
<li>애자일에서 강조되는 4가지 원칙
<ul>
<li><strong>짧은 주기와 빈번한 고객 피드백</strong></li>
<li><strong>지속적으로 유지할 수 있는 속도로 작업</strong></li>
<li><strong>고객 피드백에 빠르고 쉽게 적응할 수 있는 유연성 극대화</strong></li>
<li><strong>단순함 추구</strong> (극도로 최소한의 것만 개발)</li>
</ul>
</li>
<li>스크럼/칸반 도입, 고객 피드백(UX, 유저 리서치) 강조 =&gt; 그럼에도 문제 발생
<ul>
<li>주기가 짧아지고 고객 피드백이 많아져도 원래의 아이디어를 고수</li>
<li>예측불가능한 작업을 예측하지 못함</li>
<li>스프린트가 지속적인 속도를 찾지 못하게함 (격주 스프린트?)</li>
<li>나머지 비지니스가 바뀌지 않기 때문에 유연성이 없고 (제품 팀만 바뀐다고 되지 않음)
<ul>
<li>작동하지 않는다는 사실을 알게 되더라도 예산 범위 내에서 제시간에 맞춰 제공</li>
<li>사용성 테스트는 종종 프로세스 후반부에 너무 늦게 진행되어 발견한 중요한 문제를 해결하기에는 이미 너무 늦었을때가 많음</li>
</ul>
</li>
<li><strong>팀은 계속 누가 사용했는지, 고객이나 비지니스에 어떤 가치를 창출했는지 여부가 아니라 여전히 무엇을 제공했는지에 따라 평가 받음</strong></li>
</ul>
</li>
</ul>
</li>
<li>그럼에도 불구하고
<ul>
<li>배포 주기가 단축 됨</li>
<li>프로덕트를 더 잘 측정할 수 있게 됨</li>
<li>사용성 테스트를 더 잘하게 됨</li>
<li>작은 솔루션 -&gt; 큰 솔루션 반복하는 걸 잘하게 됨</li>
</ul>
</li>
<li>그럼에도 불구하고22
<ul>
<li>여전히 <strong>무엇을 build 할지 결정하는 데는 어려움</strong>을 겪었음</li>
</ul>
</li>
<li>그래도 더 잘 측정하게 되면서 이러한 문제를 훨씬 더 심각하게 인식하게 됨</li>
</ul>
</li>
<li>무엇을 만들지(build) 결정하는 것
<ul>
<li>비지니스 이해관계자에서 프로덕트 매니저로, 프로덕트 매니저에서 제품 팀 전체로.</li>
<li>Discovery 과정 전반에 걸쳐 고객을 참여
<ul>
<li>Discovery 가 끝날 때 아이디어를 검증하는 대신 처음부터 고객과 공동 창작</li>
<li>Delivery Cycle 이 짧아지면서 Discovery Cycle 도 짧아짐</li>
</ul>
</li>
<li>Continuous Discovery</li>
</ul>
</li>
</ul>
<h4 id="이-책의-대상">이 책의 대상</h4>
<ul>
<li>“PM, 디자이너, 개발자”(product people) 제품 “<strong>트리오</strong>”가 대상임</li>
<li><img src="https://i.imgur.com/KFjcNEn.png" alt=""></li>
<li>최소한의 Discovery 를 위해 “트리오”가 필요. 그 이상을 포함시킬 수 있으나 그에 대한 대가가 따름 (속도, 의사결정 균형 등)</li>
</ul>
<h4 id="필수-마인드셋">필수 마인드셋</h4>
<ul>
<li>많은 팀이 프레임워크, 도구, 방법론을 쫓으며 새로운 혁신이 갑자기 제품 성공의 문을 열어줄 것이라고 기대하지만, 결국 이러한 것들은 <strong>마인드셋이 동반</strong>되지 않으면 안된다.</li>
<li>여섯가지 사고 방식
<ul>
<li>
<ol>
<li>Outcome-oriented (결과 지향적)</li>
</ol>
<ul>
<li>결과물보다는 결과 중심 (마인드셋이자 습관이어야 함)</li>
<li>출시하는 솔루션으로 성공을 정의하기보다 솔루션이 고객과 비지니스에 창출하는 가치로 성공을 정의
<ul>
<li>고객의 삶에 미친 영향, 비지니스의 지속 가능성과 성장에 미친 영향 등 Impact 로 성공을 측정</li>
</ul>
</li>
</ul>
</li>
<li>
<ol start="2">
<li>Customer-centric (고객 중심)</li>
</ol>
<ul>
<li>고객을 세상의 중심에 두는 것</li>
<li>비지니스의 목적은 고객을 창출하고 고객에게 서비스를 제공하는 것
<ul>
<li>고객의 요구를 비지니스 요구와 동등한 수준으로 끌어올려 고객 가치 창출에 집중 (비지니스 가치 뿐만 아니라)</li>
</ul>
</li>
</ul>
</li>
<li>
<ol start="3">
<li>Collaborative (협업)</li>
</ol>
<ul>
<li>Digital Product 의 Cross-functional 한 특성을 이해하고 분업화되어 단계별로 결과물을 전달하는 사일로화된 모델을 거부 (PM이 결정하고 디자이너가 디자인하고 엔지니어가 코딩 X)
<ul>
<li>-&gt; 각자가 가진 전문성과 지식을 활용하면서 팀이 함께 의사 결정을 내리는 모델을 받아들여야함</li>
</ul>
</li>
</ul>
</li>
<li>
<ol start="4">
<li>Visual (시각)</li>
</ol>
<ul>
<li>말과 글이 아닌 시각화가 필요.
<ul>
<li>이 책에 소개된 습관은 그림을 그리고, 생각을 외부화하며, 아는 것을 매핑 (스토리 매핑?)</li>
</ul>
</li>
<li>공간적 추론 능력을 활용하는 습관을 가져야 한다.</li>
</ul>
</li>
<li>
<ol start="5">
<li>Experimental (실험적 사고)</li>
</ol>
<ul>
<li>Discovery 를 잘하려면 가정을 확인하고 증거를 수집하는 과학자처럼 사고하는 법을 배워야함</li>
</ul>
</li>
<li>
<ol start="6">
<li>Continuous (지속성)</li>
</ol>
<ul>
<li>Discovery 를 프로젝트 초반에 하는 일로 생각하지 않고 개발 프로세스 전반에 걸쳐 지속적으로 Discovery 해야함 (구체적인 내용은 뒤 챕터에서)</li>
</ul>
</li>
</ul>
</li>
</ul>
<h4 id="continuous-discovery-의-실무적-정의-working-definition">Continuous Discovery 의 실무적 정의 (Working Definition)</h4>
<ul>
<li>
<p>이미 많은 제품 팀에서 <a href="/posts/2019-12-lean-customer-questions">린 고객 개발을 위한 고객 인터뷰 기본 질문 5가지</a>, 고객 인터뷰, 사용자 테스트, A/B 테스트 를 채택하고 있다.</p>
</li>
<li>
<p>그러나, 이러한 Discovery 활동들을 <strong>체계적이고 지속 가능한 방식</strong>으로 채택하여 제품 결정에 지속적으로 반영하는 팀은 드물다 (고객의 의견을)</p>
</li>
<li>
<p>단순히 Discovery 가 아닌 Continuous Discovery 란?</p>
<blockquote>
<p>고객과 최소 주 1회 접점 (At a minimum, weekly touchpoints with customers)
제품을 개발하는 팀이 주도하여 (By the team building the product)
소규모 리서치 활동을 수행하며 (Where they conduct small research activities)
목표한 결과를 달성하기 위해 노력한다. (In pursuit of a desired outcome)</p>
</blockquote>
</li>
<li>
<p>제품 팀은 매일 의사 결정을 내린다 -&gt; 일상적인 의사 결정에서 최대한 많은 고객 의견을 반영하는 것이 Continuous Discovery 이다.</p>
<ul>
<li>제품 팀이 한 달에 한 번만 고객과 소통한다면, 그 사이 한 달 동안의 의사결정은 고객의 의견 없이 이루어지게 되는 것</li>
</ul>
</li>
</ul>
<hr>
<p><a href="/posts/2025-03-continuous-discovery-framework">2. A Common Framework For Continuous Discovery</a></p> </article></div>

flowkater's data;

flowkater

Continuous Discovery가 필요한 이유와 역사, 필수 마인드셋, 주간 고객 접점을 유지하는 실무 정의를 요약하고 프레임워크를 팀에 적용할 힌트도 메모했다.

1. The What And Why Of Continuous Discovery

댓글