재미있게 써내려간 글이라서 공유합니다. 뒤에 if 가 붙어서, 당신이 ~하다면, 프로덕트 매니저가 아닙니다.라고 설명을 합니다. 즉 이렇게 해야 하는것이 프로덕트 매니저입니다를 설명하네요. 워낙 기

재미있게 써내려간 글이라서 공유합니다. 뒤에 if 가 붙어서, 당신이 ~하다면, 프로덕트 매니저가 아닙니다.라고 설명을 합니다. 즉 이렇게 해야 하는것이 프로덕트 매니저입니다를 설명하네요. 워낙 기초적인 내용이라 이것을 읽고 계신 PM분들은 이미 해당이 되지 않을것으로 생각합니다.:-) 각 항목에 대한 설명은 제가 쓴 것입니다. 아티클을 따로 읽어보시면 좋은데, 뭐 제 설명과 거의 같습니다. 자 이러면 당신은 PM이 아닙니다! 1. 비즈니스 이해 관계자가 제품 구현 방법을 지휘하도록 허용하는 경우 PM의 오너십에 대한 이야기지요. 비즈니스 관계자는 주로 why에 집중하기 보다는 what에 포커스가 있습니다. "이게 있으면 판매성장이 될것이다"와 같은 말입니다. PM은 지겹도록 물어봐야 합니다. 왜 그것이 필요한지, 얼마나 많은 사용자가 그것을 원하는지 등등 말입니다. 2. 문제가 아닌 해결책/솔루션을 더 사랑한다면 위에서 말한 바와 같이 문제가 혁신의 기본 동력이 됩니다. why를 설명하게 하는 가장 근본적인 기회가 되는 상황이죠. 사용자 인터뷰, 사용자 설문조사, 일반 리서치등등을 통해서 그 why에 접근해야 합니다. 3. 의사 결정에 데이터를 사용하지 않는 경우 데이터를 사용하지 않고 무엇에 의지합니까? 누군가의 인사이트로만 프로덕트가 구성될 수 있는 시대는 이미 지났습니다. 데이터는 why에 대한 대답에 가장 근접한 해답을 줄 수 있습니다. 4. 최소한 로우 피델리티(저 충실도) 와이어프레임을 직접 수행하지 않는 경우 PM의 프로덕트 아이디어의 가장 초기 버전입니다. 이 아이디어를 어떻게 소개할겁니까? 와이어프레임-목업-프로토타이핑으로 발전될때, 무조건 PM은 와이어프레임정도는 작성해야 합니다. 그래야 다음에 디자이너의 도움을 받아서 목업으로 발전해 나가고 본인의 아이디어를 검증할 수 있습니다. 간단한 툴 사용을 두려워 하지 말고 배워야 합니다. 5. 제품/서비스 출시 후 성공 지표에 대한 정의를 기다리는 경우 성공지표가 출시 후에 나온다는 것을 어떻게 이해해야 하나요? 성공에 대한 자신감도 없고, 가정을 세울수도 없다는 이야기입니다. PM은 출시전에 제품을 출시하고 나타날 수 있는 모든 변수와 응답을 예상하고 그에 따라 목표를 설정해야 합니다. 물론 매번 정확하게 맞을 수 없지만, 그래야 나중에 어떻게 왜 잘못되었는지를 측정할 수 있습니다. 6. 제품 지표를 정기적으로 추적하지 않는 경우 많은 분들은 제품이 출시되면 일이 끝났다고 생각하는데, 실제로 제품 관리가 시작되는 곳이 바로 출시 후가 되죠. 제품 메트릭을 정의하고 그것에 집착해야 합니다. 올바른 방향으로 가고 있는지 확인하려면 매일 추적해야 합니다. 동시에 제품 지표를 달성하기 위한 방법을 평가하고 살펴보아야 합니다. 제품 피드백을 지속적으로 읽고 건설적으로 받아들이고 가능한 한 많은 가치를 이끌어 내십시오. 7. PDLC(제품 개발 수명 주기)를 따르지 않는 경우 상황에 따라 경영진이나 비즈니스 이해 관계자로부터 지금 단계를 건너뛰고 다음 단계로 넘어가라는 압력을 받는 경우가 많습니다. 다른 사람이 제품 개발 프로세스를 지시하도록 하지 마십시오. 이러한 지침/단계는 성공을 달성하는 데 중요하며 모든 작은 단계가 중요합니다.