ワークド・エグザンプル:AIプロトタイプを本番へ

この記事の内容. 説明用のワークド・エグザンプルであり、顧客の実績ではありません。フィンテックチーム、そのプロダクト、すべての数字は仮定です。デモでは見栄えのするAIプロトタイプを、すべてのユーザーに出せる機能に変えるために何が必要かを示します。

シリーズBのフィンテックのプロダクトチームを仮定します。プロダクトマネージャーが週末にlovableでAI機能のプロトタイプを作りました。本物らしく見え、全社会議でも好評でした。その後は止まったままです。本物らしく見えることと、信頼できることは別の仕事だからです。

この例について: チームは一般的なもので、背後に顧客はいません。ここにあるものは、納品した成果でも予測でもありません。大事なのは設計であり、ロゴではありません。

良いプロトタイプが本番化の手前で止まる理由

プロトタイプが答える問いと、本番環境が答える問いは違うからです。プロトタイプが証明するのは、きれいな入力に対して、創業者が操作すれば、そのアイデアが一度は動くということだけです。本番環境では、乱雑な入力に対して、深夜2時に、誰も見ていない状態で動き、顧客が機能の回答に異議を唱えたときに説明責任を果たせなければなりません。ほとんどの v0 や Lovable の構築物は、このギャップで力尽きます。アイデアが間違っていたからではありません。デモから、自分の名前を出せるものへの道筋がなかったからです。

本番向けの設計には何が含まれますか

プロトタイプのチャットボックスから始めないでください。サポートのキューから始めます。この機能について量が最も多い3つのチケットが、どれも同じことを指していると仮定します。ユーザーはサポートにメールしないと明確な答えを得られません。機能は、貼り付けたウィジェットではなく、チーム自身のプロダクトとデザインシステムの中で、まずその3つの質問に答えるように作ります。

• ストリーミング応答 — スピナーではなく即応している感覚になるよう、回答が形になるにつれて文字が表示されていきます。
• テストスイート — 変更のたびに正解が分かっている回答と照合し、あるプロンプトの調整が別のケースを気づかぬうちに壊すことを防ぎます。
• 監査ログ — すべての応答を記録し、顧客が機能の回答に異議を唱えたとき、サポートが正確な入力と出力を取り出せるようにします。
• プロダクト内UX — 誰かが貼り付けたチャットウィンドウではなく、プロダクトの一部として感じられるよう、自社のデザインシステムの中に構築しました。

機能がサポートチケットを減らしているか、どうやって知りますか

機能は、チケットから逆算して作ります。サポートの量が最も多い質問は、誰かがメールする前に、機能がプロダクト内で答える質問です。監査ログは、機能が処理する質問と、まだ人に届く質問を示します。同じログは、本当の減少と季節的な落ち込みを見分けるのにも役立ちます。チケットの種類ごとの量を、公開前の基準期間と比較してください。

テストスイートは、あらゆる改善を定着させるものです。公開前に、すべての変更が既知の正解に対して実行されます。1つのケースを直して2つを壊すプロンプトの修正は、ユーザーに届く前に捕まります。これが、一度だけ動くデモと、毎回動く機能との違いです。プロダクトチームはこれを出荷と呼びます。私たちも同じ考えです。私たちのプロダクトの取り組み方はこちらをご覧ください。

どの順序で作りますか

まず監査ログとテストスイートです。測れないものは改善できないからです。次に、上位のチケットへの回答をプロダクト内で作り直します。次に、デザインシステムのUXとストリーミングです。最後に、増えていくユーザーの割合に対する段階的な公開を行い、テストが見逃したものがないか監査ログを見守ります。一斉公開はしません。

当てはめるテストはこれです。デモしたものから、出荷したものへと変わること。そしてサポートのキューが、それが機能した証拠になります。

これが、私たちのワークド・エグザンプルに共通するものです。成果はモデルではありません。周りの地味な部分です。テストスイート、監査ログ、レビューのゲート、見守れる公開です。それがプロトタイプを、すべてのユーザーに出せるものに変えます。v0やlovableのビルドがデモで止まり、先に進む道がないなら、それこそ私たちが埋める隙間です。何を作っているか教えてください。