훌륭한 제품을 만드는 데 있어 비즈니스 모델의 중요성

제품 관리의 시야를 넓히세요

제품을 좁은 시각에서 바라보고 기능에만 집중하는 것은 쉽습니다. 최근 창업자 모드와 제품 관리에 대한 도전이 증가하면서, 제품 관리자 역할은 빠르게 “기능을 밀어넣는 사람”으로 축소되고 있습니다.

제품 관리는 그것 이상입니다.

저는 제품 관리가 거의 모든 것이라고 주장하고 싶습니다. (저는 제품 쪽 사람이라 편향되어 있을 수 있습니다.)

제품 관리자는 더 큰 그림을 이해하지 못하면 업무를 제대로 할 수 없습니다. 기능을 출시하는 것도 중요하지만, 이 기능들이 비즈니스의 핵심과 연결되지 않는다면 아무 의미가 없습니다.

제품 관리와 제품 관리자를 틀에 가두면 가둘수록, 그들은 단순히 프로젝트 관리자 역할만 하게 됩니다. 사용자나 고객과의 연결도 없고, 조직 전반(예: 영업, 마케팅, 고객 성공 등)에서 들어오는 피드백을 종합하여 실제로 중요한 것을 우선순위로 삼지 못하게 됩니다. 가장 영향을 미치는 지표들을 측정하지도 못하게 되죠.

제품 관리자를 고립시키는 가장 흔한 방법은 그들을 비즈니스 모델에서 멀리 두는 것입니다. 제품을 만들고 개선하지만, 실제로 중요한 것—즉, 사업이 실제로 잘 돌아가고 있는지와는 전혀 연결되지 않은 상태로 일을 하게 됩니다.

비즈니스 모델이 가장 중요합니다

회사의 모든 사람은 비즈니스 모델을 위해 일합니다. 비즈니스 모델은 모든 것을 포괄합니다. 단순히 회사가 돈을 버는 방식이 아니라, 사용자가 회사와 그 제품/서비스를 경험하는 모든 접점이 포함된 전체 연결 시스템입니다.

여러분의 업무가 비즈니스 모델에 영향을 미치지 않는다면, 중요한 일을 하고 있지 않은 것입니다. 이것이 대부분의 제품 관리자들이 겪는 문제입니다. 그들은 무언가를 하고 있지만, "그게 무슨 의미가 있나요?" 라는 질문이 남습니다.

제품 관리자는 비즈니스 모델에 가장 큰 영향을 줄 수 있는 요소들을 이해해야 합니다. 예를 들어:

• 만약 여러분의 수익 모델이 사용량 기반이라면, 제품 관리자는 사용량을 증가시키는 작업을 우선해야 합니다.
• 여러분의 수익 모델이 많은 사람들이 다른 사람들을 여러분의 솔루션으로 초대하는 데 의존한다면, 초대율(및 초대 수락율)을 극대화하는 것이 제품 관리자들의 우선순위가 되어야 합니다.

이 예시들은 단순화된 것일 수 있지만, 핵심은 변하지 않습니다. 대부분의 회사들, 특히 초기 스타트업들은 이러한 방식으로 무자비하게 우선순위를 정하지 않습니다. 중요하지 않은 일들을 주변에서 계속 진행합니다. 그것이 더 쉽거나 기분이 좋거나, 또는 다른 의미 없는 이유 때문이죠. 스타트업이 자금을 많이 조달하게 되면 상황은 더 악화됩니다. 이제 더 많은 사람을 고용하여 “더 많은 일을 할 수 있는” 상황이 되어 가치 창출을 기대하지만, 대개는 속도가 느려지고 실제 우선순위가 희미해져서 결국 스타트업이 정체 상태에 빠지게 됩니다.

다음은 간단한 부분 유료화 비즈니스에 대한 개략적인 비즈니스 모델입니다:

여러분이 어느 단계에 있느냐에 따라 초점을 맞출 수 있는 영역이 여러 가지 있습니다. 예를 들면:

• 방문자 수 증가 (“일단 누군가 방문해야 합니다!”)
• 프리미엄 가입 (“누군가 등록만 하면 됩니다!”)
• 유료 가입 (“사람들이 지금 당장 결제해야 합니다!”)
• 사용자 활성화 / 참여 사용자 (“사용자가 충분히 제품을 사용하여 전환해야 합니다!”)
• 유료 전환 (“활성 사용자가 유료로 전환되지 않으면 우리는 망합니다!”)
• 이탈 고객 (“큰일이네요, 너무 많은 고객을 잃어 지속 가능한 비즈니스 모델이 될 수 없습니다!”)

