기능 출시는 성과가 아닌가요?

주니어 PM 성장기 #13

어느새 25년의 2분기가 시작되었다.

직장인이라면 올해의 연봉협상을 대부분 마무리했을 것이다.

미니 CEO라는 별명을 가진 PM도 한낱 직원에 불과하기에 연봉 협상이 중요하다.

연봉을 조금이라도 많이 올리기 위해서는 1년 간의 성과를 제대로 정리할 필요가 있다.

짧은 경력이지만 PM이 성과를 정리하는 방법에 대한 생각을 작성해보려 한다.

PM이라면 '이건 제가 맡았습니다'라고 말할 수 있는 무언가가 있을 것이다.

기능이든 운영이든, 크든 작든 PM은 다양한 협업을 이끌고, 여러 의사결정에 영향을 주기 때문이다.

그렇기에 PM의 성과는 가시적인 것처럼 느껴진다.

'A 기능 출시', 'B 운영 프로세스 체계화' 등과 같이 말이다.

그러나, 이건 PM의 성과라고 보기 어렵다.

PM이 생각한 것을 실제로 수행한 주체는 디자이너나 개발자, 혹은 유관 부서다.

PM 혼자서 무엇을 할 수 있었겠는가?

PM의 성과를 정의하려면 회사에서 PM에게 기대하는 바가 무엇인지 알아야 한다.

1. 고객이 가진 문제를 정의하고

2. 이를 해결하여

3. 고객 가치와 비즈니스 가치를 창출한다.

기능 출시, 프로세스 체계화 등은 PM에게 기대하는 점 중 한 가지에 불과하다.

심지어 PM의 고유 영역조차 아니다.

PM이 가장 핵심적으로 영향력을 발휘해야 하는 부분은 '문제 정의'다.

그렇다면, 고객의 문제를 얼마나 잘 정의했는지를 어떻게 설명할 수 있을까?

이때 중요한 개념이 Output과 Outcome이다.

두 단어는 얼핏 비슷해 보인다.

한국어로는 모두 '결과'로 번역되기 때문에 헷갈리기 쉽다.

하지만 이 둘은 PM의 성과를 구분 짓는 핵심 기준이다.

Output은 '무엇을 만들었는가', Outcome은 '무엇을 얻었는가'다.

좀 더 쉽게 말하면, '무엇인가를 만들어서(Output) 이러한 결과(Outcome)를 얻었다.'라고 할 수 있다.

Outcome은 PM의 성과를 증명할 수 있는 도구다.

고객의 문제를 얼마나 정확히 정의했는지가 Outcome의 크기를 좌우한다.

해결책이 적절했는지도 중요하지만 문제를 정의하는 단계가 제대로 되어야 적절한 해결책이 나온다.

따라서, PM의 성과에는 Outcome이 있어야 한다.

'A 기능을 출시했습니다.'가 아니라 'A 기능을 출시하여 B 결과를 얻었습니다.'라고,

'A 프로세스를 체계화했습니다.'가 아니라 'A 프로세스를 체계화하여 B 결과를 얻었습니다.'라고 해야 한다.

Outcome을 정리하는 것은 생각보다 쉽지 않다.

이 기능으로 인해 특정 지표가 올랐다는 사실을 명확하게 하기 어렵기 때문이다.

프로덕트는 유기적이기 때문에 여러 복합적인 요인이 함께 작용할 수밖에 없다.

그렇기 때문에 각 기능마다 가설을 확실히 세우고, 꼼꼼하게 검증하는 과정이 중요하다.

Output과 Outcome은 성과를 정리할 때가 아니라, 출발점에서부터 고려되어야 한다.

평소에 가설을 아래와 같이 세우고 검증한다면 성과를 정리하는 데 큰 어려움은 없을 것이다.

1. 어떠한 유저에게 (Target User)

2. 어떤 경험을 제공한다면 (Output)

3. 어떤 결과를 얻을 수 있을 것이다. (Outcome)

주의할 점은 Output이 중요하지 않다는 것이 아니다.

문제를 효과적으로 해결하는 것도 가치 창출에 큰 영향을 준다.

논지는 성과를 말할 때, Output에서 끝나는 것이 아니라 Outcome까지 이어져야 한다는 것이다.

따라서, 나는 성과를 정리할 때 Output과 Outcome을 나누어서 작성한다.

예를 들면, 아래와 같이 말이다.

Output
- A 기능 출시 (2월)
- B 운영 프로세스 체계화 (3월)
Outcome
- A 기능을 통해 a 문제를 해결하였고 C 지표가 상승함
- B 운영 프로세스를 채계화하여 b 문제를 해결하였고 D 지표가 상승함

‘무엇을 했는가’가 아니라 ‘무엇을 얻어냈는가’로 말하는 것.
그게 바로 PM으로서의 성과를 가장 잘 보여주는 방식이라고 믿는다.