顧客の行動を通じて顧客の問題を先制的に解決するケーススタディ

Visibuild の製品ロードマップに最近導入された機能は、Visis の複数の PDF を任意のプロジェクト ロケーション ページからエクスポートする機能で、適切に Bulk PDF Exports と名付けられました。ユーザーが選択した場所に基づいてVisisをフィルタリングできるようにする以前の更新を考えると、次の論理的なステップは、ユーザーがそのデータをエクスポートできるようにすることでした.

注: Visi は、製品内のタスク、検査、または問題を説明するために使用する広義の用語です。」

スタートアップで働くことは、製品開発に携わる人々にとって興味深い課題をもたらします。新しいプロジェクトを開始するには、特に製品チームの規模が小さいことを考えると、私たちのチームが一堂に会して機能と優先リストの位置を再調整する必要があります!

迅速に市場に参入し、製品を競争力のある機能同等に引き上げ、「なぜ私たちが違うのか」という壕を築くには、無慈悲な優先順位付けと、ロールフォワードまたは短期的にピボットする意欲を備えた、創造的で短い機能リリース タイムラインが必要です。知らせ。

市場に迅速に参入し、製品を競争力のある同等の機能にまで引き上げ、「他社との差別化の理由」を構築するには、冷酷な優先順位付けが必要です。

キックオフする各製品機能について、チームとして、いくつかの重要なトレードオフについて最善の努力を払って見積もりを行います。

• 市場投入までの時間。
• 機能の検証。
• エンドユーザーからのフィードバックサイクル。

Visibuild では、お客様と緊密に連携し、透明性を維持して、正確な情報を把握し、できる限り効果的に行う必要があることに優先順位を付けることができるようにしています。これらの決定が下されると、内部チームが協力して機能のビジョンをまとめ、最終目標を実行可能な部分に切り分けて、できるだけ早く顧客に価値をもたらすのに役立ちます. そのプロセスの一部には、問題が発生する可能性があることを予測するための取り組み、それらの結果を事前に追跡する方法、および問題が機能の約束の「契約違反」と見なされた場合にロールフォワードする方法が含まれます。

私が最近構築した機能の 1 つは、お客様がお客様の「Visis」(プロジェクトの検査、問題、タスク、および不適合レポートを網羅する包括的な用語) のPDF を一括エクスポートできる機能でした。

この機能は多くの要望があったため、最終結果を反復に分割して、機能をより迅速にユーザーに提供できるようにしたいと考えました。

この機能の反復を 2 つの部分に分割しました。

1. 最初のイテレーションでは、Web アプリケーションに顧客向けの UI を導入し、単一の Visi の PDF エクスポートを電子メールの添付ファイルとして電子メールで送信するために既に持っていたバックエンド フローを利用します。
2. 2 回目の反復では、電子メールで送信された zip ファイルを PDF に置き換え、それらの zip ファイルをリモートで保存し、電子メールの添付ファイルをダウンロードへのリンクに置き換えることに焦点を当てます。

ユーザーが私たちの機能を使用するようになるにつれて、この問題が発生する可能性が大幅に増加しました。これに関与した (特定できた) 要因には、Visi の添付ファイルの数や、エクスポートのために要求された Visi の量が含まれます。

最初のイテレーションを定義する際にこの既知の仮定を考慮して、一度にエクスポートを要求できる最大 50 の Visis を持つように一括エクスポートを制限しました。この上限は、お客様に上限を設けるように設計されたものではありませんが、これを測定して制限を適用することで、機能を早期にリリースし、使用統計を収集して、移行の 2 回目の反復で十分な情報に基づいた決定を下すことができることはわかっていました。ダウンロードリンクに。この上限は、添付ファイルのサイズが大きいために失敗する可能性を防ぐものではありませんが、PDF 添付ファイルのサイズの恣意的な性質を考えると、失敗するエクスポートが多すぎるというリスクを確実に軽減するのに役立つと考えました。

上限の決定により、当社の製品チームは一息つくことができ、その結果、圧縮された PDF を置き換える 2 回目の反復のソリューションを急ぐ機会が得られ、顧客により早く価値を提供することができました。

初期採用からの統計

