다국어 관리 어떻게 하시나요?

다국어 관리 어떻게 하시나요?

요새는 국내 시장이 아닌 글로벌 서비스로 시작하는 회사들이 많아요.

근데 다국어 관리 어떻게 하시나요?

피그마에 있는 단어를 구글시트로 옮기고, 매크로를 통해 JSON으로 변환하고.. 

정말 많은 리소스가 들어가요.

이러한 문제를 개선하고자 한 번에 처리해 줄 서비스를 만들었어요!

쉽고 편안하게 다국어 관리하세요!

현재 베타서비스 신청자를 모집 중에 있으니, 많은 관심 부탁드립니다!

6주, 18시간 동안 나만의 웹/앱 서비스를 만들어보자! 1기 모집

안녕하세요!

이런 고민 해보셨나요?

• 좋은 아이디어가 떠올랐는데, 개발자를 못 구해서 멈췄어요.

• 팀원 모집은 했는데, 진행하다가 흐지부지됐어요.

• 개발자랑 대화하는데 하나도 이해가 안되서 걱정이에요.

• 데이터를 어떻게 분석하면 좋을지 고민이에요.

• 언제까지 회사 일만 할 순 없잖아요.

• 제품을 빠르게 검증하는 방법을 배우고 싶어요.

• 온라인 VOD를 봤는데도 무슨 말인지 모르겠어요.

18시간 동안 나만의 웹/앱서비스를 만들어보는 프로그램 1기를 모집합니다!

비전문가도 웹/앱 서비스를 만들고 데이터까지 분석할 수 있다!

Cursor AI로 앱 완성 + 데이터 분석까지 🚀

개발을 전혀 몰라도, Cursor AI라는 도구를 활용해 스스로 앱을 만들고,

Mixpanel로 데이터를 분석하는 방법까지 배워보세요.

직접 만들어보는 경험을 통해, 앞으로의 혼자 원하는 서비스를 만들 수 있다는 자신감을 드립니다.

💡 이 강의는 바로 그런 고민을 해결하기 위해 준비했습니다!

해당 강의는 비전공자를 대상으로 합니다.

기존 전공자, 전현직 개발자, Cursor AI를 잘 사용하고 있는 분들에게는 너무 쉬운 강의가 될 예정이라 신청 시 유의해주시기 바랍니다.

이런 분들에게 추천합니다

• 사이드 프로젝트를 시작하고 싶은데, 개발 지식이 없어 막막한 분

• 기획 단계에서 끝나는 아이디어를 직접 구현해보고 싶은 분

• 데이터 분석에 관심이 있지만, 어디서부터 시작해야 할지 모르는 분

• 취업/이직을 위해 포트폴리오를 강화하고 싶은 분

• 6주 안에 제품 개발 과정 전체를 경험해보고 싶은 분

📌 이 과정은 부트캠프 강의와 달리 실전형 실습 과정으로 직접 기획부터 디자인, 개발까지 모두 혼자 진행하게 됩니다.

단순히 화면만 만드는 과정이 아닌 실제 AWS에 서버를 운영하고, DB를 만들어 실제 서비스를 운영할 예정입니다.

“한 번 해볼까?”라는 마음 가짐보다는 해당 시간 참여하실 분이라면 돈을 버리는 시간이 될 것입니다.

그렇기 때문에 VOD 방식의 온라인 강의가 아닌 오프라인 형태로 밀착해서 진행합니다.

정말 짧은 기간 임팩트있게 내 제품을 만들어 시장의 반응을 보고 싶으신 분들만 참여 부탁드립니다!

1:1로 밀착해서 진행해드리기 때문에 정말 후회없는 선택이 되실 거예요!!
이전 후기 보러가기: https://www.latpeed.com/products/hcxRe

신청하러 가기 : https://www.latpeed.com/products/6HHQ0

4월과 5월 PO/PM 포트폴리오를 만드는 달로 삼아보세요!

안녕하세요.

포트폴리오 만드는 것에 대해 고민있으신 분 계신가요?!

기존에 기획을 배워보고 싶으신 분, 현업에서 PO나 PM이 하는 업무를 배우고 싶으신 분들은

이번 4월, 5월 포트폴리오 준비과정을 통해 좋은 포트폴리오를 만들어보세요~!

과정 소개

PO, PM, 서비스 기획자로 취직, 이직, 전향을 하고자 할 때 회사의 업무가 포트폴리오에 담기 어려운 경우가 많습니다. 개인적으로 팀을 구해 사이드 프로젝트를 진행하게 됩니다만, 원하는 결과를 얻기까지는 매우 어렵습니다.

이러한 문제점을 해결하고자 실제 원하는 결과까지 얻을 수 있도록 밀착해 도움을 주는 포트폴리오 준비과정을 운영하고 있습니다. 과정 내용은 타 부트캠프와 동일하게 진행될 예정이기 때문에 이미 부트캠프를 경험하신 분들 혹은 현재 포트폴리오가 있으신 분들은 큰 효과를 얻지 못할 수 있습니다.

하지만 현업의 가이드를 받으면서 실제 현업에서의 기획을 배워보고 싶다 혹은 현업에서 어떻게 일하는지 간접 경험해보고 싶다는 분들은 아주 큰 도움을 받을 수 있습니다.

포트폴리오 준비과정을 통해 얻는 효과

• 소수 인원으로 온오프라인 병행해서 16회 만에 포트폴리오를 만드는 것을 목표로 합니다.

• 현업에서 사용하는 방식들만 빠르게 전달드리기 때문에 효율적으로 지식을 쌓을 수 있습니다.

• 과정 동안 주 1회 팀 미팅과 1:1 미팅을 진행하여 협업하는 방법과 노하우를 최대한 많이 배울 수 있도록 도와드립니다.

• 과정 후 원하는 수준의 포트폴리오를 얻어가실 수 있습니다.

운영 방식

기본적으로 주 2회 온오프라인을 병행하여 진행됩니다.

• 온라인 (평일 저녁) : 디스코드

• 오프라인 (주말 오전): 추후 공지

비용

• 10만원

신청하기 : https://tally.so/r/w2eNxM

'안 한 것은 못한 것이다'에서 배우는 진짜 회고

2024년 2월 1주 회고

'안 한 것은 못한 것이다'에서 배우는 진짜 회고

그 때는 정말 주먹구구식으로 일했던 것 같아요!

한 때 같이 일했던 동료가 현재 회사도 커지고 좋은 분들이 많이 들어와 예전보다 일하기 좋아졌다, 성장하기 좋아졌다는 말을 하면서 했던 말인데 괜히 서운함을 느끼게 되었습니다. 그 때를 돌이켜보면 그 당시 상황에서는 도저히 도입이 어려워 저만의 로드맵으로 2-3년 뒤에는 꼭 이러한 조직이 되자하며 방향을 잡았던 것들이 있는데 이를 몰라줘서 정말 서운했습니다.

서운함이 생각보다 컸는지 집에 돌아오는 내내 떠올랐고 3일이 지나도 계속 생각이 났습니다. 더 나아가 다시 돌아간다면 이런 걸 해보고 싶다는 생각이 들었습니다. 그래서 아예 시간을 잡고 왜 이러한 생각들이 떠오르는지 고민해보기로 했습니다. 

진정한 회고가 되려면 진심과 이해, 2가지가 필요합니다. 

같이 일하는 동안에 회고를 한다면 "이 말을 하면 상처받지 않을까?", "앞으로도 볼 사이인데 나한테 불이익은 오지 않을까?" 등 말에 감정을 빼고 이야기한다고 해도 서로 조심스러움을 지울 수 없습니다. 그러다보니 자체 필터링이 되어 반쪽짜리 진심이 됩니다. 또한 충분한 라포가 없다보니 "이건 이렇게 했어야 해요", "앞으로 이것을 챙겨주셨으면 해요" 등의 나의 기준에서 상대방 행동에 대한 평가에 대해서만 이야기합니다. 회고를 하지만 진짜 회고를 하는 것은 아닌 것이죠.

이러한 기준에서 좋은 동료와 인연이 지속된다는 것은 엄청난 행운이라 생각합니다. 좋은 동료와의 인연이 아쉬워 퇴사를 했음에도 몇몇 분들은 지속적으로 연락드리고 주기적으로 만남을 지속하면서 저도, 그들도 모르게 진정한 회고가 되고 있기 때문에 서운함도 들고 서운함과 동시에 다음에는 이렇게 하자라는 액션 플랜까지 세울 수 있었던 것입니다. 

안 한 것은 못한 것이다.

시간을 잡고 시각화도 하며 생각을 정리해 본 결과, 내려진 결론은 "안 한 것도 못한 것이다"입니다. 지나고 나서 "내 의도는 원래 그랬어" 라고 말하는 것은 누구나 결과를 보기 전까지는 완벽한 계획이 있다는 말이자 서로에게 어떠한 의미부여도 되지 않기 때문입니다. 특히 회사 생활은 성공 혹은 실패 2가지 결과만이 존재하는 곳입니다. 결과를 보지 못했다는 것은 어떠한 성과도 만들어 내지 못했다는 말이고 결국 안 한 것과 못한 것이 같다라는 공식이 성립하기 때문입니다. 이러한 생각을 통해 어떠한 환경이 되든 같이 생각하고 같이 실행하고 같이 결과를 보는 사람이 되고자 합니다. 

