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

만들 만한 가치가 있는 제품이 아니라면 엔지니어 팀이 얼마나 훌륭한지는 아무 의미가 없다.

최고의 기업들과 대부분 기업이 제품을 만드는 방식에서 큰 차이가 있음을 발견했다. 최신 기술을 잘 아는 것과 실제로 잘 만드는 것은 매우 다르다는 것을 느꼈다.

🍭 훌륭한 제품을 이끄는 사람

제품팀을 이끌며, 비즈니스 목표에 맞는 방향으로 기술과 디자인을 통해 고객의 실제 문제를 해결한다. 이런 사람들을 우리는 제품 관리자(Product Manager)라고 부른다.

제품팀은 적어도 한 명의 제품 관리자 및 두 명에서 최대 10명의 엔지니어로 구성된다. 사용자 접점에 있는 제품을 만드는 경우라면 아마도 팀에 제품 디자이너도 필요할 것이다.

이 책을 관통하는, 내가 확신하고 있는 중심적인 개념이 있다. 바로 모든 훌륭한 제품 이면에는 지칠 줄 모르고, 무대 뒤에서 최선을 다하는 누군가가 있다는 것이다. 그 사람은 제품 팀을 이끌며, 비즈니스 목표에 부합하는 방향으로 기술과 디자인을 통해 고객의 실제 문제를 해결한다.

🍭 기술 중심의 제품과 서비스

나는 오늘날 대부분 제품이 기술 중심의 제품으로 탈바꿈하고 있다고 생각한다.

그리고 이러한 변화를 꺠닫지 못하는 기업은 빠르게 무너질 것이다. 다시 한번 말하지만 나는 기술 중심의 제품과 기업에 집중할 것이다. 그들은 기술 변화를 빠르게 흡수하고 고객을 위해 끊임 없이 혁신해야만 한다고 믿는 기업들이다.

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

나는 스타트업이란, "제품/시장 궁합을 아직 찾지 못한, 새로운 제품을 만드는 회사"라고 간략히 정의한다.

스타트업이란, "유효한 비지니스를 창출하는 제품을 찾기 위해 여전히 노력하고 있는 단계의 회사" 정도로 해두자.

스타트업은 제품에 집중할 필요가 있으며, 초기 시장의 니즈에 부합하는 강력한 제품을 만들어 내야 한다. 스타트업은 대개 초기 자금이 매우 제한적이다. 시장이 필요로 하는 제품을 발견하고 출시할 수 있을지 결정하는 것을 목표로 자금을 사용한다.

스타트업은 시간과 비용이 매우 빠듯하다. 그래서 좋은 스타트업은 실행 속도를 늦추는 불필요한 관료 체계를 최소화한다. 그런데도 아직 기술 스타트업은 실패 확률이 높다. 그중 일부 성공하는 스타트업은 특히 제품 발견에 매우 뛰어나며, 이는 이책의 중요한 주제다.

제품/시장 궁합을 위해 달려나가야 하는 스타트업에서 일한다는 것은 높은 스트레스, 산더미 같은 업무량, 위험한 상황을 항상 마주해야 한다.

초기 시장의 니즈에 부합하는 강력한 제품을 만들어 내야한다.

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

많은 사람을 채용하는 동시에 초기 성공을 이어나가기 위해 새롭고 인접한 제품과 서비스를 어떻게 만들어 낼지 고민해야 한다. 동시에 핵심 비즈니스 또한 가능한 한 빠른 속도로 성장시켜야 한다.

제품팀들은 큰 그림을 이해할 수 없다며 불평하기 시작한다. 그들이 하는 일이 전체 목표에 어떻게 기여하는지 도대체 알 수 없다고 한다. 또한, 권한을 가진 자율성 높은 팀에서 고군분투하며 일을 해나간다.

첫 제품의 요건에 부합했던 기술 인프라도 한 번씩 터질 듯한 상황이 온다. 당신이 이야기를 나누는 모든 엔지니어의 입에서 "기술 부채"라는 단어가 들리기 시작한다.

리더들은 초기 스타트업 시절에 작동했던 리더십 스타일과 방식이 이제는 잘 통하지 않는 문제들을 겪는다. 리더들을 그들의 역할과 많은 상황에서의 행동이 바뀌어야 한다는 압박을 받는다.

반면 이런 변화를 극복해야만 한다는 동기부여는 매우 강한 상황이다. 세상에 유의미하고 큰 영향을 줄 수 있다는 현실적인 가능성도 강한 동기부여 요인이 될 수 있다.

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

