PM이 회의를 리딩하는 방법

사용자를 생각해서 UX를 만들었다.

하지만 제품 개발은 리소스와 현실을 고려해야 한다.

가설, 사용자 UX, 개발 사이에서 어떻게 조율하는지

이 글은 PM으로서 내가 그런 순간을 어떻게 풀어내는지 기록하는 글이다.

---

2주 안에 출시해야 하는 기능이 있었다.

백엔드, 웹, iOS, 안드로이드 개발자들과 함께 기능 구현 회의를 시작했다.

나는 유저 흐름을 기준으로 설계한 UX 플로우 설명하고 왜 만들어야 하는지를 열심히 설명했다.

"지금 흐름은 작성한 오더가 있는지 몰라서 사용자가 계속 다시 오더를 작성해해요, 실험으로 진행할 거고 플랫폼 간 싱크도 맞춰야 하고 우리의 성공 지표는 구매전환이고 유저스토리는 이렇습니다!"

웹과 아이폰 개발자는 이것저것 질문을 하는데 안드로이드 개발자는 아무 말 없이 UX만 쳐다보고 있었다.

혹시 안드로이드 쪽은 문제가 있을까요?

“이 흐름은 저희 쪽 구조를 뜯어고쳐야 해요. 꽤 많은 공수가 들어갈 것 같아요.”

플랫폼 간 구조가 다르게 설계되어있었나 보다.

여기서 내가 할 수 있는 일은 질문을 하며 스코프를 조절하고 싱크 맞추기이다.

Q. 웹과 아이폰은 어떻게 구조화되어 있나요? 안드로이드는 어떻게 되어 있나요?

Q. 안드로이드에서는 이 기능을 구현하려면 어느 정도가 필요한가요?

Q. 그럼 어떻게 하면 스코프를 줄 일 수 있을까요?

안드로이드 개발자가 고민하는 부분을 백엔드와 웹 개발자도 같이 고민해 주면서

우리는 UX를 같이 그리면서 협의했다.

그리고 회의 시간에 있었던 일을 디자이너에게도 공유하고 디자인으로 반영해 다시 커뮤니케이션했다.

회의 자리에서 저렇게 서로 상황을 공유하고 말할 수 있는 사이가 너무 특별하다.

저 회의에서 안드로이드 개발자가 불편해서 말을 안 했다면 저대로 만들다가 기간이 너무 길어져서 나는 물어볼 거고 그제야 안드로이드 개발자가 구조를 변경하고 있어서 좀 오래 걸린다라고 말했다면 지금보다 많은 시간이 낭비 됐을 것이다.

회의는 결정의 순간이기도 하지만, 무언가를 다시 정리하고 조율하는 시간일 때가 많다.

PM으로서 내가 할 수 있는 일은 모두가 말할 수 있도록 돕고, 질문하며 현재 상황을 편하게 이야기할 수 있도록 분위기를 만드는 것이다.

회의에서 침묵이 있더라도 그 회의를 포기하지 말고

PM의 에너지로 질문을 유도하여 다른 방법을 찾던지 기간을 늘리던지 결정을 하자!