1. PM은 어떤 역할을 하는 사람인가? 비슷한 경험을 해 본 적이 있나? 1) 크게 '프로덕트 기획'과 '프로젝트 매니징', ' 그로스 프로덕트 (출시 후)' 세 개로 나뉘는 것 같다. (1) 프로덕트 기획  타겟의 불편, 욕구, 경험하고 싶은 것들을 캐치하여 해당 부분들을 만족시킬 수 있는 프로덕트를 기획. 특히 PM의 두드러지는 특징은, 기획단계에서부터 데이터를 사용한다는 것이다. 판단의 근거를 데이터를 통해 하고 후에 프로덕트 출시 후 개선에 있어서도 데이터를 매우 적극적으로 사용한다. 거의 데이터 분석가가 하는 정도로 해야 되는 것 같다. 이미 기획이 된 프로덕트의 경우 프로젝트 매니징 및 출시 후 관리를 주로 하게 된다. (2) 프로젝트 매니징(출시 후) 기획이 되었으면, 프로젝트가 원활히 진..

1. 데이터 드리븐하게 어떻게 페르소나를 만드는지에 대한 예를 한번 봐보자. 시나리오: 헬스케어 앱 개발목표: 20~30대 직장인을 위한 건강 관리 앱 개발.결과물: 페르소나를 통해 사용자의 주요 요구와 고충을 반영한 기능 설계. 1) 데이터 수집 단계(1) 데이터 소스-설문조사질문:"주로 건강 관리를 위해 어떤 앱을 사용하시나요?""건강 관리에서 가장 큰 어려움은 무엇인가요?""건강 관리를 위해 하루에 투자할 수 있는 시간은?"결과: 응답자의 60%가 "시간 부족"을 주요 문제로 꼽음.75%가 하루 10분 이하의 시간을 투자할 수 있다고 응답.-사용자 인터뷰대상: 20~30대 직장인 10명.주요 발언:"회사에선 너무 바빠서 운동을 할 시간이 없어요.""앱 사용이 번거롭거나 복잡하면 바로 삭제해요."결과..

1. 왜 한 사람을 대표하도록 만드는 걸까? 왜 분포로 만들지 않는 걸까? 결론 분포로 만들지 않는 이유는 분포가 너무 추상적이어서 실질적인 의사결정을 돕기 어렵기 때문이다. 일단 사용자 데이터를 사용해 분포를 세분화한 뒤, 각 그룹의 대표 페르소나를 생성해야 한다. 페르소나는 분포를 대변하는 구체적인 이야기를 통해 팀의 방향성을 명확히 하는 역할을 해야 한다는 사실을 명심하자.  1) 페르소나는 "의사결정 도구"-한 명의 사람처럼 만드는 이유는 구체성과 공감에 있다.페르소나는 단순한 통계 데이터가 아니라, 구체적인 행동과 맥락을 담은 "가상의 인물"이다.팀이 한 명의 사용자에게 집중하면, 더 쉽게 공감하고 그 사람의 문제를 해결하려는 방향으로 논의가 이루어진다. 예: "김지수(28세 마케터)는 직관적인..

1. 페르소나를 사용하는 근본적인 목적  1) 사용자 중심의 의사결정 지원제품이나 서비스 개발 과정에서 실제 사용자의 요구, 목표, 행동을 반영해 설계와 개발의 방향성을 제시한다.팀이 사용자의 관점을 이해하고, 고객의 니즈와 문제를 해결하는 데 초점을 맞추도록 돕는다. 2)팀 내 커뮤니케이션과 협업 강화페르소나는 팀 내 공통된 사용자 모델을 제공해, 제품 기획, 디자인, 마케팅 팀 간에목표와 이해를 일치시키는 역할을 한다. 특히 마케팅 설계에서 페르소나를 정확히 이해하여 적절한마케팅 플랜을 기획할 수 있게 한다.3) 사용자 경험(UX) 및 만족도 개선사용자의 구체적인 문제와 요구를 이해함으로써,제품이나 서비스가 더 나은 해결책을 제공할 수 있다. 또한 사용자와 제품 간의 접점에서 발생하는 불편함이나니즈 ..