회사 초기에는 분명하고 멋진 비전이 있었다. 하지만 회사의 규모가 커지면서 회사는 본래의 비전을 어느 정도 달성하였고, 사람들은 이제 다음 모습이 무엇인지 확신이 없다. 제품팀들은 비전의 부재, 권한 위임의 부재, 너무나 느린 의사결정에 대한 불만을 쏟아 낸다. 또한, 제품을 만드는 일은 점점 사공 많은 배처럼 되어 간다.

리더들도 마찬가지로 제품팀의 혁신 부재로 좌절하기 일쑤다.

🍭 실패한 제품의 근본 원인

대부분의 회사가 여전히 사용하고 있는 제품 개발 프로세스는 아이디어에서 출발한다. 대부분 아이디어는 내부 혹은 외부에서 유입된다.

이제 대부분 회사는 이러한 아이디어들의 우선순위를 매겨 로드맵으로 전환하기를 원한다. 그들은 두 가지 이유로 로드맵을 사용한다. 첫째는 가장 중요한 일을 먼저 수행해 주기를 원하기 때문이며, 둘째는 각 업무가 언제 준비 상태가 될지 예측하고 싶기 때문이다.

로드맵을 작성하기 위해 보통 분기 또는 연간 계획 세션과 같은 별도의 시간을 마련한다. 우선순위를 선정하기 위해 그들은 먼저 각 아이디어에 대한 비즈니스 케이스 정의가 필요하다. 각 아이디어에 대해 두 가지를 분명히 알아야 한다는 것이 핵심이다. (1) 얼마만큼의 매출이나 가치를 만들어 내는 것인가? (2) 얼마만큼의 비용이나 시간이 필요한 것인가? 이러한 정보는 다음 분기의 로드맵을 작성하는 데 활용된다.

어떤 아이디어가 가장 높은 우선순위에 있으면 제품 관리자가 가장 먼저 해야 할 일은 해당 이해 관계자를 만나서 아이디어를 구체화하는 것이다. 이를 통해 일련의 "요구사항"을 정리한다.

이러한 요구사항은 사용자 스토리 형태이거나, 아마도 기능 명세와 같은 양식의 형태일 것이다. 요구사항은 디자이너와 엔지니어에게 무엇이 만들어져야 하는지를 커뮤니케이션하기 위함이다.

요구사항이 모두 수집되고 나면 사용자 경험 디자인팀은 상호작용 디자인(interaction design), 시각 디자인(visual design), 물리적인 기기의 경우 산업 디자인(industrial design)에 대한 진행을 요청한다.

결국 그 요구사항과 디자인 결과물은 엔지니어에게 전달된다. 대개 이 시점에서 애자일이 등장한다.

아무튼 엔지니어들은 보통 그 과정을 이터레이션(반복 업무 단위)으로 나눈다. 스크럼(scrum) 프로세스에서 말하는 "스프린트(sprint)"다. 아이디어를 구현하기 위해 한 번에서 세 번 정도의 스프린트가 걸린다.

QA 테스트(QA test)가 스프린트 일부로 포함되어 있으면 다행이다. 혹은 별도 QA 팀이 있다면 그 신규 아이디어 과제가 예상대로 동작하는지, 다른 문제를 만들어 내지는 않는지를 검증한다.

QA 담당자로부터 이상이 없음을 확인하는 녹색 신호를 받으면, 그 신규 아이디어는 마침내 실제 고객에게 배포(deploy)된다.

여전히 이런 기업들은 일관된 불평불만을 제기한다. 혁신이 부족하고, 제품을 고객에게 전달하기까지 너무 오랜 시간이 걸린다는 것이다.

방금 설명했던 상황은 완전히 폭포수 프로세스에 대한 것이었다. 엔지니어 관점에서 말하자면 그들은 보통 주어진 폭포수 프로세스의 환경에서 할 수 있는 최대한의 애자일을 실천하고 있다.

다음 목록을 통해 이러한 업무 방식이 가지는 가장 큰 문제 10가지를 공유할 것이다. 이 10가지 문제는 팀을 망칠 수 있는 매우 심각한 이슈라는 것을 명심하자.