Visibuild の目標は、お客様からのフィードバックと追跡されたアクションが製品の方向性を推進できるようにすることです。

最初の反復で合意された電子メール添付ファイルの制限を考慮して、追跡が追加され、どのプロジェクトが新機能を使用しているか、リクエストの一部としてエクスポートしようとしていた Visis の数、およびエクスポートの場合のエラーをキャプチャする方法が表示されました。メールに添付するには大きすぎます。

結局のところ、最初の 1 週間以内でさえ、バルク エクスポートを使用して、当初の仮説よりも大きなバッチでエクスポートしていました。

上のグラフは、リクエストごとに PDF 生成のためにリクエストされた Visis の数を示しています。最初の 1 週間以内に、ユーザーが新機能の上限付きエクスポート制限を最大限に活用する必要があるという初期の兆候がいくつか見られました。

最初の 1 週間以内に、ユーザーが新機能の上限付きエクスポート制限を最大限に活用する必要があるという初期の兆候がいくつか見られました。

1 つの要求は、私たちが避けたいと思っていた正確なシナリオに突き当たりました: ZIP ファイルの添付ファイルがサイズ制限に達したために電子メールを送信できませんでした。

サポート チームは、失敗したエクスポートがリクエストを行ったユーザーに確実に提供されるように取り組みましたが、特に機能として、このような問題が引き続き発生した場合、サポート チームにとってコストがかかることをリリース前に特定し、理解していました。採用は指数関数的に増加するだけです。

最終的に、最初の 100 件のリクエストのうち、失敗したのは 1 件だけでした。最初のイテレーションをリリースするという私たちの決定は、それでも私たちに有利に働きました。99% のリクエストに対して顧客に価値を提供しました。そうは言っても、この初期の使用、顧客からの直接のフィードバック、および最初のインシデントはすべて、優先リストの上位にある添付ファイルよりもダウンロード リンクを使用する次の反復を進めるという決定を通知する参考資料でした。

初期の使用、顧客からの直接のフィードバック、および最初のインシデントはすべて、次のイテレーションを進めるという決定を通知する参考資料でした。

2 番目の反復へのロール フォワード

最初の繰り返しの最後に、複数の Visis をエクスポートするためのワークフローは、次の状態図に簡略化できます。

これを次のイテレーションに進めるために合意された技術的解決策は、次の変更を行う必要があることを意味しました。

1. 一括エクスポート ジョブの状態を追跡する方法を導入します。つまり、ジョブが保留中、進行中、完了、または拒否されているか?
2. 成功したジョブと失敗したジョブの両方で通知が行われるようにして、エンド ユーザーに常に通知するようにします。
3. エクスポートされた ZIP ファイルを保存してアクセスするための安全なメカニズムを構築します。

このソリューションは、添付ファイルのサイズに関する問題を解決するだけでなく、一括エクスポート プロセス中に問題が発生したかどうかを顧客に知らせることをより積極的に行うことを意味しました。

最終的な解決策

製品チームの他のメンバーと協力して、ユーザー エクスペリエンスの次のイテレーションを定義した後、ユーザーに情報を提供するために更新された一連の電子メール フローを実装しました。また、ジョブが取り得る一連の状態を定義、実装、追跡し、エクスポート ダウンロード ページのユーザー インターフェイスを介してそれをどのように反映するのが最善であるかを確認し、さらなる問題が頭に浮かび、私たちによって対処されるようにしました。製品チーム。

新しいフローは、ユーザーが新しいエクスポートを要求することから始まり、成功通知によってエクスポートの時間枠が設定され、ユーザーはエクスポートにかかる時間をより適切に把握できるようになります。

エクスポートが正常に完了し、ダウンロードの準備が整うと、更新された電子メールに添付ファイルではなくリンクが提供されるようになりました。これにより、私たちが遭遇した添付ファイルのサイズの問題に関する問題が解決されます。このリンクは、エクスポートの現在の状態に関する情報と、エクスポートの準備が整った (期限切れになっていない) 場合にエクスポートをダウンロードするためのリンクを提供する新しいエクスポート ダウンロード ページにユーザーを誘導します。

