Part 1 | 최고의 기술 기업에서 배운 것

저자는 1년이 넘는 기간 동안 만든 제품을 아무도 구매하지 않는 상황을 겪고, 만들 만한 가치가 있는 제품이 아니라면 엔지니어 팀이 얼마나 훌륭한지는 아무 의미가 없다, 최신 기술을 잘 아는 것과 실제로 잘 만드는 것은 매우 다르다는 것을 느꼈다고 한다. 그리고 아래의 질문을 하게 된다.

우리가 만드는 것에 대해 누가 무엇을 정의해야 하는가? 그들은 어떻게 의사결정을 하는가?

우리가 만드는 제품의 사용성이 충분한지를 그들은 어떻게 파악할 수 있을까?

그리고 이것에 대해 답해야 하는 사람을 제품 관리자, PM라고 말한다. PM은 제품팀을 이끌며 비즈니스 목표에 맞는 방향으로 기술과 디자인을 통해 고객의 실제 문제를 해결한다.

회사의 단계별 미션

1) 스타트업: 제품/시장 궁합 찾기

제품/시장 궁합을 아직 찾지 못한, 새로운 제품을 만드는 회사. 유효한 비즈니스를 창출하는 제품을 찾기 위해 여전히 노력하고 있는 단계의 회사.

통장의 잔액이 떨어지기 전에 제품/시장 궁합을 어떻게든 달성하기 위해 달리는 경주와 같다. 제품이 집중할 필요가 있으며, 초기 시장의 니즈에 부함하는 강력한 제품을 만들어 내야 한다. 시간과 비용이 매우 빠듯하므로 좋은 스타트업은 실행 속도를 늦추는 불필요한 관료 체계를 최소화한다.

2) 성장 단계의 회사 : 성공을 위한 확장

제품/시장 궁합을 달성한 스타트업들은 어떻게 효과적으로 성장하고 확장해 나갈 것인가 하는 문제를 풀어야 한다. 많은 사람을 채용하는 동시에 초기 성공을 이어나가기 위해 새롭고 인접한 제품과 서비스를 어떻게 만들어 낼지 고민해야 한다. 동시에 핵심 비즈니스 또한 가능한 한 빠른 속도로 성장시켜야 한다.

제품팀은 권한과 책임의 불분명함, 영업 마케팅에서는 시장 진출 전략의 변화, 엔지니어들은 기술 부채, 리더들은 리더십의 변화 등의 압박을 받게 된다. 반면 이를 극복하고자 하는 동기부여는 기업 공개, 비전 등으로 강한 편이다.

3) 대기업 : 끊임없는 제품 혁신

규모의 확장에 성공했고 이제 영속하는 비즈니스를 만들기 원하는 기업들도 도전이 있다. 강한 기술 제품 회사는 끊임없는 제품 혁신이 필요하다는 것을 잘 알고 있다.현재 고객과 비즈니스를 위해 지속해서 새롱누 가치를 제공해야 하는 것을 의미한다.

기업이 이 정도 규모가 되면 회사가 이룩한 것들을 지켜 내고자 하는 수많은이해 관계자들이 비즈니스 전반에 걸쳐 존재한다. 이렇게 되면 비즈니스를 재창조할 수 있는 새로운 시도나 사내 벤처들을 막아 버리게 된다.

제품이 실패하는 이유

Waterfall 프로세스

• 아이디어 : 내부 혹은 외부에서 유입된다. 제품 관리자가 처리해주기를 바라는 엄청난 양의 과제들이다.

• 비즈니스 케이스 : 각 아이디어에 대해 (1) 얼마만큼의 매출이나 가치를 만들어 내는 것인가? (2) 얼마만큼의 비용이나 시간이 필요한 것인가?를 정의한다.

• 로드맵 : (1) 가장 중요한 일을 먼저 수행하기 위해 (2) 각 업무가 언제 준비 상태가 될지 예측하기 위해 각 아이디어의 우선순위를 매기고, 이에 따라 가장 높은 우선순위부터 차례대로 실행한다.

