PM Hazel Blog
  • 🌈by Hazel
  • ☀️Product Manager
    • PM, 제품팀, 로드맵
    • PM이 하는 일
  • 🗓️Torn Calendar
    • QAing 큐에잉
      • 프롤로그
      • 정말 이렇게 QA하는 게 최선인 건가?
      • QA 담당자가 생각하게 하지마!
      • 리드 제너레이션을 하는 방법
      • 만들기만 하면 돼!라는 착각
      • 유료화는 언제 해야할까?
      • 피봇을 결심하는 순간
      • 진짜 프리세일즈를 해보자
      • 언제 서비스를 접어야 하는가
      • 큐에잉이 안된 이유 3가지
      • 에필로그
    • 드라마 조연출이 하는 일
    • 0으로 돌아가기로 했습니다
  • 💡Sophia
    • 서양철학사
      • 왜 서양철학사인가
      • 고대철학
      • 밀레투스학파
      • 피타고라스학파
      • 엘레아학파
      • 다원론자
      • 소피스트
      • 소크라테스
      • 플라톤
      • 아리스토텔레스
    • Mission, Vision&Goals, Strategy
    • 오이디푸스 왕
    • 바코스의 여신도들
    • 진화론 시작하기
  • 📚book
    • 탁월한 사유의 시선
      • 1강 | 부정 否定 - 버리다
    • 아이디어 불패의 법칙
      • 1부 | 불변의 사실
    • 인스파이어드
      • Part 1 | 최고의 기술 기업에서 배운 것
      • Part 2 | 사람
      • Part 3 | 제품
      • Part 3 | 프로세스
        • 제품 발견 구조화 기법
        • 제품 발견 계획 기법
        • 아이디어 발상 기법
        • 프로토타이핑 기법
        • 제품 발견 테스트 기법
          • 사용성 테스트
          • 가치 테스트
          • 실현 가능성 테스트
          • 사업 유효성 테스트
          • 사용자 테스트 vs 제품 데모 vs 워크스루
        • 변화 기법
      • Part 4 | 문화
    • 승려와 수수께끼
    • 죽음의 수용소에서
      • 제1부 | 강제 수용소에서의 체험
      • 제2부 | 로고테라피의 기본 개념
    • The Mom Test
      • 1장 | The Mom Test
      • 2장 | 잘못된 데이터 피하기
      • 3장 | 중요한 질문을 하기
      • 4장 | 편안한 분위기 유지하기
      • 5장 | 고객의 실제 관심과 구매 의향 확인하기
      • 6장 | 고객과의 대화 기회 찾기
      • 7장 | 올바른 고객을 선택하는 법
      • 8장 | 대화에서 배운 것을 실행으로 옮기기
      • 결론 | 더 나은 고객 대화를 위한 원칙
    • 스틱!
      • 1. 단순성
      • 2. 의외성
      • 3. 구체성
      • 4. 신뢰성
      • 5. 감성
      • 6. 스토리
    • 회복탄력성
    • 왜 일하는가?
      • 1장 | 왜 일하는가
      • 2장 | 일을 사랑하는가
      • 3장 | 무엇을 꿈꾸는가
      • 4장 | 노력을 지속하는가
      • 5장 | 현재에 만족하는가
      • 6장 | 창조적으로 일하는가
    • 그릿
      • 1장 | 그릿, 성공의 필요조건
      • 2장 | 그릿을 기르는 법
      • 3장 | 그릿을 키워주는 법
Powered by GitBook
On this page
  • 원칙
  • 실현 가능성(feasibility) 프로토타입
  • 사용자 프로토타입
  • 라이브 데이터 프로토타입
  • 혼합 프로토타입
  1. book
  2. 인스파이어드
  3. Part 3 | 프로세스

프로토타이핑 기법

버리기 위해 계획하라. 어쨌든 결국 그렇게 될 것이다. (Plan to throw away; you will, anyhow)

-프레드 브룩스

