brunch

You can make anything
by writing

C.S.Lewis

by June Sep 02. 2021

Product Spec 문서와 PRD

무엇을 만들어 볼까요?

제품 및 서비스를 만들기 위해서는 가장 먼저 어떤 제품인지, 어떤 서비스인지를 정의 내리는 것이 필요하다. 이렇게 제품 및 서비스를 정의하는 문서는 제품 사양 문서(Product Sepectification, 이하 'Product Spec')와 제품 요구사항 정의서(Product Requirement Document, 이하 'PRD') 2가지가 있다.

이번 글은 제품과 서비스를 정의하는 2가지 문서, Product Spec과 PRD에 대해 작성해보았다. 글의 순서는 아래와 같다.

1. 제품 사양 문서(Product Specification)
2. 제품 요구사항 정의서(Product Requirement Document)
3. Product Spec 및 PRD 작성하기

제품 사양 문서(Product Specification)

Product Spec 문서는 제품을 정의하는 가장 기본적인 문서다. 하나의 제품에는 여러 이해관계자 존재한다. 제품을 만들어야 하는 개발자나 디자이너뿐만 아니라, 제품을 사람들에게 알리고 구매할 수 있도록 유도하는 마케터도 보아야 하고, 제품이 얼마나 수익을 창출할지, 어떤 전략을 수립해야 할지를 고민하는 비즈니스 담당자가 볼 수도 있다.

그래서 Product Spec 문서는 여러 이해 관계자들에게 우리가 만들고자 하는 제품의 목표와 타겟 유저, 제품에 대한 세부 내용을 알려줄 수 있어야 하고, 이를 토대로 조직이 제품에 대한 청사진을 파악할 수 있도록 도와줄 수 있어야 하는 문서다.

여러 이해관계자가 보고 이해할 수 있어야 한다는 의미는 모두가 이해할 수 있는 용어를 사용해야 하고, 모두가 이해할 수 있도록 내용을 구성해야 한다는 것이다. 그렇다 보니 Product Spec 문서를 작성할 때는 지나치게 기술적인 내용을 담지 않아야 한다. 또한 최대한 간결하고, 명료하게 작성해야 한다.

Product Spec 문서는 초기 제품 또는 새로운 제품을 기획하는 단계에서 작성하게 된다. 이를 통해서 제품 개발 및 개발 및 디자인에 대한 일종의 지침 역할을 하기도 한다. 그리고 이렇게 작성한 Product Spec 문서는 제품 개발 간 발생할 수 있는 다양한 이슈들을 처리할 수 있는 근거가 되어 여러 불필요한 장애들을 사전에 미리 제거할 수 있도록 도와준다.

제품 요구사항 정의서(Product Requirement Document)

제품 요구 사항 정의서는 앞서 Product Spec 문서와 유사하다. 제품의 기능을 기획하는 단계에서 작성하는 문서다. 앞서 Product Spec 문서에서 요구사항에 해당하는 부분을 조금 더 구체화시킨 문서라고 보는 것이 좋다. 주로 "어떻게 제품 및 서비스를 만들 것"인가 보다는 "왜 제품 및 서비스를 만들어야 하는지"에 중점이 맞추어져 있다.

PRD는 기획 문서이지만 또한 제품 및 서비스를 올바르게 만들기 위한 가이드를 제공하는 문서다. 이 뿐만 아니라 팀이 제품을 만드는 과정을 효율적이고 효과적으로 수행할 수 있도록 돕고 나아가 사용자에게 긍정적으로 좋은 가치를 전달하기 위해 고민하는 과정이기도 하다.

그래서 작성된 PRD를 토대로 팀 리뷰를 진행하고, 이 과정에서 의견을 전달하고, 피드백을 받아 아이디어를 보완한다. 보완된 문서를 토대로 최종 리뷰 과정을 거침으로써 새로 진행할 제품의 방향에 대해 팀원 간 이해와 합의를 일궈낸다.