블로그 바로가기

뉴스레터 구독하기

[홍보] 리더와 실무진을 설득하는 PRD 작성 마스터하기

​

안녕하세요! ​

홍보글은 처음 작성해보는 것 같네요.

올해부터 PO/PM/서비스기획자 분들을 대상으로 여러 세션을 진행해보고자 합니다. 그 첫 번째 시작인 PRD 세션을 소개해드리고자 합니다.

PRD는 Product Requirement Document로 우리가 이 아이템을 왜 해야하는지, 한다면 어떠한 결과를 예상할 수 있는지 작성하는 요구사항 정의서입니다. PRD는 단순히 요구사항 정의를 넘어 같이 일하는 사람들에게 동일한 목표를 바라볼 수 있도록 해줍니다.

이번 기회를 통해 ​커리어를 한 단계 더 발전시킬 수 있는 기회를 놓치지 마세요! ​

​이번 특강을 통해 얻을 수 있는 것들:

1. ​PRD의 기본 구조 및 필수 요소 이해

2. 명확하고 설득력 있는 PRD 작성 기법

3. 리더 및 실무진과의 효과적인 커뮤니케이션 전략

4. 실제 사례 분석을 통한 이해도 향상 ​ ​

📅 일시: 2월 17일 (토요일), 오후 14:00 - 15:30 ​

💡 대상: 제품 매니저, 기획자, 마케터, 개발자 및 PRD 작성에 관심 있는 모든 분 ​

💰 비용 및 장소 : 10,000원 (신청자에 한해 추후 줌링크가 제공될 예정입니다.) ​

많은 분들의 관심과 참여를 기다리고 있겠습니다. ​

감사합니다.

원티드 PO 챌린지를 마무리하며...

작년 말, 좋은 기회를 얻어 올해 1월부터 원티드 PO 챌린지에 연사로 참여했습니다. 총 4번에 걸친 12시간의 세션은 부담스러웠지만, PO/PM으로 커리어를 쌓아가는 누군가에게 도움이 되고 싶다는 마음이 컸기에, 준비 과정은 그리 힘들지 않았습니다. 다만, "어떤 주제를 선택해야 할까?"라는 생각이 많이 들었습니다. 제가 원하는 메시지를 전달하지 못할까 봐 걱정되었습니다.

첫 번째 세션을 마친 후, 많은 생각이 들었습니다. "현업에 대한 이야기를 더 많이 했어야 했나?", "취업이나 이직에 대한 구체적인 조언을 해줬어야 하나?", "다음 세션에 참여자가 줄어들까?" 이러한 고민을 안고, 어느새 4번의 세션을 모두 마쳤습니다.

온라인으로 150여 명의 참여자에게 지식을 전달하는 것은 쉽지 않았습니다. 놓친 부분도 많았고, 그래서 많이 배웠습니다. 다음 기회가 온다면, 무엇을 생략하고 무엇을 강조해야 할지 많은 액션 플랜을 세우고 있습니다.

이렇게 누군가에게 지식을 나누고자 하는 생각은 오래전부터 있었습니다. 2010년 해외봉사를 하며 '안다는 것'의 중요성을 깨달았고, 제가 아는 것들을 사회에 환원하겠다는 목표를 세웠습니다. 2024년이 되어서야 시작할 수 있었지만, 이번 경험을 계기로 블로그, 커뮤니티, 뉴스레터 운영에도 적극적으로 나설 계획입니다. 부족함이 많지만, 많은 분들에게 도움이 되길 바랍니다.

PO & PM 관련 이야기 나누고 싶으신 분들은 언제든 환영입니다~!

[PMC 1week 후기] 무엇을 하고 싶은지 명확히 하자

안정적인 것들을 포기할 수 있을까?

제가 대학교 졸업할 때까지만 하더라도 창업하면 자영업이 대부분이었습니다. 저 또한 다른 사람들처럼 대기업에 입사하는 것을 목표로 학과 수업에 집중하였고 목표가 무엇이냐 물어봤을때 대기업 입사해서 안정적으로 회사 생활하며, 임원까지 올라가는 것이라 대답했었습니다. 제 사업을 하고 싶단 생각을 가지리라 꿈에도 생각을 못했습니다.

그러던 도중 우연한 기회로 2년 동안 인도네시아에 해외 봉사를 하게 되었습니다. 하루하루가 미션 같았던 한국 생활을 떠나 인도네시아에서 생활해보니 제가 가진 것이 많았단 것을 알았고, 이를 사회에 환원해야겠다는 생각을 가지게 되었습니다. 당시 한국에서는 왓챠, 배달의 민족 등의 IT 서비스를 기반으로 한 창업이 시작되었고 저 또한 IT 서비스를 기반으로 한 창업을 하리가 마음을 먹었습니다. 하지만 여러 창업 모임들을 나가면서 느낀 것은 제 역량이 너무 부족하다는 것입니다. 당시에는 제품 기획도, 개발도 아무 것도 몰랐습니다. 모르는 것들, 새로운 것들을 배워야겠단 생각을 가지고 회사 생활을 시작했습니다.

회사 생활을 하면서 다양한 문제를 해결하는 능력을 키울 수 있게 되었고 실제적으로 회사가 어떻게 돌아가는지, 제품은 어떻게 만드는지 등을 많이 배울 수 있었습니다. 하지만 역량이 늘수록, 몰랐던 부분을 알수록 두려움도 같이 커져갔습니다. 엄밀히 말하면 '할 수 있을까?'의 두려움보다 '지금까지 누리고 있는 안정적인 것들을 모두 포기할 수 있을까?' 의 문제가 더 커져 버렸습니다.

"시기가 언제든 현재 상황이 어떻든 주변에서 다 말려도 할 사람은 해"

의도하지 않게 다양한 분야, 다양한 서비스의 여러 스타트업을 다니게 되었고 정말 의도하지 않게 매 회사 창업자 분들과 사석에서 왜 창업했는지를 들을 수 있었습니다. 저 또한 그 이야기를 들으며 창업에 대한 저만의 고민들을 털어놓을 수 있었습니다. 그리고 들었던 공통된 말.

"시기가 언제든 현재 상황이 어떻든 주변에서 다 말려도 할 사람은 해. 내일 세상이 망한다고 하면 너는 뭐를 하고 싶어?"

PMC 신청

물이 흐르지 않고 고여있으면 썩습니다. 멈춰있지만 말고 뭐든 하자는 생각을 가지고 그 다음부터 링크드인, 커피챗 등 방법과 수단을 가지리지 않고 초기 창업자 분들, 예비 창업자 분들과 이야기 나눠보면서 어떻게 시작했고 어떻게 PMF를 찾았는지 물어보았습니다. 많은 이야기를 들으며 더 몰입할 수 있는 환경에 놓고자 PMC 신청을 하게 되었습니다.

무엇을 하고 싶은 것인가?

여러 스타트업에서 개발자로 PM/PO로 일하면서 유관부서에 "'하겠다' 보다 중요한 것이 '무엇을' 입니다" 라고 줄곧 외쳤었는데 하루 하루가 갈수록 정말 "무엇을"이 중요하다는 것을 느끼고 있습니다.

평소 관심많았던 아이템이 많다본니 무엇을 할까에 대해서 많은 시간을 투자했습니다. 초기 아이템은 여러 번 바뀐다는 것을 알고 있었지만 그럼에도 하고 싶은 것과 잘할 수 있는 것, 그리고 대중에게도 관심이 있을 만한 것을 정해야겠다 생각했습니다.

우리는 24시간 중 회사에서 최소 8시간 이상을 보냅니다. 가족보다도 동료랑 보는 시간이 더 많다는 것에 누구나 동의합니다. 또한 회사는 생계입니다. 생계라는 것은 돈을 받는다는 것이며 받는 돈을 통해 안정감을 얻습니다. 그렇기 때문에 우리는 회사를 통해 성장하고 원하는 것을 이루고자 합니다. 결국 회사란 곳은 좋은 동료들과 어울어져 하나의 성과를 만들어 보람을 느끼는 곳입니다.

저 또한 여러 스타트업을 다니면서 조직문화, 효율적으로 일하는 환경이 갖춰지지 않아 많은 어려움을 겪었습니다. 불확실한 R&R, 상사/동료와의 불화, 몰입하는 환경 등이 갖춰지지 않으면 출근하기 싫어지며 성과를 낼 수 없습니다. 이는 결국 회사 입장에서도 개인 입장에서 큰 손실이라 생각합니다.

애자일 코치, Management 3.0 등의 교육을 수료하며 HR에서 만드는 조직문화도 중요하지만 결국 실무를 하는 실무단에서의 문화도 중요하다는 것을 알게 되었고 입사부터 퇴사까지 개인에게 몰입할 수 있는 환경, 더 일을 효율적으로 할 수 있는 아이템을 시작하고자 합니다.

앞으로의 계획 및 목표

특히 PMC에서 이미 시작한 분들, 연사로 오신 분들과 이야기를 나누면서 하루 시간을 어떻게 나눠서 사용해야 하는지, 얼마나 절박하고 간절해야 하는지 배우고 있습니다. 또한 변화의 시작은 나로부터 출발한다는 것을 느꼈습니다.