이 모든 것들이 자체로도 방대한 작업입니다. 초기에 모든 것을 동시에 집중할 수는 없습니다. 비즈니스에 가장 긍정적인 영향을 줄 수 있는 것을 가장 짧은 시간 내에 찾아내야 합니다.

제품 관리자가 반드시 매출을 올려야 할 책임이 있는 것은 아니지만, 비즈니스 모델에 대해서는 책임이 있습니다. 이는 모든 구성원이 그렇습니다.

중요한 일을 하세요

사람들은 새로운 기능을 출시할 때 마치 자금을 조달했을 때처럼 축하합니다. 공개적으로 발표하고, 서로 축하하고, 서로 등을 두드려줍니다. 큰 승리를 이룬 것처럼 느껴지죠. 이해합니다—기능을 만드는 것은 어려운 일입니다. 자금을 조달하는 것도 어렵고요.

하지만 그 기능들이 비즈니스 모델에 긍정적인 영향을 미치지 않는다면, 무슨 의미가 있을까요?

예를 들어, 영업 및 마케팅 팀이 퍼널의 최상단에서 더 많은 돈을 쓰고 싶어하지만 이탈율이 너무 높은 상황이라고 가정해봅시다. 버킷에 구멍이 난 것입니다. 이를 모두가 알지만 다들 마지못해 동의하는 상태입니다. 이 경우 모든 것이 이탈율 감소에 집중되어야 합니다. 제품 관리자들은 이를 위해 가능한 모든 방법을 찾아야 합니다: 기능 추가/제거/변경; 새로운 가치 제안 테스트; 새로운 고객 세그먼트 타겟팅; 고객에게 전화해서 머물도록 설득하기 등. 어떤 방법이든 사용해야 합니다. 왜냐하면 (이 예에서) 이탈율을 낮추지 못하면 끝이니까요. ☠️

모든 기능에는 비용이 따릅니다. 투입된 시간과 돈뿐만 아니라 유지 관리, 업데이트, 사용자/고객 교육, 불만 처리(“왜 제가 좋아했던 기능을 변경했나요?”) 등의 지속적인 비용이 발생합니다. 하지만 그 비용을 고려하는 사람은 없습니다. 대신에 더 많은 것을 빨리 만들려고만 합니다. 무언가를 만드는 것은 즐겁고—제품 관리자, 디자이너, 개발자는 그것을 좋아하므로—문제를 해결하기 위한 기본적인 답으로 빠르게 자리잡습니다.

종종 어떤 창업자가 “우리 경쟁사가 한동안 제품을 업데이트하지 않았어. 아마 문제가 있는 게 분명해. 우리 제품이 곧 더 좋아질 거야.”라고 말하는 것을 듣습니다.

경쟁사가 문제를 겪고 있을 가능성은 있습니다. 혹은 아닐 수도 있습니다. 그들은 새로운 기능을 잔뜩 추가하는 것이 현재 단계에서 비즈니스 모델을 긍정적으로 이끌어가는 최선의 방법이 아님을 깨달았을 수도 있습니다. 그들의 초점은 다른 곳에 맞춰져 있을 수도 있고, 아닐 수도 있습니다. 솔직히 경쟁사가 무엇을 하고 있는지 추적하는 것은 항상 어려운 일이며, 그들이 내리는 결정에 대해 우리는 알 수 없습니다. 다른 사람이 무엇을 하고 있는지에 신경 쓰기보다는, 여러분의 비즈니스에 실질적인 변화를 줄 수 있는 것에 집중해야 합니다.

비즈니스 모델에 미치는 영향 측정

여러분이 스타트업에서 하는 모든 일은 비즈니스 모델을 개선하려는 시도여야 합니다. 항상 성공할 수는 없으므로, 빠른 실험 속도가 중요합니다.

