brainstorm-ideas-existing

brainstorm-ideas-existing の概要

brainstorm-ideas-existing は、既存プロダクトを前提に新しいアイデアを生み出すためのプロダクト発見スキルです。ゼロから発明するためのものではありません。PM、Designer、Engineer の3つの視点から機会を整理し、そのうえで有望な方向に絞り込むのを助けます。すでにプロダクト、狙うセグメント、解決したい課題がある状態で、一般的なプロンプトよりも構造化された発想をしたいときに使います。

このスキルが特に向いているケース

brainstorm-ideas-existing は、新しい機能案、既知の機会に対する解決策の代替案、あるいはプロダクト発見のための仮説出しの起点を強化したいときに特に力を発揮します。特に、ロードマップの方向を決める前に、顧客の痛み、事業価値、実装現実をつなげたい Product Management の仕事に向いています。

何が違うのか

ゆるいブレインストーミング用プロンプトと違い、このスキルは複数の視点と優先順位付けを明示的に使います。これにより、一面的なアイデアに偏りにくく、実際に検証する価値のある選択肢を拾いやすくなります。また、発見のループを促すので、最初の出力が十分でない場合や、証拠がまだ不完全な場合にも役立ちます。

どんなときに合うか

brainstorm-ideas-existing を選ぶべきなのは、次の3点に答えられるときです。つまり、どのプロダクトについて考えるのか、どの機会や課題を掘るのか、そしてアイデアの受け手は誰か、です。単に一般的な発想力が欲しいだけなら、これはやや手順が多すぎるかもしれません。プロダクト戦略や実行上の制約に根ざしたアイデアが必要なら、より適しています。

brainstorm-ideas-existing スキルの使い方

インストールしてスキルの場所を確認する

npx skills add phuryn/pm-skills --skill brainstorm-ideas-existing でインストールします。brainstorm-ideas-existing の導入判断で重要なのは、この repo がかなり軽量だという点です。補助スクリプトや support folder はなく、確認すべき主な情報源は SKILL.md です。まずそこを読み、frontmatter を確認してから、ワークフローに合わせて本文を適用してください。

スキルに適切な入力を与える

brainstorm-ideas-existing の使い方は、プロダクト名、具体的な機会、対象ユーザー、欲しい結果を含めると最も効果的です。良い入力例は「既存の fitness app で、1週目に離脱する新規ユーザーの定着率を上げるアイデアをブレインストーミングして」です。弱い入力例は「自分のプロダクトのアイデアを出して」です。前者ならスキルが十分な文脈を持てるため実用的な案を出しやすく、後者は推測に頼らせてしまいます。

3者視点のプロンプトにする

このスキルは PM、Designer、Engineer のように考える設計なので、単なる発想ではなく意思決定のための依頼として組み立てるのがコツです。実用的な brainstorm-ideas-existing のガイドとしては、視点ごとに案を出させ、その後で短く優先順位付けを依頼するとよいでしょう。たとえば、「PM から5案、Design から5案、Engineering から5案を出し、その後で impact、feasibility、confidence の順で上位5案を並べて」といった形です。この構成はスキルのワークフローに合っており、ワークショップや計画立案でも使いやすくなります。

先にソースファイルを読む

この repo では、まず確認すべき主ファイルは SKILL.md です。README.md、rules/、resources/、ワークフローを拡張するスクリプトはありません。自分の組織向けに brainstorm-ideas-existing を調整するなら、重要なのは文言をそのまま写すことではなく、手順の順番を保つことです。つまり、文脈を確認し、複数視点で発想し、最後に優先順位を付ける、という流れです。この順序があるからこそ、出力が実際のプロダクト課題に結びつきます。

brainstorm-ideas-existing スキルの FAQ

brainstorm-ideas-existing は Product Management 専用ですか？

いいえ。brainstorm-ideas-existing は Product Management に役立ちますが、意図としてはクロスファンクショナルです。特に、意思決定に PM、Design、Engineering の観点がすべて関わるとき、つまり「望ましさ」と「作れること」の両方が重要なときに最も効果的です。

普通のプロンプトと何が違いますか？

普通のプロンプトでもアイデアは出せますが、brainstorm-ideas-existing は構造を加えます。文脈を求め、視点を分け、最後に優先順位付けへ進めるのです。その結果、特に機会が複雑なときやチームで共通の出発点が必要なときに、より使える出力と、一般論の少ない提案が得やすくなります。

初心者でも使えますか？

はい、すでにプロダクトと課題が分かっているなら使えます。スキルを使うのにディスカバリーの専門知識は不要ですが、機能させるための文脈は必要です。初心者は、アイデアを求める前に、プロダクト、ユーザーセグメント、事業目標を1段落で説明すると、より良い結果を得やすくなります。

どんなときに使わないほうがいいですか？

問題がまだ定義されていない、プロダクトが未確定、あるいは単にランダムな概念を短く並べたいだけなら、brainstorm-ideas-existing は使わないでください。また、深いリサーチ統合、UX コピー、実装仕様が必要な場合にも適していません。このスキルの価値は、それらの前段階、つまり既知の機会をより良いプロダクト案に変えるところにあります。

brainstorm-ideas-existing スキルを改善する方法

まず制約をはっきりさせる

brainstorm-ideas-existing で良い結果を得るには、対象セグメント、プロダクト段階、指標、既知のペインポイントを明確にするのが近道です。たとえば「self-serve SMB 管理者の最初の7日間の activation を高める」と書けば、「オンボーディングを改善して」とだけ言うよりずっと良い案が出ます。制約があるほど、スキルは広さより関連性を優先できます。

評価できる出力を求める

アイデアを出すだけで終わらせないでください。各案がなぜ重要なのか、どの視点から出たのか、どう評価すべきかまで入れるよう求めましょう。たとえば、「各アイデアについて、想定ユーザー価値、期待される事業インパクト、主な実装リスクを示して」と依頼します。そうすると、brainstorm-ideas-existing の出力は意思決定に使いやすくなり、product trio でも議論しやすくなります。

最初の出力のあとに反復する

最初の結果はたいてい出発点であり、最終回答ではありません。案が広すぎるなら、対象ユーザーか期待する成果を絞ってください。安全すぎるなら、もっと大胆な विकल्पや隣接機会を求めてください。コストが高すぎるなら、より低工数のバリエーションを依頼します。こうした反復こそが、brainstorm-ideas-existing をワークショップの練習ではなく、実際のプロダクト発見で役立つものにします。

根拠を足してプロンプトを強くする

リサーチメモ、顧客の引用、ファネルデータ、現状のプロダクト制約があれば追加してください。このスキルは機会の文脈と組み合わせて使うよう設計されているため、根拠があると一般的なブレインストーミングに流れにくくなります。強い入力こそが brainstorm-ideas-existing の使い方を最短で改善し、単なる議論ではなく実験につながるアイデアを得るための近道です。