製品の専門知識は一晩では得られません。 製品開発の全過程が特定の機能や機能に関する「専門家」を作り出し、それはリリースの前後に存在するすべての文書の基盤となります。

製品の有効化のためのGuruを使用しているチームは、製品リリースライフサイクル全体にわたる知識の一元的な信頼の源を持つことの重要性を認識しています。 専門家が検証した情報を一つの合意された信頼できる場所に置くことで、これらのクロスファンクショナルなプロセスに関与するすべての人がより良い仕事ができます。 最近の機能リリースの例として、Guruでの製品有効化のプロセスを見ていきましょう。

1月中、私たちの新しく形成された収益化のポッドは、Guruの請求体験のアップグレードの第一部に取り組みました。 このプロジェクトには通常の製品開発チーム—製品管理、デザイン、エンジニアリング、製品マーケティング—と、財務、サポート、営業運用を含む他の利害関係者が関与しました。 これは、関与するすべてのチーム間での緊密なコミュニケーションと調整を必要とする技術的な更新であり、お客様と直接接する担当者がこれらの変更について自信を持って話せるようにするための substantial prep workを必要としました。 以下の三つのフェーズは、私たちがこのような機能リリースについてGuruを使用する主な方法をまとめたものです。

フェーズ 1: 機能の計画と開発

製品の有効化は、プロダクトチームのプロジェクトがゴーサインを受けた瞬間に本当に始まります。 これは、小さな機能強化、ページの再設計、または全く新しい機能のためのものである可能性があります。 プロジェクトの仕様がプロダクトマネージャー（PM）によって作成され、彼らのエンジニア、デザイナー、他の利害関係者と共有される時点から、全員がさまざまな著者からの信頼できる最新の文書にアクセスできる必要があります。

私たちは12月に計画を開始し、PMは私たちの請求とチェックアウト体験の中で更新が必要な主要な場所を数か所特定しました。 そこから、彼らはプロジェクト計画を立て、シリーズの最初のプロジェクトのための初期機能仕様を作成し始めました。 チームと共有する準備が整ったら、提案された変更をチームに説明し、タイムラインについて話し合うキックオフミーティングをスケジュールしました。 この時点から、プロジェクトに関与するすべての人が、プロジェクトの仕様、デザイン、関連する請求文書など、すべての関連文書にアクセスできることが重要でした。

これらの文書は頻繁に変更される可能性があり、プロジェクトの初期段階ではよく追加されるため、チームが戻って確認できる信頼できる情報源を持つことが重要です。 すべての人にこれらのリソースを共有し、アクセスできる一元的な場所を確保するために、アクティブプロジェクトリソースカードを作成してチームと共有しました。 これを収益化ポッドボード内に配置し、すべての適切な利害関係者が著者アクセスを持っています。

開発プロセスを通じて、私たちのエンジニアはデザインファイルをブックマークしたり、先週彼らに提供されたコピーがまだ最新かどうかを再確認したりすることを心配する必要はありませんでした。 代わりに、彼らは作業中に最も最新の情報を基に構築していることを確実にするために、アクティブプロジェクトリソースカードを参照できます。 エンジニアリングチームがGuruを使用する方法を見る。

フェーズ 2: リリース準備

私たちは機能リリースをGuruでのチームスポーツと見なしています。 開発が終わりに近づくにつれて、すべての要件を満たし、潜在的な顧客の痛点をテストし、今後の変更を顧客向けのチームに適切に伝えることを確実にする必要があります。 これは、情報が最も速く変化する可能性があるフェーズなので、それぞれの専門家によってすべての知識が検証されることが最も重要です。

最近の請求プロジェクトでは、チームと利害関係者がテストを行うための品質保証（QA）のために1週間の時間を割り当てました。 これは特に技術的なプロジェクトであったため、環境を設定してテストの準備をするためにいくつかのステップがあり、機能フラグを有効にしたり、特定のセットの複製チェックアウト手順を進めたりしました。 全員がテストに参加するために必要なすべての情報を持つことを確実にするために、私たちのエンジニアチームリードはQAに参加するためのステップバイステップの指示を持つカードを準備しました。 私たちはこのカードを私たちのポッドと利害関係者に発表として送信し、テストを開始する前に彼らがそれを読んでいたことを確認しました。

QAが進行中である間、顧客向けのチームに今後の変更について通知し、見込み客や顧客が持つかもしれない質問に備えることも重要でした。 これらの変更は大部分が使いやすさと信頼性に焦点を当てたもので（より大きなインターフェースの変更ではなく）、プロジェクトによってはレガシーの請求体験の一部が変更される予定でした。 これらの変更を十分な時間を持って伝えるために、請求機能の詳細を更新したカードを作成しました。

プロセスの中で、今回初めて「リフレッシュ」という言葉を使っていることに気付くでしょう。それは意図的なものです。 私たちは機能の詳細カードを顧客向けのチーム用の機能の生きた信頼の源として使用しており、それはすべてのライブ機能のために常に存在します。 

既存の機能を更新および改善する際には、機能の詳細カードもそれに応じて更新し改善します。 これにより、営業担当者が機能に関する古い文書を見ているか不確かで、パニックになってエンジニアに電話するという古くからの問題を防ぐことができます。 彼らは、昨年依存していた請求ページに関するカードが、今年も業務改善担当者によって確認され、正確であることを確信できます。

フェーズ 3: リリースとその後

製品の有効化の最も明白な応用は、新しいまたは強化された機能のリリースの周りにあるかもしれません。 上記の機能の詳細カードのような概要から、非常に技術的で具体的なトラブルシューティングQ&Aまで、顧客向けのチームが各リリースを売上げやサポートできるように、必要な情報を備えていることが重要です。 そして、機能が時間とともに改善されていくにつれて、すべての文書を最新に保ち、製品の現状を反映させることが重要です。

請求ページが非常に複雑で微妙であることは驚くべきことではありません。これにより、顧客がチェックアウトプロセスを完了する際に持つ可能性のある質問が少なくなることはないのです。 私たちの請求体験は、営業チームが詳細に話す必要がないかもしれませんが、それはサポートチームが頻繁に顧客のナビゲートを助ける分野です。 このローンチや今後のチェックアウト体験の改良に備えるために、私たちのエンジニアチームリードは、顧客サポートのチャンピオンと協力して、技術的なFAQのリストを編纂しました。 これは、サポートチームだけでなく、請求について顧客の質問に答えるすべての人が（そしてその後、技術的なFAQカードに追加することができる、最初に確認する一貫した場所を持つことができるようになります。

FAQカードを更新し続けるだけでなく、機能の詳細カードも常緑のまま維持されます。 公式のローンチ日や新しい請求体験についての重要な会話ポイントを記録すると同時に、他の関連カードやリソースへのリンクを繋げていきます。 機能に関する利用可能な情報にアクセスするためのワンストップショップを作成することにより、顧客向けのチームが完全に情報を持って顧客や見込み客について話す自信を持てるようにしています。

このループを閉じるために、顧客と市場のフィードバックが製品開発サイクルにおいて重要な役割を果たすことを忘れてはなりません。 私たちのチームが新しい強化された機能を既存の顧客と市場に提供する際に、彼らがより良い仕事をするのに役立つことや、次に焦点を合わせてほしいことに関する貴重な洞察を集めています。 この情報を私たちの製品チームと文書し共有することは、私たちの反復的な開発プロセスの重要な部分であり、顧客に最高の価値を提供するのに役立ちます。 異なるフィードバックモードの共有方法に関する文書（通話記録、メールなど）は、言うまでもなくGuruに保存されます。