편집자 주: 시리즈 B에서 IPO로 제품 관리 확장에 대한 시리즈의 세 번째 부분입니다. 첫 번째와 두 번째 부분 읽기 여기에서 지금 확인해 보세요. 과 여기에서 지금 확인해 보세요..

성공적인 조직(제품 및 기타)은 고객에게 매우 집중되어 있습니다. 이 초점이 사라지면 다음과 같은 문제가 발생합니다.

• 일관되지 않은 제품 경험
• 낮은 NPS
• UX 감소 및
• 낮은 사용자 및/또는 고객 유지.

Series B에서 IPO로 확장할 때 고객 중심으로 전환하는 것은 종종 올바른 문제와 프로젝트를 추구하는 것처럼 보입니다. 회사가 성장하고 지분이 증가함에 따라 오류의 여지가 줄어듭니다. R&D 시간을 어디에 투자하느냐가 중요하며 최대 효과를 내는 투자를 선택해야 합니다. 고객 우선 조직을 구축하면 올바른 선택을 할 가능성이 높아집니다.

SendGrid의 제품 관리 VP 및 GitLab의 CPO로서의 경험을 통해 고객과 사용자에게 초점을 유지하는 것이 초성장의 부담을 견딜 수 있는 제품을 만드는 방법을 직접 보았습니다. 고객 중심의 진정한 의미는 다음과 같습니다.

a) 누구를 위해 건물을 짓고 있는지 알고
b) 문제를 효과적으로 해결하는 것을 구축합니다.

둘 다 제대로 하려면 문제 및 솔루션 검증 프레임워크를 설정하고, 고객을 인터뷰하고, 조직도 배송을 피하고, 검증 결과를 사용하여 자신 있게 거절해야 합니다.

1. 문제 및 솔루션 검증 프레임워크 구축

SendGrid와 GitLab 모두에서 우리가 구축한 것과 구축하지 않은 것을 안내하는 명확한 문제 및 솔루션 검증 프로세스를 확립했습니다. 제안된 솔루션이 심각한 고객 문제를 효과적으로 해결할 것이라고 확신한 후에야 개발을 시작할 수 있었습니다.

확신이 없으면 검증 프로세스를 계속하거나 아이디어를 폐기해야 했습니다.

특히 GitLab에서는 제품 개발 흐름을 유효성 검사와 빌드라는 두 가지 트랙으로 나누었습니다. 이 두 트랙은 서로 독립적으로 이동하지만 주요 프로젝트 또는 기능은 유효성 검사를 성공적으로 통과할 때까지 빌드 트랙에 들어갈 수 없습니다. 에 따르면 GitLab 핸드북, 유효성 검사 트랙의 목표는 다음과 같습니다.

• 알다 우리가 해결하려는 사용자 문제
• 확인 성공을 결정하는 비즈니스 목표 및 주요 지표
• 생성 가설 및 연구/실험/사용자 테스트
• 밝히다 MVC(Minimum Viable Change) 디자인 패턴 및 잠재적인 향후 반복
• 최소화 정성 및 정량 분석을 통한 가치, 사용성, 타당성 및 사업 가능성에 대한 위험

새롭거나 크거나 잘 이해되지 않는 문제 영역의 경우 PM은 UXer와 협력하여 문제를 깊이 이해합니다. 이 단계는 일반적으로 대상 사용자와 최소 XNUMX번의 문제 인터뷰를 수행한 다음 프로젝트의 한 페이지 요약을 캡처하는 것으로 구성됩니다. 기회 캔버스, 제품 및 디자인 리더십으로 검토됩니다. 승인된 캔버스 검토는 솔루션 검증으로 진행됩니다.

Solution Validation에서 디자이너는 문제에 대한 솔루션을 구상하기 위해 올바른 프로토타입을 생성함으로써 주도권을 잡습니다. 그런 다음 디자이너와 PM은 대상 사용자와 최소 XNUMX회 이상의 인터뷰를 수행하여 프로토타입 디자인이 사용자의 문제를 충분히 해결하는지 확인합니다. 여기에서 프로젝트는 빌드 트랙으로 들어갑니다.

2. 고객 인터뷰를 최우선으로 한다

SendGrid에서 처음 18개월 동안 저는 ~100명의 고객을 만났습니다. GitLab에서 처음 XNUMX분기 동안 나는 제품 조직의 OKR 중 하나인 "PM당 완료된 고객 인터뷰 ​​수"를 만들었습니다. 이를 통해 저와 제품 조직은 고객이 누구이고 고객이 원하는 것이 무엇인지에 대한 견고한 기본 지식을 얻을 수 있었습니다. 이 연구는 조직 수준의 개발 우선 순위를 알려주고 팀 간에 귀중한 통찰력을 공유할 수 있게 했으며 신뢰를 구축했습니다.