• 요구사항 : 해당 이해 관계자를 만나서 아이디어를 구체화한다. 사용자 스토리 형태 또는 기능 명세 형태로, 디자이너와 엔지니어에게 무엇이 만들어져야 하는지 커뮤니케이션 하기 위해 만든다.

• 디자인, 구현 : 요구사항과 디자인 결과물을 전달하고, 엔지니어는 그 과제를 이터레이션으로 나눠 진행한다. (일부 애자일)

• QA 테스트 후 문제가 없으면 배포된다.

나도 처음 책을 읽을 때는 '에이 설마 이렇게 하겠어? 이제 애자일 프로세스 너무 유명하잖아', 심지어는 실제 PM 분들이 이런 식으로 일하는 곳이 있다라고 할 때도 '내가 가는 데는 안그러겠지, 스타트업이잖아!'라고 생각했던 것 같다. 근데 진짜 있다. 진짜! 많은 "스타트업"이 이렇게 일하고 있다. 놀랍게도!

이렇게 하면 망하는 이유

1. 아이디어 (1) 뛰어난 아이디어를 가져오기 어려움 (2) 권한 위임이 안되므로 제품팀은 열심히 실행할 뿐

2. 비즈니스 케이스 얼마만큼의 수익이 날지, 얼마만큼의 비용이 들지 현재 시점에서 알 방법이 없음 어떤 솔루션을 만들지 모르는 상태이기 때문에, 그에 해당하는 수익/비용 모두 말그대로 아무것도 모름

3. 로드맵 (1) 아이디어 중 최소 절반 이상은 유효하지 않음 (2) 비즈니스 가치를 만들어 내는 수준으로 만들려면 최소 몇 번의 이터레이션을 반복해야 함 = 돈을 버는 데 필요한 시간이 필요함. 그런데 로드맵 체제로 하면 개선이 아니라 다음 프로젝트를 시작하는 식으로 넘어가게 됨.

4. 제품 관리자의 역할 제품 관리가 아니라 프로젝트 관리. 엔지니어를 위해 요구사항을 수집하고 문서화하는 역할만 하게 됨

5. 디자이너의 역할 디자인의 진정한 가치를 담기에 너무 늦은 상황에 투입됨

6. 엔지니어의 역할 너무 늦게 참여하게 되면서, 코드를 짜는 역할만 하게 됨

7. 애자일의 원칙과 핵심적인 장점이 늦게 적용됨 제품 구현과 전달에서만 애자일 적용

8. 프로젝트 중심적 프로젝트는 결과물에 대한 것, 제품은 비즈니스 성과에 대한 것

9. 고객 검증이 너무 늦게 일어남

10. 기회비용 그 시간에 조직이 할 수 있었던 혹은 해야만 했던 것에 대한 기회비용

핵심 원칙

어떤 도구라도, 그것을 현명하게 활용할 줄 알아야 한다.

린 원칙을 따르고 있다는 많은 팀들이 최소 기능 제품(Minimum Viable Product)이라고 부르는 것을 몇 달 동안이나 작업하고 있으며, 엄청난 시간과 비용을 소모할 때까지 그들이 무엇을 만들고 있고 고객에게 팔 수 있을지를 잘 모른다. 보다 극단적으로 나아가서는 모든 것들을 테스트하고 검증해야 한다고 생각해 버린다. 이런 방식들을 린 철학이라고 보기는 어렵다. 진짜 핵심 원칙은 아래와 같다.

1

위험을 초기에 대응한다.

구현을 결정하기 이전에 위험을 먼저 발견하고 대응한다.

• 가치 위험 (value risk) : 고객이 과연 이 제품을 구매할 것인가?

• 사용성 위험 (usability risk) : 사용자가 이 제품의 사용 방법을 쉽게 이해할 수 있는가?

• 실현 가능성 위험 (feasibility risk) : 우리 엔지니어가 보유한 시간/역량/기술로 필요한 것들을 만들어 낼 수 있는가?

• 사업 유효성 위험 (business viability risk) : 이 솔루션이 영업/마케팅/재무/법무 등 우리 사업의 다양한 측면을 고려했을 때 제대로 효과를 발휘할 수 있는가?

