제품 전문성은 하룻밤 사이에 나타나지 않습니다. 전체 제품 개발 프로세스는 특정 기능 및 작동 방식에 대한 "전문가"를 만드는 것이며, 그 출시 이전 및 이후의 모든 문서의 기초입니다.
제품 활성화를 위한 Guru를 사용하는 팀은 전체 제품 출시 생애 주기에 걸쳐 지식의 단일 진실 출처를 갖는 것의 중요성을 인식합니다. 초기 개발부터 지속적인 지원 및 유지 관리까지. 모든 부서에 전문가가 검증한 정보를 놓을 수 있는 한 단일하고 신뢰할 수 있는 장소를 제공함으로써, 이러한 교차 기능 프로세스에 관여하는 모든 사람이 더 나은 작업을 수행할 수 있습니다. 제품 활성화의 실제 사례로 Guru에서 최근 기능 출시를 살펴보겠습니다.
1월 동안 newly formed Monetization pod는 Guru의 청구 경험을 업그레이드하기 위한 첫 부분에서 작업했습니다. 이 프로젝트에는 일반 제품 개발 팀—제품 관리, 디자인, 엔지니어링 및 제품 마케팅—뿐만 아니라 재무, 지원 및 영업 운영을 포함한 여러 다른 이해 관계자가 포함되었습니다. 이것은 모든 관련 팀 간의 긴밀한 소통과 조정이 필요로 하는 기술 업데이트였으며, 고객과의 대면 팀이 이러한 변경 사항에 대해 자신 있게 이야기할 수 있도록 상당한 사전 작업이 필요했습니다. 다음 세 가지 단계는 기능 출시와 같은 제품 활용을 위해 Guru를 사용하는 주요 방법을 요약합니다.
1단계: 기능 계획 및 개발
제품 활성화는 제품 팀의 프로젝트가 승인되는 순간부터 진정으로 시작됩니다. 이것은 사소한 기능 향상, 페이지 재설계 또는 완전히 새로운 기능일 수 있습니다. 프로젝트 사양이 제품 관리자(PM)에 의해 작성되고 그들의 엔지니어, 디자이너 및 다른 이해 관계자들과 공유되는 시점부터, 모든 사람은 다양한 저자의 신뢰할 수 있고 최신 문서에 접근할 수 있어야 합니다.
우리의 계획은 12월에 시작되었으며, PM들은 청구 및 체크아웃 경험 전반에 걸쳐 몇 가지 주요 장소를 식별했습니다. 이후 그들은 프로젝트 계획을 세우고 시리즈의 첫 프로젝트에 대한 초기 기능 사양을 작성하기 시작했습니다. 팀과 공유할 준비가 되었을 때, 그들은 팀을 이끌고 제안된 변경 사항에 대해 논의하고 타임라인을 논의하기 위해 킥오프 회의를 일정을 잡았습니다. 이 시점부터, 프로젝트에 관련된 모든 사람이 프로젝트 사양, 디자인, 관련 청구 문서 등을 포함한 모든 관련 문서에 접근할 수 있는 것이 매우 중요했습니다.
이 문서들은 자주 변경되며, 프로젝트 초기 단계 동안 자주 추가될 수 있기에, 팀이 돌아와서 검증된 진실 출처를 갖는 것이 중요합니다. 모두가 이러한 리소스를 공유하고 접근할 수 있는 단일 장소를 확보하기 위해, 우리는 팀과 공유할 Active Project Resources Card를 만들었습니다. 우리는 이것을 Monetization Pod Board 내에 두었으며, 모든 적절한 이해 관계자가 작성 권한을 갖습니다.
우리는 Guru에서 기능 출시를 팀 스포츠로 보고 있습니다. 개발이 마무리될 무렵, 우리는 모든 요구 사항을 충족하고 있을 뿐만 아니라 잠재적인 고객 통증 포인트를 테스트하고, 다가오는 변경 사항을 고객 대면 팀에 적절히 전달했는지 확인해야 합니다. 이 단계가 정보가 빠르게 변경될 가능성이 가장 높은 단계이므로, 모든 지식이 각각의 전문가에 의해 검증되어야 하는 것이 가장 중요합니다.
최근의 청구 프로젝트에서, 우리는 팀과 우리의 이해 관계자가 라이브로 전환되기 전에 고객 경험을 테스트하고 품질 보증(QA)을 실시하는 데 한 주를 할당했습니다. 특히 기술적인 프로젝트였기 때문에, 테스트를 위한 환경을 설정하고 준비하는 데 여러 단계가 수반되었으며, 기능 플래그를 활성화하고 특정 세트의 복제 체크아웃 단계를 진행해야 했습니다. 모두가 테스트에 참여하는 데 필요한 모든 정보를 갖고 있도록 보장하기 위해, 우리의 엔지니어링 팀 리더는 QA에 참여하기 위한 단계별 지침이 담긴 카드를 준비했습니다. 우리는 이 카드를 우리의 Pod와 이해 관계자들에게 공지를 통해 보내어 테스트를 시작하기 전에 읽어봤는지 확인했습니다.
QA가 진행되는 동안, 고객 대면 팀에게 다가오는 변경 사항을 알리는 것도 중요했습니다. 이러한 변경 사항은 대부분 사용성과 신뢰성에 중점을 두고 있었으며(대규모 인터페이스 변경과는 달리), 이번 프로젝트로 인해 일부 구형 청구 경험이 변경될 것입니다. 이러한 변경 사항을 검토하고 질문할 시간이 충분하도록 제시간에 전달하기 위해, 우리는 청구 기능 분해 카드에 대해 새로 고쳤습니다.
프로세스에서 우리가 create 대신 refresh라는 단어를 사용하고 있다는 점에 유의해야 하며, 이는 의도적입니다. 우리는 기능 분해 카드를 고객 대면 팀을 위한 기능에 대한 살아있는 진실의 출처로 사용하며, 이는 모든 라이브 기능에 대해 항상 존재합니다.
기존 기능을 업데이트하고 개선할 때, 우리는 기능 분해 카드를 그에 맞게 업데이트하고 개선합니다. 이러한 방식으로, 세일즈 직원이 기능에 대한 구식 문서를 보고 불안해하며 엔지니어에게 문의하는 고전적인 문제를 예방할 수 있습니다. 그들은 작년 자신이 의존했던 청구 페이지 카드가 올해에도 그대로 정확하다는 것을 확신할 수 있으며, 이는 강화 작업을 수행하는 팀에 의해 검증되었습니다.
3단계: 출시 및 그 이후
제품 활성화의 가장 명백한 적용은 새로운 기능이나 개선된 기능의 출시일 수 있습니다. 위의 기능 분해 카드와 같은 개요부터 시작하여, 매우 기술적이고 구체적인 문제 해결 Q&A까지, 고객 대면 팀이 각 출시를 판매하고 지원할 수 있도록 필요한 모든 것을 갖추도록 보장하기 위해 많은 노력이 들어갑니다. 기능이 반복되고 개선됨에 따라 모든 문서가 최신 상태로 유지되고 현재 제품의 상태를 반영하는 것이 여전히 중요합니다.
청구 페이지는 매우 복잡하고 세밀하기 때문에, 체크아웃 프로세스를 완료하면서 고객이 가질 수 있는 잠재적인 질문이 부족하지 않습니다. 우리의 청구 경험은 우리의 영업팀이 너무 많은 세부정보를 부각할 필요가 없을 수도 있지만, 이는 고객이 내비게이션하는 데 종종 지원팀이 도움을 주는 영역입니다. 이번 출시와 체크아웃 경험에 대한 추가 개선을 준비하기 위해, 우리의 엔지니어링 팀 리더는 고객 지원 챔피언과 협력하여 새로운 질문이 발생할 때 추가되는 기술 FAQ 목록을 작성했습니다. 이로 인해 지원팀뿐만 아니라 청구에 대한 고객 질문에 답변하는 모든 사람에게도 우리 팀에 연락하기 전에 가장 먼저 확인할 수 있는 일관된 장소를 제공합니다(그 후, 기술 FAQ 카드에 추가!).
FAQ 카드를 업데이트하는 것 외에도 기능 분해 카드는 항상 최신 상태로 유지됩니다. 우리는 새로운 청구 경험에 대한 공식 출시 날짜와 중요한 말하기 포인트를 기록할 뿐만 아니라, 이 블로그 게시물과 같은 관련 카드 및 리소스를 연결할 것입니다. 기능에 대한 모든 사용 가능한 정보에 접근할 수 있는 원스톱 샵을 생성함으로써, 우리는 고객 대면 팀에게 고객 및 잠재 고객에 대해 충분한 정보로 이야기할 수 있는 자신감을 제공합니다.
이 루프를 닫기 위해, 고객 및 시장 피드백이 제품 개발 주기에서 중요한 역할을 한다는 것을 잊지 말아야 합니다. 우리 팀이 기존 고객과 시장에 새로운 기능 및 향상된 기능을 가져다줄 때, 우리는 고객이 더 나은 작업을 수행하는 데 도움이 되는 것과 우리가 다음에 집중해야 할 것에 대한 귀중한 통찰력을 모읍니다. 이 정보를 문서화하고 제품 팀과 공유하는 것은 우리의 반복적 개발 프로세스에서 중요한 부분이며, 고객에게 최대 가치를 제공하는 데 도움이 됩니다. 다양한 피드백 모드를 공유하는 방법(Document, Email 등)에 대한 문서화는 여러분이 추측한 것처럼 Guru에 보관됩니다.
제품 전문성은 하룻밤 사이에 나타나지 않습니다. 전체 제품 개발 프로세스는 특정 기능 및 작동 방식에 대한 "전문가"를 만드는 것이며, 그 출시 이전 및 이후의 모든 문서의 기초입니다.
제품 활성화를 위한 Guru를 사용하는 팀은 전체 제품 출시 생애 주기에 걸쳐 지식의 단일 진실 출처를 갖는 것의 중요성을 인식합니다. 초기 개발부터 지속적인 지원 및 유지 관리까지. 모든 부서에 전문가가 검증한 정보를 놓을 수 있는 한 단일하고 신뢰할 수 있는 장소를 제공함으로써, 이러한 교차 기능 프로세스에 관여하는 모든 사람이 더 나은 작업을 수행할 수 있습니다. 제품 활성화의 실제 사례로 Guru에서 최근 기능 출시를 살펴보겠습니다.
1월 동안 newly formed Monetization pod는 Guru의 청구 경험을 업그레이드하기 위한 첫 부분에서 작업했습니다. 이 프로젝트에는 일반 제품 개발 팀—제품 관리, 디자인, 엔지니어링 및 제품 마케팅—뿐만 아니라 재무, 지원 및 영업 운영을 포함한 여러 다른 이해 관계자가 포함되었습니다. 이것은 모든 관련 팀 간의 긴밀한 소통과 조정이 필요로 하는 기술 업데이트였으며, 고객과의 대면 팀이 이러한 변경 사항에 대해 자신 있게 이야기할 수 있도록 상당한 사전 작업이 필요했습니다. 다음 세 가지 단계는 기능 출시와 같은 제품 활용을 위해 Guru를 사용하는 주요 방법을 요약합니다.
1단계: 기능 계획 및 개발
제품 활성화는 제품 팀의 프로젝트가 승인되는 순간부터 진정으로 시작됩니다. 이것은 사소한 기능 향상, 페이지 재설계 또는 완전히 새로운 기능일 수 있습니다. 프로젝트 사양이 제품 관리자(PM)에 의해 작성되고 그들의 엔지니어, 디자이너 및 다른 이해 관계자들과 공유되는 시점부터, 모든 사람은 다양한 저자의 신뢰할 수 있고 최신 문서에 접근할 수 있어야 합니다.
우리의 계획은 12월에 시작되었으며, PM들은 청구 및 체크아웃 경험 전반에 걸쳐 몇 가지 주요 장소를 식별했습니다. 이후 그들은 프로젝트 계획을 세우고 시리즈의 첫 프로젝트에 대한 초기 기능 사양을 작성하기 시작했습니다. 팀과 공유할 준비가 되었을 때, 그들은 팀을 이끌고 제안된 변경 사항에 대해 논의하고 타임라인을 논의하기 위해 킥오프 회의를 일정을 잡았습니다. 이 시점부터, 프로젝트에 관련된 모든 사람이 프로젝트 사양, 디자인, 관련 청구 문서 등을 포함한 모든 관련 문서에 접근할 수 있는 것이 매우 중요했습니다.
이 문서들은 자주 변경되며, 프로젝트 초기 단계 동안 자주 추가될 수 있기에, 팀이 돌아와서 검증된 진실 출처를 갖는 것이 중요합니다. 모두가 이러한 리소스를 공유하고 접근할 수 있는 단일 장소를 확보하기 위해, 우리는 팀과 공유할 Active Project Resources Card를 만들었습니다. 우리는 이것을 Monetization Pod Board 내에 두었으며, 모든 적절한 이해 관계자가 작성 권한을 갖습니다.
우리는 Guru에서 기능 출시를 팀 스포츠로 보고 있습니다. 개발이 마무리될 무렵, 우리는 모든 요구 사항을 충족하고 있을 뿐만 아니라 잠재적인 고객 통증 포인트를 테스트하고, 다가오는 변경 사항을 고객 대면 팀에 적절히 전달했는지 확인해야 합니다. 이 단계가 정보가 빠르게 변경될 가능성이 가장 높은 단계이므로, 모든 지식이 각각의 전문가에 의해 검증되어야 하는 것이 가장 중요합니다.
최근의 청구 프로젝트에서, 우리는 팀과 우리의 이해 관계자가 라이브로 전환되기 전에 고객 경험을 테스트하고 품질 보증(QA)을 실시하는 데 한 주를 할당했습니다. 특히 기술적인 프로젝트였기 때문에, 테스트를 위한 환경을 설정하고 준비하는 데 여러 단계가 수반되었으며, 기능 플래그를 활성화하고 특정 세트의 복제 체크아웃 단계를 진행해야 했습니다. 모두가 테스트에 참여하는 데 필요한 모든 정보를 갖고 있도록 보장하기 위해, 우리의 엔지니어링 팀 리더는 QA에 참여하기 위한 단계별 지침이 담긴 카드를 준비했습니다. 우리는 이 카드를 우리의 Pod와 이해 관계자들에게 공지를 통해 보내어 테스트를 시작하기 전에 읽어봤는지 확인했습니다.
QA가 진행되는 동안, 고객 대면 팀에게 다가오는 변경 사항을 알리는 것도 중요했습니다. 이러한 변경 사항은 대부분 사용성과 신뢰성에 중점을 두고 있었으며(대규모 인터페이스 변경과는 달리), 이번 프로젝트로 인해 일부 구형 청구 경험이 변경될 것입니다. 이러한 변경 사항을 검토하고 질문할 시간이 충분하도록 제시간에 전달하기 위해, 우리는 청구 기능 분해 카드에 대해 새로 고쳤습니다.
프로세스에서 우리가 create 대신 refresh라는 단어를 사용하고 있다는 점에 유의해야 하며, 이는 의도적입니다. 우리는 기능 분해 카드를 고객 대면 팀을 위한 기능에 대한 살아있는 진실의 출처로 사용하며, 이는 모든 라이브 기능에 대해 항상 존재합니다.
기존 기능을 업데이트하고 개선할 때, 우리는 기능 분해 카드를 그에 맞게 업데이트하고 개선합니다. 이러한 방식으로, 세일즈 직원이 기능에 대한 구식 문서를 보고 불안해하며 엔지니어에게 문의하는 고전적인 문제를 예방할 수 있습니다. 그들은 작년 자신이 의존했던 청구 페이지 카드가 올해에도 그대로 정확하다는 것을 확신할 수 있으며, 이는 강화 작업을 수행하는 팀에 의해 검증되었습니다.
3단계: 출시 및 그 이후
제품 활성화의 가장 명백한 적용은 새로운 기능이나 개선된 기능의 출시일 수 있습니다. 위의 기능 분해 카드와 같은 개요부터 시작하여, 매우 기술적이고 구체적인 문제 해결 Q&A까지, 고객 대면 팀이 각 출시를 판매하고 지원할 수 있도록 필요한 모든 것을 갖추도록 보장하기 위해 많은 노력이 들어갑니다. 기능이 반복되고 개선됨에 따라 모든 문서가 최신 상태로 유지되고 현재 제품의 상태를 반영하는 것이 여전히 중요합니다.
청구 페이지는 매우 복잡하고 세밀하기 때문에, 체크아웃 프로세스를 완료하면서 고객이 가질 수 있는 잠재적인 질문이 부족하지 않습니다. 우리의 청구 경험은 우리의 영업팀이 너무 많은 세부정보를 부각할 필요가 없을 수도 있지만, 이는 고객이 내비게이션하는 데 종종 지원팀이 도움을 주는 영역입니다. 이번 출시와 체크아웃 경험에 대한 추가 개선을 준비하기 위해, 우리의 엔지니어링 팀 리더는 고객 지원 챔피언과 협력하여 새로운 질문이 발생할 때 추가되는 기술 FAQ 목록을 작성했습니다. 이로 인해 지원팀뿐만 아니라 청구에 대한 고객 질문에 답변하는 모든 사람에게도 우리 팀에 연락하기 전에 가장 먼저 확인할 수 있는 일관된 장소를 제공합니다(그 후, 기술 FAQ 카드에 추가!).
FAQ 카드를 업데이트하는 것 외에도 기능 분해 카드는 항상 최신 상태로 유지됩니다. 우리는 새로운 청구 경험에 대한 공식 출시 날짜와 중요한 말하기 포인트를 기록할 뿐만 아니라, 이 블로그 게시물과 같은 관련 카드 및 리소스를 연결할 것입니다. 기능에 대한 모든 사용 가능한 정보에 접근할 수 있는 원스톱 샵을 생성함으로써, 우리는 고객 대면 팀에게 고객 및 잠재 고객에 대해 충분한 정보로 이야기할 수 있는 자신감을 제공합니다.
이 루프를 닫기 위해, 고객 및 시장 피드백이 제품 개발 주기에서 중요한 역할을 한다는 것을 잊지 말아야 합니다. 우리 팀이 기존 고객과 시장에 새로운 기능 및 향상된 기능을 가져다줄 때, 우리는 고객이 더 나은 작업을 수행하는 데 도움이 되는 것과 우리가 다음에 집중해야 할 것에 대한 귀중한 통찰력을 모읍니다. 이 정보를 문서화하고 제품 팀과 공유하는 것은 우리의 반복적 개발 프로세스에서 중요한 부분이며, 고객에게 최대 가치를 제공하는 데 도움이 됩니다. 다양한 피드백 모드를 공유하는 방법(Document, Email 등)에 대한 문서화는 여러분이 추측한 것처럼 Guru에 보관됩니다.
Experience the power of the Guru platform firsthand – take our interactive product tour
.webp)