Product Spec 및 PRD 작성하기

Product Spec과 PRD는 전반적으로 유사하다. 차이점이라면 Product Spec은 제품이라는 큰 범위에 초점이 맞춰져 있고, PRD는 제품에 대한 세부적인 기능에 초점에 맞추어져 있다고 보면 좋다. 그래서 Product Spec은 "어떤 제품을 왜 만드는 것인가"라는 질문에 답을 하는 문서라면, PRD는 "어떤 기능을 왜 만들 것인가"에 질문에 답을 하게 된다. 하지만 두 가지 문서를 엄격하게 구분하지는 않고, 내용 또한 비슷하기 때문에 혼용해서 사용하기도 한다.

그리고 대부분의 경우 PRD를 많이 작성하게 되는데 이는 제품 자체를 새로 정의 내리는 경우는 많지 않기 때문이다. 그래서 Product Spec은 생소할 수 있다. 반면 같은 제품에도 새로운 기능이 추가되거나, 개선을 이루어내거나 하는 경우들은 많다. 이런 경우에는 PRD를 작성하게 된다.

Product Spec 및 PRD를 작성하기에 앞서 몇 가지 제품 및 기능에 대한 공통적인 주요 질문을 상정해보자. 우리의 문서는 이 공통적인 주요 질문에 답을 해줄 수 있어야 한다. 주요 질문이라 함은 대체로 아래와 같다.

1. 우리가 만들고자 하는 것은 무엇인가?
2. 왜 이 제품을 만들어야 하는가?
3. 제품 개발을 통해 달성하고자 하는 목표는 무엇인가?
4. 목표 달성을 위한 검증 지표는 무엇인가?

Product Spec 및 PRD 구성요소

1. 개요
  가. 문제 정의
  나. 목적 및 배경(왜 이 제품이 필요한가요?)
  다. 주요 사용자(Tarket User)
  라. User Story / User JourneyMap(고객은 어떠한 행동을 보여줄까요?)
  마. 사용자 가치(고객을 위해 어떤 일을 하는 걸까요?)
  바. 개발 원칙

2. 기회 및 임팩트
  가. 기회
  나. 가설
  다. 가설 검증 지표
  라. 임팩트 예측

3. 제품 정의 및 요구사항

4. 마일스톤

5. FAQ

개요

먼저 개요는 제품을 개발해야 하는 근거를 제시하기 위해 작성한다. 우리가 만들 제품이 어떤 문제를 해결하기 위한 것인지, 우리의 제품이 나오게 된 배경은 무엇인지, 문제를 가지고 있는 사용자는 누구인지, 그러한 사용자가 우리의 제품을 어떻게 사용할 수 있을 것이지, 우리의 제품을 사용하면서 사용자가 가지게 될 가치는 무엇인지, 제품을 만드는 과정에서 원칙은 무엇인지를 기재한다.

문제 정의

가장 먼저 어떤 문제를 해결하기 위한 것인지, 그 문제를 정의해야 한다. 문제를 정의하는 과정은 Product Spec 문서를 작성하는 데 있어서 가장 중요한 부분이라고 볼 수 있다. 결국 우리가 만들어갈 제품의 근본적인 존재 이유가 되는 부분이기 때문이다.

문제는 어렵게 적기보다는 이해관계자 모두가 공감할 수 있도록 적는 것이 좋다. 또한 뒤에 이어서 작성하게 될 목적 및 배경, 주요 사용자와 이어지는 내용이어야 한다. 결국 문제는 우리의 제품을 사용하게 될 사용자의 니즈를 말하는 것이고, 그 사용자의 니즈를 해결하는 것이 제품을 만드는 목적 및 배경이기 때문이다. 만약 3가지가 서로 다른 방향을 가리키는 모습으로 작성된다면, 제품을 만들어야 하는 설득력이 매우 떨어지게 될 것이다.