프로토타입에는 수많은 다른 형태들이 있고, 각각은 차별화된 특징이 있으며, 각기 다른 것들을 테스트하기 위해 맞추어져 있다. 즉시 해결해야 하는 업무에 대해 잘못된 유형의 프로토타입을 사용하면 큰 문제를 겪을 수 있다. 다양한 프로토타입 기법 중에서 현재 다루고 있는 위헙과 제품의 유형에 맞게 선택하는 것이 중요하다.

원칙

  1. 어떤 형태의 프로토타입이건 가장 중요한 목적은 실제 제품을 만드는 것보다 시간과 노력의 측면에서 훨씬 더 적은 비용으로 학습하는 것이다.

  2. 모든 프로토타입의 핵심적인 장점은 단순히 대화하거나 적는 것보다 훨씬 더 깊은 수준으로 문제에 대해 생각할 수 있도록 해준다는 것이다.

  3. 프로토타입은 팀 협업에 매우 강력한 도구다. 공동의 이해를 발전시키기 위해 프로토타입을 함께 체험할 수 있다.

  4. 충실도의 단계에 따라 매우 다양한 수준의 프로토타입이 있다. 충실도는 프로토타입이 얼마나 실제와 같은 모습인지를 말한다. 의도한 목적에 맞는 올바른 수준의 충실도를 만드는 것이 원칙이다.

  5. 프로토타입의 주요한 목적은 제품 발견 단계에서 하나 혹은 그 이상의 제품 위험(가치, 사용성, 실현 가능성, 유효성)을 해결하기 위해서다. 거기에 더불어 조직 전체에 무엇이 만들어져야 하는지 효과적으로 커뮤니케이션하는데 도움이 된다.

실현 가능성(feasibility) 프로토타입

일반적으로는 실현 가능성에 대해 우려할 상황이 적으나, 특정 문제를 해결하던 중 실현 가능성 위험이 포함되는 경우가 있다.

  • 알고리즘/성능/확장성/내고장성에 대한 우려

  • 사용해본 적 없는 기술/제 삼자의 컴포넌트나 서비스/기존 시스템 이용

  • 다른 팀이 새롭게 만든 것 또는 관련 변경사항에 의존

실제 전형적인 코드 작업이므로 엔지니어가 프로토타입을 제작한다. 이는 상업적으로 출시 가능한 제품과는 거리가 멀며, 실현 가능성 위험을 완화하려는 목적에 필요한 수준의 코드를 작성해야 한다.

의도적으로 버려지는 코드로, 데이터를 수집하는 목적으로 충분하다. 실현 가능성 프로토타입을 만드는 데 걸리는 시간의 추정은 엔지니어가 제공하지만 팀이 그 시간을 실제로 사용할지 여부는 프로토타입을 수행할 만한 가치가 있는지에 대한 제품 관리자의 결정에 의존한다. 이러한 실현 가능성 프로토타이핑 업무를 실제로 하는 사람이 엔지니어이긴 하지만, 그것은 제품 실행 업무가 아닌 제품 발견 업무로 간주한다. 이 접근 방법 또는 아이디어를 계속 진행할지 말지에 대한 결정으로 일은 끝이다.

사용자 프로토타입

일종의 시뮬레이션으로 폭 넓은 종류가 있다.

스펙트럼의 한 끝은 낮은 충실도의 사용자 프로토타입이다. 기본적으로 상호작용이 가능한 와이어프레임 형태이기 때문에 시각 디자인이나 실제 데이터가 만들어 내는 차이 등의 영향을 전혀 활용할 수 없다.

다른 끝에는 높은 충실도의 사용자 프로토타입이 있다. 실제 제품처럼 보이고 느껴지지만 라이브 데이터는 아니다. 만약 검색 결과의 연관성에 대해 테스트를 하고 있다면 프로토타입은 적절하지 않다. 하지만 전반적인 쇼핑 경험이나 사람들이 원하는 물건을 찾는 방법에 대해 알아내고자 한다면 적합한 도구가 될 것이다.

사용자 프로토타입의 주요한 한계점은 그것이 무언가를 증명해주지 않는다는 점이다. 당신의 제품이 팔릴지 팔리지 않을지와 같은 문제를 증명할 수는 없다.

