프로덕트팀내 신뢰를 쌓는 방법

협업툴 마림바이야기 #19

#역할자 #프로덕트팀 #애자일 #린스타트업 #마림바 #퍼소나 #디자인 #신뢰

조와 애나는 두 개의 프로토타입을 정제하고, 인터뷰를 준비하고 있었다. 사용자 리서치 때 함께 잡아놓은 7개의 인터뷰를 빠르게 확인했다. 다양한 IT분야의 잠재 사용자들과의 인터뷰가 준비되었다.

-------------------------------------------

- 영국 엔젤 스타트업 풀타임 원격근무 프로덕트 매니저

- 미국 시리즈 C 스타트업 풀타임 원격근무 기술지원 매니저

- 미국 시리즈 A 스타트업 파트타임 원격근무 프로덕트 매니저

- 미국 시리즈 B 스타트업 파트타임 원격근무 프로덕트 매니저

- 독일 시리즈 C 스타트업 풀타임 원격근무 개발 리더

- 미국 대기업 애자일 코치

-------------------------------------------

조가 말했다.

"우리 크리스와 가장 가까운 사람부터 우선순위를 정해보죠"

'크리스'는 우리가 정한 퍼소나의 이름이었다. 조와 애나는 함께 우리가 정한 퍼소나를 보며 대화를 나누고 있었다. 퍼소나는 우리가 정한 타깃을 명확히 하고 그들의 문제를 쉽게 파악할 수 있도록 고민하여 만들었다. 퍼소나는 가능하면 구체적인 것이 좋다. 레이저 포커스하여 정확한 사용자층을 먼저 타깃해야 하기 때문이다.

퍼소나 크리스

가장 먼저 타깃한 사용자도 만족시키지 못하면, 우리가 정한 문제와 솔루션은 시작부터 모호해진다. 때문에, 퍼소나를 정하고 일관된 커뮤니케이션을 해야 한다. 여전히 이 퍼소나는 잠재 사용자들을 만나면서 계속 조금씩 업데이트해야 하는 것이지만, 그때마다 여전히 구체적이고 일관되어야 한다.

팀 내에서 퍼소나와 퍼소나의 업무 시나리오에 대한 이해는 매우 중요하다. 이 두가지를 이해하면서 만드는 기능과, 이해가 부족한 상태에서 기능을 만드는 것은 개발자 입장에서도 천지차이의 결과를 만든다. 이러한 이해가 동반된 개발자들은 태도부터 달라진다. 이를 이해하는 개발자들은 종종 다음과 같은 가치 제안을 할 수 있다. 

"설계가 이렇게 되어 있지만요. 우리 '크리스'가 좀 더 가치를 얻으려면 이렇게 하면 어떨까 하는데 어떻게 생각하나요?"

퍼소나에게 보다 큰 가치를 주기 위해 개발자가 제안을 하는 경우, 말을 하는 개발자도, 듣는 프로덕트 매니저도, 이를 디자인한 디자이너도 제품에 대한 온전한 오너십을 공통적으로 느끼게 된다. 이들의 대화는 프로페셔널리즘이 기반이 되어 '내 제품'을 더 잘 만들고 싶다는 욕구로 서로에게 전해진다. 그리고 제품의 가치를 높이기 위한 치열한 토론이 시작된다.

이러한 토론을 할 때 주의할 점은 '기획 방향'과 '구체적인 설계'를 한 프로덕트 매니저와 '사용자'를 만나 '디자인'한 디자이너는 개발자들에게 최대한 '증명'을 통한 올바른 설명을 해야 한다. 직접 만나 본 잠재 사용자 검증을 통해 퍼소나에 가장 가까운 복수의 사람들의 반응을 말해주어야 한다. 그리고 현재의 기획 및 디자인 방향이 퍼소나에게 가장 현재 상태로는 최적 안일 것이라는 확신을 대화 속에 알려주어야 한다. 이는 당연히 퍼소나의 사용자 시나리오를 기반으로 진행된다.  

이러한 대화를 통해 팀은 신뢰를 쌓는다. 그리고 이러한 대화를 반복적으로 몇 차례 하게되면, 이제부터는 더 이상은 많은 설명을 하지 않아도 서로를 이해하는 순간이 온다. 어떤 역할자가 A라고 말하면, 더 이상 많은 '증명'을 요구하지 않는다. 대신에, 고개를 끄덕이고 바로 움직인다.