1. 위에서부터 시작해 보자. 바로 아이디어의 출처다. 이 모델을 사용하면 판매 확대를 위한 기능이나 이해 관계자 위주로 제품이 끌려가게 된다. 이러한 접근 방법은 팀에게 필요한 권한 위임이 안 된다. 이 모델을 따르면 제품팀은 마치 외부 용병처럼 그저 열심히 실행할 뿐이다.
2. 비즈니스 케이스의 치명적인 결함은 로드맵을 작성하는 단계에서 비즈니스 케이스를 작성하는 것은 정말 말도 안 된다. 비즈니스 케이스의 핵심적인 두 가지 요소는 "얼마만큼의 돈을 벌 수 있는가"와 "얼마만큼의 비용이 드는가"다. 현재 시점에선 우리는 이 두 가지 수치에 대한 근거가 전혀 없다는 것이다. 알 방법이 없다. 어떤 경우에도 제품 개발의 가장 중요한 교훈 중 하나는 우리가 모르는 것을 알아간다는 것이다. 그리고 단지 이 단계에서는 우리가 얼마만큼의 돈을 벌 수 있는지 알 수 없다.
3. 회사가 제품 로드맵에 대해 빠져들기 시작하면 더 큰 이슈가 발생하기 시작한다. 제품에 관한 두 가지 불편한 진실이 있다. 첫 번째 진실은, 당신의 아이디어 중 최소 절반 이상은 유효하지 않을 것이라는 사실이다. 이러한 이유는 이 아이디어에 대해 우리만큼 고객이 관심을 가지지 않는다는 것이다. 첫 번째가 충분하지 않다면 두 번째 불편한 진실은 아이디어가 충분히 잠재적인 가치가 있는 것으로 파악되더라도 필요한 비즈니스 가치를 만들어 내는 수준에 도달하려면 최소 몇 번의 이터레이션을 반복해야 한다는 것이다. 우리는 이것을 돈을 버는 데 필요한 시간이라고 한다.
4. 이 모델에서는 제품 관리의 역할은 엔지니어를 위해 요구사항을 수집하고 문서화해 주는 것이 주요 업무다. 이는 내가 실제 기술 제품 관리라고 하는 일과는 180도 다르다는 것을 짚고 넘어가고 싶다.
5. 디자인의 역할도 상황이 비슷하다. 이미 사황은 더 나빠졌으므로 엉망인 제품에 페인트 코팅이라도 씌우려고 시도한다. 사용자 경험(UX) 디자이너도 이것이 바람직하지 않다는 것을 잘 알고 있지만, 이렇게라도 그들이 할 수 있는 방법으로 보기 좋고 일관된 디자인을 해나간다.
6. 아마 이 모델에서 놓치는 가장 큰 기회는 엔지니어들이 너무 늦게 참여한다는 것이다. 제품 개발에서 작은 비밀이 있다면 엔지니어가 보통 혁신을 하는 데 가장 훌륭한 원천이라는 것이다. 그러나 이 모델에서 그들은 회의에도 초대받지 못한다.
7. 이러한 방식으로 업무를 하면 팀은 애자일 방법론의 실질적인 가치와 잠재성을 단지 20%만 활용하게 된다. 이는 제품 구현과 전달에만 애자일이 적용되는 것이며, 다른 모든 조직과 업무 상황에는 해당하지 않는다.
8. 이 모든 프로세스는 다분히 프로젝트 중심적이다. 회사는 프로젝트에 투자하고, 프로젝트에 인력을 지원하며, 조직에 프로젝트 단위로 압박하며, 결국 프로젝트를 출시하게 된다. 불행하게도 프로젝트는 결과물에 대한 것이고, 제품은 비즈니스 성과에 대한 것이다.
9. 전통적인 폭포수 방식이 여전히 가지고 있는 가장 큰 문제는 위험이 가장 마지막에 발견된다는 것이다. 고객에 대한 검증이 너무 늦게 일어난다는 의미다.
10. 끝으로, 우리가 이 프로세스로 시간과 비용을 낭비하느라 정신없을 때 발생하는 가장 큰 손실은 따로 있다. 바로 그 시간에 조직이 할 수 있었던 혹은 해야만 했던 것에 대한 기회비용이다. 우리는 시간과 돈을 다시 돌릴 수 없다.

🍭 린과 애자일을 넘어

세 가지 중요한 핵심 원칙

1. 위험은 마지막보다는 초기에 대응한다. 뛰어난 팀들은 어떤 것에 대한 구현을 결정하기 이전에 위험을 먼저 발견하고 대응한다. 이러한 위험의 종류는 다음과 같다.

• 가치 위험: 고객에 과연 이 제품을 구매할 것인가?
• 사용성 위험: 사용자가 이 제품의 사용 방법을 쉽게 이해할 수 있는가?
• 실현 가능성 위험: 우리 엔지니어가 보유한 시간/역량/기술로 필요한 것들을 만들어 낼 수 있는가?
• 사업 유효성 위험: 이 솔루션이 영업/마케팅/재무/법무 등 우리 사업의 다양한 측면을 고려했을 때 제대로 효과를 발휘할 수 있는가?

