brunch

You can make anything
by writing

C.S.Lewis

by 윤동구리 Jun 03. 2023

실패한 제품의 근본 원인

인스파이어드 - (1) by 마티 케이건

IT 기업이 일하는 방식


    스타트업이냐 대기업이냐. 기업의 규모에 무관하게 훌륭한 제품을 만드는 프로세스는 동일하다. 핵심은 아이디어의 유용성을 빠르게 파악하고, 가치를 만들어 내기 위하여 이터레이션(iteration)을 반복하는 것이다. 아무리 좋은 아이디어라 하더라도 비즈니스 성과를 도달하기 위해서 반복적인 이터레이션은 불가피하고, 자원은 제한적이기에 돈 벌기 까지 필요한 시간(time to money)을 줄이는 것이 중요하다.



실패한 제품의 근본 원인 (워터폴 방식)


    많은 기업들은 위와 같은 워터폴 방식을 채택하면서 애자일하게 일한다고 착각한다. 업무를 나누어 순차적으로 진행되는 이런 방식은 근본적으로 몇 가지 문제를 가진다.


- 톱-다운으로 전달된 아이디어는 이해관계자나 매출 증대에만 초점이 맞추어져 있어 유효하지 않을 가능성이 크다. 사실 아이디어의 반 이상은 유효하지 않다. 잘못된 아이디어에 자원을 투입하는 것은 큰 낭비이다.


- 제품을 실제로 만들기 전까지는 어떠한 효용과 비용이 발생할지, 시간이 얼마나 걸릴 지를 정확하게 알 수 없다. 우리는 모르는 것을 알아가는 과정이기 때문이다. 따라서 비즈니스 케이스와 이를 타임라인으로 나누어 놓은 로드맵은 무용하다.


- 제품 관리자, 디자이너, 개발자가 순차적으로 개입한다. 그러나 사실 셋은 모두 제품 발견부터 실행 단계까지 함꼐 협업하는 것이 맞다. 그럼으로써 그들의 인사이트를 활용할 수 있다. 던져준 업무를 수행하는 용병이 아니라, 함께 고민하고 해결점을 찾아가는 미션팀으로 일하기 위해서도 모두가 함께 참여하는 것은 중요하다.


- 무엇보다도 고객이 정말 원하는 제품인지에 대한 검증이 너무 늦게 일어난다.



지속적인 제품 발견과 실행(에자일)

    불필요한 자원 투입을 줄이려면 끊임 없이 테스트하고 발견한 바를 공유해야 한다.


- 주요 리스크를 초기에 숙고한다. 고객이 원하는 제품인지, 쉽게 사용할 수 있을지, 주어진 자원(시간/역량/기술)의 제약 하에서 구현이 가능한지를 알아본다. 이를 빠르게 파악하기 위하여 MVP를 활용하기도 한다.

* Minimun Viable Product 라는 이름 떄문에 실제 '제품'이어야 한다는 오해를 산다. 실제로는 Prototype의 개념으로 이해하는게 바람직하다. MVP에 몇 주를 쏟는 것 또한 낭비이다.


- 제품 관리자, 디자이너, 개발자가 제품 발견 단계부터 합류하여 협업한다.


- 제품을 통해 비즈니스 성과를 달성하는 것을 목표로 한다. 특정한 기능을 구현하는 것이 중요한게 아니다. 얻을 수 있는 비즈니스 성과를 기준으로 생각해야 한다.




어떤 사람들이 일하고 있을까


1. 제품관리자

- 고객/데이터/비즈니스/시장과 산업데 대한 깊은 이해

- 지적 호기심이 많고, 빠른 학습능력을 바탕으로 고객 문제 해결, 신규 고객 확보, 비즈니스 모델을 발굴

- 평범한 제품의 기능 범위를 뛰어넘는 방법을 창의적으로 고안, 차별화되는 제품을 발견

- 완강한 저항에도 불구하고 적당함과 타협하지 않는 집요함, 끝없는 설득과 대화 및 조직 간의 가교 역할

* 컴퓨터 프로그래밍(HTML 제외) & 비즈니스 회계 및 재무 기본을 공부하면 대화의 지평이 넓어진다

 제품 총괄(VP product): 강력한 비전을 가지고 CEO를 보완하는 역할

 그룹 제품 관리자(GPM): 제품 총괄을 키우고, 여러 제품을 유기적으로 연결하는 역할


