우리의 제품이 문제를 푼다고 착각했던 순간을 솔직히 공유합니다.

저는 AI 프로젝트 매니저 Ace를 만들고 있습니다. 최근에 프로덕트의 퍼블릭 베타를 런칭함과 동시에 AI 메이커 스프린트 1기에 참여하고, 10개 정도의 고객사와 함께 하루하루 성장하며 PMF를 찾으려고 노력하고 있어요.

저희가 푸는 프로젝트 매니지먼트라는 문제는 매력적이라고 느껴요. 초등학생 때부터 10년간 10개 이상의 프로덕트를 만들던 저에게 제일 큰 고통을 줬던 문제기도 하고, 많은 사람들에게도 마찬가지니까요.

프로젝트 매니지먼트는 모든 소프트웨어 팀이 겪는 문제

Ace의 첫 삽을 뜨기 전에, 2-30명정도의 PM님들을 인터뷰했어요. 프로젝트 매니지먼트는 문제는 공통적으로 많은 팀들이 느낀 문제였습니다. 티켓 업데이트의 어려움부터 많은 사람들과 싱크하는데 많은 시간을 쓰는 등, 단순한 문제를 넘어서 해결을 포기할 정도의 문제가 많이 보였어요.

이를 해결하기 위해서도 JIRA, Asana 등의 툴을 유료로 도입하는 건 이미 흔한 현상이였습니다. 심지어 내부 티켓팅 슬랙봇을 만든다던지, 여러 프로세스를 시도하거나 사람을 채용하는 등 자체적인 시도도 많이 보였어요.

많은 회사들이 이 문제 해결을 위해 PM 툴을 도입한다. 하지만 팀원 모두가 내용을 채우지 않으면 의미가 없는 간접적인 툴에 불과하다. 그럼 툴이 아니라, 실제 사람처럼 팀원과 싱크해서 PM 툴을 업데이트하는 PM AI를 만들어 문제를 직접 해결하면 어떨까?

그렇게 야심차게 MVP를 출시합니다!

순탄하지 않은 첫 MVP

처음에 저희가 내놓은 MVP는 "JIRA에 태스크를 업데이트해주는 AI 데일리 스탠드업 봇"이였습니다. 예를 들어 "어제 뭐했는지 / 오늘 뭐할건지"에 대한 데일리 스탠드업 질문이나, 마감일이 다가오는 태스크를 팔로업하는 등의 질문을 던지고 그 결과를 JIRA에 업데이트해주는 것이였죠.

열심히 개발하던 어느날, 유저 피드백 하나를 받고 큰 변곡점이 생기게 됩니다.

"Ace는 주니어 PM이 시니어 흉내를 내는 것 같다. 건방지다는 느낌을 받았다."

이 피드백을 받고 당황했습니다. 건방지다는게 뭐지?

그때 팀에서 논의했던 결론은 "기능이 부족하기 때문에 Ace의 효용이 적은 것 아닐까?" 였습니다.
그러면서 생각했던 내용은:

• 말투를 커스텀할 수 있는 기능을 만들자.

• Ace의 질문을 진지하게 생각하게 만들기 위해서 답변 모니터링 기능을 만들자.

...등의 (지금 보면 황당한) 기능을 만들려고 하면서 코드를 짜며 키보드에 코를 박고 있었습니다.

유저와 대화한 결과: 우리의 제품은 실제로 문제를 풀고 있지 않았다

유저의 피드백을 내부에서 이리저리 추측하면서 스트레스로 머리가 너무 아팠습니다.

며칠을 고민하다... 결국 가장 간단한 방법을 선택합니다.

바로 유저들에게 직접 물어보는 것이죠. 모든 고객들과 미팅을 잡고 피드백을 들었습니다.

어떤 팀의 경우에는 직접 스탠드업 미팅을 직접 참관하기도 했어요. 마치 파견 개발자처럼 오전에 가서 스탠드업 미팅을 참관하고, 실제 미팅 내용과 Ace가 어떻게 연계되고 활용되는지도 직접 지켜봤어요. 피드백을 주셨던 분들을 찾아가 즉석에서 인터뷰를 하기도 했습니다.

직접 유저들을 만나면서 실제로 어떻게 쓰는지를 보니, 드디어 위 피드백의 맥락이 이해되었어요.

• 🥶 Ace의 질문에 대한 팀원들의 답변은 합의된 결론이 아님: 예를 들어, 어떤 태스크를 완료 처리하기 전에는 리뷰, QA 및 배포 등의 과정을 거쳐야 하는 경우가 많습니다. 그런데 스탠드업 질문에 대한 답변으로 "오늘 중 끝날것 같아"라고 했는데, 태스크를 완료 처리하려고 시도한다면 당황스럽겠죠.
  

• 👥 일은 디지털 세상 바깥에서 진행됩니다. JIRA에서 듀가 지났는데도 완료 처리가 되지 않았다고 어떤 작업자가 듀를 못 지키는 작업자가 되는 건 아닙니다. 이미 PM과 논의를 했거나 실제로 완료되었는데 업데이트가 안된 경우도 있으니까요.

그런 점에서 Ace가 지금까지 제공했던 티켓 업데이트 기능이 실제로 유저의 문제를 풀고 있다고 보기는 어려웠고 지금까지 받은 피드백이 이해가 되었어요.

PM을 보조하는 방향으로의 Micro-Pivot

이런 레슨런이 있고 나서, Ace는 세부적으로 방향성을 바꿨습니다.

• ✅ 합의된 결론을 바탕으로 태스크를 업데이트하는 데 주력하기: Ace의 대화 내용으로는 함부로 태스크를 만들거나 상태를 바꾸려고 하지 않고, 태스크를 최신화하는데 사용되는 맥락 정도로 사용하고 있습니다. 오히려 합의된 결론이 모여있는 Slack 대화 스레드나, 회의록 등으로부터 액션 아이템을 생성/업데이트하고 팔로업할 수 있는 기능을 준비하고 있어요.
  

• 🏃‍♂️ PM을 위한 행동 가능한 인사이트 제공: PM의 커뮤니케이션을 대신 하기보단, 커뮤니케이션 과정을 보조하고 인사이트를 제공하는 방향으로 바꾸고 있습니다. 예를 들어 팀원 A가 B에게 블로킹이 걸렸다고 했으니 싱크 미팅을 잡으라고 제안하는 식으러요.

전환률 등의 지표도 개선되고 좋은 피드백을 얻었던 효과도 있었지만, 제일 중요한 건 문제를 풀고 있다는 착각에서 벗어날 수 있었다는 것이였습니다.

불확실하고 불안할 때, 언제나 길잡이는 유저와의 대화다.

문제가 생겼을 때 이를 들춰보지 않으면 그 문제는 불확실함으로 가득찬 불안함일 뿐입니다. 이 불확실함을 제일 직접적으로 해소할 수 있는 방법은 제일 직접적인 이해당사자인 유저와 대화하는 것이라는 걸 느꼈어요. Talk-to-User는 실제로 많은 창업자들이 입버릇처럼 이야기하는 중요한 포인트이지만, 이를 머리로는 알면서도 정작 정말 길을 잃었을 때는 쉽사리 실천하기 어려웠다는 게 아찔한 경험이였습니다 🥹