앞으로 개발이 되었든 디자인이 되었든 사용자 인터뷰가 되었던 최소 3시간씩은 아이템을 발전시키는 시간으로 가져가려고 합니다. 아직 회사에 속했다보니 많은 시간을 못내 아쉽지만 있는 시간이라도 알차게 사용하고자 합니다.

본격적으로 창업을 해보자라 생각했지만 솔직히 말하면 아직도 창업만이 답은 아니라 생각합니다. 그래서 Hard-due를 선언하고자 합니다. 6개월 안에 무조건 결과를 보려고 합니다. 짧으면 짧고 길면 긴 시간이지만 변화를 이끌어내기에는 충분한 시간이라 생각합니다.

해당 서비스의 5년 후 모습은 이직 혹은 취직을 할 때 이 서비스를 사용하지 않는 회사는 우선 거르는 문화를 만들고자 합니다. 쉽진 않겠지만 해당 문제에 대해 관심있고 해결하고 싶은 욕구도 크며 그만큼 자신이 있습니다.

블로그 바로가기

뉴스레터 구독하기

PRD 관련 번역 글과 무료 템플릿

Week 62 - 📄 Guide to Product Requirements Documents + Free Templates

62주차 - 📄 제품 요구 사항 문서 가이드 + 무료 템플릿

"좋은 제품은 문제를 해결하고, 훌륭한 제품은 우아하고 유쾌한 방식으로 문제를 해결합니다." - 스티브 잡스

💯 프레임워크 // 개념 // 멘탈 모델

효과적인 제품 요구사항 문서 작성을 위한 완벽한 가이드 📄

제품 관리자의 가장 중요한 책임 중 하나는 포괄적인 제품 요구 사항을 정의하는 것입니다. 하지만 이해 관계자를 명확하게 조율하는 방식으로 정의하려면 신중한 계획과 커뮤니케이션이 필요합니다. 이때 상세한 제품 요구사항 문서(PRD)를 작성하는 것이 매우 중요합니다. 

이 포괄적인 글에서는 제품 개발을 주도하는 훌륭한 PRD를 작성하기 위해 PM으로서 알아야 할 모든 것을 자세히 살펴봅니다. 🚀

PRD의 간략한 역사 📜

PRD는 시간이 지남에 따라 제품 관리 모범 사례와 함께 발전해 왔습니다. 2000년대 초반의 PRD는 종종 길고 지루한 Word 문서였습니다. 하지만 오늘날의 PRD는 더욱 간소화되고 시각적이며 협업이 가능합니다. PRD의 진화에 있어 몇 가지 주요 이벤트를 소개합니다:

• 2001: 경직된 프로세스에 대한 빠른 반복을 촉구하는 애자일 선언문 발표.

• 2006: 마티 케이건이 애자일 PRD 관행을 옹호하는 인기 저서 "PRD 작성 방법"을 출간했습니다. 📝

• 2010: 제품 관리의 성장은 더 많은 교육과 전문화로 이어집니다.

• 2020: PRD가 더욱 사용자 중심적이고 시각적이며 민첩하게 진화합니다. 📱

PM 표준의 상승과 부서 간 협업 덕분에 최신 PRD는 상당히 개선되었습니다. 이제 오늘날 효과적인 PRD를 만드는 요소에 대해 자세히 알아보세요.

PRD란 무엇인가요? 🤔

제품 요구사항 문서는 새로운 제품이나 기능의 기능과 작동 방식을 완벽하게 정의합니다. 엔지니어링, 디자인, 제품 마케팅 및 기타 팀이 비즈니스 목표를 충족하는 올바른 제품을 구축할 수 있도록 안내하는 완전한 제품 사양 역할을 합니다.

PRD는 제품을 성공적으로 시장에 출시하는 데 필요한 모든 기능, 사양, 구성 요소, 워크플로 및 기타 요소에 대한 세심한 세부 정보를 제공합니다. 또한 UI/UX 사양, 우선순위가 지정된 기능, 성공 지표, 프로젝트 타임라인 등이 포함되는 경우가 많습니다.

PRD는 제품에 대한 '진실의 원천'💯이라고 생각하세요. 팀이 실행에 집중할 수 있도록 제품의 '무엇'과 '왜'를 충분히 상세하게 명시해야 합니다.

강력한 PRD의 핵심 요소 ✨

조직의 필요에 따라 구체적인 문서 형식은 달라질 수 있지만, 대부분의 포괄적인 PRD는 이러한 핵심 요소를 공유합니다:

• 요약 - 제품의 목적, 목표, 대상 사용자에 대한 개괄적인 개요. 중요한 맥락을 설정합니다. 📖

• 사용자 페르소나 - 제품을 사용할 1차, 2차, 3차 사용자 유형에 대한 자세한 프로필입니다. 사용자 중심 디자인에 필수적입니다. 👥

• 사용자 스토리 - 제품 기능으로 지원되는 주요 사용자 작업 및 워크플로우에 대한 명확한 설명. 필요한 기능을 설명하는 데 도움이 됩니다. 📚

• 기능 - 문서의 핵심입니다. 필요한 모든 기능에 대한 세심한 기능 사양을 논리적으로 그룹화하여 포함합니다. ✅

• UI/UX 사양 - 의도한 사용자 경험 디자인을 정의하는 목업, 와이어프레임, 다이어그램을 포함한 시각적 사양입니다. 🎨

• 성공 지표 - 성공적인 출시를 정의하는 비즈니스, 사용자 채택, 리텐션 및 제품 지표에 대한 정량적 목표. 📈

• 프로젝트 타임라인 - 주요 마일스톤, 반복 작업, 릴리스 단계 및 전체 목표 릴리스 날짜. 🗓️

• 가정 - 유효하지 않은 경우 제품에 영향을 미칠 수 있는 주요 기술, 비즈니스 또는 사용자 가정에 대한 문서입니다. 🤔

• 제약 - 백엔드 시스템, 규제 요구 사항 또는 레거시 호환성 등 설계를 제한하는 모든 제한, 종속성 또는 요구 사항. ⛔️

• 팀 - 주요 팀원/이해관계자 목록과 그들의 책임. 👥

• 서명 - PRD가 완료되면 주요 이해 관계자의 승인을 위한 서명 필드입니다. ✒️

강력한 PRD의 이점 📈

사전에 상당한 시간을 투자하여 철저하고 체계적인 PRD를 작성하면 다음과 같은 많은 이점을 얻을 수 있습니다:

• 공유된 제품 비전에 따라 모든 이해관계자를 조율 - PRD는 필요한 모든 제품 기능과 그 근거를 자세히 설명함으로써 모든 사람이 동일한 최종 목표를 향해 일할 수 있도록 합니다. 🎯

• 개발을 안내하는 세부적인 요구 사항 기준 제공 - PRD는 최종 제품을 측정하는 기준이 되어 팀이 올바른 기능을 구축하는 데 집중할 수 있도록 합니다. 📏

• 신뢰할 수 있는 단일 소스를 통해 잘못된 커뮤니케이션 감소 - 모든 제품 세부 정보가 중앙 집중식으로 저장되어 있으므로 팀은 모호한 요구 사항에 대해 토론하는 데 소요되는 시간을 줄일 수 있습니다. 💬

• 설계 및 엔지니어링 팀의 효율적인 작업 범위 설정 - 세부 사양을 통해 팀은 필요한 노력과 리소스 수준을 효과적으로 예측할 수 있습니다. 🛠️

• 리소스 계획 및 예산 수립 개선 - PRD 내의 릴리스 단계 및 마일스톤을 통해 부서 간 계획 수립을 개선할 수 있습니다. 💰

• 문서화된 사양에 대한 객관적인 제품 평가 가능 - 정량화 가능한 성공 지표와 요구 사항이 있으면 데이터에 기반한 제품 의사 결정이 가능합니다. 📊

PRD 생성을 위한 모범 사례 ✨

제품 관리자로서 효과적인 PRD를 만들 때 다음과 같은 입증된 모범 사례를 따르세요:

• 폭넓은 협업 - 엔지니어링, 디자인, 마케팅, 지원 및 기타 팀과 긴밀히 협력하여 다양한 관점에서 포괄적인 요구 사항을 수집하세요. 🤝

• 쉽게 액세스할 수 있는 중앙 위치에 PRD를 유지 - 접근성을 위해 중앙 집중식 문서, 위키 또는 요구 사항 관리 플랫폼을 사용합니다. 📁

• 시각 자료를 자유롭게 사용 - 목업, 다이어그램, 순서도, 와이어프레임은 빽빽한 텍스트보다 요구 사항을 더 쉽게 이해할 수 있도록 도와줍니다. 🖼️

• 요구 사항을 논리적으로 정리 - 관련 사양을 명확한 섹션 또는 모듈로 그룹화하여 검색 가능성을 높입니다. 🔢

• 무자비한 우선순위 지정 - 꼭 필요한 MVP 기능과 있으면 좋은 기능을 구분하세요. 범위 확대에 저항하세요. ✂️

• 기술 구현을 규정하지 않기 - 제한이 불가피한 경우를 제외하고 엔지니어가 최상의 솔루션을 결정할 수 있도록 권한을 부여하세요. 👩‍💻

