PM 포지션 채용 중일 때 우리 회사에 맞는 JD 작성하는 방법

JD가 템플릿으로 안 끝나는 이유: '우리 회사에 맞는'이 먼저예요

안녕하세요. 채용 때문에 머리 복잡한 HR 담당자입니다.

PM(Product Manager) 채용할 때 이런 경험, 한 번쯤 있으셨을 것 같아요.

• 공고 올리면 지원자는 꽤 오는데, 면접 들어가면 “뭔가 우리랑 결이 다른데…” 싶고
• 반대로 “이 분은 진짜 만나보고 싶다” 싶은 PM은 서류 자체가 안 들어오는 느낌

저도 처음엔 연봉, 브랜드, 시장 분위기 탓만 했거든요. 그런데 시간이 지나면서 제일 뼈아픈 깨달음이 하나 생겼습니다.

PM 채용에서 JD는 ‘설명서’가 아니라 ‘필터’더라고요.
그리고 그 필터는 생각보다 잔인하게 작동합니다. 지원자가 JD를 읽고 “아, 여긴 내가 가면 고생하겠다” 혹은 “여긴 내가 해볼 만한 문제를 풀겠네”를 10초 안에 판단해버리니까요.

문제는, 우리가 흔히 쓰는 템플릿 JD가 “그럴듯해 보이게”는 만들어주지만, ‘우리 회사에 맞는’을 대신 결정해주진 않는다는 점이에요.

예를 들어 이런 문장들 있죠.

• “서비스 기획 및 운영 전반”
• “유관부서 커뮤니케이션”
• “데이터 기반 의사결정”

틀린 말은 아닌데… 이 문장만 보면 지원자가 머릿속에서 각자 다른 그림을 그립니다.

• 어떤 PM은 “아, 여기 PM이 권한이 없고 조율만 하나 보다”라고 읽고
• 어떤 PM은 “아, 여기서 내가 진짜 문제를 정의하고 우선순위를 잡을 수 있겠네”라고 읽어요

같은 JD를 보고도 서로 다른 ‘약속’을 상상하는 순간부터, 채용은 이미 삐끗하기 시작하더라고요.

그래서 오늘은 “PM 포지션 채용 중일 때 우리 회사에 맞는 JD를 어떻게 쓰냐”를, 템플릿이 아니라 기준으로 정리해보려고 합니다.

제가 요즘 제일 많이 쓰는 순서는 이거예요.

1. 문제(Problem)를 한 문장으로 고정하고
2. 책임 경계(R&R)를 먼저 박아두고
3. 성과 기준(특히 90일 기대치)을 JD에 넣고
4. Why-Problem-Impact 구조로 자기선택이 되게 쓰고
5. 자격요건을 스킬 나열이 아니라 ‘신호’로 바꾸고
6. 마지막으로 검증(과제/면접/레퍼런스)을 설계합니다

이 순서대로만 가도, “지원자는 많은데 핏이 안 맞는” 상황이 꽤 줄어들더라고요. 다음 섹션부터 하나씩 같이 정리해볼게요.

Step 1) 우리 회사의 PM이 풀어야 할 '문제'를 한 문장으로 고정하기

JD를 쓸 때 제가 제일 먼저 하는 질문은 이거예요.

“그래서 이 PM이 와서, 지금 당장 무엇을 해결해야 하죠?”

PM JD가 흔들리는 대부분의 이유는, 업무를 잘못 써서라기보다 문제가 고정되지 않아서더라고요.
문제가 고정되지 않으면,

• 업무 범위가 계속 늘어나고(“일단 다 하세요”)
• 우선순위가 바뀔 때마다 PM 탓이 되고(“왜 이걸 안 했죠?”)
• 면접도 뜬구름 잡는 얘기만 하게 됩니다(“커뮤니케이션이 중요합니다”)

그래서 저는 ‘업무 리스트’가 아니라 문제 문장부터 JD에 심거나, 최소한 JD를 쓰기 전에 내부에서 합의합니다.

1) 제품/조직 단계에 따라 PM의 ‘문제’는 달라요

