[PM일기] 도메인 지식이 부족한 기획자가 회사에서 일하는 법

히츠의 ‘하이퍼랩(Hyper Lab)’은 신약개발 연구원을 위한 AI를 활용한 신약 개발 플랫폼이다.

그러기 위해서는 신약 개발에 대한 도메인 지식이 서비스 기획에 있어서는 어느 정도 필요하기 마련이다.

 

그래서 글을 쓰고 있는 나는 ‘신약 개발 또는 의약 화학’에 대한 전공을 했느냐고 물어보시면,

NO

 

라고 당당하게 말할 수 있다.  나는 의약 화학과 거리가 먼 ‘경영학과’ 출신이다.

 

이 글은 의약화학이 아니더라도, 자신이 알고 있는 도메인 영역 밖의 서비스에 도전하기 어려운 서비스 기획자에게도 이렇게 살아가고 있는 기획자도 있다는 말을 하기 위해서 작성해 본다.

---

 

그럼 도메인 기획은 누가 할까?

한 번 해보겠습니다! (출처 : mbc)

아이러니하게도 도메인 지식이 부족한 내가 한다.

 

하지만 우리는 우리만의 방식으로 기획을 한다.

지금부터 도메인 기획이 없는 기획자도, 디자이너도, 개발자들이 ‘AI 신약개발 플랫폼’을 만드는 과정을 간략하게 소개하고자 한다.

 

우리는 고객이 회사에서 함께 일한다.

히츠에는 하이퍼랩의 고객이 되는 ‘신약 개발 연구원’이 회사에서 함께 일하고 있다.

 

AI 신약 개발 플랫폼을 제공한다면, 당연히 내부에서도 하이퍼랩을 통해서 신약 개발에 필요한 후보 물질을 발굴해 보는 검증은 당연히 필요한 법이다.

 

히츠의 신약개발 본부 분들은 하이퍼랩을 통해서 실제로 AI 신약 개발에 대한 후보 물질 발굴을 진행하고 있는 분들이다.

기획자인 나는 이 분들과 함께 하이퍼랩의 방향성과 필요한 기능들을 수집한다.

 

실제 사용자가 직접 쓰는 생생한 Backlog

그렇다면 기획의 시작점이 되는 Backlog와 PRD는 어떻게 작성될까?

 

‘내부의 고객’ 신약 개발 본부에서는 하이퍼랩의 기능 고도화 및 발전에 필요하다고 생각되는 고객의 Needs와 그에 맞는 Backlog들은 실제 제약회사에서의 다른 서비스를 사용했던 경험들과 하이퍼랩을 실제 사용해 보면서 발견하는 개선 사항들을 Backlog로 작성한다.

 

“Backlog는 기획자의 문서가 아닌가요?”

 

라고 생각할 수 있다. 실제로 기획자는 Backlog를 비롯한 필요시에 그에 맞는 PRD를 작성하는 역할을 담당한다.

하지만 나는 기획의 전체 프로세스에서 시작 부분을 담당하는 Backlog와 최초 PRD 작성을 요청드렸다.

 

실제 사용되는 PRD 양식

 

내가 신약 개발과 관련된 도메인 지식이 부족한 것처럼, 신약 개발 본부 분들은 서비스 기획에서 사용되는 PRD의 용어가 생소하기 때문에 PRD를 작성함에 있어서 쉽게 사고해 볼 수 있는 자체적인 템플릿을 생성해서 요청드렸다.

 

이것이 도메인이 부족한 기획자가 고객의 니즈를 고려한 서비스 기획 프로세스의 시작점이었다.

 

좋은 Backlog들이 많이 쌓인다. (출처 : mbc)

 

PRD가 완성되면 기본적인 서비스 기획의 프로세스가 시작된다.

PRD를 통해 충분히 요구사항이 명확해졌고, 나는 해당 요구사항에 필요한 세부적인 정책과 유저 Flow, 기능 정의서, Wireframe을 작성한다.

 

도메인적인 부분이 있지만 PRD에 우리가 이해할 수 있도록 최대한 자세하게 작성해 주시기 때문에 그 뒤에 이어질 개발 및 디자인에 전달될 기획서를 작성하는 것은 훨씬 수월한 일이 되었다.

 

이렇게 하이퍼랩은 매번 개선되어 나가는 중이다.

 

어디에나 단점은 있다.

지금까지 작성된 것만 보면 굉장히 이상적인 프로세스로 운영되고 있는 듯하다.

하지만, 어디에나 그렇듯 100% 완벽한 프로세스란 존재하지 않는다. 그것은 바로,

고객을 완벽하게 대표할 수는 없다는 것.

 

아무리 내부에서 하이퍼랩을 사용을 통해 개선점을 발굴하고, 과거의 경험에 의거해서 Backlog가 작성되지만, 현재 서비스를 이용하는 실제 고객은 아니라는 점을 절대 잊어서는 안 된다.

 

실제로는 고객의 인터뷰 후기는 우리가 생각했던 것과 다른 부분도 있었고, 비슷한 부분도 있었다.

 

그리고 현재 프로세스로 내부에서 작성된 Backlog들이 반드시 고객을 100% 만족시키는 Point이자, 고객을 서비스에 오래 머물 수 있는 핵심 가치가 된다는 오만한 확신도 경계해야 한다.

 

 

그렇기에 꾸준히 기획도 고민해야 한다.

장점과 단점이 확실한 프로세스인 만큼, 기획자이자 Product의 전체적인 관점을 바라보는 것을 잊지 말아야 하는 나도 한 가지 관점에 현혹돼서 빠지지 않도록 기획적인 고민을 꾸준히 해야 한다.

스스로 기획에 대한 고민과 회고를 끊임없이 필요로 한다.

그리고 더 이상적인 프로세스, 더 효과적으로 Product를 발전시킬 수 있는 내부에서의 시너지 프로세스도 꾸준히 고민해 볼 예정이다.

---

평생 도메인을 모르고 살 수는 없는 법이다. 하지만…

지금까지 도메인이 부족한 기획자가 일하는 법이었지만, 언제까지나 도메인을 ‘아모르겠다’라는 태도로 기획해야 한다는 말은 아니었다.

 

그러나 서비스 기획자라는 직업을 가진 이상 평생 한 가지 도메인의 서비스만 기획하고 사는 것은 너무 재미없을 것 같다.

그리고 너무 특수한 도메인이라고 해서 먼저 겁먹을 필요도 없이 도전해 볼만한 충분한 가치가 있다는 것을 알려주고 싶었다.

(출처 : dreamstime)

 

혹시 모른다. 그 서비스가 나의 커리어의 최고의 걸작이 될지.