https://nusnu.tistory.com/89 데밸챌) 그로스 해킹 - 1데이터를 다루면서, 특히 예측 문제들을 많이 다루면서  실제로 내가 하는 이 행동이 회사에 실질적으로 기여를 하고 있긴 한 것인가 하는  의문을 가질 때가 많았다.  예측 모델의 정확성을nusnu.tistory.comhttps://nusnu.tistory.com/90 데밸챌) 그로스 해킹 - 2본질적으로 그로스 해킹이란 "어떻게 하면 서비스, 제품 측면에서 데이터를 바탕으로 회사를 성장시킬것인가? " 에 답하는, 성장에 초점이 맞추어진 프레임이라고 할 수 있다.   주요 흐름은nusnu.tistory.comhttps://nusnu.tistory.com/91 데밸챌) 그로스 해킹 - 3. 지표란?조금은 넓은 시야에서 지표를 바라..

아이스 브레이킹이라는 작으면 작고 크다면 큰 프로덕트(?) 를 모두와 진행하게 되면서 PM을 향한 첫 발자국을 밟게 되었다.   사실 지금까지는 PM과 같은 다 같이 뭔가를 하는 것보다 혼자 모든 것을 처리하는 것을 더 선호하기는 했다. (근데 결국 전체 프로세스를 전부 다 알고 싶고, 전부 다 하고 싶어서, PM 하고 싶은 것도 있다.) 자기 자신의 행동으로 인한 결과만 책임지면 되는 상황에서 모두의 노력이 들어간 결과의 책임을 져야 한다는 그 압박감이 대단히 크게 느껴졌기 때문일까   항상 매우 작은(3인 이하) 혹은 1인 연구 및 개발만 하다 5인 이상의, 각각 전부 전문가를 향해 나아가는 분들을  이끌어 간다는 것이 상상만 해도 매우매우 아찔한데 이거 잘할 수 있으려나 모르겠다.   개인적으로도 ..

How -> What  > 1. Why  특정 문제를 해결해야한다. 혹은 특정 목표를 달성해야 한다.어떻게 달성할 것인가?문제 해결 및 목표 달성을 위해 기획을 한다.  그렇다면 대해 왜 A라는 주제의 기획이어야 하는가? 정당성을 생각해야만 한다. 그래야 설득이 가능하다.그래야 사람들을 움직일 수 있다.  판단의 기준이 되는 가장 밑바닥의 근거가 무엇인가? 즉, 갖고 있는 소명과 신념은 무엇인가? "단 한마디의 소명. 이것이 모든 것의 판단 기준이 된다." - 문해일   "사람들은 여러분들이 무엇을 하느냐 때문에 구매하지 않는다.사람들은 그 일을 왜 하느냐를 보고 구매한다.즉, 상품에 소명이 드러나야한다. " " 사람을 고용할 때도 단지 직업을 필요로 하는 사람들이 아니라 여러분들이 믿고 있는 것을 믿어..

피드백이 계속되는 상황에서  어떻게 하면 효율적으로 프로덕트를 만들고 개선해 나아갈 것인가? 이러한 질문에 대해 프로세스 최적화를 한 전략이 Agile이라는 개발 방법론인 것 같다. 결국 모든 일이라는게  1. 목표를 정한다.2. 달성한다.  이렇게 단순화 할 수 있는데, 여기에 "시시각각 변화하는 환경과 피드백"에 대응하기 위해서  1. 조직의 관점에선 1) 팀의 단위가 작아서 의사결정이 빨라야 한다.(한 팀을 스쿼드, 스크럼이라 부른다.)2) 일반적으로 프로덕트 오너(프로덕트 매니저)와 개발자로 나뉜다.(경우에 따라선 몇몇 직무들이 추가될 수도 있다.)3) 하나의 기능을 위해 한 번의 스프린트를 진행한다.(1~2주)4) 스프린트를 진행하고 매일 증가분을 축적한 후 체크한다.(이를 데일리 스크럼이라 한..