같은 PM이라도 회사 단계가 다르면 미션이 완전히 달라요. 이걸 JD에 드러내야 “맞는 사람”이 스스로 들어옵니다.

회사/제품 단계	PM에게 제일 큰 문제	JD에서 강조할 것
0→1 (초기)	“무엇이 문제인지”부터 불명확	고객/문제정의, 가설검증, 빠른 실험
1→10 (성장)	스케일하며 우선순위가 충돌	우선순위/로드맵, 이해관계자 정렬, 지표
10→100 (확장/성숙)	복잡성(조직/프로세스/레거시)	의사결정 구조, 운영 체계, 제품 포트폴리오

‘우리 회사에 맞는 JD’는 결국 이 표에서 어디에 가까운지부터 시작하더라고요.

2) 문제 문장 템플릿 (제가 제일 자주 쓰는 형태)

이건 PM이 들어와서 해야 할 일을 ‘사람’이 아니라 ‘문제’에 붙이는 방식이에요.

• “우리는 (고객/사용자)에게 (상황/니즈)에서 (가장 큰 장애물)을 겪고 있고, PM은 (원인 가설)과 (해결 방향)을 정리해 (성과 지표)를 개선해야 한다.”

예시로 바꿔보면 이런 느낌입니다.

(Bad) 흔한 JD 문장

• “서비스 기획 및 운영”
• “신규 기능 기획”

(Good) 문제 문장으로 고정한 JD

• “결제 전환율이 특정 단계에서 급격히 떨어집니다. 이탈 원인을 정의하고 우선순위를 잡아 8주 안에 전환율을 개선할 PM이 필요합니다.”
• “B2B 고객의 온보딩이 길어 영업→활성화 전환이 막힙니다. 온보딩 프로세스를 재설계해 90일 내 활성화까지의 리드타임을 줄이는 PM을 찾습니다.”

여기까지 쓰면 지원자도 바로 판단합니다.

• “아, 나는 이런 문제 풀어본 적 있다. 지원할래.”
• “나는 이런 문제는 싫다. 안 맞겠다.”

이게 저는 오히려 건강하다고 느껴요. JD가 지원자를 더 끌어모으는 게 목적이 아니라, 맞는 사람과 덜 소모적으로 만나는 것이 목적이니까요.

다음 섹션에서는, 이 문제 문장을 “일정관리/조율 역할”로 오해받지 않도록 R&R(책임 경계)를 JD에 어떻게 박아두는지 이야기해볼게요.

Step 2) PM의 책임 경계(R&R)부터 박아두기: PM/PO/프로젝트의 차이

PM JD가 “우리 회사에 안 맞는 지원자만 모으는” 방향으로 흐르는 순간이 있어요.
바로 JD에 이런 단어들이 반복될 때입니다.

• “일정 관리”
• “개발 리딩”
• “요구사항 전달 및 조율”

물론 PM이 일정도 보고 조율도 하죠. 그런데 JD에서 이것만 크게 보이면, 지원자는 이렇게 읽습니다.

“아, 여긴 PM이 문제를 정의하거나 우선순위를 결정하진 못하고, 전달/독촉 역할인가 보다.”

이건 지원자에게도 불행하고, 회사에게도 불행해요.
우리는 ‘제품의 문제를 책임질 PM’을 뽑고 싶었는데, JD가 ‘프로젝트 코디네이터’를 부르는 신호가 되어버리니까요.

1) 역할 이름보다 중요한 건 ‘결정권과 책임’이에요

현실적으로 PM/PO/프로덕트/프로젝트 명칭은 회사마다 다르더라고요.
그래서 저는 이름 논쟁보다, 아래 3가지를 JD에 박아두는 쪽이 훨씬 효과가 좋았습니다.

1. 누가 우선순위를 결정하나요? (PM이냐, 대표/사업부냐, 특정 위원회냐)
2. 무엇까지 PM이 결정하나요? (문제/목표/스펙/릴리즈/가격/채널 등)
3. PM이 책임지는 결과는 무엇인가요? (지표/리드타임/리텐션/매출 등)

2) JD에 바로 넣을 수 있는 ‘R&R 문장 템플릿’

