Output 집중 vs Outcome 집중

Outcome에 집중해야 하는 이유

많은 조직, 개인들이 기능 배포, 프로젝트 완료 중심으로 일을 합니다. 이러한 output 중심의 조직은 계획에 따라 delivery를 했는지 집중합니다. 왜냐하면 명확하고 관리하기 쉽기 때문입니다 (기능을 일정 내에 만들었는가? 못 만들었는가?)

output 중심으로 훈련된 조직, 개인은 프로덕트 개발에 있어 주로 이런 질문을 많이 합니다. "개발 리소스가 얼마나 많이 드나요?" 프로덕트 개발을 통한 고객의 행동 변화나 비즈니스의 성과 보다 구현 가능성에 관심이 많고, 이러한 프로덕트 팀은 기획결과의 기술 검토 중심으로 운영됩니다.

output 중심의 PM,기획자로 관찰되는 커뮤니케이션 특징은 엔지니어를 '개발자님'이라 표현합니다. 사실 이러한 표현은 직군에 대한 존중 보다는 정치적인 경우가 많습니다. 엔지니어, 디자이너를 자신의 잘 기획된(하지만 검증되지 않은) 아이디어를 output 중심으로 딜리버리하는 대상으로 객체화하여 생산능력만 고려합니다.

또한 output 중심으로 일하는 조직과 개인들은 바쁘게 보이기 쉽습니다. 그러나 실제로는 완료 중심의 업무를 수행하며, 고객의 문제를 해결하고 니즈를 충족시키기보다는 결과물을 쌓아두기에 관심이 많아집니다. 결과물은 많이 만들어지지만 고객의 행동 변화를 가져오는 경우는 적거나 그에 대한 관심이 부족합니다. 결과물이 나오면, 바로 다음 프로젝트로 넘어가는 경향이 있기 때문입니다.

결과물 자체가 아닌 결과물이 가져다주는 변화가 중요하며, 이것이 실질적으로 기업의 비즈니스 성과와 고객 만족도를 높이는데 기여합니다. Output 대신 Outcome 중심으로 목표를 설정하는 것이 그 시작이라고 할 수 있습니다.