ダウンロード リンクをクリックすると、ユーザーが PDF をダウンロードするためのダウンロード ページが表示されます。

ダウンロード リンクと一緒に、リンクの有効期限が切れるまでの時間を含めます。エクスポートされた PDF は通常、エクスポート後すぐに古い状態になるため、リンクを 14 日後に「有効期限切れ」に設定するように決定しました。

有効期限が組み込まれたこの新しいアプローチにより、これらの PDF エクスポート要求をリモート ZIP ファイルとしてホストするコストを先取りすることができました。これにより、これらの古い ZIP ファイルを自動的に削除し、使用されなくなるデータのコストを節約するようにバックエンドを設定して、大規模な新機能の予算を立てることができました。

有効期限が組み込まれたこの新しいアプローチにより、これらの PDF エクスポート要求をリモート ZIP ファイルとしてホストするコストを先取りすることができました。これにより、大規模な新機能の予算を立てることができました。

障害が発生した場合、顧客が問題について私たちに連絡する原因となった「サイレント」障害の問題を解決するために、問題が発生したことをユーザーに通知するメールも設定しました。これにより、お客様に対して積極的に透明性を保つことができ、必要に応じて詳細について問い合わせることができるようになりました。

パズルの最後のピースは、エクスポート ダウンロード ページのユーザー インターフェイスを、ジョブのさまざまな状態に関する情報を提供し続けることでした。有効期限が切れているか、予期しないエラー状態になっています。

これらの状態の一部は、次のようにユーザー インターフェイスに表示されました。

更新されたユーザー インターフェースのおかげで、ユーザーは特定のエクスポート リクエストの進行状況を確認し、そのリクエストがジョブ ライフサイクルのどの段階にあるかを理解できるようになりました。

時間をかけて新しいフローの更新されたライフサイクルを簡略化し、次のように要約できます。

このフローでは、単一 PDF エクスポート、一括 PDF エクスポート (1 つの要求で複数の PDF エクスポート) で発生するすべての PDF エクスポートのライフサイクルの概要と、これらのフローが実行される際の単一および一括 PDF エクスポートの失敗フローの概要を示します。時間とともに。

再集計、結果、および結果

これを書いている時点で、この機能のイテレーションが出荷されており、結果と結果を注意深く監視しています。

繰り返しになりますが、次のステップを理解するために最終的なことを念頭に置いて機能をお客様に提供することに焦点を当てた最初のイテレーションから始めました。使用状況の分析と顧客からのフィードバックを検討した後、ロードマップの 2 回目の反復の実装を推進しました。

この 2 回目の反復には、添付ファイルのサイズの問題を解決して回避し、顧客向けに設定したハード Visi エクスポート制限のロックを解除するという最終目標がありました。これは、エクスポートされた ZIP ファイルを添付ファイルとして電子メールに直接添付するという以前のアプローチを移行することで実現し、代わりに一時的なストレージ ソリューションとダウンロード リンクを利用することを選択しました。

この最新のイテレーションのおかげで、これらの問題を軽減することに成功し、添付ファイルのサイズが原因で失敗したエクスポートに関するリクエストはもうありません。

この新しいイテレーションのリリース以降、この機能の採用は370% 以上増加しました。ロードマップのイテレーションを上に移動するという私たちの決定により、いくつかの頭痛の種やお客様との難しい会話を回避できた可能性があります.

このプロジェクトは、私たちが会社で共有している協調的な考え方を示しています。終わりを念頭に置くことで、初期のイテレーションで潜在的な落とし穴を事前に認識し、リスクが高く問題のある問題が予想よりも早く発生した場合にピボットして対処するという会社の価値を強化します。

終わりを念頭に置くことで、初期のイテレーションで潜在的な落とし穴を事前に認識し、リスクが高く問題のある問題が予想よりも早く発生した場合にピボットして対処するという会社の価値を強化します。

この再集計で取り上げた一括 PDF エクスポート機能の 2 つの反復は、価値を早期に出荷し、顧客の使用状況に基づいて決定を下すことの重要性を示しています。

ユーザーが機能を最大限に活用したいという問題に遭遇することは、良い問題です。私たちのチーム オフィスでよく言われるように、「Ship to Learn」です。