오늘 한 일
오늘은 PRD 문서를 다듬으면서, 페르소나 선정 기준과 데이터 기반 가설의 흐름을 다시 점검했다.
처음에는 내가 중요하다고 생각하는 기준을 세우고, 그 기준에 따라 페르소나나 핵심 변수를 고르면 충분하다고 생각했다. 하지만 문서를 다시 보면서 깨달은 것은, 기준 자체보다 중요한 것은 그 기준이 독자에게도 납득 가능한가였다.
특히 과제나 포트폴리오처럼 실제 기업 내부 데이터를 모두 알 수 없는 상황에서는, 내가 만든 기준이 자의적으로 보이지 않도록 더 조심해야 한다. “이 기준이 좋아 보인다”가 아니라, 왜 이 기준으로 판단하는 것이 합리적인지를 설명해야 문서가 설득력을 가진다.
⸻
배운 점 1. “좋아 보이는 기준”보다 “왜 이 기준이어야 하는지”가 더 중요하다
Before
페르소나를 고를 때는 전환율, 임팩트, 원인 명확성 같은 기준을 적당히 세우면 된다고 생각했다.
예를 들어 특정 페르소나가 중요해 보이면, 그 이유를 “전환 가능성이 높다”, “비즈니스 임팩트가 크다”, “문제가 명확하다” 정도로 설명하면 충분하다고 생각했다.
After
오늘 느낀 것은, 기준 자체보다 더 중요한 것은 그 기준이 자의적이지 않게 보이는 것이었다.
내가 중요하다고 생각해서 만든 기준은, 독자 입장에서는 “왜 그 기준으로 봐야 하지?”라는 질문을 만들 수 있다. 특히 실제 기업 맥락이 없는 과제에서는 더 그렇다.
그래서 기준을 세울 때는 내가 중요하다고 생각하는 이유만으로는 부족하다.
외부 관점, 데이터, 사용자 문제, 비즈니스 목표와 연결해서 누가 봐도 납득할 수 있는 판단 기준으로 만들어야 한다.
예를 들어 페르소나를 고를 때도 단순히 “이 사용자가 좋아 보인다”가 아니라,
- 이 사용자가 실제 문제를 가장 선명하게 보여주는가
- 해결안을 적용했을 때 행동 변화가 관찰 가능한가
- 비즈니스 목표와 연결되는가
- 지금 과제 범위 안에서 검증 가능한가
같은 기준으로 설명해야 한다.
So What
앞으로 과제든 포트폴리오든, 기준을 세울 때는 먼저 이렇게 확인해야겠다.
이 기준은 내가 중요하다고 생각해서 만든 것인가,
아니면 다른 사람에게 설명해도 납득 가능한 기준인가?
좋은 판단은 취향에서 나오는 것이 아니라, 설명 가능한 기준에서 나온다.
⸻
배운 점 2. “갑자기 왜 이 얘기?”가 들리면 중간 논리가 빠진 것이다
Before
문서를 쓸 때, 내가 알고 있는 연결고리는 독자도 자연스럽게 따라올 것이라고 생각했다.
내 머릿속에서는 데이터와 결론이 연결되어 있기 때문에, 문서에서도 바로 결론을 제시해도 괜찮다고 생각했다.
After
오늘 가장 많이 수정한 부분이 바로 이 지점이었다.
예를 들어 “리뷰 클릭 여부가 핵심 변수다”라는 결론 자체는 맞을 수 있다. 하지만 그 전에,
여러 행동 변수를 비교했고,
그중 리뷰 클릭 여부에서 가장 큰 차이가 나타났다.
라는 단계가 없다면, 독자는 바로 이렇게 느낄 수 있다.
왜 갑자기 리뷰 클릭이 중요하지?
즉 결론이 틀린 것이 아니라, 결론까지 가는 중간 다리가 부족했던 것이다.
문서에서 설득력은 결론의 정답 여부만으로 만들어지지 않는다. 독자가 그 결론까지 자연스럽게 따라올 수 있어야 한다.
그래서 앞으로 문서를 쓸 때는 다음을 더 점검해야겠다.
- 지금 결론이 왜 나왔는지 앞 문장에서 설명했는가
- 데이터 → 해석 → 판단 → 제안의 순서가 끊기지 않는가
- 독자가 중간에 “갑자기 왜?”라고 느낄 만한 지점은 없는가
- 내가 머릿속으로만 알고 있는 연결고리를 문서에 써두었는가
So What
앞으로는 내 결론이 맞는지만 보지 않고, 독자가 그 결론까지 무리 없이 따라올 수 있는지를 더 보려고 한다.
설득은 정답을 제시하는 것이 아니라, 중간 다리를 놓는 것이다.
⸻
오늘의 한 줄
오늘의 배움은 새로운 개념을 더 배운 것이 아니라, 문서가 설득되는 방식 자체를 더 정교하게 이해한 것에 가까웠다.
좋은 문서는 좋은 결론만으로 완성되지 않는다.
기준이 왜 합리적인지 설명하고, 독자가 결론까지 따라올 수 있도록 중간 논리를 놓아야 한다.
앞으로는 문서를 쓸 때마다 이렇게 점검하겠다.
기준은 설명 가능한가?
결론까지 가는 중간 다리는 충분한가?
이 두 가지를 지키는 것이, 더 설득력 있는 PM 문서를 만드는 기본이 될 것 같다.