제가 JD에 자주 넣는 문장 구조는 이렇습니다.

• 우선순위(Decision): “PM은 (고객/데이터/현장)의 근거를 바탕으로 (백로그/로드맵)의 우선순위를 제안하고, (의사결정자)와 합의합니다.”
• 범위(Scope): “PM은 ‘무엇을 왜’에 책임지고, ‘어떻게(구현)’는 엔지니어링/디자인과 함께 결정합니다.”
• 협업 방식(Collaboration): “PM은 이해관계자(영업/CS/운영)와 요구를 수집하되, 모든 요청을 그대로 수용하지 않고 제품 목표에 맞춰 조정합니다.”

그리고 꼭 한 줄 더 붙입니다.

• “이 역할은 ‘일정 관리’가 핵심이 아닙니다. 목표와 우선순위를 정리하고, 팀이 같은 방향으로 움직이게 만드는 역할입니다.”

이 한 줄이 들어가면, 지원자들이 정말 많이 달라져요.
“아, 여긴 PM을 PM으로 쓰려는 회사구나”라는 신호가 되니까요.

3) PM/PO/프로젝트를 ‘표’로 오해 없이 정리하기 (회사 내부 합의용)

지원자용 JD에 전부 넣진 않아도, 내부 합의용으로는 이런 표를 한 번 만들어두면 도움이 됩니다.

구분	PM(제품 책임)	PO(실행/백로그)	프로젝트(딜리버리)
핵심 질문	“무엇을/왜?”	“무엇을 먼저?”	“언제/어떻게 끝내?”
책임	문제/성과(Outcome)	백로그/스코프	일정/리스크
주 협업	비즈/데이터/고객	개발/디자인	전 부서

이 표를 기준으로 JD 문장도 정리되더라고요.
우리 회사가 지금 당장 필요한 건 PM인지, PO인지, 프로젝트 리드인지.

다음 섹션에서는, 지원자가 제일 궁금해하는 “입사 후 무엇으로 평가받나요?”를 JD에 넣는 방법을 이야기해볼게요. 저는 여기서 90일 기대치를 꽤 적극적으로 쓰는 편입니다.

Step 3) 성과 기준을 JD에 넣는 법: 90일 기대치와 지표

PM 지원자가 JD를 읽을 때 속으로 제일 궁금해하는 질문이 뭔지 아세요?

“그래서 여기서 PM을 ‘잘한다’는 건 뭐지?”

그런데 많은 JD가 이 질문에 답을 못 하더라고요.
그러면 면접에서도 서로 이런 대화만 반복합니다.

• 회사: “주도적으로 일하실 분”
• 지원자: “네, 주도적으로 하겠습니다”

결국 입사 후에야 서로의 기대가 달랐다는 걸 알게 되고요.

그래서 저는 가능하면 JD에 성과 기준(Outcome)을 넣습니다.
거창한 KPI까지 확정하라는 의미가 아니라, 최소한 초기 90일의 기대치라도 쓰자는 거예요.

1) 30/60/90일 기대치를 JD에 쓰면 좋은 점

• 지원자 입장: “내가 첫 3개월 동안 무엇을 해야 하는지”가 보이니까, 자기 경험을 기반으로 지원 여부를 판단합니다.
• 회사 입장: 면접이 훨씬 구체화됩니다. “주도성”을 말로 평가하는 게 아니라, “이 상황에서 60일 내 무엇을 정리할 건지”를 묻게 되니까요.

2) 제가 JD에 자주 쓰는 30/60/90 템플릿 (복붙용)

아래는 회사/제품 상황을 크게 안 가리는 형태라서, 대부분의 PM JD에 붙일 수 있어요.

• 30일: 제품/고객/데이터/내부 프로세스 이해, 이해관계자 맵 정리, 문제 리스트 작성
• 60일: 핵심 문제 1~2개를 우선순위로 합의, 가설/지표 정의, 실행 계획(로드맵) 제안
• 90일: 최소 1개의 개선을 배포/적용하고, 지표 변화 또는 학습 결과를 공유(다음 사이클 제안)