• 기본 사용자 워크플로우를 위한 설계 - 엣지 케이스 이전에 대상 사용자의 주요 시나리오에 맞게 UX를 최적화합니다. 🤳

• 측정 가능하고 정량화 가능한 성공 지표 설정 - 지표가 주요 비즈니스 목표 및 목적에 부합하는지 확인합니다. 🎯

• 프로젝트 타임라인 내에 버퍼 구축 - 엔지니어와 함께 추정치를 검증하고 예기치 않은 작업 발생을 고려하세요. ⏱️

• 버전 관리 사용 - 필요한 경우 잘못된 요구 사항 변경을 롤백할 수 있습니다. 🔙

• 피드백을 조기에 자주 요청 - 최종 확정하기 전에 공동으로 PRD를 다듬습니다. 🙋‍♀️

뉴스레터 유료 구독을 하면 전체 내용과 제가 제작한 템플릿을 확인할 수 있습니다.

블로그 바로가기

뉴스레터 구독하기

제품으로 가져야 할 기준

2023년 10월 3주차 회고

제품으로 가져야 할 기준

제품이란 무엇일까요?

제품이란 무엇일까요? IT 회사에서, 제조회사에서 나름 오랫동안 일했다 생각하지만 항상 이 질문에 명확한 답을 내리지 못하는 것 같습니다. 제품이란 사전적 의미로는 자연이나 인공의 공정에 의해서 생산된 유형의 물건이나 사물의 실체를 말합니다. 학부 때 배운 시스템공학에서는 제품(Product)은 이해당사자(stakeholder)인 개발자, 생산자, 고객, 사용자, 소유자, 용역제공자의 요구를 충족하는데 필요한 기능을 수행할 수 있는 것이라 합니다. 결국 제품이란 문제를 해결하기 위한 해결책입니다. 그렇기 때문에 앱이다, 웹이다의 형태 분류보다는 어떠한 형태도 가질 수 있음을 인지하는 것이 좋습니다. 그럼 제품이 가져야 할 기준은 무엇일까요? 

제품으로 가져야 할 기준은 무엇일까요? 

‎

• 문제 해결 여부

‎제품은 문제를 해결하기 위한 해결책입니다. 그렇기 때문에 “제품이다” 라고 말하기 위해서는 문제가 문엇인지 정의되어야 하고 그 문제가 해결되었는지와 어떻게 해결했는지를 알 수 있어야 합니다. 크게 본다면 일반적으로 PMF를 찾는 일이 해당 될 것이며, 작게 본다면 하나의 기능을 구현하여 NPS 지표가 올라가는 것을 생각할 수 있습니다. 가장 중요한 것은 어떻게 해결되었다도 명확해야한다는 점입니다. 내부적으로는 제품의 방향성을 전달하고 외부적으로는 제품의 가치를 전달할 수 있기 때문입니다.  

‎‎

• 기술 완성도

‎기술 완성도는 제품을 만들고 단순히 “버그의 수가 적다”로만 판단해서는 안됩니다. 정말 좋은 제품임에도 유지보수를 위해 코드를 매번 다 고쳐야 한다면 제품으로 인정받기 어렵습니다. 해당 기술을 구현하기 위해 들어간 리소스가 얼마나 효율적인지, 운영/유지보수에 대한 비용은 어떻게 되는지 등 제품을 만들기 위해 필요한 기술을 전반적이며 종합적으로 검토해야 합니다. 

‎

• 사용성

사용성은 문제 해결 여부와 기술 완성도보다 더 정성적이기 때문에 기준을 잡기가 매우 어렵습니다. 그렇기 때문에 매번 우선순위에서 밀리거나 무시되기 쉬운 항목입니다. 그럼에도 수많은 실험과 User Test를 진행해야만 합니다. 초반에는 많은 비용이 들겠지만 그만큼 우리 제품이 가져가야할 사용성에 대한 기준을 만들 수 있게 됩니다. 또한 말로만 “우리 제품은 사용성이 중요하지 않아”로 하는 것과 실제 시장에서 우리 제품의 사용성이 밀려서 안 팔리는 것. 그 차이를 아는 것이 중요합니다. 

뉴스레터 구독하기 : https://maily.so/marcus.lee?pop=up

Today I Learned #19 (23.09.18) - 프로젝트에서 제품까지

프로젝트 중심 모델과 프로덕트 중심 모델의 차이

• 프로젝트 중심 모델

  • 목적

    • 일반적으로 특정 날짜까지 특정 결과물을 제공해야 하는 대규모의 느리고 비용이 많이 드는 경우 시도합니다.

    • 시장 출시 기간 단축을 목표로 합니다.

  • 단점

    • 필요한 결과를 얻기까지 이전 반복에서 얻은 학습을 바탕으로 여러 번의 반복이 필요하지만, 첫 번째 시도 이상으로 자금을 지원받는 경우는 거의 없으며, 지원받는다고 해도 보통 몇 분기 후에나 가능합니다.

    • 사람들이 기술과 결과에 대해 진정한 주인의식을 느껴야 하는데, 프로젝트 기간 동안만 한 분야에 배치되는 프로젝트에서는 주인의식이 거의 없고 영향력 있는 무언가를 구축하기 위해 고민할 인센티브가 거의 없습니다.

    • 제품 팀, 특히 엔지니어가 지금 당장 가능한 것을 고려하기보다는 이해관계자가 요구하는 기능과 프로젝트를 제공하는 데만 집중합니다.  그 결과 어떤 형태의 혁신도 프로젝트에서는 극히 드물게 이루어집니다.

    • 팀은 프로젝트에 필요한 기능만 구축하기 때문에 이 작업의 장기적인 영향이나 기반 기술 개선에 대해 걱정할 사람이 없으므로 기술 부채가 빠르게 누적됩니다.

    • 주인의식은 여러 이해관계자에게 분산되어 있으며, 그 결과 프로젝트 팀이 일을 제대로 수행하지 못한 것에 대해 책임을 지게 될 가능성이 가장 높습니다.

• 프로덕트 중심 모델

  • 목적

    • 수익 창출 기간에 집중하고자 할 경우 시도합니다. 

  • 장점

    • time-to-market의 프로젝트보다 time-to-money 성과를 빨리 달성하고자 할 수 있습니다.

    • 이탈률 감소, 성장률 개선 등 비즈니스 성과에 초점을 맞추고, 각 상황에 맞는 관련 KPI를 설정하며, 이러한 결과를 모니터링하고 개선하기 위해 끊임없이 노력할 수 있습니다. 

    • 단순히 기능을 출시하는 것뿐만 아니라 결과에 대한 책임을 지는 문화적 변화를 불러 일으킵니다.

현재 해야 하는 일이 두 모델 중 어떤 것이 더 중요한지 판단해야 합니다. 이 날짜를 맞추는 것인지 아니면 이 결과를 달성하는 것이 더 중요한지에 따라 프로젝트 중심 모델과 프로덕트 모델 중심을 선택하는 것이 필요합니다. 

뉴스레터 구독하기

[5DPP 01] ShortenURL 개발기, 11시간 7분 소요

안녕하세요.

디스콰이엇에서 Marcus.lee로 활동하고 있는 PO입니다.

항상 "내 걸 해보자" 라는 생각만 가지고 있었다가 올해로 10년차에 들어서면서 이러다 아무것도 못하게 될 것 같단 불안감이 엄습했습니다. 그래서 9월부터 working day로 5일 안에 무엇이든 만들어보자(5 Day Product Project)는 결심했고 별 것 아니고 빈약하지만 첫 번째 결과물이 나와 회고의 글을 작성하고자 합니다.

우선 혼자 기획과 개발을 모두 해야 하기 때문에 아이템 선정이 매우 중요했습니다. 과거 이미 몇 번이나 생각보다 큰 프로젝트를 개발하려했다 포기했던 기억이 있기 때문에 더욱 신중하게 고민했습니다. 또한 아무도 안 쓰더라도 나는 꼭 쓸 것을 만들기로 하였습니다. 그래서 2가지 기준을 세웠습니다.

1. 내가 일상에서 필요로 했던 것을 찾아보자.

2. working day로 5일 안에 만들기 위해서 MVP는 정말 필수 기능 1개와 차별점 1개 빼고는 모두 나중으로 미루자.

이 두 가지 기준에 맞춰서 선택된 아이템은 긴 주소를 짧게 줄여주는 서비스입니다.

평소 회사에서 일을 하면서 URL을 공유할 때가 많았는데 URL이 짧은 경우 상관없지만 긴 경우 복사해서 다른 곳에 붙여넣을 때 매우 불편했습니다. 특히 해당 링크를 모바일에서 복사할 때 문장 사이에 포함되어 있을 경우 꾹 눌러 링크 길이에 맞게 수정해야 하다보니 많이 불편했습니다. 그래서 항상 긴 URL을 복사하면 바로 짧은 URL로 자동 변환되었으면 좋겠다 생각했었고 이번 기회에 개발에 들어갔습니다.

