[문제와 가설을 제대로 정의하는 PM의 노하우]_오세규/플래터 -PM은 문제와 가설을 명료하게 정의하고 이를 제품의 발전에 활용할 수 있어야합니다. 본문에서 말하는 문제와 가설을 정의하기 위해

[문제와 가설을 제대로 정의하는 PM의 노하우]_오세규/플래터 -PM은 문제와 가설을 명료하게 정의하고 이를 제품의 발전에 활용할 수 있어야합니다. 본문에서 말하는 문제와 가설을 정의하기 위해 유의하면 좋은 점은 다음과 같습니다. : 1) 문제 정의와 해결책 제시가 동시에 일어날 필요가 없습니다. 오히려 문제 정의가 명확해야 그에 대한 해결 방안을 제시할 수 있습니다. 2) 프로덕트에 대한 이해도가 PM보다 낮은(낮을 수밖에 없죠) 사람도 이해할 수 있는 수준으로 문제와 가설은 구체적이고 친절해야합니다. 3) 모호함이 없도록 용어나 개념에 대한 얼라인먼트를 팀 내에서 맞춰야합니다. 4) 문장의 주어를 공급자인 '우리'가 아닌 '사용자'로 두어 고객 중심적으로 문제를 바라봐야합니다. -상술한 것들에 유의하여 문제와 가설을 분명하게 정의하면 가설 검증을 위한 실험/제품 설계 방향과 그에 필요한 데이터/분석 지표가 명확해집니다. 또한 설계가 명확하기 때문에 가설이 성공했거나 실패했을 때 취해야 할 대응도 명확해집니다. -마주한 문제와 그에 대한 가설이 틀렸을 때도 그게 어떻게, 왜 틀렸는지 잘 알아야 같은 문제가 발생했을 때 같은 실패를 하지 않을 수 있습니다. 그럼으로써 더 효율적으로 문제를 해결할 수 있고, 그걸 알려면 결국 문제와 가설에 대한 최초의 생각이 명확해야겠죠. 1. 내가 무얼 해결해야 하는지 명확히 알아야 그것을 해결할 수 있습니다. 단순히 '뭔가...별론데?'라는 생각을 하거나, 단편적인 '개선안'을 제시하는 건 PM이 아니더라도 누구나 할 수 있습니다. 그래서 문제 해결 이전에 문제 정의의 중요성을 강조하는 아티클이 많은 거겠죠? 2. PM은 프로덕트의 허브이기 때문에 본인이 문제를 아는 데에서 그치지 않고, 팀원들이 비슷한 수준으로 그 문제를 이해할 수 있도록 명료하고 구체적으로 전달하는 것이 문제 정의 자체만큼 중요한 것 같습니다. 3. 궁극적으로는 사용자를 이해하고, 그들의 입장에서 문제를 정의하고, 그 문제를 팀원이 나와 같은 수준으로 이해하도록 하여, 팀 전체가 사용자 중심적 사고로 문제를 해결할 수 있도록 해야겠습니다.