/ビルダー
プロンプトから、最初に役に立つ小さな構築へ
マーケターがプロンプトの先へ進み、実際のユーザーが試せる一つの見えるAI支援の実用スライスを定義するための実務的な方法。
短い答え
プロンプトから構築へ進むとは、実在する一人のユーザーのために見える実用スライスを一つ選び、何を試せるのか、何を範囲外にするのかを定義することです。
プロンプトは役に立ちます。同時に、隠れやすい場所でもあります。
プロンプトを改善し、ツールを試し、例を保存し続けて、何週間も実際のユーザーの前に何も出さないことがあります。私もその版を何度かやりました。私の場合は、たいてい真面目そうなフォルダ名があり、私のラップトップの外には使える人がいませんでした。動いているので、生産的に感じます。でも、まだ誰もそのものを使えません。
作る側の動きは違います。
一つの見える実用スライスを定義し、テスト可能にします。
実用スライスに必要なもの
実用スライスには四つの要素があります。
-
一人のユーザー
市場ではありません。人、または役割です。 -
一つの反復ジョブ
意味があるほど頻繁に起きること。 -
一つのアウトプット
下書き、メモ、スコア、提案、ブリーフ、引き継ぎ。 -
一つのレビュー地点
人間がアウトプットを受け入れる、修正する、または拒否できる場所。
弱い実用スライス:
AIアカウントマネジメントアシスタントを作る。
より良い実用スライス:
一人のアカウントリードが、散らかったクライアント質問スレッドを事前コール用の意思決定メモに変換できるようにする。その提案を共有する前に、人間の承認を必須にする。
二つ目は小さいですが、見せることができます。
マーケターにある強み
マーケターは、エンジニアには見えていない仕事を知っています。
どのブリーフが三回の混乱を生むかを知っています。どのレポートが誰にも読まれていないかを知っています。プロセス文書では問題なさそうに見える引き継ぎが、毎週木曜にどこで壊れるかを知っています。
その知識には価値があります。ただし、ビルドブリーフに変える必要があります。
ビルドブリーフは、ユーザー、問題、最初のアウトプット、リスク、受け入れ条件を明記します。それがないと、AIはかなりのコードを間違った方向に生成できます。
Provaでの扱い方
Provaの構築者ルートは、現実確認から始まり、プロジェクト概要、構築計画へ進みます。この順序には理由があります。
現実確認が弱ければ、概要は空想になります。概要が曖昧なら、構築計画は見せかけになります。構築計画がQAを無視すれば、ローンチ判断で遅すぎる形で見つかります。
間違っているかもしれませんが、非エンジニアがAIで何かを作ろうとして痛い目を見るのは、ここだと思っています。アイデアがないから失敗するのではありません。最初の実用スライスが曖昧すぎてテストできないから失敗します。
もっと小さく始めてください。
一つのものを見える形にしてください。
実在する誰かに反応してもらってください。
見せるのが少し恥ずかしいけれど、それでも学べる最小の実用スライスは何ですか？
ではまた、Chandler
