유저와 얼마나 자주, 소통하시나요?

프로덕트를 만들다 보면 항상 고민되는 지점이 있습니다.

"이렇게 적어두면 사용하는 사람이 이해할까?"

"이 버튼은 위에 두는게 편할까, 밑에 두는 게 편할까?"

기획자분들이라면 사소하지만 매일같이 고민하는 지점일 것이라고 생각합니다. 저희 팀은 기획 뿐만 아니라 디자이너, 개발자 분들도 이런 기획사항에 대한 피드백을 아낌없이 전달해주시는 편이고, 유저에게 가장 쉽고 편한 UX/UI를 위해서 매번 고민과 회의를 굉장히 많이 거칩니다.

물론 사소한 결정사항이라도 저희 팀은 기본적으로 빠르게 접근할 수 있는 유저 분들에게 개인적으로 연락을 취해본다던지 하며 고객의 목소리를 가장 1순위로 두려고 하고 있지만 서비스가 고도화되고 기능이 많아지면서 모든 것에 대해 여쭤보는 것도 어쩌면 민폐가 아닐까, 하는 생각이 들기도 하고 했습니다.

최근에도 저희 서비스 내 사이드바에서 사용하고 버튼인 '예약 일정 관리'와 '예약페이지 관리'에 대해서 명칭이 '너무 헷갈린다, 직관적이지 못하다!' 라는 내부 VOC가 접수되어서 팀 내 회의를 거친 적이 있었는데요,

'현재 상태가 최선이다', '아니다, 꼭 수정되어야 한다' '수정 되었으면 좋겠는데 최적의 대안을 못찾겠다' 등 여러가지 의견이 나와 뚜렷한 해결책을 못찾고 있었습니다. 모두가 유저에게 어떤 것이 최선인지 말할 수가 없어,

'아.. 유저분들 한테 물어보고 싶다...' 하는 생각을 가지고 있었습니다.

그때 생각 난 것이 바로 저희 서비스의 슬랙 커뮤니티 였습니다!

본래 해당 커뮤니티의 취지는 저희가 새로운 기능을 런칭하거나 수정 사항이 있을 때 이를 공지하고, 유저분들의 VOC를 보다 빠르게 수집하기 위함이었는데요,

유저가 말을 걸어주길 기다리기 보다 우리가 먼저 말을 걸어보면 어떨까?

라는 생각이 들었습니다.

그래서 바로 저희가 하고 있는 고민을 털어놓아 보았고, 많은 분들이 이모지로 반응 해주시고, 코멘트로 좋은 의견까지 남겨주셔서 저희 팀도 빠르게 이를 반영하여 수정하기로 결정했습니다 :)

모든 서비스가 유저와 가까운 관계를 유지하려고 하지만 사실 그런 관계를 지속시키기는 쉽지 않죠? 그래도 최근에는 저희와 같은 방식으로 빠르게, 그리고 자주 유저와 만나는 서비스가 늘어나고 있는 것 같습니다. 제 개인적으로 가지고 있었던 '이런걸 물어보는 유저에게 너무 피로한거 아니야?'라는 생각도 많이 변화하고 있습니다. 적극적으로 유저의 목소리를 듣고 그것이 실제로 서비스에 바로바로 반영이 되는 것, 그런 효능감을 끊임없이 유저에게 전달하는 것이 유저와 친밀한 관계를 유지하는 첫걸음 아닐까요?

저희 팀은 이번주 '유저에게 가볍게 말 걸어보기'를 실천해보았습니다! 개인적으로 결과는 너무 성공적이었다고 생각하고 앞으로도 이런 소통의 기회를 늘려보고 싶은데요, 사람과 사람 관계에서도 친해지고 싶을 때는 먼저 말걸기, 가장 기본이죠? 여러분의 유저에게 가벼운 말걸기 부터 시작해보는 건 어떨까요? 유저와의 스몰토크를 매주, 나아가서 매일할 수 있는 서비스가 있다면 정말 이상적이지 않을까요?

"첫 회사로 스타트업을 가고 싶어요!"

인생의 첫 회사로 '스타트업'을 고르신 분, 계신가요?

저 역시 첫 회사가 지금 일하고 있는 스타트업 회사이지만, 저는 처음부터 '나는 스타트업에서 내 커리어를 시작해야지!' 하는 생각은 크게 하지 않았어요.

