brunch

라이킷 3 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by sooinsoo May 18. 2023

제품을 개선할 때 설득하는 최악의 근거 3가지

"타협의 길로 안내하는 최악의 주장”

제품을 개선할 때 나를 타협하게 만드는 최악의 근거 3가지

PM으로서 제품 개선 시 다음의 3가지 주장은 지양하세요! ① 경쟁사에 있어요 ② 고객이 필요하대요 ③ 사용자가 선택해서 사용할 수 있게 해요

PM은 올바른 방향으로 제품 개선을 끌어내는 역할이다. 다양한 이해관계자로부터 “이거 고쳐주세요. 이건 왜 안 해줘요?” 라는 많은 요구사항을 받는다.

고객, Biz, Tech, 개발, 마케팅 등 모든 것을 고려하여 제품의 방향을 정한다. 누구보다 프로덕트에 대한 깊은 이해로 한발 앞서 팀의 다음 방향을 제시해야 하므로, 가끔은 타협하고 싶다는 생각을 할 수 있다.

금융권 재직시절, 상사로부터 무수히 많이 들었던 최악의 주장을 소개하려고 한다. 흔한 주장이며 그럴듯해 보여 쉽사리 타협하기 쉽다. 나는 어땠을까? 한 번 되돌아보자.

제품 개선 시 주장하는 최악의 근거 3가지

1. “경쟁사에 있는 기능인데요”

“토스에 있는 이 기능 우리도 넣자!” “토스에 있는 이 기능 편한데 우리도 이렇게 바꾸자” 무수히 많이 들었다. 이 질문에 나는 매번 같은 질문으로 되묻는다.

토스가 왜 이걸 넣었을까요? 이 기능은 사용자에게 어떤 효과가 있을까요? 실제로 그 효과를 얻었을까요?

경쟁사가 ‘왜, 이 기능을 넣었는지’ 그들의 의도와 목적을 확인하고 사용자 관점에서 철저히 평가하고 학습해야 한다(토스 역시 같은 금융이지만 KB와는 다른 제품 비전을 가지고 있다). 그런 목적의 논쟁이라면 얻을 게 많다. 경쟁사 제품을 보다 보면, 우리 서비스에 없는 것이 많게 느껴지거나 더 좋아 보일 때가 있다. 그건 착각이다.

나도 가끔은 경쟁사 프로덕트가 좋아 보여 따라 하고 싶다고 생각한 적이 있다. 퇴사하고 경쟁사로 이직한 후, 이직한 곳의 동료가 내가 만든 기능을 좋다고 평가했다. 그 당시 어떤 의도로 만들었고, 실제 어떤 효과가 있었는지 알려주면 ‘좋다는’ 생각이 바뀐다.

경쟁사 제품은 참고용이니, 그들의 제품을 보며 학습해야 한다. 누굴 대상으로 어떤 문제를 무슨 방법으로 해결했는지, 그에 따른 성과가 무엇인지 철저하게 분석하면 얻는 게 많아진다.

2. “고객이 필요하대요”

- A 차장님: VOC 보니, 고객이 이런 기능 필요하다던데 우리 이번 개편 때 이 기능 넣자!
- 나: 이거 이 사람만의 문제인 것 같은데, 빈번하게 발생하는 문제가 아닐 텐데, 확인해보죠!

다양한 채널로 인입된 VOC를 보면, 사용자의 문제를 확인할 수 있다. 여기서 중요한 게 있다. 문제를 발굴하는 것과 문제를 정의하는 것은 다르다. 위 대화의 차장님은 발굴한 문제가 해결해야 할 가치 있는 유효한 문제인지 판단하지 않았다. 사용자가 직접 언급했으니, 중요한 문제라고 착각한 것이다.

흔한 사례다. 사용자가 직접 언급한 내용을 근거로 쓰면 되니 설득하기 쉽다. 발굴한 모든 문제를 해결하는 것이 아닌, 가치 있는 유효한 문제를 정의하고 정의된 문제를 해결해야 한다. 그렇다면, 해결해야 할 유효한 문제를 어떻게 정의할까?

2가지 기준으로 정의하면 된다. (자세한 내용은 ‘가치 있는 유효한 문제를 정의하는 방법’ 글 참조)

그림 1. 문제를 정의하는 2가지 기준

예를 들어보자. 과거 인터넷뱅킹을 하기 위해서 공동인증서(과거 공인인증서)를 PC로 옮기고, 보안 프로그램과 Active X를 설치했다. 설치해도 오류가 발생하기 부지기수. 이 문제는 많은 사용자가 자주 겪는 불편한 문제이다. 다수의 사용자가 겪는 이 불편함을 토스, 카카오뱅크가 해결했다.

아래와 그림과 같이, 문제의 유효함은 해당 문제를 겪는 사용자가 얼마나 많은지, 얼마나 자주 겪는 불편함인지, 불편함으로 인해 이득의 손실이 얼마나 발생하는지에 따라 결정된다.

그림 2. 문제의 유효성을 판단하는 척도

3. “사용자가 선택할 수 있게 해요”

Feature를 설계하는 과정에서 빈번하게 듣는 주장이다. 이 주장의 기본적인 전제는 ‘모든 사용자를 만족시키자’ 이다. 크게 2가지 상황으로 나뉜다.

① 일부 고객은 편하나, 일부 고객은 불편한 경우

A Feature를 만들었더니 일부 고객은 편하게 쓰나, 일부 고객은 불편하게 느낀다. 불편함을 느끼는 일부 고객을 위해 B Feature를 만든다. 이론적으론 완벽해 보인다. 하지만 생각해보자. A Feature에 대한 반응이 달랐다면, 또다시 B Feature에 대한 반응도 달라질 수 있지 않을까? 기본적으로 Feature가 생기면 신규 사용자, 기존 사용자 등 프로덕트 내 사용자에게 영향을 미친다. 우리 프로덕트가 Scale이 끝난 복잡한 서비스라면 더더욱이 그 반응은 제각각이다. 선택적으로 만들어진 모든 기능은 제품의 복잡성을 증가시킨다.

② 필요한 모든 것을 제공해주는 경우

Feature를 설계하는 과정을 생각해보자. 사용자가 이것도 필요할 것 같고, 저것도 필요할 것 같다. 그래서 사용자가 필요한 모든 것을 선택항목으로 넣었다. Feature를 설계하는 PM은 생각한다. ‘사용자가 만족할 수밖에 없어!’ 이 역시도 착각이다. 사용자는 3개 이상의 선택지가 제공될 경우, 선택에 혼란을 느끼고 고민에 많은 시간을 소요한다(선택의 역설 - The Paradox of Choice 참고). 실제 이를 가지고 대학원 다닐 때 실험한 적이 있다. 5개 입력 항목을 1페이지에서 모두 입력받는 방식과 1페이지에 1개의 입력 항목으로 총 5개 페이지로 입력받는 방식을 비교했다. 사용자의 만족도는 1페이지에서 1개의 항목만 입력받는 방식이 더 높았다(많은 스타트업의 디자인 원칙 중 1 Page 1 Thing이 있는 이유가 있지 않을까?).

Feature를 만들 때 고민해야 한다. 정의한 문제를 해결하는 최선의 방법이 무엇인지. 누굴 대상으로 어떤 문제를 해결하기 위함인지를. 그리고 무엇에 집중해야 하는지를.

때론 아무것도 안 하는 게 Best!

PM으로서 아무것도 안 한다는 것은 쉽지 않다. 그렇기 때문에, 위 3가지 주장을 하면서도 제품을 개선하려고 한다. 하지만 고민해보자! 프로덕트에 기능이 들어갈수록 기술 부채(Tech debt)는 증가한다. 오히려 현시점에 내가 맡은 프로덕트가 나아가야 할 뾰족한 수가 없다면, 잠시 멈추고 그 뾰족한 수를 찾는 데만 집중하는 게 훨씬 낫다.