고객 공감으로 구축
“필요는 발명의 어머니이다.” 이 속담은 인간 정신의 지울 수 없는 것과 타고난 발명 본능을 담고 있습니다. 옥스포드 영어 사전에 "무엇인가에 대한 필요가 필수일 때 그것을 얻거나 달성하는 방법을 찾아야 한다."고 설명된 바와 같이 발명에 대한 이러한 보편적인 진리를 부인하는 사람은 거의 없을 것입니다. 그러나 디지털 경제의 혁신 문서에 설명된 대로 클라우드 혁신은 발명과 채택 간의 균형이 필요합니다.
비유를 계속하자면 혁신은 더 커진 가족으로부터 나오는 것입니다. 고객 공감은 혁신의 자랑스러운 부모입니다. 혁신을 촉진하는 고객 공감 솔루션을 만들려면 고객이 중요한 문제를 해결하기 위해 다시 돌아오도록 하는 타당한 고객 요구가 필요합니다. 이러한 솔루션은 고객이 원하는 것 또는 변덕보다는 고객이 필요로 하는 것을 기반으로 합니다. 고객의 진정한 요구를 찾기 위해, 고객의 경험에 대한 공감과 깊은 이해로부터 시작합니다. 공감은 많은 엔지니어, 제품 관리자, 심지어 비즈니스 리더들에게 개발이 더딘 기술입니다. 다행히 클라우드 설계자 역할의 다양한 상호 작용과 빠른 속도는 이 기술을 육성합니다.
공감을 구축하는 방법은 무엇이며 고객 공감은 왜 중요할까요? 고객 공감은 고객의 경험을 이해하고 공유하는 데 도움이 됩니다. MVP(최소 실행 가능 제품)의 첫 번째 릴리스부터 시장급 솔루션의 일반 공급에 이르기까지 고객 공감은 더 나은 솔루션을 빌드하는 데 도움이 됩니다. 보다 중요한 것은 공감이 있으면 팀은 채택을 장려하는 솔루션을 발명하기 위한 더 나은 위치에 자리 잡을 수 있습니다. 디지털 경제에서 고객의 요구에 가장 기꺼이 공감할 수 있는 제품 팀들은 시장을 재정의하고 이끄는 더 나은 도구를 통해 밝은 미래를 구축할 수 있습니다.
고객 공감을 통해 생성할 가정 정의
가정을 정의하는 것은 계획의 기본 부분입니다. 더 많은 플랜을 세울수록 가정이 훌륭한 아이디어의 기초로 들어오는 것을 더 명확하게 볼 수 있습니다. 가정은 일반적으로 자기 공감의 산물입니다. 즉, 이 위치에 있었다면 무엇을 원했을까?라는 것이며 빌드 단계를 시작할 때 가정이 솔루션을 침해할 수 있는 기간을 최소화합니다. 또한 이 방법은 실제 고객과의 피드백 루프를 가속화하여 더 일찍 배우고 공감할 수 있는 기회를 촉진합니다.
주의
빌드할 내용을 올바르게 정의하는 것은 까다로울 수 있으며 몇 가지 연습이 필요합니다. 너무 빠르게 빌드하는 경우 고객의 요구 사항이 반영되지 않을 수 있습니다. 초기 고객 요구 사항 및 솔루션 요구 사항을 이해하는 데 너무 많은 시간을 할애하는 경우 빌드할 기회를 얻기도 전에 시장이 이를 충족할 수 있습니다. 두 시나리오 모두 학습 기회가 크게 지연되거나 줄어들 수 있습니다. 경우에 따라 데이터가 손상될 수도 있습니다.
역사상 가장 혁신적인 솔루션은 직관적인 믿음으로 시작되었습니다. 그 직감은 기존의 전문 지식과 직접적인 관찰 모두에서 나옵니다. 이러한 직관에 대한 신속한 테스트가 허용되기 때문에 빌드 단계부터 시작합니다. 거기에서 더 심도 있는 이해와 공감의 명확한 수준을 구축할 수 있습니다. 솔루션의 모든 반복 또는 릴리스에서 고객 공감을 보여주는 MVP 빌드에서 균형이 이루어집니다.
이러한 균형 조정 작업을 안정화하기 위해 다음 두 섹션에서는 공감을 구축하는 방법과 MVP 정의에 대한 개념을 설명합니다.
고객 중심 가설 정의
공감으로 구축하는 경우 이는 특정 고객의 필요를 보여 주는 정의된 가설을 기반으로 솔루션을 만드는 것을 의미합니다. 다음 단계는 공감으로 구축을 장려하는 가설을 수립합니다.
- 공감으로 구축할 때 고객은 항상 중심이 됩니다. 이 의도는 여러 형태로 나타날 수 있습니다. 고객 성향, 특정 가상 사용자 또는 해결하려는 문제에 놓인 고객의 사진을 참조할 수 있습니다. 또한 고객은 내부(직원 또는 파트너) 또는 외부(소비자 또는 비즈니스 고객)에 있을 수 있습니다. 이 정의는 테스트할 첫 번째 가설입니다. 이 특정 고객을 도울 수 있나요?
- 고객 환경을 이해합니다. 공감으로 구축한다는 것은 고객의 경험과 관련이 있고 고객의 과제를 이해할 수 있다는 것을 의미합니다. 이 사고방식은 테스트할 다음 가설을 나타냅니다. 이 특정 고객이 관리 가능한 과제에 도움을 줄 수 있나요?
- 단일 과제에 대한 명확한 솔루션을 정의합니다. 사람, 프로세스 및 실무 전문가의 전문 지식에 의존하면 잠재적인 솔루션으로 이어질 수 있습니다. 다음은 테스트할 전체 가설입니다. 제안된 솔루션을 통해 이 특정 고객이 관리 가능한 과제를 해결할 수 있도록 도울 수 있나요?
- 가치 설명에 도달합니다. 이러한 고객에게 어떤 장기적인 가치를 제공할 건가요? 이 질문에 대한 답변은 다음 전체 가설을 만듭니다. 이 관리 가능한 문제를 해결하기 위해 제안된 솔루션을 사용하여 이러한 고객의 삶을 어떻게 개선할 수 있을까요?
이 마지막 단계는 고객 공감 중심 가설의 절정입니다. 대상, 문제, 솔루션 및 메트릭을 이루어질 개선으로 정의하며, 이 모든 것의 중심에는 고객이 있습니다. 측정 및 학습 단계 중에 각 가설을 테스트해야 합니다. 팀이 해결 가능한 고객 기반에 대해 더 큰 공감을 하게 됨에 따라 고객, 문제 설명 또는 솔루션의 변경을 예상합니다.
주의
목표는 고객의 공감으로 구축하는 것이지 공감으로 계획하는 것이 아닙니다. 완벽한 고객 공감 설명에 도달하기 위해 계획과 조정의 끝없는 주기에 너무나 쉽게 갇힐 수 있습니다. 이러한 설명을 개발하기 전에 MVP 정의 및 빌드에 대한 다음 섹션을 검토합니다.
핵심 가정을 입증한 후 이후 반복은 공감 테스트에 추가적으로 성장 테스트에도 초점을 맞춥니다. 공감을 구축, 테스트 및 검증한 후에는 주소 지정 가능한 시장을 대규모로 이해하기 시작합니다. 앞에서 설명한 표준 가설 수식을 확장하여 해결 가능한 시장을 보다 깊이 이해할 수 있습니다. 그런 다음, 사용 가능한 데이터에 따라 총 시장(잠재 고객 수)의 크기를 예측합니다.
여기에서 유사한 문제를 겪고 있으며 따라서 솔루션에 관심이 있을 총 시장의 백분율을 추정합니다. 이제 해결 가능한 시장이 준비됩니다. 다음은 테스트할 가설입니다. 제안된 솔루션을 사용하여 관리 가능한 문제를 해결함으로써 고객의 삶에서 x%를 어떻게 개선할 수 있을까요? 고객의 작은 샘플링은 참여 고객의 풀에 대한 백분율 영향을 제안하는 선행 지표를 나타냅니다.
가설을 테스트하는 솔루션 정의
빌드-측정-학습 피드백 루프를 반복하는 동안 공감으로 구축하려는 시도는 MVP에 의해 정의됩니다.
MVP는 고객과 함께 학습할 수 있는 충분한 솔루션을 만드는 데 필요한 가장 작은 노력 단위(발명, 엔지니어링, 애플리케이션 개발 또는 데이터 아키텍처)입니다. 모든 MVP의 목표는 이전 가설의 일부 또는 전부를 테스트하고 고객으로부터 직접 피드백을 받는 것입니다. 출력은 업계를 변화시키는 데 필요한 모든 기능을 갖춘 아름다운 애플리케이션이 아닙니다. 각 반복의 원하는 산출은 학습 기회이며 가설을 더 깊이 테스트할 수 있는 기회입니다.
작업 일정은 제품에 군살이 없는 상태를 유지하도록 하는 표준 방법입니다. 예를 들어 개발 팀에서 신속한 테스트를 가능하게 만들기 위해 솔루션을 단일 반복으로 만들 수 있다고 생각해야 합니다. 속도, 반복 및 릴리스를 사용하여 최소한의 의미를 정의하는 방법을 더 잘 이해하려면 계획 속도, 반복, 릴리스 및 반복 경로를 참조하세요.
복잡성 감소 및 기술 급증 지연
혁신 방법론에 설명된 발명 분야는 성숙한 혁신 또는 즉시 스케일링 가능한 MVP 솔루션을 제공하는 데 종종 필요한 기능을 살펴봅니다. 이러한 분야를 기능 포함을 위한 장기 가이드로 사용합니다. 마찬가지로 솔루션에서 고객 가치와 공감을 조기에 테스트하는 동안 주의 가이드로 사용합니다.
기능 폭과 다양한 발명 분야를 단일 반복으로 만들 수 없습니다. 여러 분야의 복잡성을 포함하려면 MVP 솔루션에 대한 몇 번의 릴리스가 필요할 수 있습니다. 개발에 대한 투자에 따라 여러 분야 내에서 여러 병렬 팀이 작업하여 여러 가설을 테스트할 수 있습니다. 이러한 팀 간의 아키텍처 맞춤을 유지하는 것이 현명하지만 가치 가설의 유효성을 검사할 수 있을 때까지 복잡하고 통합된 솔루션을 빌드하는 것은 현명하지 않습니다.
기술 급증의 빈도 또는 볼륨에서 복잡성을 가장 잘 검색합니다. 기술 급증은 고객과 쉽게 테스트할 수 없는 기술 솔루션을 만들기 위한 노력입니다. 고객 가치와 고객 공감이 테스트되지 않은 경우 기술 급증은 혁신에 대한 위험을 나타내며 최소화되어야 합니다. 마이그레이션 작업에서 찾을 수 있는 완성도 높은 테스트 솔루션의 유형에 대해 채택 전체에서 기술 급증이 일반적일 수 있습니다. 그러나 혁신 노력의 가설 테스트를 지연시키고 가능하면 연기해야 합니다.
끊임없는 단순화 방법은 모든 MVP 정의에 도움이 됩니다. 이 방법은 가설의 유효성을 검사하는 기능을 지원하지 않는 모든 항목을 제거하는 것을 의미합니다. 복잡성을 최소화하려면 가설을 테스트하는 데 필요하지 않은 통합 및 기능 수를 줄여야 합니다.
MVP 빌드
각 반복에서 MVP 솔루션은 다양한 형태로 나타날 수 있습니다. 일반적인 요구 사항은 산출에서 가설을 측정하고 테스트할 수 있다는 것입니다. 이 간단한 요구 사항은 과학적 프로세스를 시작하고 팀이 공감으로 구축할 수 있도록 합니다. 이 고객 우선 핵심을 제공하기 위해 초기 MVP는 발명 분야 중 하나에만 의존할 수 있습니다.
경우에 따라 가장 빠른 혁신 경로는 클라우드 채택 팀이 가설이 정확하게 검증되었다고 확신할 때까지 이러한 분야를 일시적으로 피하는 것을 의미합니다. Microsoft와 같은 기술 회사에서 제공되는 이 지침은 직관적이지 않을 수 있습니다. 그러나 이는 단순히 특정 기술 결정이 아닌 MVP 솔루션에서 가장 높은 우선 순위인 고객의 요구 사항을 강조합니다.
일반적으로 MVP 솔루션은 최소한의 기능과 제한된 특징을 가진 애플리케이션 또는 데이터 솔루션으로 구성됩니다. 전문 개발 전문 지식이 있는 조직의 경우 이 경로는 학습 및 반복에 가장 빠른 경로인 경우가 많습니다. 다음 목록에는 팀이 MVP를 빌드하기 위해 수행할 수 있는 몇 가지 다른 방법이 포함되어 있습니다.
- 시간의 99%가 잘못되었지만 원하는 특정 결과를 보여 주는 예측 알고리즘입니다.
- 프로덕션 규모에서 안전하게 통신하지는 않지만 프로세스 내에서 거의 실시간 데이터의 가치를 보여 주는 IoT 디바이스입니다.
- 가설을 테스트하거나 소규모 요구 사항을 충족하기 위해 시민 개발자가 빌드한 애플리케이션입니다.
- 따라야 할 애플리케이션의 이점을 다시 만드는 수동 프로세스입니다.
- 고객이 상호 작용할 수 있을 만큼 자세히 설명된 와이어프레임 또는 비디오입니다.
MVP를 개발에는 엄청난 수준의 개발 투자가 필요하지 않습니다. 한 번에 테스트되는 가설의 수를 최소화하기 위해 최대한 투자를 제한해야 합니다. 그런 다음, 각 반복 및 각 릴리스에서 여러 발명 분야를 나타내는 즉시 스케일링 가능한 솔루션으로 솔루션을 의도적으로 개선합니다.
MVP 개발 가속화
시장 출시 시간은 혁신의 성공에 매우 중요합니다. 릴리스 속도가 빨라질수록 학습 속도가 빨라집니다. 더 빠른 학습은 더 빠르게 확장할 수 있는 제품으로 이어집니다. 때때로 기존의 애플리케이션 개발 주기로 인해 이 프로세스가 느려질 수 있습니다. 혁신은 사용 가능한 전문 지식에 대한 제한에 의해 제약을 받게 됩니다. 예산, 인원 및 직원 가용성은 모두 팀이 처리할 수 있는 새로운 혁신의 수에 대한 제한을 만들 수 있습니다.
인력 제약 조건과 공감으로 구축하려는 욕구는 시민 개발자를 향한 급속한 성장 추세를 낳았습니다. 이러한 개발자는 위험을 줄이고 조직의 전문 개발 커뮤니티 내에서 규모를 제공합니다. 시민 개발자는 고객 경험의 실무 전문가이지만 엔지니어로 교육을 받지는 않았습니다. 이러한 개인은 프로토타이핑 도구 또는 전문 개발자가 눈살을 찌푸리게 할 수 있는 가벼운 개발 도구를 사용합니다. 이러한 비즈니스 정렬 개발자는 MVP 솔루션을 만들고 이론을 테스트합니다. 잘 정렬된 경우 이 프로세스는 가치를 제공하지만 충분히 효과적인 스케일링 가설은 통과하지 못하는 프로덕션 솔루션을 만듭니다. 팀은 스케일링 작업이 시작되기 전에 솔루션을 사용하여 프로토타입의 유효성을 검사할 수도 있습니다.
혁신 계획 내에서 클라우드 채택 팀은 시민 개발자 노력을 포함하도록 포트폴리오를 다양화해야 합니다. 개발 작업을 스케일링하면 투자 감소로 더 많은 가설을 형성하고 테스트할 수 있습니다. 가설의 유효성을 검사하고 해결 가능한 시장을 식별하면 전문 개발자는 최신 개발 도구를 사용하여 솔루션을 강화하고 스케일링할 수 있습니다.
최종 빌드 관문: 고객 고충
고객 공감이 강한 경우 기존 문제를 쉽게 식별할 수 있어야 한다는 것은 명확합니다. 고객의 고충은 분명해야 합니다. 빌드하는 동안 클라우드 채택 팀은 고객의 고충 지점을 기반으로 가설을 테스트하는 솔루션 작업을 진행하고 있습니다. 가설이 잘 정의되어 있지만 고충 지점이 아닌 경우 솔루션은 진정으로 고객의 공감을 기반으로 하지 않는 것입니다. 이 시나리오에서는 빌드가 올바른 시작점이 아닙니다. 대신 실제 고객의 공감과 학습을 구축하는 데 먼저 투자합니다. 공감을 구축하고 고충을 검증하는 가장 좋은 방법은 간단합니다. 고객의 의견을 경청해야 합니다. 자주 발생하는 고충을 파악할 수 있게 될 때까지 시간을 투자하여 그들과 만나고 관찰합니다. 고객 고충 지점을 잘 이해하면 그 고충을 해결하기 위한 가설 솔루션을 테스트할 준비가 된 것입니다.
이 방법을 적용하지 않을 경우
대체 방법을 필요로 할 수 있는 많은 법률, 규정 준수 및 업계 요구 사항이 있습니다. 개발 솔루션의 퍼블릭 릴리스인 경우 이 방법이 적합하지 않을 수 있습니다.
- 특허 타이밍, 지적 재산권 보호 또는 고객 데이터 유출에 대한 위험 만들기
- 설정된 규정 준수 요구 사항 위반
이런 위험이 인식되면 릴리스 관리에 대한 단계별 접근 방식을 채택하기 전에 법률 자문을 구해야 합니다.
참조
이 문서의 개념 중 일부는 Eric Ries가 The Lean Startup에서 설명한 아이디어를 기반으로 합니다.
다음 단계
MVP 솔루션을 빌드한 후에는 공감 가치와 규모 가치를 측정할 수 있습니다. 고객 영향을 측정하는 방법을 알아봅니다.