알아두어야 할 사항에 대해 의도적이지 않거나 질적 인터뷰 모범 사례를 따르지 않는 경우 고객과 대화하는 데 소요되는 시간은 낭비될 수 있습니다. 고품질 인터뷰를 수행하는 것은 필수 PM 기술이므로 SendGrid에서는 전체 팀이 Cooper Design의 정성적 인터뷰 교육에 참여했으며 GitLab에서는 대부분의 팀이 다음과 같은 우수한 원격 과정을 수강했습니다. 지속적인 인터뷰 테레사 토레스에서. 고객 인터뷰를 통해 팀 전체를 능숙한 수준으로 끌어올리는 것은 각 팀원이 귀중한 고객 인터뷰 ​​시간에서 얻은 통찰력의 품질을 극대화할 수 있었기 때문에 막대한 배당금을 지불했습니다.

모범 사례 제안 인터뷰

각 고객과 함께 진행해야 할 질문 목록을 작성하여 이러한 인터뷰를 준비했습니다. 이러한 일관성 덕분에 인터뷰 대상자 간에 통찰력을 교차 확인할 수 있었습니다. 여러 사람이 모두 같은 것을 꺼낸다면 훨씬 더 큰 고객 세그먼트에서 그들의 감정을 공유할 수 있다는 좋은 표시입니다.

기타 모범 사례 제안은 다음과 같습니다.

• 개방형 질문을 하세요 예/아니오 또는 선행 질문을 피하십시오.
• 그들이 실제로 한 일을 설명하도록 요청하십시오. 그들이 하고자 하는 일보다
• 문제 면접의 경우, 끝까지 문제에 대한 해결책을 제시하지 마십시오. 만약에
• 솔루션 인터뷰의 경우, 인터랙티브 프로토타입 가져오기 안내나 지시 없이 프로토타입을 사용하여 의도한 문제를 해결하도록 요청하고 경험에 대한 느낌과 반응에 대해 큰 소리로 이야기합니다.
• 부정적이거나 가혹한 피드백은 괜찮다고 인터뷰 대상자를 안심시키십시오. 그리고 당신을 모욕하는 것에 대해 걱정하지

인터뷰 물류 및 일정에서 마찰 제거

많은 PM이 충분한 인터뷰를 수행하지 않는 한 가지 이유는 고객 인터뷰를 식별, 소싱, 예약 및 수행하는 것이 논리적으로 어렵기 때문입니다. 팀 구성원을 위해 프로세스에서 마찰을 제거하기 위해 제품 리더로서 할 수 있는 모든 작업을 수행하십시오. SendGrid와 GitLab에서 우리는 인터뷰를 위해 고객을 소싱하고 예약하는 데 도움을 주는 UX 코디네이터를 고용하기로 했습니다.

도움을 줄 전담 직원을 고용할 수 없는 경우 인터뷰에 응할 고객/잠재 고객의 데이터베이스를 유지 관리하거나 고객이 제품에서 직접 인터뷰 슬롯에 등록할 수 있도록 하는 등 프로세스를 자동화하거나 단순화하는 다른 방법을 고려하십시오. 제품 팀을 위한 영업/고객 성공 라인업 인터뷰가 있습니다.

3. 조직도를 보내지 마세요

회사에 반복 가능한 검증 프로세스가 없으면 중요하지 않은 것을 구축하기가 훨씬 쉽습니다. 내가 자주 보는 한 가지는 PM 팀이 조직도를 배송하기 시작한다는 것입니다. 고객의 사용 사례를 고려하지 않고 자신이 소유한 모든 영역에 최적화된 제품을 구축할 때의 모습입니다.

CA Technologies에서 제품 관리 선임 이사로 재직했을 때 저는 XNUMX개 제품 영역의 융합으로 형성된 새로운 사업부의 일원이었습니다. 우리의 목표는 고객이 이 사업부가 존재하는 이유를 이해하도록 돕는 것이었고, 이 네 가지 제품 라인 간의 시너지 효과를 정말로 원했습니다. 우리는 우리의 모든 문제를 해결할 것이라고 생각하는 아이디어를 생각해 냈습니다.

그것은 종이에 멋져 보였다. 사업부가 존재하는 이유를 명확하게 설명했고 고객에게 흥미로울 것 같았습니다. 그런 다음 모든 기능을 통합하는 제품 기능을 구상하고 즉시 구축에 착수했습니다.

통합은 우리가 의도한 대로 교차 판매를 유도하지 않았습니다. 아무도 그것을 사용하지 않았습니다. 아무도 신경 쓰지 않았기 때문입니다. 그들은 네 가지 제품이 어떻게 함께 작동하는지 묻지 않았습니다. 그것이 그들에게 진짜 문제를 해결했는가? 대답은 아니오였습니다.

내부 구조가 아닌 사용 사례에 집중

각 제품 관리자가 자신의 제품 조각을 보고 있으면 팀 간에 이음새가 나타나기 시작합니다. PM 또는 디자이너로서 귀하는 자신이 소유한 영역에서 결과를 도출하도록 동기를 부여받습니다. 반드시 전체 제품에 걸쳐 더 광범위한 결과를 가져오는 것은 아닙니다. 제품 부서 전체에서 이러한 일이 발생하면 단절된 느낌의 제품 경험을 얻게 됩니다.

