피드백을 목적에 맞게 고르는 법

피드백은 답이 아니라 관찰할 정보다.

제품을 만들면 서로 다른 피드백을 듣게 된다.

어떤 사람은 기능을 더 넣어달라고 하고, 어떤 사람은 더 단순하게 만들어달라고 한다. 같은 흐름을 두고도 누군가는 불편하다고 말하고, 누군가는 충분히 좋다고 말한다.

여기서 중요한 것은 모든 의견을 반영하는 일이 아니다. 어떤 피드백이 우리가 풀려는 문제와 연결되는지 확인하는 일이다.

모든 피드백에는 맥락이 있다

피드백은 제품이 실제로 어떻게 사용되는지 알려주는 정보다.

다만 정보마다 무게는 다르다.

한 사람이 한 번 말한 취향과 여러 사람이 반복해서 겪는 불편은 다르다. 필요하다고 말하지만 실제로 사용하지 않는 기능과, 불편을 감수하며 계속 우회해서 쓰는 행동도 다르다. 있으면 좋겠다는 의견과 비용을 감수하고서라도 해결하려는 문제도 다르다.

피드백을 잘 듣는다는 것은 모든 의견을 그대로 따르는 뜻이 아니다.

누가, 어떤 상황에서, 어떤 행동과 함께 말했는지 보는 것이다.

사용자는 해결책의 형태로 말할 때가 많다.

“버튼을 추가해 주세요.”

“화면을 바꿔 주세요.”

“이 기능이 필요해요.”

이때 요청을 바로 만드는 것보다 그 뒤에 있는 문제를 먼저 본다.

왜 버튼이 필요하다고 느꼈는가. 어느 순간에 막혔는가. 지금 방식에서 무엇이 불안한가. 요청은 하나의 가능한 해결책일 뿐이다. 실제 문제를 이해하면 더 단순한 방법을 찾을 수도 있다.

좋은 제품 팀은 피드백을 명령으로 받지 않는다.

관찰 자료로 받아 문제를 다시 정의한다.

강한 신호처럼 보여도 처음부터 크게 바꾸지 않는다.

문구를 바꿔본다. 흐름을 하나 줄여본다. 일부 사용자에게 먼저 열어본다. 다음 18시간 안에 확인할 수 있는 실행을 고른다.

그다음 실제 행동을 보고 예상과 다른 점을 기록한다. 배운 것을 다음 실행에 반영한다.

이 과정이 있으면 의견의 크기보다 증거를 보고 결정할 수 있다. 팀은 어떤 신호를 믿어야 하는지 조금씩 더 잘 알게 된다.

피드백은 관찰하고, 문제로 바꾸고, 작게 실행하고, 다시 배우기 위한 재료다.

모든 피드백을 같은 무게로 반영하지는 않는다.

대신 모든 피드백에서 배울 준비를 한다.