1. 비상장 기업의 경우 투자 대상 기업이 어떤 기업인지를 전혀 파악할 수 없는 어려움이 존재합니다.
2. 투자 대상 기업의 과거 투자 이력을 파악하는데 어려움이 존재합니다.
3. 투자 제안을 하는 AC/VC가 어떤 곳인지를 파악할 수 없어 투자 제안을 수락할 때 고민이 됩니다.
4. 투자자가 우리 회사에 적절한 도움을 줄 수 있는지 파악하기 어렵습니다.

목적 및 배경(왜 이 제품이 필요한가요?)

문제를 정의했다면 이제 제품을 기획하게 된 목적 및 배경을 제시한다. 여기서는 문제가 발생하는 사회적인 배경을 기재하여도 되고, 우리 제품의 기획 목적 및 배경을 설명해도 괜찮다. 해당 부분은 우리가 만들고자 하는 제품이 왜 만들어져야 하는지를 설득하는 영역이기 때문이다.

1. 투자자와 피투자자가 서로 신뢰할 수 있도록 중간에 정보를 교류할 수 있어야 합니다.
2. 정보 교류를 통해 상호 투자 가치에 대해서 판단할 수 있도록 도와줄 수 있어야 합니다.
3. 투자자는 피투자자에 대한 충분한 정보를 토대로 투자 결정을 진행할 수 있어야 합니다.
4. 피투자자는 투자자에 대한 충분한 정보를 토대로 기업에 도움이 될 수 있는 투자 결정을 내릴 수 있어야 합니다.

주요 사용자(Target User)

이제 이 문제를 겪고 있는 대상이 누구인지를 기재해보자. 앞서 기재한 문제를 겪고 있는 대상이 바로 주요 사용자가 될 것이다. 주요 사용자를 작성할 때는 단순하게 사용자의 형태만 표현하기보다는 어떤 어려움을 겪고 있는 사용자인지를 함께 표현해주는 것이 좋다.

아래 예시처럼 ‘새로운 투자 대상을 찾고 있는’ AC/VC와 같이 구체적으로 어떤 어려움을 겪고 있는지를 같이 적어주는 것이 머릿속에서 상황을 그려보기 용이하기 때문이다. 그리고 이를 통해서 기획안을 읽는 대상자가 주요 사용자와 사용자가 겪고 있는 문제에 공감을 하기 수월해진다.

1. AC/VC
  가. 새로운 투자 대상을 찾고 있는 AC/VC
  나. 투자를 집행하기 전, 투자심사보고서를 작성하기 위해 기업에 대한 정보를 수집해야 하는 투자 심사역
2. 스타트업 대표
  가. 자금이 필요하여 제안서를 보낼 적합한 투자자를 찾고 있는 스타트업 대표
  나. 투자 제안을 받았으나, 해당 투자자에 대한 정보가 불명확하여 제안 수락을 망설이고 있는 스타트업 대표

User Story / User JourneyMap

User Story는 주요 사용자가 문제를 해결하기 위해 행동하는 상황을 묘사한다. 문제를 겪던 시점부터, 우리의 제품을 인식하게 되거나, 우리의 제품을 어떠한 방법으로 사용함으로써 문제를 해결하게 되는지 일련의 스토리를 그려보는 것이다.

User Story와 User JourneyMap의 모습은 조금 다를 수 있다. User Story는 어떤 상황에 놓인 유저가 무엇을, 왜 원하는지를 기재한다. 간단하게 표현하자면 ‘As Who, I Want What, so that’이 된다. 가령 ‘As a Product Manager, I Want Write a Product Spec, so that I can make the product’의 형태로 기재하는 것이다. 이를 통해서 Story마다 무엇을 만들어야 할지 생각해볼 수 있다.