2

제품은 함께 협업하며 정의되고 설계된다

PM, 디자이너, 엔지니어가 함께 붙어서 활발히 의견을 주고받으며, 고객이 사랑하고 비즈니스 성과를 이룰 수 있는 기술 중심의 솔루션을 만들어 낸다.

3

기능을 구현하는 것이 아니라 문제를 해결한다

전통적인 제품 로드맵은 생산량에 대한 것이다. 뛰어난 팀은 솔루션을 구현하는 것이 아니라, 사업적 성과와 연결되는 문제를 해결한다.

핵심 개념

총체적인 제품

기능(fucntionality)와 그것을 가능하게 하는 기술, 이를 표현하는 사용자 경험 디자인을 포함한다. 이를 통해 어떻게 돈을 벌지, 사용자를 획득하는 방안, 제품의 가치를 전달하기 위해 필요한 오프라인 경험도 포함한다.

지속적인 제품 발견과 실행

모든 제품팀은 필수적으로 두 가지 활동을 한다. 이 두 가지 업무는 끊임없이 동시에 실행된다.

1. 제품 발견 : 만들 제품을 발견하는 것

2. 제품 실행 : 시장에 그 제품을 전달하는 것

제품 발견

제품 발견의 목적은 좋은 아이디어와 그렇지 않은 아이디어를 빠르게 판별하는 것이다. 제품 발견의 산출물은 검증된 제품 백로그(validated product backlog)다.

다음 네 가지의 중요한 질문에 답을 하는 과정이다.

1. 사용자들이 이 제품을 살 것인가?

2. 사용자가 이 제품을 어떻게 사용하는지 이해할 수 있는가?

3. 우리 엔지니어가 이것을 만들어 낼 수 있는가?

4. 우리 이해 관계자가 이것을 지지하는가?

프로토타입

제품 발견은 일련의 빠른 실험들의 진행을 포함한다. 이 실험을 빠르고 적은 비용으로 진행하기 위해서 실제 제품보다는 프로토타입(prototype)을 활용한다. 프로토타입에는 몇 가지 유형이 있지만, 최소한 제품을 구현하는 데 드는 시간과 노력보다는 작은 규모로 진행되어야 한다.

기대 수준으로 말하자면 최고의 팀들은 한 주에도 여러 가지 제품 아이디어를 실험한다. 10개에서 최대 20개 이상을 진행하기도 한다. 프로토타입은 출시를 위한 것도, 비즈니스를 만들어 내기 위한 것도 아니다. 빠르고 저렴한 비용으로 학습하기 위한 것이다.

제품 실행

판매하고 비즈니스를 운영할 만한 품질 수준의 기술 제품을 만들고 전달하는 것

제품 비전

2~10년 정도에 해당하는 제품의 장기적인 목표. 제품 조직으로서 회사의 미션을 어떻게 달성할 것인가에 대한 것.

최소 기능 제품(MVP)

MVP를 만드는 데 애를 먹고 있는 팀의 대부분은 훨씬 더 짧은 시간과 노력으로 동일한 학습을 할 수 있음에도 몇 달 동안이나 MVP를 만드는 데 시간을 허비한다. 이 근본 원인은, MVP는 실제 제품이 아니어야 함에도 MVP의 P가 제품을 상징해서 라고 생각한다. 제품이라는 것은 엔지니어가 자신감을 가지고 출시할 수 있고, 고객이 원하는 일을 처리할 수 있도록 당신이 판매하고 지원할 수 있는 것이다.

MVP는 프로토타입이지 제품이 아니다. 비록 최소한의 기능을 하는 것일지라도 학습하기 위해 실제 제품 수준의 것을 만드는 것은 상당한 시간과 비용의 낭비를 초래한다.

결론

제품팀은 제품 발견의 신속한 실험을 위해 프로토타입을 활용하고, 제품 실행 단계에서는 제품/시장 궁합을 성취하기를 기대하며 제품을 만들고 출시한다. 이 과정을 통해 회사의 제품 비전을 달성해 나간다.