이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 파트너사 제안서 초안을 처음 작성하면서 논리 구조를 어떻게 잡아야 하는지를 배웠습니다. 처음 작성한 초안은 '우리가 할 수 있는 것 목록' 형태였는데, 팀장님 피드백에서 '상대방이 이 제안을 받아들여야 할 이유가 안 보인다'는 지적을 받았습니다. 이를 계기로 SCQA(Situation-Complication-Question-Answer) 구조를 배웠습니다.
상황 설명→문제 제기→핵심 질문→우리 솔루션 순으로 전개하니 제안의 필요성이 먼저 드러나고 솔루션이 자연스럽게 따라오는 흐름이 됐습니다. 수정된 제안서가 파트너사와의 첫 미팅에서 빠르게 논의 단계로 넘어갔다는 팀장님 공유가 있었습니다. 제안서의 논리는 '우리가 좋다'는 주장이 아니라 '상대가 왜 이 선택을 해야 하는가'를 먼저 증명하는 것에서 시작한다고 생각합니다.
제안서를 쓸 때 제가 의식하는 건, 결론을 먼저 두고 근거를 계층으로 받치는 구조입니다. 읽는 사람은 첫 문장만 봐도 핵심을 알 수 있어야 합니다. 그래서 저는 '우리가 할 수 있는 것 목록'으로 늘어놓지 않고, 상대가 이 제안을 받아야 할 이유를 맨 앞에 두고 그걸 지지하는 근거를 아래에 배치합니다. 또 근거 항목이 서로 겹치지 않고 빠짐없이 전체를 덮는지를 점검해, 분석 누락이나 중복을 막으려 합니다. 다만 제 한계도 인정합니다. 저는 인턴 때 제안서 초안을 써 본 수준이라, 항목을 겹치지 않게 빠짐없이 나누는 게 말처럼 깔끔하진 않았고, 그 분류 감각이 부족합니다. 또 결론을 앞세우려다 근거가 약한데 단정해 버릴 위험도 있습니다. 그래서 작성 후 '이 논리에 반박한다면?'으로 스스로 검증하려 합니다. 제안서 논리는 '우리가 좋다'가 아니라 '상대가 왜 이 선택을 해야 하는가'를 먼저 증명하는 데서 시작한다고 봅니다.
인턴 때 파트너사 제안서 초안을 처음 쓰며, 제가 직접 부딪힌 건 논리 구조였습니다. 처음 초안은 '우리가 할 수 있는 것 목록'이었는데, 팀장님이 '상대가 이 제안을 받아야 할 이유가 안 보인다'고 했습니다. 그걸 계기로 저는 상황 → 문제 제기 → 핵심 질문 → 우리 솔루션 순으로 전개하는 구조를 배워 적용했습니다. 그러자 제안의 필요성이 먼저 드러나고 솔루션이 자연스럽게 따라오는 흐름이 됐습니다. 수정한 제안서가 첫 미팅에서 빠르게 논의 단계로 넘어갔다는 공유를 받았습니다. 제안서 논리는 우리가 좋다는 주장이 아니라 상대가 왜 이 선택을 해야 하는지를 먼저 증명하는 것이라고 배웠습니다. 다만 제 한계도 인정합니다. 저는 초안 작성 수준이라, 근본 원인 분석을 거쳐 솔루션이 그 원인을 직접 푸는지 논리적으로 잇는 데까진 정교하지 못했습니다. 또 상관관계를 인과처럼 쓰는 오류에 빠질 위험도 있습니다. 그래서 SCQA 구조를 토대로, 그 논리의 엄밀함을 더 키우려 합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 피처링 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.