10.17 ~ 10.28 인스파이어드를 읽고

좋은 문장이 많았다.

하지만 내가 문장을 이해하더라도, 경험 부족 등의 이유로 아직 체감되지 않는다면 옮기지 않는다.

 

19p

모든 비즈니스 케이스의 핵심적인 두 가지 요소를 기억하는가? ‘얼마만큼의 돈을 벌 수 있는가’와 ‘얼마만큼의 비용이 드는가’다. 자, 냉엄한 진실은, 현재 시점에서 우리는 이 두 가지 수치에 대한 근거가 전혀 없다는 것이다. 솔직히 우리는 알 방법이 없다.

 

• 왜 해야 하는가?
• 무엇을 위한 것인가?
• 누가 ( 어떤 고객이 ) 하라고 했는가?
• 그 누가 몇 명인가?
• 그 누가 어느 정도 매출에 영향을 주는가?
• 이렇게 하라고 했는가?

나는 일을 할 때는 항상 사용자와 비즈니스 관점에서 질문을 던져봐야 한다고 믿는다. 납득이 되지 않는다면 아직 실행에 옮겨서는 안 된다. 납득 없이 바로 행동하는 건 그 행동 비용과, 그 행동을 번복하기 위한 비용을 발생시킨다.

 

26p ~ 27p

위험은 마지막보다는 초기에 대응한다. 제품은 순차적인 방식보다는 함께 협업하며 정의되고 설계된다. 끝으로 기능을 구현하는 것이 아니라 문제를 해결한다.

 

각자의 역할을 존중하는 것은 좋다.

하지만 그 역할 존중이 제품팀 전체에 피해를 주는 방향으로 가서는 안 된다.

간혹 존중이 지나쳐, 미연에 방지할 수 있는 위험을 방치하게 된다면 그거야말로 존중하지 못하는 태도다.

상대의 역할, 나와 다른 직군에서의 전문성을 존중한다는 게 상대의 작업으로부터 눈 돌릴 이유가 되진 못한다.

 

전통적인 로드맵은 생산량에 대한 것이다. 강한 팀은 그것이 단순히 솔루션을 구현하는 것이 아니라고 이해한다. 그들은 솔루션은 근원적인 문제를 반드시 해결해야 한다고 믿는다. 바로 사업적인 성과에 대한 것이다.

 

프로젝트를 끝내는 건, 어떤 제품을 만드는 일보다도 훨씬 간단한 일이다.

주어진 명세를 해석하고, 명세대로 만들기만 하면 그만인 일이지만, 업보다는 ‘직’을 위한 태도에 적합하다.

사람의 일은 결국 만류귀종이라, 바퀴를 만드는 일도 극에 달하면 결국 한 가지 철학과 다를 바 없는데,

일을 하면서도 아무런 생각을 하지 않는 건 자신에게 주어진 시간을 너무나 낭비하는 일이다.

 

68p

고객이 그 제품을 어떻게 처음 알게 되는가? 처음 방문한 사용자를 어떻게 안착시키고 ( 아마도 천천히 ), 새로운 기능을 소개할 것인가? 고객의 하루 일과에 따라 제품과 어떻게 상호작용이 발생하는가? 사용자의 관심을 두고 어떤 것들과 경쟁을 하고 있는가? 한달이 된 고객과 1년이 된 고객은 어떤 차이점들이 있을까? 제품에 대한 더 높은 애착을 가지게 하기 위해서 어떻게 사용자에게 동기부여 할 수 있을까? 어떻게 희열을 느끼는 순간을 만들 수 있을까? 사용자가 다른 사람에게 어떻게 경험을 공유할 수 있을까? 고객이 오프라인 서비스를 어떻게 사용할 수 있을까? 제품의 반응성을 어떻게 느끼고 있는가?

 

머리에 띵했다.

내가 만든 기능들은, 유저들은 존재한다는 걸 알기나 할까, 그리고 그걸 어떻게 활용할 것인가.

나는 최근 유저들이 자신의 데이터를 조회할 수 있는 공간을 설계했고, 이를 알릴 방법으로 뉴스레터를 제안했다.

이 페이지가, 저 위 질문들에 대한 답이 되줄 수 있기를 바란다.

 

94p

시스템은 복잡성과 규모가 증가하는 것이, 누군가가 그것을 문서로 정리하는 속도보다 항상 더 빠르다. 그리고 소프트웨어에서 절대적인 답은 항상 소스 코드에서만 찾을 수 있다. ( 과거 자료나 근거를 찾는 경우 말고, 현재 상황에 대한 답을 찾을 때는 )

96p

구체적으로 다음 네 가지의 탁월한 핵심 역량이 검증된 사람을 찾아야 한다. (1) 팀 개발, (2) 제품 비전과 전략, (3) 실행, (4) 제품 문화

116p

처음에는 몇 개의 제품팀으로 나누기 시작하며, 점차 확장하면서 25개, 50개, 100개의 제품팀이 된다. 이는 회사가 빠르게 움직이는 역량에 매우 중요한 요인이 된다. 그리고 각 팀이 의미 있는 권한과 책임감을 느낄 수 있도록 유지되려면 각 부분의 합보다 전체가 더 큰 효과를 낼 수 있도록 보다 큰 비전을 제시해야 한다.

 

우리가 가진 돈이 한정적이고, 일반적으로는 그 돈이 딱 한 번의 프로젝트를 시도할 수 있다고 해보자.

그렇다면 우리는 단 한 번의 시도로 성공을 거두지 않으면 와해될 팀일 수 밖에 없다.

성공 가능성을 높이기 위해서는 시도 횟수를 늘려야 하는데, 돈이 한정적이라면 어떻게 해야 하는가?

방법은 한 프로젝트 당 들어가는 비용을 줄이는 수 밖에 없다.

정말 필요한 핵심 기능들만 가진 채 프로토타입을 만들고, 추가 개발이 마땅한 일인지 검토해봐야 한다.

나는 이런 게 린 스타트업이라고 생각한다.

하지만, 개인적인 생각이지만, 조직은 커지면 커질수록 비효율이 증대된다고 본다.

아마, 조직이 가진 자원이 늘어남에 따라, 실패를 가볍게 여기는 분위기가 확산되는 건 아닐까 싶다.

예전처럼 이번 도전 한 번 잘못하면 다 같이 망하는 일이 발생할 일이 없으니, 안심하는 분위기라고도 할 수 있겠다.

이런 분위기는 사실 제품을 만드는 데에 좋은 것 같지는 않다.

적당한 긴장감이, 더 나은 제품을 만드는 데에, 제품 개발자 ( ≠ programmer ) 들을 몰입하게 해준다고 본다.

그래서 조직이 커짐으로 인해 안심을 느낀다면, 조직을 다시 여러 개의 작은 조직으로 나눠야 한다.

각 부분의 합이 전체보다 크려면, 나눔으로 인해 늘어난 생산성이 나누기 전보다 커야 한다.

생산성은 긴장감으로부터 온다고 생각한다.

 

131p, 135p

내가 정의하는 제품 로드맵은 팀이 해야 할 일에 대한 우선순위가 정해진 기능과 프로젝트들의 목록**이다. 이러한 제품 로드맵 작업은 보통 분기에 한 번씩 수행되며, 석 달마다 실행하는 회사도 있고, 1년에 한 번 하는 회사도 있다.

아무리 좋은 의도가 있었다고 하더라도 제품 로드맵은 일반적으로 매우 실망스러운 비즈니스 성과를 초래한다. 그 이유를 내가 쓰는 표현으로 하자면 ‘제품에 관한 두 가지 불편한 진실’이다. 첫 번째 진실은 최소 절반 이상의 아이디어가 유효하지 않을 것이라는 사실이다. 아이디어가 기대한 효과가 없는 데는 많은 이유가 있다. 대부분은 이 아이디어에 대해 우리만큼 고객이 관심을 가지지 않는 경우다. 그들에게 가치가 없으므로 사용하지 않는 선택을 한다. 가장 보편적으로 발생하는 상황이다.

 

할 걸 다 하고 나서 유저에게 선택받는가 안 받는가의 문제는 결국 우리가 마지막까지 검토못한 부분에 달린다.

정말로 최선을 다 했다면, 이제 그 부분은 운 밖에 남지 않는다.

따라서 제품 로드맵은, 운이 있다는 가정 하에 만들어진, 허위 보고서에 가깝다.

로드맵이 나쁜 건 아니지만, 적어도 내가 경험한 걸로만 보더라도 초기 스타트업에는 별로 쓸 모가 없었다.

 

142p ~ 143p

약속에 대한 모든 근심의 근본적인 원인은 약속이 발생하는 ‘시점’이라는 점을 이해하는 것이 핵심이다. 약속이 너무 이른 시점에 발생하는 것이 문제다. 책임지고 제품을 전달할 수 있을지 알기도 전에 약속이 발생해버린다. 더 중요한 것은 우리가 전달하는 제품이 고객의 문제를 해결할 수 있을지도 모르는 상태라는 것이다.

 

언제까지 완성할 수 있냐는 질문에 답하기 항상 곤란한 것도 이 부분이다.

 

149p ~ 150p

제품 비전과 전략의 차이점은 마치 좋은 리더십과 좋은 관리의 차이점과 비슷하다. 리더십은 영감을 주고 방향을 제시하고, 관리는 목표한 곳으로 우리를 이끄는 데 도움을 준다.

 

리더십과 관리의 차이가 명쾌하다.

 

157p

좋은 제품 원칙은 특정 제품 기능에 영감을 줄 수도 있다. 그것보다는 회사나 제품팀들이 중요하다고 믿는 것에 대한 것이다. 예를 들어, 초기 이베이에서 우리는 구매자와 판매자이 관계에 대한 제품 원칙의 필요성을 느끼고 있었다. 대부분 수익은 판매자로부터 발생하였으므로 우리는 판매자를 만족시키려는 방법을 찾는 데에 강한 동기부여가 되어 있었다. 하지만 곧 판매자들이 우리 제품을 좋아하는 진짜 이유는 우리가 많은 구매자를 제공했기 때문이라는 것을 깨달았다. 그 교훈을 바탕으로 중요한 원칙이 만들어졌다. “구매자와 판매자가 서로 원하는 것 사이에 충돌이 발생하는 경우 우리는 구매자가 필요로 하는 것에 우선을 둔다. 그것이 판매자를 위해 우리가 할 수 있는 가장 중요한 일이기 때문이다.

 

내가 있던 이전 스타트업에서도, 판매자와 구매자 문제는 닭과 달걀 문제처럼 어려운 주제였다.

지금 와서 생각해보면 답도 없는 문제에 우리는 너무 많은 시간을 썼다.

판매자가 있어야 구매자가 있고, 구매자가 있어야 판매자가 있고, 결국 어느 쪽도 맞는 말이라면 선택의 문제다.

 

166p

제품 조직에 OKR을 적용할 때는 OKR을 제품팀 레벨로 초점을 맞추는 것이 핵심이다.

 

제품 조직 레벨로 OKR을 끌어 당기는 것 뿐만 아니라, 어떻게 그런 판단이 가능한지도 충분히 설명을 해야 한다.

내가 해야 할 일과, 조직이 해야 할 일이 서로 엇갈릴 때 당연히 조직을 위한 선택을 해야 한다.

하지만 내가 해야 할 일이, 결과적으로 조직을 위한 더 나은 선택이 아닐 거라고도 할 수 없다.

명확한 판단 기준이 없다면 OKR은 쓸 데 없는 얘기다.

 

201p

첫째는 분명한 목적과 연계성에 대하여 팀이 모두 같이 이해하고 있도록 하는 것이다. 특히 우리가 집중하고 있는 사업 목표는 무엇인지, 우리 고객을 위해 해결하고자 하는 구체적인 문제는 무엇인지, 어느 사용자 또는 고객의 문제를 해결하고 있는지, 성공은 어떻게 측정하는지 등에 대해 의견이 일치해야 한다. 이 항목들은 제품팀의 목표와 핵심 성과에 직접 연계되어 있어야 한다.

 

위에 적은 것과 동일하다.

 

205p

이 일은 어떤 사업 목표를 다루는 것인가? (목표(objective))
성공을 어떻게 판단할 수 있는가? (핵심성과(key result))
우리의 고객을 위해 어떤 문제를 해결하는 것인가? ((고객 문제(customer problem))
우리가 집중하고 있는 고객은 누구인가? (목표시장(target market)))

 

테스트

여기는 재미도 없고 써먹을 구석도 없어 보여서 건너뛰었다.

 

294p

매출과 브랜드를 지키는 것과 더불어, 우리는 직원과 고객 또한 보호해야 한다. 만일 우리의 고객 서비스팀, 전문 서비스팀 또는 영업 사원이 지속적인 변화의 사각지대에 있다면 그들이 업무를 제대로 수행하기 힘들고, 고객을 잘 관리하기가 매우 어려워진다. 마찬가지로, 고객들 또한 제품이 마치 움직이는 목표물처럼 느껴져서 끊임없이 다시 배워야 하는 상황에서 행복을 느끼지 못할 것이다. 이것이 우리가 고객 영향력도를 진단하는 것을 포함하여 완만한 배포(gentle deployment)를 실행하려는 이유다. 비록 이러한 방식이 선뜻 납득되지 않겠지만, 지속적 배포 (continuous deployment)는 매우 강력하고 완만한 배포 기법이다. 특히 고객 영향도 진단과 연계하여 적절하게 사용했을 때는 우리의 고객을 보호할 수 있는 강력한 도구가 된다.

한 번 더 말하면 대부분의 실험과 변화는 이슈가 되지 않는다. 하지만 고객과 직원을 위해 선제적으로 대비하고 변화에 세심하게 대응하는 것은 우리의 책임이다.

 

우리 서비스 ( 백 오피스 )도 현재 우리 운영팀을 제대로 배려하고 있지 못하다는 느낌을 받는다.

반면에 서비스 변경점은, 고객에게는 크게 영향을 못주고 있다.

개발 이후, 그걸 어떤 순서로 보여줄 것인지에 대해서도 생각해볼 법 하다.

 

299p

가치 입증을 위해 돈을 사용하기 가치 입증을 위해 평판을 이용하기 ( ⇒ 주변 사람들에게 소개할 수 있는가? ) 가치 입증을 위해 시간 이용하기 가치 입증을 위해 접근성 이용하기

 

우리 서비스를 위해 어느 정도 비용을 지불할 수 있는지를 확인해야 할 때, 반드시 돈을 예시로 들 필요가 없다.

 

309p

데이터가 의견을 압도한다.

 

우리가 가진 데이터는 충분한가?

데이터에서 옳다, 그르다는 판단은, 데이터가 충분하기에 옳고 그른 것인가?

아니면 아직 데이터를 더 수집해야 하는가, 또는 그 데이터를 수집하기 위한 방법이 정말 있는가?

데이터가 주관보다는 낫다고 생각하지만 우리가 가지고 있는 데이터로만 판단 가능한 것도 사실이다.

또한 데이터는 무슨 일이 일어났는지는 설명 가능하지만, 왜 그런지는 설명해주지 못한다.

 

315p

그들에게 해야 할 질문은 “이것을 할 수 있나요?”가 아니다. 대신 아이디어를 자세히 살펴보고, 다음과 같은 질문에 대답해 주기를 요청한다. “이 아이디어를 진행할 최선의 방법은 무엇인가요? 그것을 하는 데 얼마나 걸릴까요?”

 

너무나도 공감된다!

할 수 있냐고 물어보면 설마 하지 못한다고 대답하겠는가?

할 수 있는데, 그 전에 상대방의 질문이 어떤 걸 의도하고 있는지부터 명명백백하게 밝히고 들어가야 한다.

애초부터 질문이 나에게, 지금까지 들은 이야기를 어떻게 구현할 것이냐고 물어본 거라면 이야기는 간단하다.