라이브 데이터 프로토타입

가끔 제품 발견 단계에서 확인된 중요한 위험에 대응하기 위해 실제 사용자의 데이터를 수집할 수 있어야 한다. 하지만 확장할 수 있고 출시 가능한 실제 제품을 만드는 시간과 비용을 사용하기 이전에 제품 발견 단계를 진행하면서 이러한 증거를 수집해야 한다.

제한된 양의 트래픽을 보낼 수 있고, 라이브 데이터 프로토타입이 어덯게 사용되었는지에 대한 분석 데이터를 수집하는 것이 핵심이다. 실제 사용자들이 라이브 데이터 프로토타입을 현실 세계의 작업에 사용했고, 이를 통해 실제 분석 데이터를 만들어 내고, 기존의 제품 또는 기대 수준과의 비교를 할 수 있게 된다. 새로운 시도가 과연 더 나은 성과를 내는지 확인할 수 있는 것이다.

주로 게임 역학, 검색 결과의 연관성, 다양한 소셜 기능, 제품 퍼널 작업 등에 적용한다. 라이브 데이터 프로토타입은 최종적인 제품보다 훨씬 더 적은 수준으로 구현되며, 품질/성능/기능성에 대한 기준이 현저하게 낮다. 다음의 두 가지 제약사항을 고려해야 한다.

  1. 이것은 코드이므로 엔지니어가 제작해야만 한다.

  2. 이것은 상업적으로 출시 가능한 제품이 아니다. 이것으로 사업을 진행할 수는 없다. 라이브 데이터가 잘 수행되어서 제품화를 하기로 했다면 충분한 시간을 엔지니어에게 제공해줘야 한다.

혼합 프로토타입

세 가지 프로토타입의 범주로 대부분 상황에 잘 활용할 수 있지만 폭넓고 다양한 조합의 혼합 프로토타입 또한 가능하다. 주로 사용하는 것은 오즈의 마법사 프로토타입으로, 높은 충실도 사용자 프로토타입의 프론트엔드 사용자 경험을 활용하되, 보이지 않는 곳에서 실제 사람이 수동으로 조정하는 것을 말한다.

오즈의 마법사 프로토타입은 확장 가능성이 전혀 없으며, 유의미한 양의 트래픽을 보내지도 않지만, 제품팀 관점에서 매우 빠르고 쉽게 만들 수 있으며 사용자 측면에서는 실제 제품처럼 보이고 작동한다는 것이 장점이다.

실시간 채팅 응대 서비스를 제공하고 있다고 해보자. 이 서비스는 고객 서비스 직원이 사무실에 있는 동안에만 가능하다. 하지만 고객은 전 세계에서 언제든 제품을 사용하고 있으므로 언제든지 도움이 되는 답변을 제공할 수 있는 자동화된 채팅 기반의 시스템을 개발하고 싶다.

이때 제품팀은 어떤 유형의 질문들을 일상적으롭 다고 어떻게 그들이 대답하는지에 대한 이야기를 고객 서비스 직원과 먼저 이야기해보고 이러한 자동화에 대한 문제에 해결방안을 찾을 것이다.

이때 한 가지 방법은 간단한 채팅 기반의 인터페이스를 제공하는 오즈의 마법사 프로토타입을 제작해서 매우 빠르게 학습하고, 몇 가지 접근 방법을 테스트해보는 것이다. 실제로는 PM 또는 CS팀의 멤버가 숨어서 고객의 요청을 확인하고 답변을 구성한다. 곧 시스템이 작성하는 답변에 대한 실험을 시작하고, 알고리즘을 통한 라이브 데이터 프로토타입을 사용할 수 있을 것이다.

이는 제품 발견에 '확장성을 고려하지 않고 만든다'라는 철학을 따르는 사례다. 조금만 영리하게 실행하면 매우 신속하게 학습할 수 있게 해주는 도구들을 빠르고 쉽게 제작할 수 있다.

Previous아이디어 발상 기법Next제품 발견 테스트 기법

Last updated 3 months ago

📚