商品を思いついたとき、名前や機能を考える前に確かめたいことがあります。
対象者が、その問題を今どの程度解決したいのかです。
「便利そう」という感想と、時間や費用を使う意思は同じではありません。
このレッスンでは、会議後の議事録整理を支援する架空の商品を題材にします。
課題、現在の対処、提案への行動を分けて調べ、作る範囲と見直す条件を決めます。
この記事で学ぶこと
- 顧客の感想と実際の行動を分けます。
- 需要の仮説を確かめる小さな試行を設計します。
- 続行を判断する日と追加する時間を決めます。
検証する仮説を一文にする
最初の仮説には、対象者、困る場面、現在の不都合を入れます。
「AIで議事録を便利にする」では、利用者も判断基準も定まりません。
「毎週会議を運営する担当者は、決定事項の確認に時間を使っている」と書けば、調べる相手と出来事を選べます。
解決方法を仮説に混ぜず、問題があるかを先に確かめます。
例えば「会議後、複数人へ担当と期限を確認している」という事実が集まれば、単なる文字起こしより確認工程の支援に可能性があります。
一方、議事録を作らない会議では同じ提案は響かないかもしれません。
役職や企業規模だけでなく、直近の業務経験を対象条件へ入れます。
調査前に、仮説が弱まる事実も書いてください。
「確認に困っていない」「既存の方法で十分」「改善を求める担当者に導入権限がない」などです。
支持する話だけを集めると、作りたい気持ちを確認する作業になります。
仮説は採用を前提とする約束ではなく、調べて変更するための仮置きです。
仮説は「この事実が確認できなければ見直す」と読める形にします。
会議回数が多いだけでは不十分なら、再確認が生じた記録を必要な証拠にします。
問い合わせ先を決める前に証拠の形を決めると、身近な人の賛同だけで企画を固めにくくなります。
現在の対処から課題の強さを見る
課題の強さは、困っているという言葉だけで判断しません。
最後に困った場面、発生頻度、使った時間、放置した結果、すでに試した方法を聞きます。
本人が覚えていない時間は推定と記録します。
業務画面や匿名化した記録を見せてもらえるなら、発言と実際の作業を照合できます。
架空の聞き取りで、毎週30分の整理と翌日の再確認があると分かったとします。
しかし30分すべてを削減できるわけではありません。
内容を判断する時間と、転記する時間を分け、支援できる部分を特定します。
既存テンプレート、同僚への依頼、何もしないことも競合となる対処です。
頻度が高くても本人が困っていない業務があります。
逆に年に一度でも、失敗の影響が大きい業務は優先されます。
頻度だけで順位を決めず、影響と改善を決める人を確かめます。
話を聞いた人数は需要の大きさそのものではありません。
調べた相手の条件と、まだ聞いていない相手を併記します。
現在の対処には、組織の事情も含まれます。
無料の表計算を使い続ける理由が社内規定なら、高機能な別サービスを提案しても変えられません。
代替手段の不満だけでなく、使い続ける理由を聞くことで、乗換えに必要な条件を拾えます。
手作業で価値の一部を届ける
問題が見えたら、完成品より小さい提供を試します。
議事録支援なら、自動化ツールを開発する前に、許可された会議メモから担当別の確認一覧を手作業で作れます。
確かめたいのは技術の性能ではなく、確認一覧が次の業務に使われるかです。
試す範囲を狭めるほど、失敗した理由を追いやすくなります。
試行では、受け取る材料、渡す成果物、提供日、相手にお願いする確認を明記します。
「何でも整理します」では追加作業が膨らみ、事業として続けられるかが分かりません。
未完成の機能を利用できるように見せず、人が作業する試行であることも説明します。
無料で試して使われたことは、支払ってもらえる証拠とは区別します。
参加の同意、素材の提出、日程確保、実際の利用、有料の提案への判断はそれぞれ別の行動です。
断られたら理由を一つに決めつけず、時期、内容、権限、価格を確認します。
無理な申込みを迫る必要はありません。
試作品の評価では、どこを自分で直して使ったかも尋ねます。
完成度への感想より、使うために必要だった修正が次の仕様になります。
相手が気を使って褒める可能性もあるので、試用の有無が分からない回答を利用実績へ含めないようにします。
続行と修正の条件を先に決める
試す前に、結果をどう扱うかを決めます。
例えば3社へ確認一覧を提供し、翌週も同じ業務で使うかを聞きます。
3という数はこの試行の作業量に合わせた例で、市場を代表する数ではありません。
確認したい行動を先に決めることで、後から都合のよい反応だけを成功と呼ぶのを防ぎます。
「3社中2社が実際の確認に使用したが、有料継続は未確認」と書けば、利用価値と事業性を分けられます。
続行するなら価格を含めて提案する、使われなければ成果物の形を見直す、問題自体が弱ければ対象を変える、と次の分岐を置きます。
結果が少ないときは結論を広げません。
反応だけでなく、提供側の作業時間と修正回数も残します。
毎回大幅な個別対応が必要なら、売れる可能性があっても提供方法の修正が必要です。
検証の終了時点で残すのは完成の宣言ではなく、確認できたこと、分からないこと、次に使う時間の上限です。
中止条件を置くのは消極的な判断ではありません。
今の対象では課題が弱いと分かれば、対象を変えて調べる余地が残ります。
すでに使った時間の大きさで続行を決めず、これから追加する時間で何が分かるかを比較してください。
記録を商品仕様へ変換する
顧客の要望をそのまま機能一覧へ移すと、商品が広がり続けます。
要望の背後にある困る場面をまとめ、共通する最小の成果物を選びます。
「メールで欲しい」「一覧にして欲しい」は、見落とさず担当を確認したいという同じ目的から出ている可能性があります。
形式の好みと解決したい問題を分けてください。
仕様へ採用する項目には、根拠となった観察と対象条件を添えます。
例えば「担当別に並べる／3社のうち2社が担当への転送に使用」と残します。
少数の声を全顧客の必須条件にせず、個別対応として残す項目も決めます。
採用しない要望には、無視ではなく保留理由を書きます。
商品案を一文にすると「会議後の確認担当者へ、合意していない担当と期限を一覧にして翌営業日までに渡す支援」となります。
誰の何をどこまで助けるかが明確です。
ここまで絞ってから、自動化や販売ページへ進みます。
検証の費用は、作らないものを決められた場合にも意味があります。
仕様には、提供できる状態と今後検討する状態を分けて表示します。
未実装の自動化を通常機能として販売しないでください。
最小限の提供を明確にすれば、顧客は参加する条件を理解でき、提供側も試行中の変更を説明しやすくなります。
実践課題
実践課題：商品案の検証シートを作る
一つの商品案の検証シートを作ります。
実在顧客の秘密情報を入れず、対象条件、仮説、試す提供、観察する行動、判断日を一枚へ書きます。
まだ聞いていないことは空欄を推測で埋めず、未確認と残してください。
- 対象者を最近経験した業務で定義する
- 過去の対処を聞く質問を3つ書く
- 一週間以内に渡せる試作品と作業上限を決める
- 続行・修正・中止の条件を先に記入する
架空の完成例「対象＝週次会議の確認担当。仮説＝担当と期限の再確認が負担。試行＝3社へ確認一覧を1回提供。観察＝翌週の使用と追加依頼。上限＝合計6時間。有料継続は別の提案で検証する。」
自己確認
- 感想と実際の行動が別欄になっている
- 未確認の需要を実績として書いていない
- 次に使う時間と判断日が決まっている
まとめ
商品アイデアは、顧客の具体的な出来事から検証します。
現在の対処を聞き、小さい提供への行動を観察し、提供にかかる負担も記録します。
最初にすることは開発項目を増やすことではなく、作る判断を変えうる問いを一つ書くことです。
- 顧客の感想と実際の行動を分けます。
- 需要の仮説を確かめる小さな試行を設計します。
- 続行を判断する日と追加する時間を決めます。