여기서 중요한 건 “무엇을 만들었는가(산출물)”보다 “무엇이 바뀌었는가(결과/학습)”예요.

3) Output(산출물) 대신 Outcome(결과)로 쓰는 문장 예시

(Bad) 산출물 중심 문장

• “PRD 작성 및 기능 기획”
• “정기 리포트 작성”

(Good) 결과 중심 문장

• “사용자 이탈이 큰 구간을 정의하고, 8주 내 전환율 개선 실험을 1회 이상 실행합니다.”
• “영업→온보딩 전환이 막히는 병목을 정리하고, 90일 내 리드타임을 줄일 실행안을 제안합니다.”

4) 지표를 못 박기 어렵다면, ‘지표의 종류’라도 말해요

PM JD에서 지표를 확정하기 어려운 경우가 많잖아요. 그럴 땐 이런 식으로라도 쓰면 충분히 도움이 됩니다.

• “이 역할은 ‘기능 출시’가 아니라, (전환/리텐션/활성화/리드타임/매출) 중 최소 1개의 지표 개선을 목표로 합니다.”

이렇게만 적어도 지원자는 “아, 여기 PM은 결과로 이야기하는 회사구나”라고 읽습니다.

다음 섹션에서는, 이 맥락(Why)과 문제(Problem)와 임팩트(Impact)를 JD에 어떻게 구조로 만들면 좋은지, 제가 실제로 쓰는 템플릿을 공유해볼게요.

Step 4) 지원자가 스스로 걸러지게 만드는 JD 구조(Why-Problem-Impact)

여기까지 정리하면, JD에 들어갈 재료는 거의 준비가 됩니다.

• 문제 문장(Problem)
• 책임 경계(R&R)
• 성과 기준(초기 90일 기대치)

이제 이걸 어떻게 배치하느냐의 문제인데요. 저는 PM JD를 쓸 때 Why-Problem-Impact 구조를 가장 많이 씁니다.

왜냐면 PM은 “무슨 일을 하냐(What)”보다, “왜 이 일이 지금 중요하냐(Why)”에 반응하는 직군이더라고요.
그리고 Why가 분명하면, 지원자가 스스로 “나랑 맞는다/안 맞는다”를 더 정확히 판단합니다.

1) PM JD 템플릿 (제가 실제로 쓰는 순서)

아래 순서로 쓰면, 템플릿 냄새가 덜 나고 ‘회사 맥락’이 드러납니다.

1. Why (맥락): 지금 우리 회사/제품이 어디에 있고, 왜 이 포지션이 필요한지
2. Problem (미션): PM이 풀어야 할 문제를 한 문장으로
3. Impact (기대 결과): 90일/6개월 내 어떤 변화를 만들면 성공인지
4. R&R (경계): 우선순위/결정권/협업 방식
5. Signals (자격요건): 스킬 나열이 아니라 신호
6. Process (검증): 면접/과제/레퍼런스 등

2) JD 문장 예시 (바로 가져다 쓸 수 있게)

Why 예시

• “우리는 지금 (0→1 / 1→10 / 10→100) 단계에 있고, 최근 (병목/변곡점)이 생겼습니다.”
• “기능 출시 속도는 빠른데, (전환/리텐션/온보딩)에서 기대한 만큼 성과가 나지 않아 문제를 재정의할 PM이 필요합니다.”

Problem 예시

• “(고객/사용자)에게서 반복되는 (불편/이탈/비효율)을 정의하고, 8주 내 개선 실험을 최소 1회 이상 실행합니다.”
• “(영업/CS/운영)에서 들어오는 요구를 그대로 받는 것이 아니라, 제품 목표에 맞춰 우선순위를 재정리합니다.”

Impact 예시

• “90일 내 (핵심 지표) 개선의 방향성과 첫 결과(또는 학습)를 제시합니다.”
• “6개월 내 (프로세스/지표)에서 ‘팀이 납득하는 기준’을 만들고 반복 가능한 운영 루틴을 제안합니다.”

R&R 예시 (저는 이걸 꼭 넣어요)