2. 제품은 순차적인 방식보다 함께 협업하며 정의되고 설계된다. 제품 관리자, 디자이너, 엔지니어가 함꼐 붙어서 활발히 의견을 주고받으며, 고객이 사랑하고 비즈니스 성과를 이룰 수 있는 기술 중심의 솔루션을 만들어 낸다.
3. 끝으로, 기능을 구현하는 것이 아니라 문제를 해결한다. 그들의 솔루션은 근원적인 문제를 반드시 해결해야 한다고 믿는다. 바로 사업적인 성과에 대한 것이다.

🍭 핵심 개념

🥕 총체적인 제품

제품은 당연히 기능을 포함한다. 그리고 이 기능을 가능하게 하는 기술 또한 포함된다. 이 기능을 표현하는 사용자 경험 디자인도 포함된다. 그리고 이 기능을 통해 우리가 어떻게 돈을 벌지도 포함된다. 제품은 사용자와 고객의 마음을 사로잡고 획득하는 방안도 포함된다. 그리고 제품의 가치를 전달하기 위해 필요한 오프라인 경험도 포함한다.

🥕 지속적인 제품 발견과 실행

모든 제품팀이 필수적으로 해야 하는 기본적인 두 가지 활동이 있다. 만들 제품을 발견하는 것과 시장에 그 제품을 전달하는 것이다. 제품의 발견과 실행은 다기능 제품팀의 두 가지 핵심적인 업무다. 그리고 그 두 가지 업무는 보통 끊임없이 동시에 실행된다.

이 개념에 대해 생각하고 시각화하는 여러 방법이 있겠지만, 실제로는 꽤 간단하다. 만들어질 제품에 대해 발견하는 일과 엔지니어가 출시 가능한 제품의 품질 향상을 항상 동시에 수행햐는 것이다.

🥕 제품 발견

제품 발견은 제품 관리, 사용자 경험 디자인, 기술 구현의 강력한 헙업에 관한 것이다. 제품 발견 단계에서는 심지어 실제 소프트웨어 제품의 코드 한줄이라도 작성하기 이전에 다양한 위험들에 맞선다.

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

구체적으로 이는 다음 네 가지 중요한 질문에 답을 하는 과정이다.

1. 사용자들이 이 제품을 살 것인가?
2. 사용자가 이 제품을 어떻게 사용하는지 이해할 수 있는가?
3. 우리 엔지니어가 이것을 만들어 낼 수 있는가?
4. 우리 이해 관계자가 이것을 지지하는가?

🥕 프로토타입

제품 발견은 일련의 빠른 실험들의 진행을 포함한다. 그리고 그 실험들을 빠르고 적은 비용으로 진행하기 위해서 실제 제품보다는 프로토타입을 활용한다. 그것들은 최소한 제품을 구현하는 데 드는 시간과 노력보다는 작은 규모로 진행되어야 한다.

프로토타입은 제품 출시를 위한 것이 아니고, 회사가 제품을 판매하고 비즈니스를 만들어 내기 위한 것도 아니다. 그것은 빠르고 저렴한 비용으로 학습하기 위해 대단히 유용한 수단이다.

🥕 제품 실행

제품 발견에서 프로토타입과 실험의 목적은, 이 아이디어가 만들 만한 가치가 있는지 그래서 고객에게 전달할 수 있을지에 대한 증거가 될 만한 무언가를 빠르게 찾아내는 것이다.

제품이 기획한 대로 만들어지기 위해서는 규모, 능력, 신뢰, 결함 허용, 보안, 개인정보보호, 국제화, 지역화 등이 함께 실행되어야 한다.

제품 실행의 목적은 판매하고 비즈니스를 운형할 만한 품질 수준의 기술 제품을 만들고 전달하는 것이다.

🥕 제품과 제품/시장 궁합

제품 세계에서는 제품/시장 궁합을 달성하기 위해 최선을 다한다. 제품/시장 궁합이란, 특정 시장의 고객들이 원하는 것을 충족하는 가장 작은 단위의 실제 제품이다.

분명히 하자면 이것은 제품 실행 단계의 결과물로서 실제 제품이다. 제품 발견이 필요한 제품이 무엇인지 결정하는 것이라면 제품 실행은 구현-테스트-출시할 제품을 만드는 데 필요한 일을 하는 것이다.