1. 투자 심사역
  가. 투자 심사역은 정보 습득 및 리서치를 통해 새로운 투자처를 발굴하고 싶습니다.
  나. 발굴한 잠재적 투자 대상 기업의 세부적인 정보를 습득을 통해 투자 적합성을 검토하고 싶습니다.
  다. 투자 적합 기업에 관한 제반 사항을 확인하여 투자 진행을 위한 투자심사보고서를 작성을 진행합니다.
2. 스타트업 대표
  가. 스타트업 대표는 자금 조달의 필요성을 느껴 투자를 받을 수 있는 투자사를 발굴하고 싶습니다.
  나. 발굴한 투자사가 우리 기업에 투자를 진행하기 적절한지 세부적인 정보를 파악하고 싶습니다.
  다. 투자자의 세부 정보를 토대로 콜드 메일/콜드 콜을 보내기 위해 사업계획서를 작성하고 싶습니다.

User JourneyMap은 User Story를 시간 순서, 타임라인으로 나열한 것으로 생각하면 된다. User JourneyMap은 사용자가 문제를 해결하는 과정을 몇 가지 단계로 구분하여 작성하게 된다. 가령 사용자는 문제가 존재함을 인식하게 된다. 그리고 그 문제를 해결하기 위한 탐색과정을 진행한다. 탐색 과정에서 발견된 여러 제품을 비교해보기도 하고 사용해보기도 한다. 이후 사용자의 문제를 성공적으로 해결하게 되었다면 사용자는 구매를 하게 된다. 여기서 각 단계를 정리해보면 ‘인식 – 탐색 – 비교 – 사용 – 구매’가 될 것이다.

이제 각 단계별로 사용자가 취하게 될 행동과 단계별로 달성하고 싶은 목표, 해당 단계에서 사용자가 느끼게 될 감정, 해당 단계에서 우리의 제품과 맞닿게 될 지점 등을 명시한다. User JourneyMap은 글로 쓰기보다는 Tool을 활용하거나 포스트잇 등을 활용하여 작성하는 것이 좋다. 최근에는 User JonrneyMap을 단순히 기획안의 보충자료로 사용하기보다는 User JourneyMap을 토대로 백로그를 선정하거나, 추후 개발 요건을 선정하는 방법으로 활용하기도 한다.

User JouneyMap 예시, “UXPRESSIA Mobile app Uuser journey 탬플릿” https://uxpressia.com/

사용자 가치(고객을 위해 어떤 일을 하는 걸까요?)

사용자 가치는 사용자가 우리의 제품을 통해서 문제를 해결할 수 있는지, 우리의 제품으로 무엇을 할 수 있을지, 우리의 제품을 통해서 어떤 가치를 느낄 수 있는지를 명시한다. 여기서 사용자 가치는 앞서 명시한 문제, 목적 및 배경과 관련이 있는 것이어야 한다.

설령 우리의 제품이 사용자에게 전혀 새로운 가치를 제공할 수 있더라도 가급적이면 처음에 의도했던 부분을 만족시킬 수 있는 방안으로 적는 것이 좋다. 앞서 여러 번 설명했듯 기획안은 논리적이어야 하고, 명확해야 한다. 이것도 할 수 있고, 저것도 할 수 있다는 식의 기획안은 논리적이지 못하고, 설득력을 떨어뜨릴 수 있다. 만약 우리가 의도하거나, 사용자가 원했던 것이 아니지만 정말 괜찮은 새로운 가치를 기획안에 포함시키고 싶다며 확장성의 측면으로 분리하여 부가적인 목표, 또는 지표와 함께 표현하자.

1. 투자 진행을 위해 필요한 정보를 쉽고 빠르게 제공함으로써 투자 심사역의 업무 효율성을 향상합니다.
2. 투자자의 선호에 부합하는 사업계획서 또는 제안서를 작성함으로써 스타트업 대표의 업무 부담을 경감하고, 투자 가능성을 증대할 수 있습니다.
3. 투자자와 피투자자의 활발한 교류를 통해 건전한 투자 생태계 구축에 기여할 수 있습니다.

개발 원칙