GitLab에서 우리의 주요 기능 중 하나는 병합 요청이었고 여러 팀이 이에 기여했습니다. 어느 시점에서 우리는 이 기능의 성능이 느려지고 복잡한 UX로 인해 어려움을 겪고 있음을 깨달았습니다. 우리는 UX 연구팀이 팀 경계를 무시하고 사용 사례에 집중하라는 특정 지침과 함께 병합 요청 기능을 감사하도록 했습니다.

팀은 사용자 여정 내에서 좋은 경험과 나쁜 경험을 정확히 찾아내는 사용자 여정 맵을 구축했습니다. 그런 다음 우리는 열악한 경험 수정 사항을 이를 소유한 팀에 할당하고 시간이 지남에 따라 사용 사례 수준에 집중하여 엔드 투 엔드 경험을 개선할 수 있었습니다.

4. 검증 프로세스를 사용하여 자신 있게 거절하십시오.

SendGrid에서 우리는 타이트한 배를 운영했습니다. 비즈니스는 초고속으로 확장되어 하루에 수십억 개의 이메일을 전달해야 하는 제품이 필요했습니다. 시스템의 모든 측면을 막대한 수준으로 확장해야 하는 환경에서 엔지니어링은 "두 번 측정하고 한 번 자르는" 사고 방식을 가졌습니다. 이러한 수준의 엄격함과 면밀한 조사는 개발 프로세스에 시간이 걸리고 제품 조직이 우리가 엔지니어링 팀에 구축하도록 요청한 항목에 대해 매우 선별적이어야 한다는 것을 의미했습니다. 따라서 개발 팀의 많은 시간과 에너지를 소비했을 수 있는 항목을 일찍 폐기했습니다. . 문제 면에서는 약 절반만이 유효성 검사 프로세스를 통과했습니다.

예를 들어, 한 임원은 여러 통화를 허용하도록 셀프 서비스 구매 흐름을 업그레이드하도록 요청했습니다. 이 사람은 이전 회사에서 유사한 프로젝트를 실행했으며 많은 성공을 거두었습니다. 우리는 프로젝트를 검증하고 현지 통화를 제공하고 싶다고 생각한 여러 국가의 잠재 고객을 인터뷰했습니다. 우리가 배운 것은 미국 달러로 지불하는 것이 심각한 문제가 아니라는 것입니다. 대부분의 고객은 영어에 능통했고 USD로 신용 카드로 물건을 사는 데 익숙했습니다.

물론, 추가 통화를 수용할 수 있는 좋은 기능이었지만 현재 설정이 사람들의 구매 결정에 실질적으로 영향을 미치지 않는다는 것을 알았습니다. 그들은 단지 최고의 제품을 사려고 했습니다. 추가 통화를 제공함으로써 증가하는 수익은 구현하는 데 값비싼 가격표를 적용할 가치가 없었을 것이므로 우리는 거절했습니다.

제품 리더 및 초기 단계 창업자를 위한 주요 내용

1. 고객을 알아가는 데 시간을 할애하십시오. 제품 리더로서 누구를 위해 구축하고 있으며 그들의 문제를 깊이 이해하면 경영진 수준의 우선 순위를 안내하는 데 도움이 될 뿐만 아니라 팀 전체에서 신뢰를 구축할 수 있습니다.
2. 명확한 문제 및 솔루션 검증 프로세스를 통해 대규모 프로젝트를 실행합니다. 특히 규모가 크면 고객이 신경쓰지 않는 것을 구축하거나 고객의 문제를 적절하게 해결하지 못하는 솔루션을 출시할 시간이 없습니다. 검증 프레임워크는 PM 조직 문화에서 고객 중심을 확고히 합니다.
3. 조직도를 배송하지 마십시오. 팀이 소유한 모든 영역에 최적화된 제품을 구축하는 대신 여러 팀의 기여가 필요한 경우에도 고객의 사용 사례에 집중하십시오.
4. 검증 프로세스를 사용하여 자신 있게 거절하십시오. 추구하는 프로젝트와 기능에 대해 더 자세히 조사할수록 더 좋습니다. 다시 가리키는 검증 프로세스가 확립되어 있으면 의사 결정을 다른 팀에 전달하는 데 도움이 될 수 있습니다.

Scaling Product Management 시리즈의 다음 기사를 주목하십시오. 구독하기 OpenView 뉴스레터 그리고 나와 연결 링크드인 가장 먼저 알기 위해!

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• PlatoAiStream. Web3 데이터 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 미래 만들기 w Adryenn Ashley. 여기에서 액세스하십시오.
• PREIPO®로 PRE-IPO 회사의 주식을 사고 팔 수 있습니다. 여기에서 액세스하십시오.
• 출처: https://openviewpartners.com/blog/scaling-product-management-part-3-establishing-a-customer-first-org/