빠른 실행 속에 내가 자주 놓쳤던 것

모든 아이디어는 말 그대로 가설이기 때문에 실험해보기 전에 옳고 그름에 대해 너무 많은 시간을 들여 끝장 토론을 하는 것은 의미가 없다. 회의를 통해 상대방의 아이디어를 듣고 피드백을 주고, 다양한 생각이 쌓여가며 의견이 발전해 나가야 하는데, 자신의 의견만 고수하느라 회의가 답답하게 진행되는 경우가 있다. 반대로, 처음에는 별로인 것 같은 아이디어도 다양한 피드백이 더해지면서 새롭고 창의적인 방향으로 발전되어 좋은 가설로 귀결되는 경우도 많다. (-세컨드펭귄, 임승현 지음, p.197)

올해 가장 인상깊게 읽은 세컨드 펭귄이라는 책에서 가장 좋아하는 부분이다. (독후감을 가다듬는 작업이 끝나면, 메이커로그로도 남겨보려고 한다.)

좋은 아이디어는 내는 것이 아니라 만들어가는 것

아이디어 회의나 미팅이라고 해놓고, 자신이 세운 정답을 설득하는 데에만 열을 올리는 사람과 함께하면 매우 피곤하다. 그걸 너무 싫어하면서도, 아이디어를 기획하다 보면 그것에 매몰된 나머지 은근슬쩍 내 생각을 설득시키는 것에 집중하는 나를 종종 발견한다.

매몰된 생각에서 빠르게 벗어나기 위해서 다른 사람들이 낸 가설과 아이디어를 다시 곱씹는다. '아 별로인 것 같은데..' 사실 이 생각이 먼저 든다. 하지만, 거기서 한 발짝 더 나아가서 저걸 내 스스로도 납득할 정도로 디벨롭 시킬 수 있을 지를 고민한다. 그리고 이해가 되지 않는 부분은 질문하고 부족한 부분을 함께 채워간다. 대체로 그렇게 기획한 실험들이 성과가 좋았다.

시간을 써야 한다면

누구의 의견이 옳은 지 갑론을박 하는 것은 크게 의미가 없다. 모두 다 실험과 검증이 수반되어야 비로소 가치가 드러나는 '가설'이기 때문이다. 차라리 해당 가설을 어떻게 검증하고 어떤 지표를 어떻게 추적하고 계산할 지에 대한 고민을 하는 데 시간을 쓰기를 권한다. 이런 디테일을 고민하지 않고 실행에 옮기면, 정작 원하는 인사이트는 얻지 못하고 시간만 많이 쓴 프로젝트가 되기 쉽다. 말은 쉽게 하지만, 나는 저번 주에도 비슷한 실수를 했다.

정리하자면

• 다른 팀원이 낸 아이디어를 스스로가 납득할 가설로 함께 디벨롭하기

• '가설'로 끝장토론 하지 말고 고객 검증하기

• 해당 가설을 검증하기 위한 액션 플랜과 측정할 성과지표의 타당성 검토하기

이 정도가 될 것 같다.

너무 잘짜여진 가설과 액션 플랜을 보며 하루 빨리 실행하고 싶은 나머지 해당 프로젝트의 성과 지표에 대한 디테일한 설계를 종종 놓친다. 그래서 항상 실행 직전에 스스로와 팀원들에게 묻는다. "저 지표를 보는 것이 맞을까요?"