사용자 가치까지 작성이 완료되었다면 다음은 개발 원칙을 작성해야 한다. 개발 원칙은 의사결정이나 개발 가이드가 될 수 있는 원칙을 제시하는 것을 의미한다. 이는 만약 PM이나 기획자가 부재하는 상황에서 개발의 우선순위를 개발자가 스스로 선택할 수 있도록 하기 위함이다.
또한 제품 개발 과정에서 의사 결정이 원활하게 이루어지지 못하는 상황에 진입하게 되었을 때 개발 원칙을 토대로 가장 핵심적으로 구현해야 하는 기능에 리소스를 투입할 수 있도록 유도할 수 있다.

개발 원칙은 제일 중요할수록 상단 또는 1번에 배치하고 중요도에 따라 내림차순으로 기재하는 것이 좋다.

1. 투자자와 피투자자 간 정보 교류를 위한 핵심 기능 구현을 최우선으로 진행합니다.
2. 피투자자(기업) 정보를 제공할 수 있어야 합니다. 초기 기업 정보 DB를 구축하는 과정은 운영 업무를 통해서 수기로 진행할 수 있습니다.
3. 투자사 정보를 제공할 수 있어야 합니다. 초기 투자사 정보 DB를 구축하는 과정은 운영 업무를 통해서 수기로 진행할 수 있습니다.
4. 추후 기업 정보를 자동으로 수집할 수 있는 시스템을 구축할 수 있어야 합니다.

기회 및 임팩트

기회 및 임팩트는 현재 시장에 어떤 기회가 있는지, 어떤 제품이 트렌드가 되고 있는지, 주요 통계자료나 데이터는 어떠한 지와 같은 것들을 토대로 작성한다. 여기서 우리 제품을 통해 사용자가 어떤 행동을 하게 될지를 기재하고, 그 행동을 통해서 어떤 임팩트가 세상에 나올 수 있을지를 표현하게 된다.

기회

기회는 우리가 만들 제품의 제반 환경을 의미한다. 시장 환경이 될 수도 있고, 사회적 분위기가 될 수 있고, 기술의 발전이나 정부의 정책이 기회가 될 수도 있다. 보통 많이 쓰이는 방식으로 시장 환경 분석의 일환인 SWOT 분석이나 STP와 같은 방식으로 기재하기도 하나, 최근의 트렌드나 정부 정책, 사회적인 분위기 등을 간단하게 기재할 수도 있다.

1. 사회적 관심도 증대
  가. 20 – 30 세대의 주식 시장 관심도가 증가하고 있습니다.
  나. VC 생태계가 활성화되고, 스타트업에 대한 사회적 관심이 높아짐에 따라 비상장 기업에 대한 정보 수요가 증가하고 있습니다.
2. 통계 데이터
  가. 증권사에서 분석한 2011년도 2030 연령층 주식 계좌 보유 비율
  나. 증권사에서 분석한 2021년도 2030 연령층 주식 계좌 보유 비율

가설 및 가설 검증 지표

고객이 겪을 문제를 기반으로 이를 해결할 수 있는 제품을 만든다고 해도 무조건 성공할 수 있는 것은 아니다. 우리의 제품이 사용자에게 적합한 해결책이 아닐 수도 있고, 때로는 우리가 선정한 문제가 정말 고객의 문제가 아닐 수도 있다. 이 뿐만 아니라 우리의 제품으로 수익을 창출하기 위해서 어떠한 방법으로 기능을 구성해야 할지, 제품에 어떤 매력적인 요인들을 더할 수 있을지를 끊임없이 고민해야 한다. 이를 위해 우리는 가설을 수립하고, 이를 검증하는 과정을 거쳐야 한다.