2. 제품디자이너

- 제품과 회사의 관점에서 고객이 상호작용하는 여정을 반영한 사용자 경험(UX) 디자인

  제품 첫 경험, 신기능 소개 방식, 고객 일과 중 상호작용하는 방식, 유저 숙련도에 따른 반응, 등을 고려

- 사용자 테스트, 상호작용 & 시각 디자인


3. 엔지니어

- 프론트엔드(사용자 경험) ↔ 백엔드(서버와 데이터) 혹은 특정한 기술 (데이터 베이스, 검색, 머신러닝)

 수석엔지니어, 기술 아키텍트: 기술과 개발을 리드하는 역할 

 기술 부사장(CTO): 제품을 완성하고 키우는 데 필요한 기능성, 확장성, 신뢰성, 보안, 성능 등

                              아키텍쳐를 확보하며, 제품 출시의 지속성과 빈도, 품질/신뢰성 등을 책임지는 역할

   cf) 최고정보책임자(CIO): 자료 처리, 통신, 소프트웨어 등 it 인프라 효율화에 초점 (내부 비용 절감)


4. 그 외

- 제품 마케팅 매니저: 보통 목표 고객 혹은 시장 기준으로 구성, 포지셔닝/고객 대상 메시지/시장 계획

- 사용자 연구원: 사용자나 고객 상호작용을 학습하여 구성원에게 전파 (없을 경우 제품디자이너가 수행)

- 데이터 분석가: 라이브 데이터 테스트를 계획하고 분석, BI 분석 (없을 경우 제품관리자가 수행)

- 테스트 자동화 엔지니어: QA (없을 경우 엔지니어가 수행)




▶ 제품 팀을 나누어보자

    한 가지 좋은 방법은 없을 뿐더러, 한 가지를 고집 할 필요도 없다. 각자의 상황과 환경에 따라 여러 가지 원칙 중 가중치를 두면 된다. 조직의 요구사항은 시간의 흐름에 따라 변화하기 떄문에, 제품 팀 또한 그에 맞게 지속 변화해야 한다.


- 팀의 규모: 최소 1 제품 관리자 + 2 엔지니어 (+ 1 디자이너), 어느 경우에도 1 제품 팀에는 1 제품 관리자

  아키텍쳐: 각기 다른 전문성을 가진 엔지니어들, 제품 비전을 실행할 수 있는 아키텍쳐 기준으로 그룹


투자 전략과 연계: three horizons model, portfolio management 등의 투자 전략에 연계

  시장 세분화: 담당하는 비즈니스/고객/나라 별로 제품팀을 나누어 담당하는 시장에 대한 이해 고도화

  제품 비전과 전략: 조직이 도달해야 할 vision과 주요 이정표인 strategy에 따라 팀을 구조화


- 상호 의존 최소화/자율성: 상호의존을 줄여 각 팀이 자율성을 최대로 발휘할 수 있도록, 미션팀을 설계

  레버리지 극대화: 각 제품팀이 공통적으로 필요로하는 공유 솔루션 제작 (자율성과 반비례)




▶ 자율적인 제품팀

    대부분의 리더들은 팀에게 자율성을 준다고 말하지만, 실제로 그렇게 느끼는 팀원은 극히 적다. 이 간극은 어디서 나오는 것일까? 예를 들어 각 팀이 테스트 자동화를 하는 방법을 직접 정하는 게 맞을까? 이를 허용함으로써 오히려 조직 전체의 비용이 이득보다 커질 수 있다. 어느 정도의 레버리지(공유 솔루션)은 필요하다. 둘은 트레이드 오프 관계에 있는 만큼, 하기를 고려하여 자율성을 적정 수준으로 조정해야 한다.


- 팀의 역량 수준: 올바른 의사결정을 할 수 있는지, 경험이 풍부한지


- 속도의 중요성: 레버리지를 사용하면 중복을 줄여 사용하는 시간을 줄일 수 있음

  통합의 중요성: 제품 포트폴리오가 의존적이기보다 독립적이라면 레버리지는 상대적으로 덜 중요

  혁신의 원천: 솔류션 레벨에서의 혁신이 기대된다면 최대한 자율성을 보장해야 함