빠른 구현을 위해 크롬 확장프로그램으로 개발 시작하였고 URL을 복사하면 바로 짧은 URL로 변경하는 것을 단 하나의 기능으로 잡았습니다. 차별점을 찾기 위해 비슷한 서비스를 확인해보니 모두 2번 이상의 사용자 행동이 필요한 것으로 확인되어 이를 단 한 번, 원클릭으로 해결할 수 있도록 기능을 고민하였습니다. 그 결과 단축키 한 번만 누르면 모든 URL을 어떠한 작업 없이 붙여넣을 때 무조건 짧은 URL로 변환시킬 수 있었습니다.

개발에 들어간 총 시간은 11시간 7분이었는데 간만에 개발하다보니 기능 대비 너무 많은 시간이 소요된 것 같아 아쉬웠습니다. 첫 술에 배부를 순 없다는 것에 공감하며 다음 번에는 더 후회없는 회고가 될 수 있도록 노력하겠습니다.

ps. 디스콰이엇에는 영상 올리기가 안 되나보네요 ㅠㅠ

Tech Spec을 작성해야 하는 이유

23년 9월 1주차 회고

Tech Spec‎을 작성해야 하는 이유

여러 IT 회사를 다니면서 회고 때 항상 언급되는 이슈가 있는데 바로 기획에서 개발로 넘어가는 그 중간 애매한 부분에 대해 고충을 토로하는 분들이 많다는 것입니다. 예를 들면 PO/PM/서비스 기획자들이 기획안을 다 설명했는데 개발팀이 개발을 안하고 있어서 일정이 미뤄진다는 이야기 혹은 기획안을 보았는데 이건 뭐를 만들어 달라는 것인지 모르겠다는 개발팀 이야기, 검증을 해야하는데 이걸 어떻게 개발하겠다는건지 모르겠다는 검증팀 이야기 등입니다. 정말 많은 회사를 다녀보았지만 딱 한 군데 빼고는 이 이슈가 없었던 회사는 없었습니다. 왜 이러한 이슈가 발생하는 것일까요? 

개발자 출신의 PM/PO인 제가 보았을 때는 바로 명확한 기획안 리뷰가 진행되지 않았기 때문입니다. 기획안을 0부터 같이 만들면 정말 좋겠지만 각자 해야 하는 일들이 많기 때문에 현실적으로는 불가능합니다. 그러다보니 PO/PM/서비스 기획자들이 우선 기능 명세를 작성하지만 이는 제품 베이스가 아닌 유저 단의 시나리오에 불과합니다. 유저 시나리오만 보고 제품을 만들 수는 없습니다. 유저 시나리오를 현재 우리 제품의 형상과 구조에 맞게 제품 베이스로 변환하는 작업이 반드시 필요합니다. 이 때  필요한 작업이 바로 Tech Spec 작성입니다. 

Tech Spec은 유저 시나리오를 기반으로 우리 제품의 어떠한 부분이 변경되어야 하며 어떠한 부분이 변경되면 안되는지, 그로 인해 발생할 수 있는 리스크는 무엇인지, 기획의도와 부합하는지를 검토하는 제품 중심의 기술 문서입니다. PRD가 사용자/고객 중심의 문서라면 Tech Spec은 우리 제품의 형상을 정의하는 문서입니다. 그렇기 때문에 기획안 리뷰를 한다하면 화면설계서, IA, 디자인 등의 기획안만 보는 것이 아니라 Tech Spec도 다같이 이야기를 나눠야 합니다. 대부분의 회사에서는 기획안 리뷰는 다같이 하나, Tech Spec은 개발팀과 검증팀 만의 문서로만 남는 경우가 많습니다. 혹은 Tech Spec이 일을 위한 일이라며 작성하지 않는 경우도 많습니다. 그 배경에는 PO/PM/서비스 기획자들에게 이렇게까지 알 필요 없다, 기획이 개발까지 참견하는 것은 아니다는 개발팀의 생각과 설명해줘도 어차피 모르기 때문에 우리는 안 들어도 된다는 기획팀의 생각일 것입니다. Tech Spec을 통해 기획팀이 봐야할 부분은 목표와 목표가 아닌 것입니다. 또한 기획팀이라 할지라도 기술과 멀어져서는 절대 안됩니다. 제품의 형상을 모르고 기획한다는 것이 얼마나 위험한 일인지를 깨달아야 합니다. 또한 개발팀은 Tech Spec 작성이 일을 위한 일이 아닌 사전에 Tech Spec을 작성하여 숙련자/전문가에게 혹은 구성원에게 이렇게 구현했을 경우 어떠한 리스크가 발생할지 같이 논의하고 피드백을 통해 성장하는 기회로 삼아야 합니다. 코드리뷰를 통해서는 스킬적인 부분을, Tech Spec을 통해서는 문제를 접근하는 방식 부분을 배워야 2배 이상 성장할 수 있습니다. 

또한 항상 말씀드리듯 Tech Spec이 있다는 것은 중요하지 않습니다. 어떠한 내용이 어떻게 담기고 어떻게 활용하냐가 더 중요합니다. 단순히 구글 검색해서 이러한 것들도 있으니 우리도 해보자라는 생각보다는 현재 우리에게 비어있는 부분은 무엇이고 앞서 이야기한 기획에서 개발로 넘어가는 그 중간 애매한 부분이 왜 발생하는지 고민하고 해당 내용을 어디에 담을지 결정하는 과정이 반드시 필요합니다. 

결국 명확한 기획안 리뷰란 PRD, 화면설계서, 유저시나리오 등의 기획안과 그 기획안을 바탕으로 만들어진 제품의 개발 방향이 담긴 Tech Spec이 같이 리뷰되는 것을 말합니다. 그렇기 때문에 Tech Spec은 있으면 좋고가 아닌 반드시 작성되어야 하는 문서입니다. PRD와 Tech Spec의 관계와 언제 어떻게 검토되어야 하는지 등에 대한 전체적인 제품의 개발 프로세스에 관련된 글은 9월 내에 작성할 예정입니다.

제품을 만들어야 하는 많은 분들에게 도움이 되었으면 합니다.

블로그 바로가기

뉴스레터 구독하기

PRD를 작성해야 하는 이유

23년 8월 5주차 회고

‎PRD (‎Product Requirement Document)를 작성해야 하는 이유

처음 Product Management로 일할 때만 하더라도 기능 위주의 기획을 중심으로 업무했던 것 같습니다. 그 때만 하더라도 데이터를 수집할 수 있는 방법이 많이 부족했기 때문에 고객 중심으로, 고객의 패턴을 통해 해결책을 찾는 방식보다는 우리가 할 수 있는 것들 중 해결책을 찾았습니다. 하지만 요즘은 데이터를 쉽게 수집할 수 있게 되면서 고객과 문제점을 중심으로 어떻게 해결할지 진행하는 방식으로 많이 바뀌고 있습니다. 또한 과거에는 완성도 있는 제품을 한 번에 만들어 시장에 내보내는 전략을 많이 취했는데 요즘은 불완전하더라도 빠르게 출시하고 지속적으로 수정해나가는 전략을 취합니다. 그러면서 자연스럽게 기획 문서의 양식도 바뀌게 되었습니다. 

과거 기획안이 고객과 문제점에 대한 이야기를 구두로 설명하고 문제를 해결하기 위해 이러한 것이 필요하다는 것을 설명하기 위해 PPT를 활용해 그에 따른 화면을 그려서 유관부서와 논의하는 문서였다면 요새 기획안은 왜 우리가 이것을 해야 하는지, 우리가 해야만 하는 이유는 무엇인지 등을 추가 작성할 수 있게 되었습니다. 더 나아가 정확히 어떤 고객을 타겟하고 있는지, 현재 해당 문제를 겪고 있는 고객 인터뷰 내용도 파악할 수 있게 되었습니다. 쉽게 설명하면 기존에는 기획자에 의존한 상세 기획만 가능했다면 지금은 데이터를 기반으로 한 컨셉 기획도 가능해진 것입니다. 하지만 이러면서 문제점도 같이 발생했습니다. 많은 데이터가 발생함으로 인해 여러 문서가 발생하기 시작했고, 그 문서들의 많은 내용들 속에서 정작 이것이 우리가 해결해야 하는 문제인지 판단하기 어려워졌습니다. 이러한 것을 해결하고자 작성하는 문서가 PRD (‎Product Requirement Document) 입니다. 

PRD 문서는회사마다중요한것에따라조금씩달라지겠지만기본적으로고객과고객의문제점, 제품이있다면현재제품의상태, 문제를해결하고자하는가설과해결방안이작성됩니다. PRD 문서가중요한이유는고객을이해하고문제점을파악해해결방안을수립할수있는가설을세울수있기때문입니다. 물론단순히 PRD 라는문서에위내용이있다고해서목적을달성하는것은아닙니다. 해당문서를통해프로젝트가시작할때, 유관부서와논의할때, 어떠한제품인지이해하고자할때누구나쉽게이해할수있는수준으로작성되어야그목적을달성하는것입니다.

또한 PRD 문서는 한 번 양식을 정하고 마는 것이 아니라 고객을 이해함에 있어서 유관부서와 문제점을 이해하고 해결방안을 모색하는데 있어서 필요한 내용이 있다면 추가되고 필요없는 내용이 있다면 삭제해 지속적으로 업데이트 해 나가야 합니다.  

