PO
요즘 자꾸 혼란스러워요. “기능을 만들어도 성과가 없다”는 얘기를 자주 듣다 보니, 기능은 그냥 ‘쓸모없는 output’인가 싶기도 하고요.
구루
현장에선 그런 얘기를 정말 자주 듣지. 하지만 그건 output과 outcome의 관계를 오해해서 그래. 이 둘은 경쟁 관계가 아니라, 연결된 관계야.
PO
연결된 관계요?
구루
Output은 outcome을 위한 수단이고, Outcome은 output이 가야 할 방향이에요. 다시 말해, output은 outcome을 얻기 위한 실험 도구지.
PO
그럼 outcome을 먼저 정하고 output을 설계해야 하나요?
구루
정확해요. PO는 항상 이런 흐름으로 사고해야 돼. 우리가 바라는 변화(Outcome)는 무엇인가?그 변화를 만들 수 있을 거란 가설은 어떤 것인가?그 가설을 검증할 output은 무엇인가?
PO
그럼 output 하나에도 outcome 중심의 논리적 출발점이 있어야 한다는 거네요?
구루
맞아. 예를 들어 이렇게 정리할 수 있어.
Outcome: 가입자 전환율 20% 상승
가설: “온보딩 시 추천인을 입력하면, 유저의 진입 동기가 강해져 전환율이 오른다.”
Output: 추천인 입력 UI 추가 + 리워드 제공
이런 구조가 없다면, output은 ‘그냥 기능’일 뿐이고, 검증 불가능한 채로 사라지는 경우가 많아.
PO
근데 outcome이 바로 안 나오면요?
기능을 릴리즈했는데도 전환율이 안 오르면, 팀 분위기도 다운되고...
구루
그건 아주 중요한 현실적 이슈야. PO는 반드시 Output → Outcome 사이에 존재하는 시간차를 고려해야 하지. 성과는 대부분 즉시 발생하지 않거든.
PO
그 시간차는 어떻게 다뤄야 할까요?
구루
시간차가 있는 제품을 다룰 때 PO가 할 일은 크게 세 가지야.
관측 기간을 명확히 정의한다. 예를 들어, 가입 전환율은 일주일 단위로 봐야 의미가 생기고, 구매전환은 한 달, 리텐션은 최소 2~3주 이상 데이터가 필요하지.
지표의 의미 있는 변화치를 정의한다. “1% 오르면 성공”인지 “10%는 되어야 의미 있음”인지 기준을 합의해두는 거야.
이해관계자와 기대를 조율한다. 릴리즈하고 3일 뒤에 “성과 없어”라는 말이 안 나오도록 사전에 ‘성과 측정은 언제쯤 가능하다’는 커뮤니케이션을 해둬야 돼.
PO
그러지 않으면 조급함만 쌓이고, 실제로 의미 있는 변화가 있어도 그 전에 평가절하되겠네요.
구루
정확해. Outcome 중심으로 일하려면, 시간에 대한 리더십도 함께 갖춰야 하는 거지.
PO
결국 ‘뭘 만들까’보다 ‘무슨 변화가 일어나야 하지?’를 먼저 묻고, 그 변화가 ‘언제쯤’, ‘어떻게’ 생길지를 함께 설계해야 하는 거군요.
구루
그 질문이 바로 PO의 수준을 결정짓는 거야. 그리고 여기서 중요한 포인트가 하나 더 있어.
PO
뭐죠?
구루
모든 output이 outcome을 만들어내는 건 아니야. 하지만 outcome을 만들기 위해선 output이 반드시 필요하지. 그래서 수많은 output을 실험처럼 설계하고, 그 결과를 학습자산으로 남기는 것이 중요해.
PO
실패한 output도 자산이 될 수 있다는 말씀이군요?
구루
맞아. 실패한 output을 “버린 기능”이 아니라 “가설이 틀렸다는 걸 증명한 실험 결과”로 바라보면, 다음 output은 더 정교해지는 거야. 학습 없이 output을 반복하면 낭비가 되고, 학습과 연결되면 성과의 사다리가 돼.
PO
실험마다 학습 포인트를 남기는 구조를 만들어야겠어요.
구루
그래서 PO는 다음과 같은 사이클을 팀 내에 정착시켜야 해.
Outcome 정의 – 바라는 고객 행동/비즈니스 지표
가설 설정 – 어떤 output이 그것을 이끌어낼 것인지
Output 설계 – 기능, 메시지, UI 등 실행 항목
관측 계획 – 언제까지 어떤 데이터를 볼 것인지
학습 기록 – 결과 유무와 상관없이 배운 점 정리
PO
이제 ‘기획’은 단순한 설계가 아니라 변화를 위한 실험 설계라는 말이 와닿아요.