Back to Blog
SuperPM Blog/Prompt Guide

제품팀 헬스 체크를 돌리고 개선 계획 만들기(Run a product team health check and build an improvement plan)

기능은 계속 shipping하고 있지만 뭔가 어긋난 느낌이 들고, 회고는 식상하며, 사기는 떨어지고, 크로스펑셔널 협업이 점점 어려워질 때 쓰는 프롬프트입니다. 제품팀 효과성을 8개가 아니라 12개 세부 차원에서 구조적으로 진단하고, 목표가 있는 개선 계획을 만듭니다.

Discovery
20 uses·Published 3/27/2026·Updated 4/2/2026

아무도 말하지 않지만, 너무 늦고 나서야 드러나는 팀 건강 문제

제품팀은 하루아침에 망가지지 않습니다. 천천히 부식됩니다. 한 번 건너뛴 회고, 한 번 무시된 갈등, "이번 데드라인만 넘기고 프로세스를 고치자"가 영구화되는 한 분기 같은 방식으로요. 리더십이 문제를 알아차릴 때쯤이면 이미 늦은 경우가 많습니다. 상위 퍼포머는 마음이 떠났고, 남은 팀은 안에서 스스로 진단하기 어려운 패턴에 갇혀 있습니다.

Google의 Project Aristotle 연구에 따르면 팀 효과성을 가장 강하게 예측하는 요인은 psychological safety입니다. 실수하거나 우려를 제기해도 처벌받지 않을 것이라는 믿음입니다. 그런데 Atlassian의 2024년 설문에서는 제품팀 구성원 중 단 31%만이 매니저의 제품 결정에 반대 의견을 내는 것이 "매우 안전하다"고 느낀다고 답했습니다.

즉흥적 회고만으로는 충분하지 않은 이유

대부분의 팀은 스프린트 회고에 팀 건강을 맡깁니다. 문제는 회고가 최근 사건("이번 sprint가 힘들었던 이유는...")에 초점을 맞춘다는 점입니다. 고객 연결 점수가 지속적으로 낮은 팀은 마감 놓친 sprint 회고 안에서는 그 문제가 잘 드러나지 않을 수 있습니다. 지금 머릿속에 가장 크게 남아 있는 것만이 아니라, 팀 건강의 여러 차원을 주기적으로 점검하는 구조화된 진단이 필요합니다.

Spotify는 여러 차원을 red/yellow/green으로 자가 평가하는 Squad Health Check 모델을 대중화했습니다. 힘은 점수 자체보다, 그 점수가 촉발하는 대화에 있습니다. 팀 전체가 "mission clarity"를 2/5로 평가하는 순간, 그것은 개인 불만 한두 개로는 나오지 않는 종류의 대화를 만들어냅니다.

이 Product Team Health Check 프롬프트의 작동 방식

이 프롬프트는 product & strategy, process & delivery, collaboration & culture, growth & sustainability라는 네 범주에 걸쳐 12개 차원을 평가합니다. 각 차원은 구체 기준과 함께 1-5점으로 점수화됩니다. Pattern analysis는 낮은 점수 항목을 theme으로 묶고 인과관계를 연결합니다. Improvement plan은 상위 3개 이슈에 대해 구체적 intervention, owner, metric을 붙입니다. Team agreement 단계는 개선안이 위에서 내려오는 처방이 아니라 팀이 공동으로 소유하는 계획이 되게 만듭니다.

실제 인사이트가 생기는 지점은 Step 2의 인과관계 맵핑입니다. 낮은 decision speed는 낮은 shipping cadence를 낳고, 그것이 낮은 morale을 만들고, 다시 낮은 psychological safety로 이어질 수 있습니다. 하위 증상만 고치고 decision speed를 건드리지 않으면 문제는 반드시 되돌아옵니다.

언제 사용할까

  • 팀이 함께한 지 3개월 이상 됐는데 structured health assessment를 한 번도 하지 않았을 때
  • 회고에서 늘 같은 주제가 나오는데 해결은 안 될 때
  • 팀 이탈이 늘고 있거나 engagement survey 점수가 떨어졌을 때
  • 최근 reorg가 있었고 새 팀의 baseline을 잡아야 할 때
  • PM vs. eng, design vs. PM 같은 cross-functional tension이 output quality에 영향을 주고 있을 때

흔한 함정

PM이 health check를 돌리고 모든 걸 "고쳐주려" 하는 것. 팀 건강은 공동 책임입니다. PM이 진단하고 계획하고 실행 과제를 모두 배정한다면, 오히려 문제를 만든 역학을 강화하게 됩니다. Ownership을 분산시키세요.

점수를 너무 후하게 주는 것. 팀이 계속해서 스스로를 4-5점으로 평가한다면, 정말 탁월하든지 아니면 현실을 회피하고 있는 겁니다. "이 팀을 뛰어난 친구에게 추천하겠는가?"라고 물으면 진짜 답이 나옵니다.

일회성 행사로 끝내는 것. 한 번의 health check는 문제를 발견합니다. 분기마다 반복하는 health check는 지속 개선 문화를 만듭니다. 한 번의 점수보다 추세가 더 중요합니다.

참고 자료

Sources

  1. Project AristotleGoogle re:Work
  2. Team Health MonitorAtlassian
  3. Squad Health Check ModelSpotify Engineering

Prompt details

Category
Discovery
Total uses
20
Created
3/27/2026
Last updated
4/2/2026

Ready to try the prompt?

Open the live prompt detail page for the full workflow.

View prompt details

More Discovery Guides