여기서 중요한 부분은 시장에서 우리의 제품이 고객의 문제를 명확하게 해결할 수 있는 것인지, 우리의 제품으로 수익을 창출할 수 있을 것인지는 제품을 출시하고 고객이 직접 사용해보기 전까지는 검증하기 어려운 부분이기 때문에 이렇게 가설을 수립함으로써 빠르게 검증하고, 해결방안을 모색하기 위한 과정이라는 부분을 명심해야 한다.

만약 우리의 가설이 검증 지표의 통과 기준에 적합하지 못해서 실패한 가설이라는 판단이 들면 재빠르게 다음 행동을 정해야 한다. 사용자가 겪고 있는 문제가 무엇이었는지 명확하게 다시 검증을 진행한다거나 제품의 디자인이나 기능을 개선 및 보완할 수도 있고, 어쩌면 제품이나 기능의 피봇(다른 사업모델로 전환하는 과정)을 진행하는 결정이 필요할 수도 있다.

1. 가설
  가. 스타트업에 대한 정보를 파악하기 위해 가입하는 투자자가 존재할 것이다.
  나. 투자자에 대한 정보를 파악하기 위해 가입하는 스타트업 관계자가 존재할 것이다.
  다. 투자자와 피투자자의 성향을 고려하여 매칭 해주면, 투자에 성공하는 횟수가 증가할 것이다.
  라. 투자 적합도를 분석하여 제공한다면, 투자자가 투자를 검토하고 미팅을 진행하는 횟수가 증가할 것이다.
2. 가설 검증 지표
  가. 투자자로 가입하는 계정의 수가 000건 이상인 경우, 가설 검증에 성공한 것으로 판단합니다.
  나. 스타트업 관계자로 가입하는 계정의 수가 000건 이상인 경우, 가설 검증에 성공한 것으로 판단합니다.
  다. 1개월 간 플랫폼을 통해 투자에 성공하는 횟수가 n건 이상인 경우, 가설 검증에 성공한 것으로 판단합니다.
  라. 1개월 간 플랫폼을 통해 투자자와 피투자자가 미팅 진행 후 IR 자료를 전송하는 횟수가 n건 이상인 경우, 가설 검증에 성공한 것으로 판단합니다.

임팩트 예측

임팩트 예측은 우리의 제품이 가져올 경제적, 사회적 가치를 의미한다. 또는 사용자가 우리의 제품을 통해서 얻게 될 가치를 의미하기도 한다. 특히 전자의 경우는 Product Spec, 즉 제품 자체를 정의하는 과정에서 기재하는 경우가 많고, PRD 문서에서는 작성하지 않는다. 후자의 경우는 PRD 문서에서 특히 많이 작성하게 되는데, 이는 사용자가 얻게 될 임팩트의 크기에 따라 우리 제품의 주요 지표가 올라가거나 떨어지기 때문이다.

경제적, 사회적 가치를 작성하는 경우, 둘을 구분해서 작성하는 것이 좋고 명확하게 수치로 제공하는 것이 효과적이다. 두 개를 모두 적을 필요는 없으나, 최근에는 사회적 가치나 ESG에 대한 관심이 높아지고 있으며 가치 소비의 형태로 제품을 구매하는 경우가 많아지고 있어 어떤 제품을 만들 때 사회적 가치를 고려하는 것이 좋다.

1. 찾기 어려운 비상장 기업에 대한 정보를 제공함으로써 투자사의 정보탐색 리소스를 00% 감소시킵니다.
2. 투자자에 대한 정보를 제공함으로써 투자 사기 방지를 00% 증대합니다.
3. 투자자와 피투자자 간 정보 교류 횟수를 00% 증대합니다.
4. 국내 투자 생태계를 활성화시킴으로써 투자 진행 횟수를 00% 증대합니다.

제품 정의 및 요구사항

제품 정의 및 요구사항은 제품의 구체적인 형태를 제시하고, 제품을 구성하기 위한 기능 및 기술 요건을 기재한다. 이를 토대로 개발 및 디자인팀과 논의를 통해 구현 가능한 요인들을 산출하며, 비즈니스팀과는 제품이 나아가야 할 방향 및 전략을 도출할 수 있다. 또한 이 과정에서 더 나은 제품이 나올 수도 있고, 더 나은 기술 방안이 제시될 수 있다.