이러한 순간은 팀원간 단단한 '신뢰'로 발생한다. 내가 지금 기능에 대해 약간씩 부족한점을 발견하더라도 프로덕트 매니저나 디자이너는 내가 고민하기 전에 이미 훨씬 더 많이 고민했을 것이라 신뢰하기 때문에, 우선 실행한다. 팀이 앞으로 함께 나아가는 것이 가장 중요하기 때문이다. 

하지만 그렇다고 맹목적으로 백이면 백 다른 역할자의 결과물을 그대로 수용하는 것은 결코 팀을 위해 좋은 방법이 아니다. 소프트웨어 개발은 태생적으로 후행 공정이 선행공정보자 구체적일 수 밖에 없다. 다시 말해 기획은 디자인보다 구체적일 수 없다. 디자인은 개발보다 구체적일 수 없다. 디자인을 하며 기획에 대한 보다 구체적인 정의를 디자이너가 반대로 프로덕트 매니저에게 알려줄 수 있고, 개발을 하며 보다 구체적인 정의를 프로덕트 매니저와 디자이너에게 알려줄 수 있다.

때문에 제품이나 서비스를 만드는 팀은 반드시 서로에게 기획 또는 디자인에 대한 질문을 해야 한다. 이를 통해 온전한 서비스의 가치가 만들어진다.

-------------------------------------------

(1) 영국 엔젤 스타트업 풀타임 원격근무 프로덕트 매니저

(2) 독일 시리즈 A 스타트업 풀타임 원격근무 개발 리더

(3) 미국 시리즈 A 스타트업 파트타임 원격근무 프로덕트 매니저

(4) 미국 시리즈 B 스타트업 파트타임 원격근무 프로덕트 매니저

(5) 미국 시리즈 C 스타트업 풀타임 원격근무 기술지원 매니저

(6) 미국 대기업 애자일 코치

-------------------------------------------

조와 애나는 위와 같이 인터뷰의 우선순위를 정했다. (1)의 영국 엔젤 스타트업 프로덕트 매니저는 현재 직원이 7명밖에 되지 않는 시작단계의 스타트업이었다. 우리가 최초 정한 20명 이하의 사업장의 프로덕트 매니저라는 퍼소나와 일치하는 곳이었다. 이 때문에 가장 위에 우선순위를 두었다.

(2), (3)도 우선 규모를 먼저 고려했다. 규모가 커지면 필연적으로 팀과 팀 간의 커뮤니케이션이 많아질 것이라 우리가 원하는 퍼소나가 안될 것이라는 가정 때문이었다. 또한 풀타임 원격근무 형태가 우리에게는 중요하다는 생각이었다. 파트타임은 우리가 가정한 '사회적 고립'이라는 느낌을 받기 어려울 것이라 생각했기 때문이다.(4), (5) 또한 회사 규모 > 원격근무 형태 > 역할 순으로 우선순위를 두어 정했다. (6)은 우리가 원하는 퍼소나와 많이 달랐다. 나중을 위해 우선은 인터뷰 대상에서 제외했다.

팀은 한 명당 1시간 정도의 인터뷰를 수행하기로 계획했다. 팀에게 인터뷰해주는 잠재 사용자들 모두 너무나 귀한 시간을 내주는 것이기에, 소정의 선물을 준비했다. 그리고 당연히 비밀유지 계약서를 함께 준비했다. 인터뷰는 3인 1조로 진행했다. 한 명이 질문하고 다른 한 명은 관찰하고 다른 한 명은 회의록을 적는다. 그리고 인터뷰 결과는 이 세명의 인사이트로 다시 정리한다.  

우리는 빠르게 첫 번째 인터뷰 준비를 마쳤다. 우리는 줌을 활용하여 첫 번째 인터뷰를 했다. 우리는 첫 번째 동그랗게 비디오 콜로 모양을 내어 커피를 마시는 시나리오를 보여줬다. 그리고 최대한 그들의 반응을 듣기로 했다.

"아.. 이건 정말... 뭐라고 말을 못 하겠네요. 너무 스타트업을 모르시는 것 같아요."

우리의 시나리오를 본 그녀의 반응은 차가웠다.

(계속)

----- 원격으로 일하는 가장 쉬운 방법 마림바 -----