제게 맞는 곳이 어디일까 고민하다 제 능력을 믿어주고, 제가 하고 싶은 것을 충분하게 할 수 있게 기회를 주는 지금의 팀을 만나서 운 좋게 일하고 있는 상황으로 처음부터 '스타트업'이기에 지금의 팀을 고르지는 않았습니다.

그래도 벌써 지금의 팀에서 일한지가 1년이 넘어가고 다양한 스타트업에서 일하고 계신 분들을 만나면서, 생각보다 '스타트업'을 선택해서 오신 분들이 많다는 걸 느꼈어요. 업무나 산업군보다도 '스타트업'이기에 좋다, 고 생각해서 이직을 결심하시거나 첫 커리어의 시작을 결정하시는 분들도 꽤 있으신 것 같더라구요!

그래서 저도 스타트업에서 일하고 있으면서도

스타트업에서 일하는 사람들이 궁금하다!

라는 생각을 많이 하고 있는 요즘입니다. 저희 팀에도 대기업에서 스타트업으로 이직하여 온 팀원들이 있고, 그 팀원들의 이야기를 들어보면서 대기업과 스타트업의 장단점을 느끼고 있는 것 같습니다. 많은 분들이 대기업에서 스타트업으로 이직해오시면서 작성하신 메이커 로그도 많이 읽어볼 수 있었고, 생각보다 대기업이 가질 수 밖에 없는 단점들을 해소하기 위해서 스타트업을 선택하신 분들이 많다고 느껴졌습니다.

기업 문화에 따라서 대기업마다도 전부 다르지만 기업 규모에 따른 어쩔 수 없는 비효율, 속도 문제는 항상 발생하는 것 같습니다. 빠르게 변화하고 빠르게 성장하고 싶으신 분들은 그런 면에서는 아무리 좋은 대기업이라도 충족되지 않는 아쉬움을 느끼고 결국 스타트업으로 많이 이직하시는 게 아닐까, 하고 많이 생각합니다.

이렇게 대기업을 경험하고 스타트업으로 이직한 사례의 이야기는 비교적 많이 들어본 것 같은데, 제목에 적은 것처럼 처음부터 스타트업에 대한 목표를 가지고 커리어를 시작하는 분들이 많이 계신 것 같은데, 그분들의 이야기를 들어보고 싶다는 생각을 많이 하고 있습니다ㅎㅎ

혹시 첫 커리어로 스타트업을 고민하고 계신 분들이 있다면,

어떤 마음으로, 어떤 목적으로 그런 마음을 가지게 되셨는지 댓글로 남겨주셔도 너무 흥미로울 것 같아요!ㅎㅎ 궁극적으로 CEO가 되고 싶다는 마음으로 첫걸음을 내딛는 것인지, 빠른 성장을 위해서 스타트업을 선택하는 건지, 혹은 자유로운 기업 문화가 너무 마음에 든다던지 여러가지 이유와 목적이 있을 것 같은데 다양한 이야기들이 궁금하네요!!ㅎㅎ

많은 분들의 이야기를 들을 수록 세상에는 정말 다양한 사람들이 있고, 다양한 이야기들이 있다는 걸 느낍니다ㅎ 그래서 이렇게 많은 분들의 이야기를 들을 수 있는 이 곳이 굉장히 흥미로워요!ㅎㅎ함께 같이 노력하고 계신 분들의 이야기가 많이 궁금해지는 최근인 것 같습니다!

성공하는 PM들의 소통법, PRD를 알고 계신가요?

새로운 프로덕트를 만들거나, 기존의 프로덕트에 새로운 기능을 추가하는 프로젝트를 기획하려고 할때, 많은 PO/PM 분들은 '기획서'를 작성하실 거라고 생각합니다.

혹시 여러분이 작성하는 '기획서'는 어떤 모습인가요? 그리고 그 '기획서'는 제 역할을 다하고 있나요?

저희 팀 역시 새로운 프로덕트, 혹은 프로젝트를 시작할때 프로덕트를 직접 만들어나가는 디자이너, 개발자 분들과 소통하기 위하여 PPT 형식의 기획서를 작성했었습니다. 하지만 기획사항이 빼곡하게 적혀있는 100장이 넘어가는 기획서는 디자이너에게도, 개발자에게도, 그걸 작성하는 기획자에게도 효과적인 소통방식이 아니었습니다.

그래서 제가 프로덕트를 만들어나가는 팀의 다양한 구성원들과의 효율적인 소통에 대해 고민하고 있을 때, 저희 팀의 프로덕트 멘토님께서 추천해주신 양식이 바로 PRD 였습니다. 해외 PM들은 전부 PRD를 작성하고, 우리나라에서 쓰는 그런 100페이지가 넘는 기획서를 쓰는 나라는 한국과 일본뿐이라며 조언해주셨습니다.

PRD란 Product Requirements Documents로, 쉽게 말해 우리 팀에서 만들고자하는 프로덕트의 용도, 특징, 기능 및 동작을 포함하여 특정 제품의 요구사항을 정의하여 비즈니스 및 개발 팀원들이 제품의 제작, 출시를 위해 필요한 가이드를 정리한 문서라고 생각하시면 됩니다. 정의로만 봐서는 기존의 기획서와 뭐가 다른가, 싶으시겠지만 PRD의 가장 중요한 점은,

Nobody likes writing bloated, ultra-detailed product requirements documents.

아무도 비대하고 매우 상세한 제품 요구 사항 문서를 작성하는 것을 좋아하지 않습니다. 

Turns out nobody likes using them, either.

아무도 그것을 사용하는 것 역시 좋아하지 않는 것으로 밝혀졌습니다.

PRD의 핵심은 자세하고, 구체적인 기획서를 지양한다는 점입니다. PRD는 새로운 프로덕트의 목적과 방향성을 정의하는 문서로, 나침반이 되어 줄 뿐 구체적이고 장황한 설명서가 아닙니다.

화면을 구체적으로 정의하고, 모든 동작에 대한 엄격한 요구사항을 제한하는 것이 아닌, 우리 팀이 왜 이 프로덕트를 만들어야 하는지, 이 프로덕트를 사용할 유저의 시나리오는 무엇인지, 이 프로덕트를 통해 우리 팀은 어떻게 발전할 것인지 등 해당 프로젝트의 방향성만을 확실히 하여 개발자와 디자이너에게 최대한의 창의성과 자율성을 보장하여 훨씬 효과적이고 효율적인 방법으로 프로덕트를 생산할 수 있게 도와주는 것이 바로 PRD입니다.

그렇다면 PRD라는 문서는 어떤 내용들을 담아야할까요?

우선 일반적으로 PRD 문서를 이루는 목차는 다음과 같습니다.

1. 기본정보
2. 참여자
3. 상태
4. 런칭 일시
5. 팀 목표와 비즈니스 목표 (최대 2개를 넘어가지 않도록 최상위 목표를 제시합니다. )
6. 배경 및 전략적 적합성 ( 우리 팀이 기능을 만드는 이유, 혹은 이 기능이 전체 회사 목표에 어떻게 부합하는 지 간결하게 설명합니다.)
7. 가정
8. 기술적 가정 (해당 프로젝트가 개발에 효율성을 가져오는 이유를 설명합니다. )
9. 비즈니스적 가정 (해당 프로젝트가 경제적 가치를 어떻게 가지는 지, 얼마만큼 가지는 지 설명합니다.)
10. 고객 가정 (어떤 고객들이 해당 기능을 사용하게 되는지 설명합니다.)
11. 유저 스토리
12. 고객 인터뷰 등 구체적인 고객의 목소리(VOC)
13. 고객 사용 시나리오 (유저 저니 맵)
14. 와이어프레임 (각 유저 시나리오에 대한 솔루션을 와이어프레임으로 구체화하여 설명합니다.)
15. 예상 질문과 그에 대한 답
16. 우리가 하지 않는 일 What’s we’re not doning (우리가 이번에 다루지 않을 일을 구체적으로 명시 합니다.)

실제로 저희 팀은 올 6월부터 PRD라는 문서를 통해 프로덕트, 혹은 프로젝트의 시작을 알리고 있는데요, PRD를 통해 빠르게 새로운 프로젝트의 시작을 알릴 수 있었고, 화면 정의나 기능 설명보다 팀의 목표와 비즈니스 목표, 유저 스토리를 전달하는 것이 효율적인 커뮤니케이션을 위해 선행되었어야 한다는 걸 몸으로 느낄 수 있었습니다.

앞서 설명 드린 목차에서 저희는 가끔 특정 항목을 빼기도 하고, 출시일이 정해져 있는 경우 스프린트를 추가한다던가, 유저 페르소나가 다양한 경우 유저 스토리를 구체적으로 작성한다던가 하며 필요한 부분을 강조하고, 필요없는 부분을 과감하게 제외하며 PRD의 핵심 가치를 지키려고 노력하고 있습니다.

모든 팀에 PRD라는 양식이 효과적인 커뮤니케이션을 불러온다고는 할 수 없을 것 같습니다. 하지만 혹시 기획<>디자이너<>개발자 사이의 커뮤니케이션과 관련해서 고민하고 있으신게 있다면, PRD를 한번 작성해보시는 건 어떨까요? 혹은 우리 팀에서 하고 있는 효과적인 소통방법이 있다면 꼭 알려주시면 좋겠습니다!

여러분 팀의 PO/PM의 역할은 무엇인가요? 🤔

어느 팀에나 서비스의 기획을 담당하는 PO나 PM의 직무를 가진 분들이 계실거라고 생각합니다. 그런데 제가 다양한 스타트업 팀들을 만나면서 느낀 점 각 팀에 따라 PO/PM의 역할이 굉장히 다르다는 점이었어요!

고객의 목소리를 수집하고, 서비스를 전체적으로 기획하는 일을 핵심적인 업무로 가져가는 것은 비슷하지만 구체적으로 하는 업무는 팀에 따라 많이 다르다고 느껴졌습니다! 그래서 저희 팀의 PM은 어떤 일을 담당하고 있는 지 소개해드리고, 다른 팀의 PO/PM 분들은 어떻게 일하고 계신지 이야기해볼 수 있으면 좋겠다는 생각에 메이커로그로 적어보려고 합니다!

저는 스플랩이라는 팀에서 일하면서 PM으로서 이루고 싶은 목표는

모든 팀원이 '하나의' 서비스를 '순조롭게' 만들었으면 좋겠다!

인 것 같습니다ㅎ

조금 추상적으로 표현해봤는데, 우선 '하나의' 서비스라는 의미는

모든 팀원이 서비스에 대한 깊은 이해를 바탕으로 프로덕트를 개발할 수 있는 환경을 만들고 싶다

는 의미라고 생각해주시면 좋을 것 같아요.

'사공이 많으면 배가 산으로 간다.'라는 속담 유명하죠, 저희 팀도 규모가 점점 커져서 이제는 10명이 넘는 팀원들과 함께하고 있습니다. 인원이 많아지는 만큼 프로덕트에 대해서 모든 사람이 모여서 이야기하는 시간은 줄어들 수 밖에 없고, 바빠지다 보면 그 빈도는 눈에 띄게 줄어들 수 밖에 없는 것 같습니다.

하지만 모두가 프로덕트를 다르게 이해하고 서로 다른 프로덕트를 만들고 있다면 사공이 많은 배가 산으로 가는 것처럼 전혀 효율성과 추진력을 지니지 못하는 팀이 될 수 밖에 없겠죠. 그래서 저는 모든 팀원들이 서비스 개발에 있어서 '이 기능이 왜 만들어져야 하는지', '이 기능을 쓸 유저는 어떤 사람이라서 이 기능이 필요한건지'에 대해서 끊임없이 말로, 그리고 문서로 전달하고 있습니다.

그래서 저희는 PPT나 장문의 워드파일로 만드는 기획서가 아니라, PRD 형식의 간결한 형태의 문서로 프로덕트를 팀원들에게 소개하고, 그런 프로덕트에 대한 이해를 기반으로 소통하고, 결국 프로덕트 개발에 모두가 적극적으로 참여할 수 있는 문화를 만들려고 노력하고 있습니다. 저희 개발자 분들은 유저의 사용성에 대해서도 항상 저보다 많이 고민을 해주시기 때문에 그런 고민을 더더욱 많이 할 수 있도록 정리와 공유를 통해 옆에서 서포트하는 역할을 하고 있다고 생각합니다 :)

PRD에 대해서는 제가 기획 사항 전달에 대해서 고민하고 있을 때 프로덕트 멘토님께서 추천해주신 양식인데, 해외에서는 PM들이 모두 기획서가 아니라 PRD를 작성한다고 하시면서 추천해주셨습니다. 다음 메이커로그에서는 저희 팀이 작성하고 공유하고 있는 PRD에 대해서도 자세히 다뤄보면 좋을 것 같네요!

그리고 '순조롭게' 라는 표현은 모든 스타트업들의 꿈 아닐까요?ㅎㅎ

매일매일이 위태롭고 신나는(?) 것이 스타트업인 만큼 순조로운 팀이 되기 위해 모두가 노력하고 있다고 생각하지만 쉽지가 않죠, 그래서 저는

우리 팀이라는 배가 여러가지 변수라는 파도에 최대한 흔들리지 않도록 노력하는 역할

을 하고 있다고 생각합니다.

저희도 빠르게 시도하고 실험하고 도전하는 린스타트업 팀인 만큼 매일매일 새롭게 결정되고 추가되는 일이 빈번합니다. 그럴때마다 갑작스러운 변화는 모두에게 언제나 긍정적인 원동력을 줄 수는 없다고 생각합니다. 그래서 저는 잦은 변화를 막을 수는 없으니 최대한 변화할 수 있는 많은 상황에 대비할 수 있도록 노력하고 있다고 생각합니다.

언제 어떻게 변할 지 모르는 미래에 대비하기 위해 가장 기본이 되야하는 일은 바로 지금 현재 우리 팀의 상황을 제대로 파악하고 있는 일이라고 생각합니다. 여러가지 결정의 기로에서 지금 우리가 어떤 상황이고, 어떤 일을 하고 있는지 현재의 우리를 제대로 파악하고 있는 것이 가장 먼저일 것이라고 생각합니다. 그래서 저는 항상 저희 팀에서 '소통'을 언제나 강조하고 있습니다.

저희 팀은 수평적인 팀 문화를 기반으로 소통에 모두 활발히 참여하고 있는데요, 제가 최근 건의해서 저희가 함께 하고 있는 하나의 소통방식을 설명드리면 바로 slack의 상태메세지를 활용하는 것입니다.

위 사진과 같이 지금 내가 무슨 일을 하고 있고, 그게 언제까지 할 것 같다 하는 내용들을 매일매일 업데이트하여 공유하고 있습니다. 저희 팀은 매일 스크럼을 해보기도 하고 여러가지 방법으로 소통하기 가장 적절한 방법을 찾고 있는데, 개인적으로 slack을 활용하고 있는 팀이라면 상태메세지를 활용해보시는 것도 좋을 것 같습니다. '00님, 지금 뭐하고 계세요?' 만큼 묻기 어려운 질문이 없는 것 같은데 저희 팀은 이런 방식으로 그 질문을 대체하고 있습니다. 이밖에도 스케줄링 서비스를 하고 있는 만큼 팀 캘린더를 적극적으로 사용하기를 권하고 풀타임 팀원들끼리는 매주 1회 짧은 회의를 하는 것 같이 소통을 위해 다양한 노력을 기울이고 있습니다.

혹시 여러분들은 지금 우리 팀원이 무엇을 하는지, 어떤 고민을 하고 있는지 모두 파악하고 계신가요? 혹은 모두 파악하고 있는 팀원이 팀에 있으신가요?

저는 저희 팀에서 그런 존재가 되어서 누구든 우리 팀의 현주소를 물어본다면 바로 알려줄 수 있는, 그리고 우리 팀원 중 누구라도 우리의 미래, 비전을 묻는 다면 바로 대답해줄 수 있는 그런 존재가 되려고 노력하고 있습니다. 팀을 파악하고 있는 사람이 있고, 이를 통해서 앞으로 우리가 만날 수많은 변화도 잘 이겨낼 수 있을 것이라고 신뢰를 주고 싶습니다. 그런 신뢰를 바탕으로 모두가 순조롭게 프로덕트를 개발하고 프로덕트에 몰입할 수 있게 된다면 저는 저희 팀에서 제 몫을 다하고 있다는 생각이 듭니다 :)

이렇게 저희 팀 PO/PM이 일하는 방식을 말씀드렸는데, 여러분 팀의 PO/PM은 어떤 일을 하는 사람이라고 생각하시나요? 혹 본인이 PO나 PM이시라면 어떤 일을 하고 계신가요? 궁금합니다! PO/PM의 이상적인 포지션이 무엇일까 고민이 많았는데 제가 내린 결론은 각 팀에 꼭 필요한 역할을 그때 그때 맞출 수 있는 사람이 되는 것이라고 생각했습니다. 팀 별로 상황이 모두 다르고 한 팀에서도 매일매일이 새로운 상황을 마주하는 스타트업에서 하나로 정의할 수 있는 이상적인 역할이 있을까요? 앞으로도 저는 제가 팀에 해야하는 일에 대해서 계속 고민할 것 같습니다😊