PRD 샘플 문서가 필요한 경우 아래 양식을 성실히 채워주시면 추석 연휴 전까지 전달해드릴 예정입니다. 

블로그 바로가기

뉴스레터 구독하기

사이드 프로젝트 팀원을 구합니다.

안녕하세요. 저는 10년차 PO/PM 마커스입니다.

제 커리어 상 가장 크게 성장했던 시기를 돌아보면 사이드 프로젝트를 했었을 때인 것 같습니다. 해서 3개월 안에 서비스를 릴리즈할 사이드 프로젝트 팀원(프론트 1분)을 모집하고자 합니다.

아이템의 경우 구성원 분들이 모두 모이면 빠르게 선정하여 진행할 예정이며, 주니어 개발자 혹은 디자이너 분들, 취준생 분들도 환영합니다. (디자이너, 백엔드 부분은 마감입니다~!)현업에서의 실무 경험이 필요하신 분들 혹은 포트폴리오를 만들고 싶으신 분들이 참여하신다면 목적을 달성하실 수 있을 것이라 자신합니다. 팀원 신청해주시면 팀의 성공을 위해 온라인으로 비대면 커피챗을 진행하여 팀을 꾸릴 예정입니다.

진행방식은 5주 단위로 기획(1주)-디자인(1주)-구현(2주)-회고(1주)의 과정을 모두 같이 하려고 합니다. B2C 회사에서의 가장 기본적인 애자일 방식이며, 경험해보신다면 많은 것을 배우실 수 있을 것이라 생각합니다.

신청 기간은 9월 8일까지이며, 9월 말까지 아이템을 같이 선정하고 10월 ~ 12월 구현하는 것으로 생각하고 있습니다.

많은 관심 부탁드립니다.

신청은 아래 링크 부탁드립니다.

https://tally.so/r/w4J9qY

2023년 8월 4주차 회고 - 제품을 만들어야 하는 이유

23년 8월 4주차 회고 - 제품을 만들어야 하는 이유

저는 현재 로봇 AI 비전 회사에서 유일한 PO로 근무 중입니다. 제조업 계열로 하드웨어와 소프트웨어를 모두 다뤄야 하고 로봇이라는 시장이 아직 성숙되지 않다보니 지금까지 모두 PoC를 통해서만 매출에 의존하고 있습니다. PoC 만으로 매출을 내기에는 어렵기 때문에 현재 제품을 만들기 위해 노력하고 있습니다. 기본적인 업무들은 이전 회사에서의 PM/PO의 업무와 동일하지만 이번 회사에서 조금 다른 경험을 하고 있어서 해당 내용을 소개해보고자 합니다.

SI로 매출이 잘나오고 있다면 굳이 제품을 만들어야하는 이유가 있을까요? 회사에서 제품을 만들어야 하는 이유는 무엇일까요? 

매출이 잘 나오는데 굳이 제품을 위한 투자를 한다는 것은 쉽지 않습니다. 여러 이유가 있겠지만 첫 번째로는 현재 매출이 잘 나오기 때문이고, 두 번째로는 지금도 충분히 바쁜데 일을 더 만들고 싶지 않으며, 마지막으로는 긴 SI로 인해 제품화가 불가능하다고 생각하기 때문입니다. 그럼에도 제품화를 해야만 하는 이유는 더 큰 매출을 만들고 리소스를 효율적으로 만들기 위함입니다.

제품화가 왜 SI보다 더 큰 매출을 일으킬까요? 왜 리소스를 효율적으로 만들까요? 

사실 SI도 매출을 일으키는 방법 중 한 가지 일 뿐이지 SI를 통해 고객에게 전달되는 것들 모두 제품입니다. 다만 제품의 재사용성에 대한 문제입니다. 제품을 만든다는 것은 표준을 만드는 것입니다. 제품을 만든다는 것은 우리가 어떤 목적에 의하여(Why) 어떤 시장에서 어떤 문제(What)를 겪고 있는 고객(Who)에게 무슨 서비스를 제공(What, How)하여 해결할지 정한다는 것입니다. 즉, 우리 제품이 판매 가능한 영역을 조금 더 폭넓게 잡으면서 전달할 수 있는 가치에 선택과 집중한다는 것입니다. 그렇기 때문에 더 큰 매출을 만들고 리소스를 효율적으로 사용할 수 있게 됩니다. 그럼에도 불구하고 SI를 포기하기는 쉽지 않습니다. 한 고객 혹은 몇 개의 고객에 대해서만 선택과 집중을 할 수 있고 고민할 거리가 적기 때문입니다.  

그럼 SI가 주인 회사에서 제품화는 어떻게 진행되어야 할까요? 

먼저 구성원들과 공감대를 형성하는 것이 우선입니다. 제품화를 했을 때 가져올 장점과 단점, 제품이 있을 때 변화될 우리가 일하는 방식 등을 충분히 설명하여 단순히 업무적으로 변화 뿐만 아니라 회사의 문화도 어떻게 변해가야 할지 생각할 수 있는 시간을 주어야 합니다. 이러한 시간이 필요한 이유는 업무적으로 SI를 진행하면서 고객마다 다른 요구사항을 직접적으로 경험해 제품화가 불가능하다고 생각하기 때문입니다. 이러한 생각은 원팀으로 만드는 저해 요소가 됩니다. 그렇기 때문에 앞으로 우리가 고객들을 어떻게 대할 것이며, 요구사항은 어떻게 반영할 것인지에 대한 설명하고 어느 부분까지를 범용 제품화할 것인지 각자 고민할 시간을 줘야 합니다.

두 번째로는 제품의 기준을 잡는 것입니다. SI를 했다는 것 자체가 이미 제품에 커스텀을 제외할 수 없는 형상이며 공통 부분만 제품으로 가져가기 어렵다는 뜻입니다. 또한 납품했던 제품들이 고객 가치 중심적이 아닌 고객 생각 중심이라는 것입니다. 그렇기 때문에 어디까지를 범용으로 가져갈지 어디까지를 커스텀을 할지 기준을 잡아야 하며 그 기준은 고객 가치 중심으로 판단해야 합니다. 이 부분은 가장 많은 시간을 들여 많은 의견을 듣고 정해야 할 부분입니다. 

세 번째로 제품팀을 만드는 것입니다. 제품팀을 만드는 것, 조직구조가 반드시 변경되어야 하는 이유는 기존 SI를 하던 조직구조에서 벗어나 제품을 만드는 팀이 명확히 선언되어야 프로젝트 중심의 업무 방식에서 벗어날 수 있습니다.  프로젝트 중심으로 조직구조로도 제품을 만들 수는 있겠으나 만약 그 조직이 프로젝트 업무의 비율을 줄일 수 없다면 제품이 출시되는 기간은 하염없이 늘어날 것 입니다.

마지막으로 MVP 기능보다 빠른 출시에 목표를 두어야 합니다. 첫 제품을 만든다면 정말 중요한 것이 빠른 출시를 통한 고객의 피드백 수집입니다. 이래도 되나 싶을 정도로, 판매할 수 없다 생각이 들 정도로 가벼운 MVP를 선정하여 빠르게 시장에 출시해 피드백을 들어야 합니다. 또한 빠른 출시 목표를 통해 우리 조직의 개발 속도를 알아야 합니다. 앞으로 제품을 만들게 되면 SI 하던 때와 달리 정말 빠르게 핫픽스 혹은 마이너 업데이트를 진행할 가능성이 높기 때문에 개발 속도를 아는 것은 조직 운영 차원에서도 중요합니다. 요구사항에 대한 빠른 개발 과정을 지속적으로 훈련해야 합니다. 빠른 개발 과정을 가져갈 수 있는 조직이라면 고객의 피드백을 더 많이 받을 수 있고 그로 인해 다음 제품은 좋아질 수 있기 때문입니다. 그렇기 때문에 처음 제품을 만든다면 MVP를 선정할 때 왜 이것을 개발해야 하는지, 확장성을 가질려면 어떻게 해야할지 고민하는 것을 줄여야 합니다. 

제품을 만들어야 하는 많은 분들에게 도움이 되었으면 합니다. 

[2023년 8월 3주차 회고] 중요한 것 외에는 챙기지 않는다는 말

* 중요한 것 외에는 챙기지 않는다는 말

회사에서 홈페이지 개편을 하고자 합니다. 이 업무를 A팀에서 하기로 진행하였고 A팀 팀장은 그 동안 홈페이지 개편 때 했던 일들을 모아서 확인해봅니다. 과거 진행했던 일들을 모아보니 중요해 보이는 것들만 팀원들에게 업무를 분배하여 진행합니다. 

위 업무의 마무리는 어떻게 되었을까요? 

팀원들은 팀장이 시키는대로 업무를 진행하던 중 유관부서로부터 x, y, z는 왜 안챙기고 있는지 듣습니다. 그 사실을 몰랐던 팀원들은 정해진 일정 내에 황급히 x, y, z를 챙기기 시작합니다. 유관부서에서는 급작스런 요청 때문에 고생 고생하며 어쨌던간 업무를 마무리 합니다. 팀장은 고생한 팀원들에게 중요한 것이 아닌데 다른 부서에서 비효율적으로 일한다고 이야기합니다.

사례는 다르지만 놀랍게도 제가 다녔던 모든 회사에서 있었던 일입니다.

