Internal Product Canvas

배경

회사에서 다양한 사내 제품(Internal Product)을 개발하면서, 제품을 정의하는 방법에 대해 고민했습니다. 성공한 시도와 실패한 시도를 살펴보면서 사내 제품을 성공적으로 만드는 방법에 대해 다음과 같은 결론을 얻었습니다.

결론

먼저 사내 제품의 고객을 다음과 같이 나눠 정의합니다.

1. 사용자: 회사의 제품을 사용하는 유저들을 의미합니다.
2. 개발자: 회사 내에서 제품을 개발하는 개발팀을 의미합니다.
3. 회사: 전사 단위의 의사결정을 주도하는 주요 관리자를 의미합니다.

그리고 세 고객의 문제를 동시에 해결해야 합니다. 한 고객의 문제를 여러 개 해결하더라도, 다른 고객의 문제를 고려하지 않으면 제품이 제대로 작동하지 않을 수 있습니다.

MVP(Minimum Viable Product) 기획 단계에서 다음 캔버스를 사용하여, 초기 단계에 우리 팀이 놓치고 있는 고객의 문제가 없는지 확인하세요.

(예시) 아래는 당근 프론트엔드코어 팀에서 만들고 있는 Stackflow가 해결하는 문제들을 Internal Product Canvas에 그려본 결과입니다.

왜 그럴까요?

각 고객에게 의미 없는 초기 제품을 만들면 다음과 같은 문제가 발생합니다.

상황 1. 사용자의 문제를 해결하지 않는 경우

우리가 만드는 제품의 성공이 회사의 성공과 무관한 것으로 여겨져 도입을 설득하기 어렵고, 궁극적으로 고객이 제품을 도입하기까지의 우선순위를 확보하기 어렵습니다. 생산성 증가 등의 간접적인 가치를 내세울 수 있지만, 고객의 우선순위를 조정하기에는 설득력이 부족할 수 있습니다.

상황 2. 개발자의 문제를 해결하지 않는 경우

제품의 초기 도입이 원활하게 이뤄지지 않습니다. 회사 전체에 제품을 도입하기에 초기 버전은 부족한 점이 많을 것입니다. 초기 피드백을 받아 제품을 개선하는 데 필요한 중요한 정보를 얻지 못할 수 있습니다.

상황 3. 회사의 문제를 해결하지 않는 경우

초기 도입이 성공하더라도, 이후 제품이 회사 전체에 도입되는 것에 도움을 받을 수 없습니다.