• “PM은 ‘무엇을/왜’를 책임지고, ‘어떻게(구현)’는 개발/디자인과 함께 결정합니다.”
• “PM은 이해관계자의 의견을 수집하지만, 모든 요청을 그대로 수용하지 않습니다. 제품 목표 기준으로 조정합니다.”

3) (조금 민감하지만) JD에 ‘안 맞는 사람’도 써주는 편이에요

저는 요즘 JD에 이런 문장을 한 줄 넣습니다.

• “다양한 이해관계자 의견을 모두 만족시키는 역할을 기대하신다면, 이 포지션과 맞지 않을 수 있습니다.”
• “정답이 정해진 실행만 편하게 하고 싶으시다면, 이 역할은 스트레스가 클 수 있습니다.”

처음엔 “지원자 줄어들면 어떡하지?” 싶었는데요.
오히려 면접 소모가 줄고, 합격 이후 만족도가 올라가더라고요.

다음 섹션에서는, 자격요건을 어떻게 써야 “스킬 나열 JD”를 피하면서도 우리 회사의 기준을 분명히 드러낼 수 있는지 이야기해볼게요.

Step 5) 자격요건을 '스킬 나열'이 아니라 '신호'로 바꾸기

PM JD에서 제일 흔한 함정이 “자격요건”이더라고요.

• “SQL 가능”
• “Jira/Confluence 능숙”
• “Figma 사용 경험”
• “OO 도메인 경험 3년 이상”

저도 이런 리스트를 붙여본 적이 있는데요. 시간이 지나면서 느낀 건 이거였어요.

툴은 ‘경험의 표면’이고, 우리가 진짜 보고 싶은 건 ‘신호(signal)’더라고요.

1) Must / Prefer를 나눌 때 제가 쓰는 기준

저는 Must/Prefer를 이렇게 나눕니다.

• Must: 없으면 리스크가 너무 커서, 채용 실패 확률이 올라가는 것
• Prefer: 있으면 속도가 빨라지지만, 없다고 실패하진 않는 것

예를 들어 “도메인 경험”은 대부분 Prefer에 가깝습니다.
반대로 “우선순위 판단을 근거로 설명하는 능력”은 Must에 가깝고요.

2) PM 자격요건을 ‘신호’로 바꾸는 예시

아래는 제가 자격요건을 쓸 때 자주 쓰는 변환입니다.

(Bad) 스킬/툴 나열

• “Jira로 티켓 관리 가능자”
• “데이터 분석 가능자”

(Good) 신호로 표현

• “우선순위 결정을 근거(고객/데이터/비즈니스)로 설명할 수 있는 분”
• “지표를 ‘보고서’가 아니라 의사결정 도구로 쓰는 분(가설→지표→실험→학습)”
• “갈등 상황에서 ‘좋은 말’보다 결정의 기준을 세워 합의를 만들어본 경험이 있는 분”

툴은 이 신호를 증명하는 하나의 수단일 뿐이니까요.

3) 회사 상황별로 JD에서 강조할 ‘신호’가 달라요 (표로 정리)

‘우리 회사에 맞는 JD’는 결국 여기서 갈립니다.

우리 회사 상황	JD에서 강조할 Must 신호	Prefer 신호
0→1, 문제부터 불명확	문제정의/가설검증, 빠른 실험, 모호함을 구조화	특정 도메인 경험
성장(1→10), 우선순위 전쟁	우선순위/정렬, 이해관계자 조율, 지표 기반 의사결정	특정 툴 숙련
확장(10→100), 복잡성/레거시	프로세스 설계, 의사결정 구조화, 운영 체계	대기업 경험
B2B, 고객/세일즈 협업 중요	고객/세일즈 정렬, 요구 수집→제품화, 기대치 관리	산업군 네트워크

이 표를 JD에 그대로 넣어도 좋고, 최소한 내부 합의용으로라도 만들어두면 자격요건이 덜 흔들립니다.

4) 마지막 팁: “있으면 좋다”를 최소화하고, “왜 필요한지”를 붙이세요

제가 자격요건을 쓸 때 자주 붙이는 문장이 있어요.

• “우리가 이 역량을 요구하는 이유는 (현재 병목/리스크) 때문입니다.”

