Question 1

하고 싶은 기능은 열 개인데 이번 분기에 세 개만 할 수 있다면, 어떻게 고르시겠어요?

Accepted Answer

우선순위 판단의 기준이 명확하고, 설명 가능한지 봐. 답변 순서: 결론: 판단 기준 (목표 지표 기여, 비용, 리스크) → 기준을 적용하는 방법 (점수화, 영향 추정) → 이해관계자와 합의하는 과정 → 빠진 기능을 다루는 방법. 피할 것: "중요한 것부터 합니다". 중요하다는 기준이 빠졌어.

Question 2

본인이 기획한 기능의 성공을 어떤 지표로 판단하셨나요?

Accepted Answer

출시가 끝이 아니라 결과를 보는 사람인지 봐. 답변 순서: 결론: 핵심 지표와 목표치 → 그 지표를 고른 이유 → 실제 결과 수치 → 결과를 보고 한 다음 결정. 피할 것: "사용자 만족도가 올랐습니다"처럼 측정 방법이 없는 지표.

Question 3

여러 부서의 이해관계가 부딪혔던 프로젝트를 조율해 본 경험이 있나요?

Accepted Answer

권한 없이 사람을 움직이는 능력. PM의 핵심이야. 답변 순서: 상황: 누가, 무엇 때문에 부딪혔는지 → 각 입장을 파악한 방법 → 공통 목표를 찾아 제안한 해결안 → 결과와 남은 관계. 피할 것: "회의를 많이 해서 해결했습니다". 무엇을 설득했는지가 빠졌어.

Question 4

사용자가 원하는 것과 회사가 원하는 것이 다를 때, 기획자는 어떻게 해야 한다고 보세요?

Accepted Answer

사용자와 비즈니스를 둘 다 보는 균형 감각을 봐. 답변 순서: 결론: 둘이 만나는 지점을 찾는 게 기획 → 예시 서비스와 갈등 상황 → 양쪽을 만족시키는 대안 → 판단을 검증할 지표. 피할 것: "사용자가 최우선입니다"로 끝나는 것.

Question 5

기획한 기능이 출시 후에 기대만큼 성과가 안 나왔던 경험이 있나요?

Accepted Answer

실패를 데이터로 분석하고 빠르게 결정하는지 봐. 답변 순서: 기능과 목표, 실제 결과 → 원인 분석 방법 → 내린 결정 (개선, 축소, 종료) → 다음 기획에 반영한 것. 피할 것: "마케팅이 부족해서"처럼 외부 요인만 짚는 것.

Question 6

개발자와 디자이너가 기획서를 보고 다르게 이해했던 적이 있나요? 그 뒤로 기획서를 어떻게 바꾸셨어요?

Accepted Answer

커뮤니케이션 실수를 구조로 막는지 봐. 답변 순서: 어긋났던 상황과 영향 → 원인 (모호한 표현, 빠진 예외) → 바꾼 기획서 방식 → 바꾼 뒤 달라진 점. 피할 것: "제가 더 자세히 설명했습니다"만 말하는 것.

Question 7

우리 서비스에 새 기능을 하나 제안한다면 뭘 하시겠어요?

Accepted Answer

회사 서비스를 진짜 써봤는지, 아이디어를 근거로 말하는지 봐. 답변 순서: 결론: 제안 기능 한 문장 → 발견한 사용자 문제 → 기능 설명과 최소 버전 → 성공 지표와 리스크. 피할 것: 서비스를 안 써본 티가 나는 일반론.

Question 8

어제부터 가입 전환율이 갑자기 20% 떨어졌습니다. 어디서부터 보시겠어요?

Accepted Answer

문제를 체계적으로 쪼개는 사고 과정을 봐. 정답보다 순서가 중요해. 답변 순서: 결론: 데이터 오류부터 확인 → 구간별로 쪼개기 (유입, 단계, 기기, 채널) → 최근 변경 사항 확인 (배포, 마케팅, 외부) → 가설 검증과 대응. 피할 것: 바로 원인을 단정하는 것.