- 기술의 성숙도: 공통 솔루션을 모든 팀에서 받아들일 수 있을만큼 기술의 성숙이 필요




제품팀이 일 하는 방법


▶ 제품 로드맵의 대안


제품 로드맵

    제품 로드맵은 팀이 해야 할 일에 대한 우선순위가 정해진 기능과 프로젝트들의 목록이다. 높은 가치를 가진 업무가 우선적으로 수행되고, 영업/마케팅 등 비즈니스 계획을 세우기 위하여 로드맵을 작성한다.

    그러나 문제는 로드맵 위의 아이디어들이 정말 유효하지 않다는 것이다. 고객에게 정말 가치를 전달하는 제품인지를 알아보기 위해서는 몇 번의 이터레이션을 반복할 수 밖에 없는데, 로드맵 위의 아이디어들은 반드시 달성해야만 하는 목표가 되어버린다. 아이디어가 근본적으로 유효한지를 검증하고 확인하지 않은 채 (= 비즈니스 목표를 달성) 로드맵에 따라 제품을 만드는 데에 (=결과물) 몰두하게 된다. 또한 로드맵에는 목표 달성 시점이 정해져있는데, 실제 얼머나 시간이 걸릴 지 미리 아는 것은 어렵다.


 성과 중심의 로드맵

    제품 아이디어의 우선순위가 아닌 사업 성과의 우선순위를 기준으로 업무를 수행한다. 예를 들면, '새로운 로그인 방식을 개발한다'라는 제품 아이디어가 아닌 '새로운 고객이 활성화되기 위한 시간을 줄인다' 라는 사업 모표를 기준으로 우선순위를 결정한다.

    주어진 일정을 맞추는 게 꼭 필요한 경우에는 높은 신뢰 수준의 약속을 활용한다. 제품 로드맵의 문제는 약속의 '시점'이 너무 빠르다는 것이다. 책임지고 제품을 전달할 수 있을지 알 수 없을 때, 아이디어가 유효한지 알 수 없을 때, 즉 제품을 발견하기 전에 약속을 해야 한다. 반면, 성과 중심의 로드맵에서는 제품을 발견한 후 일정과 결과물에 대해 약속한다. 




▶ 제품 비전


제품 비전은 2~5년 정도 기간에 우리가 만들어내고자 하는 미래 (하드웨어, 디바이스 회사는 보톨 5~10년)를 가리킨다. 직원이 매일 출근하여 일하는 동기 부여가 되며, 영감의 원천이 된다.


- 비전은 크게 생각해라. 작고 쉬운 것은 영감을 줄 수 없다

- '왜'를 고민하여 솔루션이 아닌 문제와 사랑에 빠져라

- 현재 가치를 만드는 것에 집중하고 가지고 있는 것에 집중하지 말아라

- 비전은 완고하되, 세세한 부분은 유연하게 하라 (발견 변경 discovery pivot)


제품 전략은 제품 비전을 실현하기 위하여 계획하는 일련의 제품 또는 출시를 뜻한다. 제품 비전이 어디로 가야할지를 가리킨다면, 전략은 목표한 곳에 다다르기 위한 방법으로 분명한 초점을 가져야 한다. 제품/시장 궁합을 바탕으로 제품 전략을 구성하는 경우가 일반적이다. ex) 고객별(나이/성별), 지리적 위치(북미/남미)


- 한 번에 한가지 시장 or 고객에 집중하라. 모두를 공략하는 건 아무도 공략하지 않는 것과 동일하다.

- 비즈니스 전략 및 시장 진출 전략과 연계되어야 한다


제품 원칙은 만들고자 하는 제품의 특성으로, 조직이 중요하다고 믿는 원칙을 가리킨다. ex) 이베이는 구매자와 판매자의 요구 사이에 충돌이 있을 경우 구매자를 우선시하는 원칙을 가지고 있다. 그것이 더 많은 구매자를 불러오고, 궁극적으로 판매자에게도 이득이 되기 떄문이다. (역은 성립하지 않는다)




그렇다면 어떻게 제품을 발견할 수 있을까?

지속적인 제품 발견 프로세스 (brunch.co.kr)

작가의 이전글 숫자에 속지 않는 방법
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari