아마존의 제품 개발 방법 Working Backwards

헉 이게 아니었는데 달리다보니 너무 멀리왔어 @.@

나폴레옹의 잘 알려진 일화가 있다.
알프스산맥의 거친 눈보라를 뚫고 백만대군의 절반을 잃으며 드디어 정상에 올랐는데 나폴레옹이 말했다.
“이 산이 아닌가봐” 두둥…
그래서 내려와 병사들을 다독여 다른 산에 겨우 올랐는데 그가 또 입을 열었다.
“아까 저 산이네”
…ㅠ.ㅠ
그러자 부하들이 “저 놈은 나폴레옹이 아니네” 라고 했다는~ (?)

방향의 중요성을 나타내는 이야기이다. 🙂

회사, 팀 또는 개인들은 각자가 만드는 가치를 사용자에게 전하기 위해 여러 노력을 기울인다. 그런데 중간중간 ‘이거 좋을 것 같아!’ 라는 기능이 있어서 살을 붙이고, 혹은 안붙이고, 여러 피드백과 상황에 따른 판단들을 반영하다보면 길을 잃거나 생각한 것과 달리 멀리 돌아가기도 한다. 나폴레옹 이야기처럼 끔찍한 상황은 아니겠지만 말이다. 😉 만들어나가는 단계들이 어디를 향해 있는지, 과연 가치에 집중하여 제대로 가고 있는가 확인하는 것은 매우 중요하다. 뚝딱뚝딱 또는 우당탕탕하며 만들어진 제품과 가치는 최종적으로 사용자, 고객에게 전달되게 된다.

아마존은 그 고객에 주목하여 시작한다. 🙂
이름하여 Working Backwards, 아마존의 제품 개발 방법론이다.
이것은 바로 고객으로부터 시작해서 거슬러 올라가는 작업을 말한다.

아마존의 제품 개발 방법 http://t.co/OT2CqllV "working backwards" PM이 한장짜리 완료보고서를 예상 작성후,제품 수익자들에게 배포해서 확인하고 그 내용이 정말 타당할때까지 반복수정. 실제 개발시엔 시금석으로 사용

— 권정혁/구루 (@xguru) January 9, 2013

이하는 트윗에 링크된 아래 두 페이지의 내용의 일부를 섞어 번역한 것이다:

• http://www.quora.com/What-is-Amazons-approach-to-product-development-and-product-management
• http://www.shmula.com/start-with-the-customer-and-work-backwards/324/

---

고객부터 시작하여 거꾸로 작업하기

아마존에는 널리 사용되는 “Working Backwards” 라 불리는 접근방식이 있다.
제품에 대한 아이디어로 시작해서 고객들을 그것에 고정시키는 것이 아니라, 고객으로부터 시작해서 거슬러 올라가는 작업을 말한다. 어느 경우에나 적용할 수 있지만, 이 접근은 특히 새 제품이나 기능을 개발할 때 중요하다.

1. 보도자료 작성

먼저 PM은 완성된(될) 제품에 대한 내부 보도자료를 작성하는 것으로 시작한다. 이 보도자료의 대상 독자는 새로 업데이트된 제품을 구매할 고객 또는 툴과 기술에 대한 내부 고객일 수 있다. 보도자료는 제품이 무엇이고 왜 이러한 제품이 있는지, 다시 말해 기능들은 무엇이고 이점은 무엇인지를 간단하게 설명해야 한다. 고객이 가진 문제와 함께 현재 나와있는 솔루션들이 어떻게 실패했는지 말하면서, 새 제품은 기존 제품을 어떻게 대체할 것인지의 내용에 주안점을 둔다. 매우 명확해야 하고 요점을 짚어야 한다. 보도자료를 작성하는 것은 이 제품에 대해 내부적으로 어떻게 생각하고 있는 것이 아닌, 세상 사람들이 그 제품을 어떻게 볼지를 명백하게 한다. 나열된 제품의 강점들이 별로 매력적이지 않다면 고객들은 설치하지 않을 것이다. PM은 그 이점들이 정말 타당하다고 생각될 때까지 보도자료를 반복 수정해야 한다. 이것은 제품 자체를 반복 개발하는 것보다 비용이 훨씬 적게 들고 더 빠르다!

다음은 보도자료 개요의 예이다:

• 제목 – 독자(대상 고객)가 이해할 방법으로의 제품을 명명한다.
• 부제 – 상품에 대한 수요자가 누구이고, 그들이 얻을 혜택을 설명한다. 타이틀 아래에 오직 한 문장으로만 한다.
• 요약 – 제품과 그 혜택을 요약한다. 독자가 다른건 읽지 않을 것이라 가정해서 문장을 잘 만들어야 한다.
• 문제점 – 제품이 해결한 문제를 설명한다.
• 해결법 – 그 문제를 어떻게 멋지게 풀어냈는지 설명한다.
• 인용 – 회사 대변인으로부터의 인용문을 넣는다.
• 시작하기 – 시작하기 쉽다는 것을 설명한다.
• 고객 인용 – 가상 고객이 어떤 혜택을 경험했는지 표현하는 인용을 제공한다.
• 맺음말과 해야할 것 – 정리 후, 독자가 다음에 해야 할 포인터를 준다.

보도자료는 한장 정도로 작성하고, 문단마다 3-4 문장으로 제한하며 과한 부분은 잘라내야 한다. 명세서를 쓰는 것이 아니다. 보도자료로는 고객이 얻는 것에 집중하도록 하고 다른 비즈니스 및 실행에 대한 내용은 FAQ를 붙일 수 있다.

“Oprah-speak” (오프라 윈프리 쇼) 식으로 보도자료를 작성한다. 소파에 앉아 오프라에게 제품을 설명하고나서 그녀가 청중들에게 그것을 설명하는 것을 듣는다고 상상해보자. 이것은 “Oprah-speak” 이지, “Geek-speak” 이 아니다.

프로젝트가 개발 단계로 가면 이 보도자료는 시금석과 등대가 될 수 있다. 팀은 스스로에게 “우리가 이 보도자료에 있는 것을 만들고 있나?” 라는 질문을 던질 수 있다. 만일 보도자료에 없는 것을 (또는 지나친 것을) 만드는데 시간을 쓰고 있다면 왜 그런지 물어봐야할 것이다. 이것은 제품 개발이 고객에게 강점을 가져다 주는 것에 집중하도록 하고 관계없는 것은 더 이상 하지 않도록 한다.

2. FAQ 문서 작성

보도자료를 통해 제공되는 뼈대에 살을 붙일 수 있는 곳이다. 이것은 보도자료를 공개했을 때 받을 질문들과 이것이 왜 좋은지 명시하는 내용을 포함한다. 사용자의 입장에 서서 받을 수 있는 모든 질문들을 고려해봐라.

3. 고객 경험을 정의

제품으로 하게 될 여러가지에 대한 고객 경험을 세밀한 항목들로 설명한다. 사용자 인터페이스 경우 각 화면에 대한 목업을 만들 수 있다. 웹 서비스 경우는 사용자들이 어떻게 사용할지에 대한 유스케이스를 코드 스니펫을 포함하여 작성한다. 이것의 목적은 사용자가 이 제품으로 어떻게 그들의 문제를 풀어냈는지에 대해 스토리를 말하는 것에 있다.

4. 사용자 설명서 작성

사용자 설명서는 제품이 어떤 것이고 어떻게 써야하는지에 대해 정말 알기 위해 사용하는 것이다. 사용자 설명서는 일반적으로 컨셉, 사용법, 레퍼런스의 세 섹션으로 나뉘며 그 안에는 제품을 사용하기 위해 알아야만 하는 모든 것이 들어간다. 사용자 타입이 하나 이상이라면, 하나 이상의 사용자 설명서를 쓴다.

이 프로세스를 따르는 것은 concept-to-delivery (브레인스토밍, 토론, 논쟁) 주기를 놀랍도록 줄였다. 왜냐하면 팀과 관계자들이 제품의 결국 보여질 모습을 보는 것보다 일찍 동의했기 때문이다.
이 프로세스는 사용자들을 중심에 두고, 프로세스에 걸쳐 간결함과 명확함을 이끈다. 고객에서 시작해서 거꾸로 작업하는 것은 효과적이며 사용자를 제 위치에 있게 하는 매우 효율적인 프로세스이다.

---

보도자료 작성 예

아래는 현재 베타 서비스되고 있는 Veckon 을 예로 하여 보도자료를 작성해본 것이다.

스타트업 Veckon, 웹 기반 화상통신 서비스 ‘Veckon’ 출시

누구나 바로, 다중 화상통신을 가장 쉽게 할 수 있는 방법

국내 주목받는 스타트업인 Veckon 은 업계 최초로 가입단계 없는 웹 기반 비디오 커뮤니케이션 ‘Veckon (http://www.veckon.com)’ 서비스를 12일 베타 오픈했다.
Veckon 은 별도의 설치과정 없이 누구나 바로 간편하게 무료로 화상통신할 수 있는 서비스이다.

다양한 화상통신 서비스가 이미 마켓에 있지만, 상대방과 동일한 기기나 앱이 있어야하며 서로 간에 확인 후에야 가능하다. 또한 반드시 가입절차를 거쳐야 할 뿐더러 사용법을 익혀야해서 바로 사용하기엔 번거롭다.

Veckon 은 가입절차가 없어 매우 간편하며, 누구든지, 웹브라우저가 있으면 언제 어디서나 사용할 수 있다. 사이트의 시작버튼을 누르기만하면 채팅방이 바로 개설되며, 생성된 URL 주소를 단지 상대방과 공유하기만 하면 된다. 해당 URL로 접속하는 누구나 통신할 수 있기 때문에 그룹 채팅도 가능하며, 원거리 화상회의에 매우 유용하다. WebRTC (Web Real-Time Communication) 기술이 지원되는 웹브라우저이어야 하며 현재는 Chrome, Chrome mobile(Android), Firefox 가 해당된다.

Veckon 의 메인 개발자인 이원제 CTO는 이날 서울 선릉 D.CAMP에서 열린 간담회에서 “다양한 의사소통 수단 중 보고 말하는 방법은 굉장히 강력함에도 불구하고 정작 화상통신과 회의는 아직 미성숙한 시장과 문화에 머물러 있다”며, “사용자들이 더욱 쉽고 간편하게 웹을 통해서 화상통신을 하고, On/Offline의 경계를 이어 진심이 담긴 소통이 이루어지도록 서비스를 개선해 나가겠다”고 말했다.

Veckon 서비스는 홈페이지(http://www.veckon.com)를 통해 회원가입없이 바로 사용할 수 있다.

베타 서비스의 사용자인 김ㅇㅇ 성형외과 원장은 “성형 상담시 굳이 병원에 직접 방문하지 않아도 되고 가입이 필요없어 환자들의 부담을 덜게 되었다”며, “웹을 통한 고화질 화상회의라는 점이 중국 등의 해외 환자들과 쉽게 연결해주어 환자들과 병원관계자 모두 만족스러워 하고 있다”라고 말했다.

Veckon 의 가입없는 웹 서비스라는 특징에서 앞으로 화상통신이 개인만이 아니라 비즈니스 등으로 어떻게 확장할 수 있을지 귀추가 주목된다. Veckon 은 홈페이지(http://www.veckon.com)에서 베타 서비스를 시작했으며 블로그(http://blog.veckon.com)도 함께 운영중이다. 문의사항은 트위터(@veckoninc)와 페이스북 페이지(http://www.facebook.com/Veckon)를 활용하면 된다.[/dropshadowbox]

정리

얼마 전에 읽은 책인 인생학교 – 일 에서는 드라마틱하긴 하지만 자신의 부고 기사를 써보는 것이 어떠하냐고 권한다. 훗날 인생을 돌아봤을 때 내가 한 일이나 했으면 좋았을 것 같은 일들을 써보는 것은 뒤늦게 후회하지 않게 하는 놀랍고도 효과적인 방법이라고 말한다. Working Backwards 도 비슷한 맥락이라고 생각한다. 🙂
전에 서비스 초기 기획 단계에 보도자료를 작성해서 내부 관계자분들께 피드백을 받은 경험이 있다. ‘이런거 하려고 해요!’ 를 설명하기에 좋았다. 할 수 있는 한 빨리 피드백을 받으라는 애자일 모델링 원칙에도 맞는다. 방법론에 대한 무조건적인 적용은 좋지 않다고도 생각하고, 실제 본격 개발 단계로 들어가지 못해서 위 방법에 대해 전체 프로세스에 걸친 경험이 없다. 하지만 사용자 중심으로 사고하고, 방향을 잊지 않도록 하는 접근방식은 의미있고 배울만하다고 생각한다.
사용자 중심으로, 길을 잃지 않고 많은 사람들이 즐거움을 느끼는 서비스를 제대로 만들었노라고 내 부고 한켠에 적히길 바란다. 😉