Meissa Platform: 이슈 관리 기능 제안, 인터뷰를 통한 가설 검증 건설은 프로젝트 기간이 길고, 의사소통 이해관계자가 많습니다. 메이사는 스마트건설 솔루션이 주 제품으로, 건설의 다양한 업무를 디지털화합니다. 현장에서 메신저로만 이슈를 관리할 때 생기는 어려움을 해소하고자 했습니다. 고객의 요구가 명확한 B2B 제품이지만 고객의 요청이 아닌, 팀 내부에서 고객의 문제를 파악해 [문제정의, 가설수립, 검증, 피드백] 사이클을 진행한 프로젝트였습니다. Behance에서도 포트폴리오를 확인하실 수 있습니다. 차례 프로젝트 개요 배경 상세 문제, 가설, 솔루션 결과물 현장 인터뷰, 인사이트 프로젝트 결과 분석 프로젝트 종료 이후 개선 이터레이션 회고 마치며 1. 프로젝트 개요 회사: (주)메이사 프로젝트 기간 기능 논의와 제작: 2022년 8월 — 2022년 11월 인터뷰 기획 및 진행: 2022년 12월 — 2023년 3월 타겟 유저: 건설 현장 관리자(공사, 안전, 감리), 협력업체별 대표, 골프장 잔디관리팀 참여 인원: PO (1), Product Designer (본인 1), FrontEnd Engineer (1), BackEnd Engineer (1) 역할: 프로젝트 목표 협의 주도, 킥오프 오퍼레이션 와이어프레임, 플로우 기획, 상세 디자인 대응, 테스트 케이스 작성 및 QA 참여 고객 인터뷰 및 솔루션 도출 → 팀원들에게 공유 기여도: 기획 50%, 디자인 100% 2. 배경 상세 건설 현장 업무는 다양하게 처리되지만 메신저(카카오톡)를 통해 이미지를 전송해 작업 지시와 보고를 하는 모습을 가장 흔하게 볼 수 있었습니다. 또 이를 컴퓨터로 다운로드해 보고서로 옮겨서 만든 한글 파일로 본사 보고가 오가는 과정이 있는데, 이 과정은 회사와 관계 없이 전체적으로 띠는 양상이라는 것을 알게 되었습니다. 건설 현장에서는 현장 이미지를 [카카오톡]으로 주고 받으며 일하고 있었습니다. 채팅만으로는 이슈를 관리하는 데에 어려움이 있을 것 같았고, 이미지와 함께 이슈를 어떻게 하면 잘 관리하게 도울 수 있을까 고민하게 되었는데요. 저희 서비스가 생기기도 전부터 사랑을 받던 [동산보드판]이라는 앱이 있습니다. 아주 간단한 기능만으로 10년 동안 계속 인기를 끌었던 이 앱은 현장 상황(이미지)을 간단하게 공유해서 지시/보고 과정을 간결화 해줄 수 있는 서비스가 꼭 필요하다는 뜻이라고 생각했습니다. 초기 요청 그리고 이런 배경을 알게 되어 기능을 담당하게 된 당시 PO는 건설 현장과 신규 사업인 골프장 잔디관리 현장이 다양한 이슈 관리를 이미지 공유, 수기로 하고 있으니 이를 우리 제품 안에서도 해결할 수 있도록 해주자고 기능을 요청하셨습니다. "[건설 작업 일보]라고 현장에서 건설 작업을 실시, 작업 내용을 기록해서 보관하는 문서가 있는데, 앞으로는 그런 것도 저희 제품에서 해결하면 좋을 것 같다." "우리가 진출 예정인 ‘골프 잔디관리’ 분야도 엑셀, 수기로 작업일지를 관리한다고 하는데 같이 해결할 수 있겠다." 당시 담당 PO가 요청하신 기능은 이런 형식이었습니다. 제품에서 이미 제공하는 [위치 도구] 하위에 [이미지] 섹션을 추가하는 것이었죠. 하지만 킥오프 후, 이게 정말 좋은 해결책일지 고민되었습니다. 기능 발견 가능성이 낮아보였습니다. 뎁스가 4단계나 되는데 강조하고픈 기능을 너무 깊이 숨겨두는 게 아닐까? 최소한 검증을 해볼 수 있는 형태로 눈에 띄게 가치가 제안되어야 하지 않을까? 사용자들이 [위치 도구]를 보고 ‘이런 이슈들을 관리하면 좋겠다’고 자연스럽게 연상할 수 있을까? 기대하는 사용성이 모호했습니다. 타겟 유저의 익숙한 프로세스인 [작업일보]를 완전히 대체할 수 있을만한 임팩트를 목표로 해야하는 걸까? 얼마나 구체적인 이슈들까지 우리 제품에서 커버할 수 있을까? 그래서 대표적인 관계자 분들과 캐주얼한 논의해봤을 때, 모두의 생각이 달라 회의를 진행해보자는 결론에 도달했습니다. 이는 프로젝트 방향을 변경하는 계기가 되었습니다. 다시 회의를 진행하면서 각자가 바라는 방향과 실현가능성을 애기해보고 프로젝트 목표와 수단을 다시 협의하고자 했습니다. 방향성 재논의 1. MVP에 모바일은 꼭 필요하다! [동산보드판]이 10년 넘게 사랑받은 이유는 휴대폰으로 공유까지 가능하기 때문이었다. 모바일 없는 이슈 관리는 앙꼬 없는 찐빵! 이중작업만 늘어나 타겟 유저들이 도입하지 않을 것. 그렇지만 당장 개발 가능한 모바일 인력이 없다! → 모바일은 무조건 해야 한다! 웹 먼저 하지만 앱을 곧 배포할 것을 약속 파일 업로드/공유가 쉬워져야 타겟 유저들의 유입이 생기고, 임팩트도 클 것! 제품팀 인력과 개발 환경을 고려해 웹 먼저 배포하지만, 모바일은 꼭 필요하다는 것에 동의. 2. 건설, 잔디 관리에 모두 적용 가능한 범용적 기능을 먼저 배포한 후에 특화하자! 골프장 잔디 관리 MVP에도 들어가면 좋겠는데, 그럼 지금은 범용적인 기능 먼저 해두고 나중에 뾰족하게 만들어 가자. → ‘범용적인 기능부터' 먼저 진행하자. 엑셀, 수기로 관리하는 일들을 인터넷/디지털 환경에서 관리할 수 있게 성공적으로 전환 카톡 커뮤니케이션, 보고서 작성하던 프로세스를 메이사에서 커뮤니케이션, 자동 보관되도록 이슈 보고/관리 프로세스 간편화 3. 검증을 어떻게 할 수 있을까? 개발 전, 데스크 리서치 말고도 좀더 검증을 해보고 싶은데 도저히 기간이 안될까? 사전/사후 검증은 현장 인터뷰가 가장 좋을 것 같다. → 배포 이후 얼마든지 검증 인터뷰 가능! 회의 시점이 잔디 관리 솔루션 출시일이 정해졌던 시기, 이슈 관리 기능의 마감 기한도 정해진 셈 배포를 먼저 한 후에 검증은 얼마든지 할 수 있도록 협의 목표와 범위 재설정 논의를 거쳐 다소 '이미지 업로드'에 치우쳐있던 프로젝트 목표와 범위를 다시 설정했습니다. 3. 문제 재정의, 가설, 솔루션 문제 건설 프로젝트는 다양한 이해관계자가 참여해 커뮤니케이션 복잡도가 높습니다. 현장 내에서만 해도 소장, 안전관리자, 감리자, 협력업체별 팀장, 인력반장, 공무팀이 있죠. 여기에 시행사 본사의 담당자와 발주처, 개별 근로자들까지 합친다면 소통해야 할 주체가 엄청나게 많아지기도 합니다. 게다가 메신저로만 이슈를 관리할 때는 많은 사람을 친구로 추가하거나 관리해야 한다는 문제가 생깁니다. 단체방 참여자 수도 300명이 넘어갈 때가 있고요. 참여해야 하는 채널 개수가 20개에 육박하기도 하고, 카카오톡은 대화용 메신저이기 때문에 Thread 기능이 없어서 중요한 정보를 놓칠 확률이 높습니다. 지시할 때 위치가 텍스트, 사진으로만 설명되는 점도 직관적이지는 않다고 판단했고, 2주 이미지 보관 제한으로 히스토리 보관을 따로 해야하는 이중작업/보고의 어려움도 있습니다. 가설, 솔루션 가설 1 카카오톡의 단점들을 해결해주는 제품을 선택할 것이다. 솔루션 1 이슈별 실시간 대화로 상태를 추적하고 증거 보관까지 한번에 해결해주자. 위에 나열한 카카오톡에서 업무 관리를 할 때 생기는 페인포인트들을 저렴하게 해결하는 솔루션을 알게되면, 선택할 거라는 가설을 세웠습니다. 저희 제품에 이슈별로 데이터를 올리고 공유하고 대화할 수 있게끔 한다면, 그리고 따로 이미지를 저장하거나 보고서를 작성할 필요 없이 히스토리가 저장되어 언제든지 열람만 해도 된다면 좋을 거라고 생각했어요. 가설 2 위치를 텍스트로 설명하기 때문에 공유받은 사람이 직관적으로 알 수 없다. 솔루션 2 위치 정보를 시각적으로 제공해서 추가적인 설명을 줄이자. 건설 현장 사용자들은 참고할 수 있는 이미지, 증거 이미지 등을 카카오톡으로 전송한 뒤에 그에 대한 보충 설명을 텍스트 메시지로 전송하는 방식으로 소통하고 있었습니다. 메이사는 언제든지 현장 전체를 한눈에 볼 수 있는 고해상도 지도를 제공합니다. 그 위에 이슈 지점을 표시하고 업무에 필요한 메시지나 이미지를 확인, 댓글로 소통할 수 있다면 위치에 대한 추가적인 설명을 줄일 수 있다고 생각했습니다. 이 기능을 만들 때 참고했던 것은 Notion과 Figma의 '코멘트' 기능이었습니다. Notion은 특정 텍스트, 블록을 선택해서 댓글을 달거나 페이지 자체에 댓글을 남길 수 있습니다. Figma는 좀더 우리 서비스와 비슷하게 모든 방향으로 이동이 자유로우면서도 원하는 위치에 마커를 표시한 뒤 댓글을 남길 수 있죠. 둘다 [완료] 처리를 할 수 있고, 완료된 댓글도 볼 수 있는 보기 옵션이 있습니다. 4. 결과물 이슈 정보 입력 이슈별로 정보를 입력할 수 있는 화면입니다. 이슈를 나타내는 대표 이미지를 선택하고 이슈에 대한 이름과 설명을 추가해 생성할 수 있습니다. 이슈 생성/완료 시 안내 생성되고 완료될 때 안내 문구가 추가되도록 하여 생성일시, 완료일시, 그 동작을 수행한 유저의 이름과 직책이 가 함께 기록 되도록 했습니다. 댓글 정보 댓글 작성자의 이름, 소속 회사, 직책 정보가 한 박스 안에 표시되어야 하는데, 카카오톡에서는 많은 이해관계자를 알아보기 위해 이름 란에 모두 정보를 넣게 되어 이름이 길어지는 단점이 있었습니다. 이를 보완하고자 위계를 다르게 디자인했습니다. 내 댓글 다른 사용자가 작성한 댓글과 시각적인 차이를 위해 이름 옆에 뱃지를 추가했습니다. 내 댓글 수정 스레드 댓글 소통이 주된 액션인 Slack 메시지 디자인을 참고해 디자인했습니다. 본인이 작성한 댓글만 수정과 삭제가 가능하고, 수정할 때는 취소와 저장 버튼이 충분히 눈에 띌 수 있도록 하고자 했습니다. 댓글 입력창 텍스트 입력 길이에 따라 유연하게 변하도록 디자인했습니다. 추후 개발될 모바일 앱 구현을 고려해, Slack 모바일 앱과 카카오톡 앱의 입력창을 가장 많이 참고했습니다. 5. 현장 인터뷰, 인사이트 1차 배포 이후, 편의성을 위해 관리자용 앱(전 Meissa Lite)을 제작할 예정이었기 때문에, 앱 기획을 시작하기 전에라도 인터뷰를 진행해서 더 좋은 방향을 설정하고자 했습니다. 인터뷰 기획 시 《꼭 필요한만큼의 리서치》, 《7가지 코드》 도서를 참고해 프로세스를 기능 담당 PO에게 제안했고, 문서를 만들어 공유했습니다. 특히 《7가지 코드》에서 MVP 대신 제안한 RAT(최고위험가설) 개념을 적용하여 가설을 새로 세워보기도 했습니다. 1개월 동안 최대한 많은 데이터를 수집해보려고 했지만, 인터뷰 일정을 잡는 것 자체가 예상보다 어려워 (사업팀의 협조 필요, 인터뷰할만한 고객사 스크리닝 필요) 인터뷰 간 텀이 약 3주에서 1개월로 길어져 예상했던 프로세스를 변경해 진행했습니다. 기존 작업 프로세스에 대한 가설, 작업 지시와 보고 과정을 자세히 파악하는 질문이 주된 내용이었고, 가장 가치를 많이 느끼시는 기능들을 확인하고 피드백을 직접 받는 시간도 포함했습니다. 가설 1, 건설 현장 인사이트 건설 현장 고객들은 이미 카카오톡의 한계를 알고 있기 때문에, 훨씬 다양한 용도에 맞는 다양한 제품을 조합해 사용하고 있었습니다. 사내 솔루션 사용 현장은 가점을 얻는 등 저희가 예상치 못했던 더 다양한 제약을 알게 되기도 했습니다. 하지만 카카오톡의 한계를 느껴 무전기, 네이버 밴드 등 적극적으로 해결책을 찾아 보완하고 있다는 점은 저희가 제대로 된 문제를 찾은 게 맞다는 의미이기도 했습니다. 고객이 불편하다고 말만 하지 않고, 실제로 해결해보려고 행동한 것이라는 점에 있어서 그렇습니다. 가설 2, 건설 현장 인사이트 현장 인터뷰를 기획하면서 만든 최고 위험 가설이 들어맞은 내용입니다. 저희는 저희가 제공할 수 있는 '위치'에 대한 시각적인 정보가 유용할 것이라고 생각했지만, 현장 외부에서 보고를 받는 경우를 제외하고는 그리 좋은 포인트는 아니었습니다. 건설 현장에는 위치가 잘 바뀌지 않는 '시설물'들이 있는데, 현장 내부에서는 위치를 얘기할 때 그 시설물을 기준으로 말하기 때문에 그리 위치 파악이 힘들지 않다는 거죠. 현장에서 일한지 얼마 안된 근로자들은 어떡하냐는 질문을 던지자, 어차피 그런 근로자들은 관리자가 직접 동행해서 지시하신다더라구요. 결국 이슈 위치 시각화는 건설현장에서 큰 의미가 없었습니다. 6. 프로젝트 결과 분석 건설 현장과 골프장 인터뷰를 함께 해본 결과, 건설에서 틀렸던 가설이 잔디 관리에서는 맞는 등 다른 양상을 보였습니다. 이슈 관리 기능은 건설보다 골프장 잔디관리 고객에게서 가능성을 볼 수 있었습니다. 건설 프로젝트는 그 시간이 아무리 길더라도 0에서 1을 만드는 것이고 끝이 있습니다. 골프장 잔디 관리는 끝이 없는 유지보수 성격이 강한 곳입니다. 농사 짓는 일을 생각하면 좀더 쉬울 것 같네요. 농장을 가꾸는 사람은 '농사일지'를 꾸준히 작성합니다. 그래야 내년, 내후년, 그 후에도 비슷한 시기에 어떤 일이 있었는지 과거를 돌아보며 미래를 예측할 수 있기 때문입니다. 골프는 건설과 필요한 데이터가 비슷해보여도 고객의 목적이 이렇게 완전히 다르기 때문에 다른 반응을 보일 수밖에 없다는 사실을 통해 B2B 제품에서 항상 강조하는 '고객이 완수하고자 하는 일(Jobs To Be Done)'의 중요성을 새삼 깨닫게 되기도 했습니다. 7. 프로젝트 종료 이후 개선 이터레이션 저희는 건설 현장보다 골프 잔디관리 현장에서 가능성을 확인했기 때문에 골프 잔디관리, 코스관리 팀을 인터뷰하며 필요한 기능들을 점진적으로 보충했습니다. 면적 이슈 추가 골프 잔디 관리에서는 위치를 콕 집어 설명하는 것보다 [이 '영역'의 잔디에 OO관리를 하라]는 지시가 필요했습니다. 그래서 점 뿐만 아니라 [면적]으로도 이슈를 추가할 수 있는 기능을 배포했습니다. 면적 이슈에 대한 식생지수 계산, 비교 골프장 솔루션에서는 잔디의 식생지수를 퍼센티지로 관리합니다. 드론으로 촬영한 이미지 전체로만 가능했던 식생지수를 특정 구역 지수를 확인할 수 있도록 했습니다. 특정 구역 지수를 최대 9개 날짜까지 비교할 수 있는 기능까지 제공했습니다. 빠른 이슈 생성 휴대폰에서 타이핑하지 않고도 빠르게 이슈를 생성할 수 있도록 했습니다. 필수값을 해제한 이슈 종류인데, 음성인식(STT)기술로 마이크를 사용하거나 사진만으로도 생성할 수 있는 이슈 타입을 추가 지원했습니다. 작업 일지 (예정) 1년 전 오늘, 10년 전 오늘 등의 현재, 미래 시점에 필요한 작업을 추천받을 수 있도록 작업 일지를 디지털화하여 저장하는 프로세스를 제안하고자 합니다. 8. 회고 건설에 대해서는 가설을 세웠지만 많이 틀렸다고 생각했습니다. 이슈 관리/커뮤니케이션의 높은 복잡도로 고객들이 실제로 어려움을 극복하기 위해 노력하고 있는 것을 보면 문제를 맞게 찾았다는 생각이지만, 가설과 솔루션을 도출할 때에 헛다리를 많이 짚었다는 생각이 듭니다. 최고위험가설(RAT) 중에 맞은 것들이 몇 가지 있었습니다. 인터뷰를 통해 다시 알게 된 업무 프로세스는 우리가 생각했던 것보다 훨씬 체계적이었고, 다양한 차원의 제약이 있었습니다. (본사 압박 등) 모바일 앱이 출시된지 꽤 지났지만, 활성 사용자가 매우 적은 상태입니다. 고객들이 제품의 Beta 기능은 신뢰를 하지 않아 사용해보지도 않는다는 사실을 인터뷰를 진행하면서 알게 되었습니다. 😥 무엇이 잘못 된 걸까? 사전검증을 하지 않고 속도에만 집중했습니다. 사용자들의 업무 프로세스를 데스크 리서치로만 확인해보고 개발에 뛰어들었습니다. 관성적으로 사용자가 아닌 개발을 위한 방향과 공수를 먼저 생각한 게 가장 큰 문제라고 생각했습니다. 데드라인이 있다는 이유로 아이디어를 먼저 간단하게라도 검증해보려고 하지 않고, 개발에 대한 생각을 했던 것입니다. 사내 리서치 문화가 없었습니다. ‘그때 왜 그렇게 생각했을까’ 돌이켜 보았더니, 사내 리서치 문화가 전혀 없었고, 그 중요도에 대한 공감대도 없다는 사실을 새삼 깨닫게 되었습니다. 문제 의식을 공유하고 함께 해결책을 모색해 봐야겠다 《린 고객 개발》이라는 책을 읽고, 회고하며 생각을 정리할 수 있었습니다. 이 책을 읽고 우리 팀은 그동안 ‘낭비를 줄이기 위한’ 액션을 딱히 시도하지 않았다는 걸 깨닫게 되었습니다. 특히 개발에 드는 낭비 자원이요. 다양하게 문제를 생각해봤지만 서로에 대한 이해와 공감이 필요한 영역이다보니 혼자서는 할 수 없었습니다. 그래서 국내사업 팀장님(하OO 님)과 PO 챕터 리드 (김OO 님) 두 분을 각각 1:1로 만나서 제가 정의한 문제들을 설명하고 해결책을 함께 논의해보면 좋겠다고 말씀드렸습니다. 두 분은 흔쾌히 이런 얘기를 꺼내주어 고맙다며 응하셨습니다. 〈김김하〉라는 회의를 3개월 정도 진행하며 서로의 페인포인트와 개선점을 총체적으로 논의하고 제안할 수 있었습니다. 저희는 카드소팅 방식을 통해서 논의해서 문제점을 크게 세 가지로 나눌 수 있었습니다. 내부에 리서치 문화/공감대가 없어 고객에 대한 이해를 충분히 하지 못하며 양질의 데이터를 수집할 수 없는 악순환이 생긴다. 원인 파악과 액션 플랜 도출을 위해 제가 읽었던 《린 고객 개발》과 《7가지 코드》라는 도서의 내용 일부를 함께 읽거나 공유하고, 다양한 MVP 검증 방법을 소개해 우리에게 맞는 방식이 있을지 대화하기도 했습니다. ✅ 액션 플랜 수행 문제점 중 우선순위를 나눠봤습니다. 3가지 중 1번과 2번이 가장 시급한 문제라고 협의했고 각각을 해결하기 위한, 당장 실행 가능한 일이 무엇인지 논의/ 도출할 수 있었습니다. 회의 내용을 바탕으로, 경영진에 리서치 문화에 대한 필요성을 강조하고 요청 2023년 4월, 회의를 마무리한 뒤 경영진에 미팅을 요청해 내용을 공유, 합의했습니다. 건설 프로젝트 이해관계자들 간의 관계를 다시 파악, 도식화해서 전사에 공유 2023년 5월 19일, 전사 공유 세션에서 PO 챕터 리드 김OO님이 해당 도식과 내용을 공유했습니다. 국내사업팀 OKR에 제품 팀원과 함께 현장 인터뷰를 진행하는, 적극적으로 돕는 목표를 추가 2023년 1–2분기 중 현장 인터뷰를 8회 이상 진행할 수 있었습니다. 💪 그 외의 노력들 온보딩 문서의 고객/사용자 정보 업데이트 새로 입사하신 분들께 보여드렸던 고객 설명을 바꿨습니다. 좀더 정확한 최신의 정보를 보기 쉽게 도식화한 이미지가 생겼으니까요. 아직도 건설이 낯설었던 사원들과 신규 입사자들에게 이전보다 좋은 가이드가 되었다는 평가를 받았습니다. Meissa Scan 제품 개발 전, 사용자 니즈와 리스크 요소 조사 당시 회사에서 드론으로 취득하는 실외 데이터 뿐만 아니라, 360 파노라마 이미지를 통해 실내 데이터를 수집할 수 있는 새로운 제품(앱)을 만들어 출시하고자 했습니다. 아직 사내에서 그 기술 가능성을 확인 중일 때, 인터뷰를 통해 위험 요소를 알아보고자 했습니다. 실내 데이터 취득이 필요하긴 하지만, 취득 주체의 모호함과 모든 건축 동을 돌아다녀야 하는 수고로움이 너무 크다는 문제를 알 수 있었습니다. 이렇게 인터뷰 후 ‘수집의 용이성’이 가장 중요하다는 것을 알게 되어 360 이미지가 아닌, ‘360 영상 수집'으로 MVP 방향을 변경해서 기술 가능성 확인을 다시 하게 되었습니다. 토공물량표 기획 전, 타겟 유저 확인 및 협의 D사와의 계약에 묶인 기능 요청이었는데, 기획을 시작하기 전 국내사업팀장님과 PO를 포함한 회의를 요청하여 타겟을 확실히 하고자 했습니다. 알고보니 D사에서 요청한 형식은 [건축] 현장에서 진행하는 토공사에 필요한 것이었고, 보통 [토목] 현장에서 만들고 보고하는 토적표와는 다르다는 걸 알게 되었습니다. 사전에 타겟을 다시 짚고 넘어가고자 했기 때문에 기능에 대한 네이밍과 가치 제안을 건축 현장으로 맞추어 진행할 수 있었습니다. 9. 마치며 그래도 의미 있던 점이 있다면... 대기업 건설사 대상의 건설 B2B 솔루션을 4년 간 기획하고 디자인하며 크게 느꼈던 점은 저희 서비스는 다른 서비스들에 비해 고객의 요구의 수가 적지만 요구마다 강하고 명확하게 들어오는 편이라는 것입니다. 요청 기능들에 대한 설명을 구체적으로 적은 PPT 파일을 주시는 고객사도 많은데, 정말 친절한 형태이지만 제품팀 입장에서 고객이 기존 업무 프로세스에서 정확히 어떤 페인포인트가 있는지 또는 왜 얼마나 필요한지 파악하기 쉬운 형태와는 멉니다. (ex. 이 기능이 이런 식으로 필요하니 이 위치에 추가해주세요) 분석에서 많은 부분을 차지하는 것은 대량의 정보를 이해해서 기본 패턴을 파악 하고 거기에 대해 조치를 취하는 것이다. 그러나 초기 단계의 B2B 스타트업은 패턴이라고 할 만한 게 없고 고객만 있다. 《린 분석》 도서에 있던 표현을 빌리자면, 그런 상황이 당연하다는 생각이 들기도 합니다. 이렇게 고객사의 까다로운 요청을 하나씩 검토하고 기본 지식을 이해하는 시간이 훨씬 더 많이 소요되는 환경이지만, 이번 이슈 기능은 제품팀이 먼저 고객들의 패턴과 페인포인트를 파악하고, 고객들에게 솔루션을 제안해본 경험이라는 것에 의미가 있다고 생각합니다. 만약 다시 시작할 수 있다면... 매몰비용이 커지기 전에(실제로 개발을 하기 전에, 기획도 하기 전에!) 컨셉에 대한 가설을 더 검증해보려고 했을 것 같습니다. 컨셉 이미지를 가지고 사전 전화 인터뷰, 현장 인터뷰 등 개발 전에 고객의 목소리를 더 적극적으로 수집했다면 배포 이후에 인터뷰를 통해 알았던 본사 차원의 제약 같은 것들도 적은 노력으로 확인할 수 있었을 것 같습니다. 그랬다면 프로젝트를 아예 다르게 이끌 수도 있지 않았을까요? MVP로 앱을 직접 만들지 않고 오히려 메신저를 더 잘 사용할 수 있도록 도와주는 형태였다면, 또는 우리가 메신저를 적극 활용하는 형태였다면 어땠을까요? 예를 들면 챗봇을 통해 작업 지시를 받고 보고하면, 자동으로 히스토리까지 보관되게 해서 관리자들도 편하게 히스토리 열람을 할 수 있는 형태로요. MVP로써도, 서비스로써도 가장 좋은 수단이었을 지도 모르겠다고 생각하며 회고를 마친 기억이 납니다.