이 한 줄이 붙으면, 지원자는 요구사항을 ‘벽’이 아니라 ‘맥락’으로 읽습니다.

다음 섹션에서는, JD를 이렇게까지 잘 써도 남는 문제(‘진짜 일하는 방식은 어떻게 검증하지?’)를 다뤄볼게요. 저는 여기서 과제/면접/레퍼런스를 같이 설계하는 편입니다.

Step 6) JD 이후가 더 중요해요: 과제·면접·레퍼런스로 검증 설계

여기까지 오면 JD는 꽤 “우리 회사에 맞게” 정리됐을 거예요.

그런데 HR 입장에서 진짜 어려운 건 그 다음이더라고요.

“JD를 잘 읽고 지원한 이 사람이, 실제로도 우리 팀에서 잘 일할까?”

PM은 특히 그렇습니다.
혼자 잘하는 사람보다, 개발/디자인/사업/CS 사이에서 신뢰를 쌓고 갈등을 처리하는 방식이 성과를 좌우하잖아요. 그런데 이건 JD나 이력서만으로는 잘 안 보입니다.

그래서 저는 JD 이후에 ‘검증 장치’를 3개로 나눠 설계합니다.

1. 워크샘플(과제): 실제 업무 유사 상황에서의 사고/우선순위/커뮤니케이션을 본다
2. 구조화 면접: 질문을 표준화해서 “말 잘함”을 줄인다
3. 구조화 레퍼런스(평판조회): 팀에서의 실제 행동을 확인한다

1) 과제(워크샘플) 설계할 때 꼭 지키는 3가지

과제는 잘 쓰면 신호가 강한데, 잘못 쓰면 지원자를 잃습니다. 저는 이 3가지를 고정해요.

• 시간 제한: 2~3시간 이내(“주말에 10시간”은 거의 탈락 신호로 읽힘)
• 평가 기준 공개: 무엇을 보려는지(문제정의/우선순위/지표/커뮤니케이션) 미리 공개
• 현업과 유사한 ‘상황’: 정답을 맞히는 문제가 아니라, 판단의 근거를 보는 문제

과제 주제는 이런 게 현실적으로 좋더라고요.

• “요청이 10개 들어왔는데 리소스는 2주치뿐일 때, 무엇부터 왜 할 건지”
• “지표가 꺾였을 때, 1주 안에 무엇을 확인하고 누구와 어떻게 정렬할지”

2) 구조화 면접 질문 예시 (PM용)

‘우리 회사에 맞는 PM’은 보통 아래에서 갈립니다.

• “마지막으로 우선순위 충돌을 해결했던 경험을 말해 주세요. 누가 반대했고, 어떤 기준으로 결정했고, 결과가 어땠나요?”
• “데이터가 부족한 상황에서 결정을 내려야 했던 경험이 있나요? 무엇을 가정했고, 무엇을 확인했고, 무엇을 포기했나요?”
• “이해관계자 요구를 그대로 받아주지 못했던 경험이 있나요? 어떻게 설명했고, 관계는 어떻게 관리했나요?”

질문 자체는 흔한데, 꼬리질문을 표준화하면 면접의 편차가 줄어듭니다.

3) 레퍼런스(평판조회)는 ‘질문’이 아니라 ‘설계’가 핵심이에요

레퍼런스 체크를 “한 번 전화 돌려보자”로 하면, 대부분 칭찬만 듣고 끝나더라고요.
저는 레퍼런스를 할 거면 아예 구조화합니다.

그리고 레퍼런스 체크 부분에서, 최근에는 이 과정을 내부 인맥에 의존하기보다 동의 기반으로 구조화된 방식으로 진행하려는 회사들도 늘어나고 있습니다.

예를 들어 스펙터 AI 기반 평판조회나 스펙터 TEO(테오) 같은 서비스는, 후보자의 동의를 기반으로 실제 협업 경험이 있는 사람들에게 구조화된 질문을 보내 데이터를 수집하는 방식이라 HR 입장에서도 부담이 줄어들더라고요.

결국 중요한 건 방식보다, “좋은 사람이었다”가 아니라 실제 행동 데이터를 확인하는 구조를 만드는 것이라고 느낍니다.