1. 제품 정의 : 투자자와 피투자자가 게시판, 채팅 등을 통해 정보를 교류할 수 있는 플랫폼 구축
2. 요구사항
  가. 투자자 및 스타트업 관계자로 구분하여 회원가입 및 로그인을 진행할 수 있어야 합니다.
  나. 투자자 및 스타트업 관계자를 인증할 수 있어야 합니다.
  다. 게시판 기능을 사용할 수 있어야 합니다.
  라. 투자자와 스타트업 관계자가 채팅 기능을 통해 교류할 수 있어야 합니다.
  마. 투자자와 스타트업 관계자가 서로 파일을 주고받을 수 있어야 합니다.

마일스톤

마일스톤은 제품을 만들어가기 위한 일정을 제시한다. 글로 제시하는 경우도 있지만, 일반적으로는 타임라인으로 볼 수 있도록 간트차트와 같은 것을 토대로 구성한다.

1. 회원가입 기능 구현
  가. 일정 : 2021. 9. 7. ~ 12.
     1) 기술 검토 : 9. 7. ~ 8.
     2) 요구사항 분석 / 정의 : 9. 8. ~ 9.
     3) 와이어프레임 : 9. 9. ~ 10.
     4) 개발 착수 : 9. 10. ~ 12.
나. 담당자
    1) 기획 : 기획자 A
    2) 디자인 : 디자이너 B
    3) 개발 : 프론트엔드 개발자 C / 백엔드 개발자 D

FAQ

FAQ는 Product Spec 문서를 토대로는 파악하기 어려운 사항이나 각 팀에서 제품에 대해 궁금하게 생각할 수 있는 부분을 사전에 미리 고민해서 작성하는 부분이다.

1. 채팅을 요청하거나 수락하는 주체가 누구인가요?
-> 채팅 제안 및 수락은 투자자, 피투자자 모두가 가능해야 합니다.
2. 예상 질문 : 회원가입 시 투자자, 스타트업 관계자 인증은 어떻게 진행해야 하나요?
-> 사업자 등록증 또는 재직증명서를 이메일로 제출받아 인증을 진행합니다.

결론

하나의 제품 또는 서비스를 만들 때는 여러 전문가의 손길이 필요하다. 어떤 기능을 만들 지에 대한 고민이 필요하고, 기능을 고객에게 잘 전달할 수 있도록 디자인이 필요하다. 그리고 기능과 디자인을 구현할 수 있도록 개발하는 과정이 필요하다. 그렇게 개발된 제품이 정상 동작하는지, 기획에서 의도된 가치 전달이 잘 이루어지는 지를 확인하는 QA도 필요하다.

이 과정을 빠트리지 않고 의사 전달이 명확하게 될 수 있도록 그래서 제품을 만들어가는 과정이 원활하게 이루어질 수 있도록 우리는 문서를 만들고 이를 토대로 업무를 진행한다. 서비스 기획자는 각 전문가들이 주어진 업무를 파악하고, 기획의 의도에 맞추어 자신들의 역량을 마음껏 발휘할 수 있도록 문서를 만들어낼 수 있어야 한다.

Product Spec 및 PRD는 반드시 완전히 완성된 상태로 리뷰를 진행하지 않아도 괜찮다. 즉 앞서 제시한 모든 부분을 작성해야만 다음 단계로 넘어갈 수 있는 것이 아니다. 기본적인 논의의 토대를 마련하고, 이를 팀원들과 리뷰하면서 부족한 부분을 보완하고 새로운 아이디어를 도출하기 위해 작성하는 것이다. Product Spec 및 PRD를 작성했다면 이제 제품을 실제로 구현하기 위한 세부 기획으로 진입하면 된다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari