🥸 프로덕트 매니저 초기에 알았더라면 좋았을 5가지 디자이너에서 프로덕트 매니저가 되어 첫 프로젝트를 담당했을 때 나는 문제와 솔루션을 검증하기 위한 실험을 진행하지 못한 채 너무나도 적절한 솔루션을 만드는데 집중했었다. 유별나고 싶지도 않았고 프로덕트 매니저로서 하나씩 솔루션을 제품에 붙여나가는 걸로 만족했었던 기억이 난다. 첫 시도에서 무난하게 시작해서인지 오랜 시간을 적절한 솔루션을 만드는데 보냈었고 팀과 나 스스로도 더 좋다고 느껴지는 솔루션이 있었음에도 불구하고 실패를 하면 안 된다고 생각하여 누가 봐도 무난하게 만들어 나갔었다. 아마존 창업자 제프 베조스는 의사결정의 시기는 필요한 정보의 70%의 재료가 모이면 실행하고 결과를 빨리 받아보라고 한다. 그 대신 의사결정에 따른 결과가 좋지 않았을 때 쉽게 돌아갈 수 있는지 고려가 필요하다. 한 번의 결정이 결과에 상관없이 되돌아갈 수 없는 길인 경우에는 조금 더 신중하게 결정을 내려도 된다고 말이다. 해당 글에서처럼 그 당시 나는 프로덕트 매니저에 대해서 잘 알지 못했기에 무난하게를 외쳤던 것 같다. 이런 글들을 조금 일찍 접했다면 결정을 내리는데 조금은 달라지지 않았을까 싶다. 📝 이하 아티클 메모 1.항상 스스로에게 묻기 "증거는 무엇인가? 이 증거로 충분한가?" 우리는 결국 증거를 모으지 못한 채 너무나 적절한 솔루션(too-proper-solution)을 만드는데 오랜 시간을 보냈습니다. 그러니 항상 증거에 대해서 물어보세요. 2. 가장 중요한 질문에 답하기 위해 몇 달을 보낼 시간이 없습니다. "실행"은 의도적이며 신속해야 합니다. 대신 가장 위험 부담이 큰 가정을 정리하고 가능한 저렴한 방법으로 테스트하세요. 3. 새로운 문제를 해결하기 위한 근거를 찾는 일을 제품 개발팀과 함께해야 합니다. 새로운 아이디어를 내놓는 데는 시간이 걸립니다. 팀이 함께 참여해서 유저 리서치를 개선하고 아이디어를 내는 데 동참하도록 합니다. 4. 인터뷰나 시장 조사에서 발견한 새로운 인사이트를 공유합니다. 인용은 특히 강력합니다. 그리고 기억하세요. 인사이트를 공유하세요. 5. 정리된 것 없이 전체 인터뷰 메모를 전달하지 마세요. 6. 새로운 기능에 아이디어가 있나요? 혹은 팀이 일하는 방식을 바꾸는 것을 제안하고 싶나요? 문제를 설명하는 것으로 시작하고 동료에게 문제에 동의하는지 확인하세요. 7. 적어도 배우려면 실수를 해야 합니다. 제가 자주 반성하고 어떤 실수를 하는지 깨닫고 방향을 수정할 방법을 찾는다면 더 빨리 배운다는 것을 알고 있습니다.