제가 PM 레퍼런스에서 꼭 묻는 질문 5개는 이거예요.

1. 갈등 상황: “의견 충돌이 났을 때, 이 사람이 보통 어떻게 행동했나요?”
2. 우선순위: “요청이 많을 때, 무엇을 기준으로 거절/선택했나요?”
3. 협업 태도: “개발/디자인과 일할 때, 어떤 점이 편했고 어떤 점이 어려웠나요?”
4. 신뢰: “다시 한 팀으로 일하자고 제안이 온다면, 같이 일하시겠어요? (이유 포함)”
5. 리스크: “이 사람을 채용한다면, 첫 60일에 무엇을 도와주면 실패 확률이 줄까요?”

이 질문들은 “좋은 사람입니다” 같은 평가보다, 구체적인 행동을 끌어내는 데 도움이 되더라고요.

그리고 여기까지 설계해두면, JD에서 약속한 ‘우리 회사의 기준’이 실제 채용 과정에서도 유지됩니다.
결국 좋은 채용은 JD만으로 끝나지 않고, 검증 시스템까지 같이 가야 하더라고요.

마무리: 좋은 JD는 '약속문', 좋은 채용은 '검증 시스템'

오늘 내용을 한 문장으로 요약하면 이거예요.

우리 회사에 맞는 PM JD는 ‘업무를 예쁘게 나열한 글’이 아니라, 회사와 지원자 사이의 ‘약속문’이에요.

그 약속문이 지켜지려면, 최소한 아래 순서가 필요하더라고요.

• 문제(Problem)를 한 문장으로 고정하고
• R&R(책임 경계)과 결정권을 명확히 하고
• 성과 기준(특히 90일 기대치)을 말해주고
• Why-Problem-Impact 구조로 자기선택을 만들고
• 자격요건을 스킬이 아니라 ‘신호’로 쓰고
• 과제/면접/레퍼런스로 검증을 설계한다

마지막으로, 제가 JD 올리기 전에 체크하는 7문장 체크리스트를 남겨볼게요. (진짜 복붙용입니다.)

• “우리 PM이 풀어야 할 문제를 한 문장으로 말할 수 있다.”
• “이 역할의 성공 기준(Outcome)을 최소 1개는 말할 수 있다.”
• “우선순위는 누가 결정하고, PM은 어디까지 권한이 있는지 말할 수 있다.”
• “PM이 ‘일정관리 담당자’로 오해받지 않게 문장을 정리했다.”
• “Why-Problem-Impact가 JD 앞부분에 드러난다.”
• “Must/Prefer가 ‘리스크 vs 속도’ 기준으로 구분되어 있다.”
• “JD 이후 검증(과제/면접/레퍼런스)의 질문과 기준이 준비되어 있다.”

여기까지 준비하면, 적어도 “지원자는 많은데 계속 안 맞는다”는 소모가 줄어듭니다.
그리고 무엇보다, 지원자도 덜 힘들어하더라고요. JD에서부터 기대치가 정렬되니까요.

그리고 실제 채용 과정에서 JD 작성부터 검증 과정까지 구조화하고 싶다면, 최근에는 스펙터 TEO(테오) 같은 솔루션을 활용해 JD 작성 이후 채용 데이터 관리나 평판 기반 의사결정을 함께 정리하는 팀들도 늘고 있습니다.

채용을 진행하다 보면 느끼지만, 결국 중요한 건 툴이 아니라 우리 조직이 어떤 기준으로 사람을 선택할지 명확히 하는 것이더라고요.

스펙터 AI 기반 채용 및 평판조회 방식이 궁금하다면 아래에서 한 번 살펴보셔도 좋을 것 같습니다.

👉 스펙터 TEO(테오) 소개
👉 스펙터 기업 서비스 안내

혹시 지금 채용 중인 PM 포지션이 있다면, 딱 한 가지 질문만 던져보고 싶어요.

“우리 회사가 진짜 원하는 PM은, ‘무슨 일을 하는 사람’이 아니라 ‘어떤 문제를 책임지는 사람’인가요?”