제품 변경이 비즈니스 모델에 미치는 영향을 측정하는 것은 어렵습니다. 새로운 기능을 추가하고 고객의 계약 체결율이나 무료에서 유료로의 전환율에 직접적인 결과를 측정할 수 있는 경우는 드뭅니다. 대신 사용량을 측정합니다. 새로운 기능이 예상 사용량에 비해 얼마나 자주 사용되었는지 측정하는 것이죠. 사용량은 측정하기 가장 쉬운 것이며, 가치 창출의 대리 지표입니다. 기능이 사용되고 있다면, 가치를 창출하고 있을 가능성이 큽니다. 정성적 데이터도 수집합니다. 제품 관리자들에게는 일반적인 모범 사례이죠. 하지만 이게 무슨 의미가 있나요? 새로운 기능을 출시했는데 사람들이 미친 듯이 사용하고 있다고 합시다. 그럼 성공한 걸까요? 아마도요. 🤔

결국, 비즈니스 모델에 영향을 미쳤다면 비로소 성공한 것입니다. 비즈니스 모델은 일반적으로 “고차원”의 메트릭으로 나타납니다; 예를 들어 매출, 전환율, 이탈율 등. 이는 사용량 기반 메트릭일 수도 있습니다; 예를 들어 DAU, WAU, MAU (혹은 DAU/MAU) 등, 여러분이 만든 변화가 전체 제품 사용에 실질적인 영향을 미치고 있다는 것을 나타내는 것입니다.

이것이 The One Metric That Matters (OMTM) 개념이 도움이 되는 이유입니다. OMTM은 특정 시점에서 집중해야 할 단 하나의 메트릭이 있다는 것을 제안합니다. 모든 노력은 그 메트릭을 개선하는 데 집중되어야 합니다. 해당 메트릭에서 목표를 달성하면 다음 메트릭으로 이동하는 것이죠.

The One Metric That Matters의 목표는 두 가지입니다:

• 스타트업이 무자비하게 우선순위를 정할 수 있도록 돕기 위해 (대부분의 스타트업은 이걸 잘 못한다고 생각합니다)
• 비즈니스 성공에 실제로 중요한 작업(제품 또는 그 외의 것)의 효율성을 측정할 수 있도록 돕기 위해

제품/기능/실험 수준에서 사용량 지표를 추적하지만, 그것이 궁극적인 목표는 아닙니다. 궁극적인 목표는 비즈니스 모델에 변화를 주는 것입니다.

다음은 OMTM에 대한 추가 자료들입니다:

• What is One Metric That Matters and how to find your OMTM?
• Lean Analytics - The One Metric That Matters And Other Provocations

Product Managers Solve Problems

제품 관리자는 기본적으로 문제 해결사입니다. 그게 직무 설명입니다: 문제를 해결하세요. 애매한 상황 속에서, 촉박한 기한 내에 해결하세요. 시작!

제품 관리자가 비즈니스 모델 및 비즈니스 운영 방식과 밀접하게 연결되어 있으면 문제와 잠재적인 해결책을 다르게 볼 수 있습니다. 모든 문제에 대한 해답은 "더 많은 기능을 구축하는 것"이 아닙니다. 사실 그것이 정답인 경우는 거의 없습니다. 하지만 제품 관리를 핵심 비즈니스와 관련이 없는 기능 구축/개선에만 몰두한다면 실패할 것입니다.

제품 관리자: "왜?"라고 물어보세요. 많이요. 기능을 추가하거나 변경하라는 요청을 받는 이유의 핵심을 파악해야 합니다(또는 그 문제에 대해 어떤 조치를 취해야 하는지). 물론, 끊임없이 질문을 받는다는 것은 짜증나는 일입니다(저도 양쪽 모두 겪어봤으니까요). 전투를 선택하세요. 하지만 진실을 찾기 위한 끊임없는 호기심과 사명을 포기해서는 안 됩니다. 그런 일이 발생하면 더 이상 제품 관리자가 아니라 일을 완수하기 위해 파이프를 통해 일을 추진하는 프로젝트 관리자가 됩니다.

창업자: "왜?"라고 묻는 제품 관리자를 고용하세요. 모호한 상황에 익숙하고(깊이 파고들기 전까지는 테스트하기 어렵습니다) 호기심이 많은 제품 관리자를 고용하세요. 비즈니스의 작은 부분뿐만 아니라 비즈니스 전체를 이해하고자 하는 제품 관리자를 고용하세요. 문제 해결사를 고용한 다음 그들이 문제를 해결하도록 하세요. 반드시 참여하고 주도하되, 제품 관리자를 자동화로 만들지 마세요.