왜 이러한 일들이 반복될까요?

회사에서 일하다보면 선택과 집중을 위해 중요한 것 외에는 잘 챙기지 않는다고 말하는 사람들을 종종 만날 수 있습니다. 리더일수록, 고인물일수록 이런 말을 자주합니다. 비효율적, 시간 절약을 위해 등등 여러 가지 이유를 통해 중요한 것만 챙기자고 합니다. 어떤 분들은 이러한 말을 선택과 집중을 잘한다는 것의 다른 표현으로 자랑처럼 말합니다. 이러한 분들과 일할 때마다 항상 선택과 집중을 하는 것이 좋은 것인지 고민을 하게 됩니다.

중요한 것 외에는 챙기지 않는다는 말 속에 중요하다는 것은 누구 기준으로 생각해야까요? 중요하지 않다는 말의 의미는 무엇일까요?

많은 업무 중에 우선순위를 정하기 위해 선택과 집중을 한다는 것은 중요합니다. 하지만 진행하기로 한 업무 프로세스 안에서 선택과 집중을 하겠다는 것은 결국 내가 하고 싶은 일만 하겠다는 것과 같은 말입니다. 그 빈 공간은 누가 채워야 할까요? 업무 프로세스란 단순히 한 두 번으로 만들어진 것이 아닌 실무자들이 고민하고 실제 그 일을 하면서 필요한 것들의 플로우이기 때문입니다. 그렇기 때문에 단순히 내가 보기에 혹은 충분히 관련 실무자들의 이야기 듣지 않고 중요한 부분만 실무자들에게 전달한다면 실무자들에게 혼란에 빠질 수 있습니다.

보통 리더들과 이야기 나누면 실무를 챙길 시간이 없어서, 마이크로매니징을 한다는 이야기를 들을까봐 본인은 중요한 것만 챙긴다고 이야기 합니다. 그 중요한 것이 업무의 우선순위인 것이지, 유관부서와 합의되지 않은 프로세스의 변화는 아닙니다. 내 팀원의 일을 줄여서 팀원 평가는 좋을 수 있겠지만 충분한 합의 없이 중요한 것만 이야기한다면 팀원에 대한 유관부서 평가는 깎는 것입니다.

리더일수록, 고인물일수록 하기로 한 업무에 대해 중요한 것과 중요하지 않는 것을 구분하지 말고 전체 프로세스에 집중해 실무자들과 이야기를 나누고 진행해야 실무자들이 혼란없이 일할 수 있습니다. 전체 프로세스를 보고 정말 비효율적인 일이 있다면 회고를 통해 이야기를 나누고 정리하면 됩니다.  현재 리더라면 한 번쯤 고민해보면 좋을 것 같습니다.

어떻게 성장하는지가 중요합니다.

2023년 8월 2주차 회고

* 우리는 회사에서 동료를 통해 성장합니다. 이 과정에서 어떻게 성장하는지가 중요합니다.

회사는 여러 경험을 가진 사람들이 모여서 일하는 곳입니다. 그러다보니 나와 같이 일하는 동료들의 성향과 생각이 이직 여부에 영향을 미칠 정도로 매우 중요해집니다. 특히 나와 같이 일하는 리더의 경우 아무리 강조해도 지나치지 않을 정도로 회사 전반적인 만족도에 영향을 받습니다. 저 또한 제 리더가 저에게 얼마나 영향을 주는지 생각해보고 반대로 제가 사람들에게 얼마만큼의 영향을 주고 있는지 생각합니다. 

이러한 과정 속에서 한 가지 배운 것이 있다면 사람은 과거의 경험 기반으로 행동하게 된다는 것입니다. 예를 들어 A라는 프로젝트를 시작한다고 할 때 모든 것을 혼자 고민하고 혼자 계획을 세워 필요한 사람들만 불러서 진행하는 사람이 있는 반면 프로젝트 시작부터 모두 모여 이야기 하면서 서포트 역할을 하는 사람이 있을 것입니다. 이 두 사람은 과거 A 프로젝트와 비슷한 업무를 진행하면서 혼자 하는 것이 낫다, 내가 서포트 역할만 하는 것이 낫다라는 경험이 있었을 것이고 그 경험 기반으로 행동한다는 것입니다. 이 사례를 통해 어떤 것이 더 좋다/훌륭하다는 것이 아니라 내 리더로부터 내가 어떠한 경험을 전달받는지 혹은 내가 어떠한 경험을 나와 같이 일하는 사람에게 전달하는지를 아는 것이 중요하다는 것입니다. 이것을 아는 것이 중요한 이유는 이 과정 속에서 나도 모르게 많은 것을 배우기 때문입니다. 이 배움/경험이 결국 나의 성장을 위해 필요한 부분이 무엇인지 알고 어떻게 채워야 할지 고민하는 시작점이 됩니다.

그럼 어떻게 성장 포인트로 삼으면 될까요?

우선 리더의 생각을 이해하고자 노력해야 합니다. 리더는 나보다 더 많은 정보를 가지고 있기 때문에 왜 이러한 의사결정을 내렸으며 이러한 행동을 했는지 이해하려고 노력할 때 그 속에서 많은 것을 배울 수 있습니다. 이 이해를 바탕으로 회사 밖의 다양한 사람들을 만나 최대한 많은 것을 경험하는 것이 중요합니다. 책을 통해서든, 강연은 통해서든 나와 다른 사람들은 비슷한 일을 어떻게 해결해 나가는지 알고 내가 처한 현실에서 어떻게 응용하면 좋을지 끊임없이 고민해야 합니다. 그리고 기회가 생긴다면 공감대를 형성하여 이를 적용해봐야 합니다. 적용하지 않고서는 성장이 아닌 단순 공부로만 그치기 때문입니다. 

만약 내가 중간관리자 혹은 리더라면 추가적으로 위임에 대한 연습을 꾸준히 해야 합니다. 앞서 이야기 했듯 나도 내가 경험한 것이 전부입니다. 내 말이 항상 정답도 아니고 합리적이지도 않습니다. 그렇기 때문에 나보다 더 경험이 많은 사람에게 혹은 더 인사이트가 많은 사람에게 권한을 위임하고 믿어주는 과정이 필요합니다. 위임이라는 부분은 내가 여러 사람에게 해보고 경험을 쌓지 않는다면 절대 배우거나 성장할 수 없습니다. 이 과정을 통해 나 또한 새로운 경험을 통해 성장을 할 수 있습니다.

0에서 1로 제품을 처음 만들 때 고려해야 할 것

현재 저는 B2B 로봇 제조회사에서 PoC 단계로만 진행되는 프로젝트들로부터 제품을 만드는 과정에 참여하고 있습니다. 업무를 진행하면 할수록 제품이란 무엇일까라는 근본적인 질문에 마주서고 있습니다. 그 이유는 일반 IT B2C/B2B 제품과 달리 고객을 쉽게 만날 수 없고, 산업 도메인으로 인해 기업이 큰 비용을 지출해야만 제품을 구매할 수 있기 때문입니다. 또한 내부적으로는 여러 부서가 있어 절대 린하게 업무를 할 수가 없기 때문에 한 번 만들 때 잘 만들어야 합니다. 이러한 경우에는 어떻게 제품을 만들어야 할까요? 

고전적으로 제품을 만드는 2가지 방식이 있습니다. 시장에서 필요로 한 것을 만들어 제공하는 market-in 방식과 우리가 잘하는 것을 만들어 제공하는 product-out 방식입니다. 이러한 방식보다 제품을 만드는데 더 중요한 기본 원칙 첫 번째는 팔리는 제품을 만드는 것입니다. 어떠한 방식이 되더라도 팔리지 않는다는 제품은 제품이라 부를 수 없습니다. 그렇기 때문에 제품을 만들고자 한다면 더욱 고객과 시장에 집중에 해야 합니다. 고객에 집중한다는 것은 고객의 말을 100% 믿고 제품을 만든다는 것이 아닙니다. 고객이 겪고 있는 근본적인 문제를 파악한다는 것입니다. 

두 번째는 시장 상태를 객관적으로 봐야한다는 것입니다. 대부분 시장을 만들어 제품을 팔겠다라고 하면 영업에 더 많은 인력을 배치하거나 마케팅 비용을 공격적으로 투자하여 인지도를 올린다는 생각합니다. 하지만 시장이 스스로 성숙될 때까지 기다린다는 것도 포함합니다. 여러 산업 도메인을 경험해보니 시장이 성숙되지 않은 상태에서 무작정 채용을 늘리거나 공격적인 마케팅을 하면 비용만 지출하는 것이지 정작 시장을 만들 수 없음을 알게 되었습니다. 현재 시장이 어떠한 상태인지를 객관적으로 바라보고 시장 상황에 맞는 전략을 펼쳐야 합니다.

세 번째는 팔 수 없는 제품일지라도 최대한 빠른 릴리즈 주기를가져가야 합니다. 특히나 제품을 처음 만든다고 할 때는 이 페이지가 왜 필요한지 파악하고 개발하는 것보다 PO/PM이 세운 가설을 믿고 구멍이 많더라도 최대한 빠르게 제품을 만들어 시장의 평가를 받도록 해야 합니다. 내부에서 아무리 이야기 나누더라도 시장의 평가보다 정확한 것은 없기 때문입니다. 유관부서가 많다면 빠른 릴리즈 주기를 가져가기 힘들다는 것을 알고 있습니다. 그럼에도 빠르게 인터페이스를 정리하고 정말 필요한 일에 리소스를 투자하는 것이 필요합니다.

마지막으로 정말 최소한의 기능만을 구현할 것, 정해진 일정을 당기지 않는 것입니다. 0에서 1로 가기 위해서는 수많은 0.1, 0.2, ... 를 지나야 합니다. 그렇기 때문에 구현 기능이 정해졌더라도 구현의 복잡도와 난이도로 인해 기능을 빼야 한다면 정말 중요한 기능이 아니면 빼고 가야 합니다. minimum의 minimum 기능을 구현하는 것을 목표로 삼아야 합니다. 또한 진행상황이 빠르다고 해서 정해진 일정을 당기는 것은 절대 안됩니다. 세 번째 항목인 빠른 릴리즈 주기와 상반된다 느낄 수 있겠지만 정해진 일정을 당기는 것보다 빠져있었던 구멍을 채우는 일에 집중해야 0.5라도 만들 수 있기 때문입니다. 

0에서 1로 첫 제품을 만드는 과정은 정말 힘들고 많은 사람들이 도와줘야만 가능합니다. 성공을 해 본 사람만이 성공의 방정식을 풀 수 있습니다. 

2023년 7월 4주차 회고

* 체계는 결국 기준이다.

제가 대학생일 때만 하더라도 대부분의 학생들은 창업하기 보다는 대기업과 중소기업으로 취직을 하였습니다. 그러다가 어느 순간부터 창업하는 사람들이 늘어나기 시작했고 창업자들은 기존 유능한 인재를 모셔오기 위해 수평적인 조직 문화, 하고 싶은 것을 다 할 수 있는 문화를 강조했습니다. 지금은 스타트업의 수가 굉장히 많이 늘어나면서 첫 직장을 스타트업으로 가는 사람들이 대부분이게 되었습니다. 그러면서 발생한 부작용이 체계가 사라진 것입니다.

단순히 자유롭고 누구나 말할 수 있어서 체계가 사라진 것은 아닐 것입니다. 자유로워도 체계가 있을 수 있습니다. 하지만 대부분 스타트업은 잃을 것이 없는 또한 도전 정신이 가장 강한 대학생 때 많이 시도하다보니 회사 경험을 해보지 않은 창업자들이 단순히 수평적인 조직 문화, 하고 싶은 것을 다 할 수 있는 문화만 만들었을 뿐 그 속에 자유로움의 기준을 명확히 제시하기 않았기 때문입니다. 기준이 없으니 회사가 지속될수록 능력자의 의견 대신 히스토리를 많이 아는 고인물의 의견대로 진행됩니다. 실제로 저도 스타트업에서 주니어 분들이 할 수 있는 거 다 할 수 있다, 누구든 의견 낼 수 있다하면서 왜 내 의견은 반영되지 않는지 이해가 안된다는 말을 많이 들었습니다. 

기본적으로 회사는 다양한 경험을 가진 여러 명의 사람들이 모여 이익이라는 한 가지 기준을 극대화 해야하는 곳입니다. 이익을 내지 못한다면 결국 존속할 수 없는 것이 회사이기 때문에 누군가는 실패에 대한 책임을 져야 합니다. 그렇기 때문에 의견 내는 것은 자유로워도 반영되는 것은 제한될 수 밖에 없습니다. 앞서 예시처럼 누구든 의견 낼 수 있다했는데 왜 내 의견이 반영되지 않는지 이해가 안간다면 우리 회사에서 의견을 반영해주는 기준은 무엇인지 생각해봅니다. 또한 내가 책임질 준비가 되었는지 돌아봐야 합니다. 또한 고인물들의 전혀 합리적이지 않은 의견만 반영된다면, 이익을 극대화할 수 있는 합리적인 의사 결정이 될 수 있도록 기준을 만들어야 합니다.

이러한 기준을 확립해나간다는 것은 매우 어렵습니다. 많은 사람들을 설득해야 하고 수많은 예외 케이스들이 발생하기 때문입니다. 만약 이러한 기준을 만드는 업무를 해야 한다면, 가장 작은 단순한 것부터 가장 극대화된 효과를 낼 수 있는 기준을 만드는 일부터 하는 것을 추천드립니다. 하나의 작은 성공들이 모여 신뢰를 쌓을 것이고 신뢰는 변화를 이끌어 냅니다.

* 멘토링을 종료하다

5월 말부터 시작되었던 멘토링이 7월 3주차로 마무리 되었습니다. 강의 형식으로 진행된 이번 멘토링은 단발성 멘토링과의 차이점을 확실히 느낄 수 있었습니다. 자료 준비를 하면서 그 동안 회사 생활하면서 경험한 것들을 최대한 많이 녹여서 해보겠다 했지만 실제적으로 다 전달하지 못한 것 같아서 아쉬운 점이 많았습니다. 이번을 계기로 다음 번 할 때는 더 좋은 자료를 바탕으로 진행하고자 준비해야겠습니다.  

Today I Learned #18 (23.07.23)

*** 오늘 본 내용 ***

원문 : https://sidsaladi.substack.com/p/week-3x-mastering-customer-interviews

• 제품의 성공은 고객의 니즈를 이해하고 해결하는 데 뿌리를 두고 있으며, 무엇을 만들 수 있는지가 아니라 고객이 진정으로 원하는 것이 무엇인지에 달려 있습니다.

• 고객으로부터 올바른 인사이트를 발견하기 위한 5가지 전략

  1. 적합한 고객과 대화하기: 🎯

  2. 좋은 질문을 하고 나쁜 질문은 피하세요: ❓❗️

  3. 인터뷰는 캐주얼하게 진행하세요: 😎

  4. 사람들이 말을 하는 이유와 문제의 근본 원인을 이해하도록 노력하세요.

  5. 덜 말하고 더 많이 듣습니다: 👂

• 고객 인터뷰 토론 가이드 템플릿 📝

  • 면접자의 배경 정보

    • 귀하의 이름:

    • ‎귀하의 직위:

    • ‎소속 회사:

  • 인터뷰 대상자의 배경 정보

    • 고객 이름:

    • ‎고객의 역할/직위:

    • ‎회사(해당되는 경우):

    • ‎고객으로서의 기간:

  • 인터뷰 목표/목적 🎯

    • 목표 1(예: 제품에 대한 고객의 경험 이해)

    • ‎목표 2(예: 불만 사항 및 개선이 필요한 부분 파악)

    • ‎목표 3(예: 잠재적인 새로운 기능 또는 솔루션 탐색)

  • 인터뷰 개요 📋

  • 소개 및 아이스 브레이커(5분)

    • 본인 소개 및 역할 소개

    • ‎참여해 주신 고객에게 감사 인사하기

    • ‎인터뷰의 목적과 목표를 설명합니다.

    • ‎기밀을 보장하고 고객의 피드백이 소중하다는 점을 강조합니다.

  • 고객 배경 및 상황(5~10분)

    • 저희 [제품/서비스]를 사용한 지 얼마나 되셨나요?

    • ‎처음에 [제품/서비스]를 사용하게 된 계기는 무엇인가요?

    • ‎과거에 비슷한 목적으로 다른 어떤 제품/서비스를 사용하셨나요?

  • 고객 경험 및 만족도(10~15분)

    • 저희 [제품/서비스]에 대한 전반적인 경험을 설명해 주시겠습니까?

    • ‎저희 [제품/서비스]에서 가장 마음에 드는 점은 무엇인가요?

    • ‎저희 [제품/서비스]의 어떤 부분이 개선될 수 있거나 어려움을 겪고 계신가요?

  • 불만 사항 및 도전 과제(10~15분)

    • 저희 [제품/서비스]를 사용하면서 어떤 구체적인 어려움이나 고충을 겪으셨나요?

    • ‎이전에 이러한 문제나 고충을 어떻게 해결했나요?

    • ‎이러한 문제를 더 잘 해결하기 위해 [제품/서비스]가 무엇을 할 수 있기를 바라십니까?

  • 새로운 기능 또는 솔루션(10~15분)

    • 저희 [제품/서비스]에 추가되었으면 하는 기능이나 솔루션이 있으신가요?

    • ‎이러한 기능이 추가되면 사용자 경험을 향상시키거나 고충을 해결하는 데 어떻게 도움이 될 것이라고 생각하시나요?

    • ‎해당되는 경우 이러한 추가 기능이나 솔루션에 대해 더 많은 비용을 지불할 의향이 있으신가요?

  • 마무리 및 다음 단계(5분)

    • 시간을 내어 소중한 피드백을 보내준 고객에게 감사합니다.

    • ‎다음 인터뷰 대상으로 추천하고 싶은 사람이 있나요?

    • ‎인터뷰의 주요 내용을 간략하게 요약하세요.

    • ‎인터뷰 대상자의 의견이 [제품/서비스] 개선에 어떻게 활용될지 설명하세요.

  • 해당되는 경우, 참여에 대한 인센티브(예: 기프트 카드, 할인)에 대한 정보를 제공합니다.

https://wikilog.tistory.com/95