#Product Management #Documentation Jeff Pattonが考案した、プロダクトの機会（オポチュニティ）を1枚で記述するためのキャンバス 仮説検証前のアイデア整理に用いられ、ユーザー価値とビジネス価値を並列に整理する 主な構成要素 Problems / Solution Ideas（課題と解決アイデア） Users & Customers（ユーザーと顧客） Solutions Today（既存の代替手段） User Value / Adoption Strategy（ユーザー価値と採用戦略） Business Problems / Benefits / Metrics（ビジネス課題・便益・指標） Budget（予算） https://jpattonassociates.com/opportunity-canvas/

Minimum Viable Solution #Agile #Product Management 期待する成果を達成できる最小のリリース単位 MVPがProductという語で新規プロダクトを想起させるのに対し、Solutionに置き換えることで既存プロダクトへのリリースにも適用できるよう概念を広げている

#Agile #Product Management プロダクトバックログ上で生まれるアイテム、要件、テストなどをまとめるハブになる

#Agile #Product Management システムの端から端まで（end-to-end）を貫く、ごく小さな実装。最終的なアーキテクチャである必要はないが、主要なコンポーネントを結合して実際に動作するものを最初に作り、そこに肉付けして少しずつ成長させる。Alistair Cockburnが提唱した。

#Agile #Product Management #Team Organization 10個のアジェンダをチームおよび関係者で答えていくワーク われわれはなぜここにいるのか エレベータピッチ パッケージデザイン やらないことリスト ご近所さんを探せ 技術的な解決策 夜も眠れない問題 期間を見極める トレードオフスライダー 何がどれだけ必要か 日本語のテンプレートは以下にある https://github.com/agile-samurai-ja/support

#Agile #Product Management ユーザーが目的を達成するために行う、ひとつひとつの行動。

#Agile #Product Management ユーザーストーリーマッピングの最上部に配置されるユーザーの主要なアクティビティの流れ アクティビティを時系列で左から右に並べ、プロダクト全体のユーザージャーニーを表現する 各アクティビティの下にユーザータスクをぶら下げ、さらにその下にストーリーを配置する

#Agile #Product Management ストーリーマップを左から右に読んだときに、ユーザーの行動が一連の物語として自然につながるような並びの流れ。

#Agile #Product Management 複数のユーザータスクをまとめた、ユーザーの大きな目的を表す行動のまとまり。

Minimum Viable Product experiment #Agile #Product Management Jeff Pattonが、エリック・リースのMVPを「実験」として捉え直して呼んだ語。何かを学ぶために作れる最小のもので、ターゲット顧客にとって本当にViableなものは何かを理解するための実験を指す。

#Agile #Product Management 作業バッチサイズを最小化させるための観点の頭文字を略称にしたもの Independent Negotiable Valuable Estimable Small Testable

OST #Product Management Teresa Torresが提唱したプロダクトディスカバリーのためのビジュアルフレームワーク。ツリー構造で意思決定を整理する Outcome（成果） → Opportunity（機会） → Solution（解決策） → Experiment（実験） の4層で構成 顧客のニーズや課題（Opportunity）を起点に解決策を導出し、仮説検証で学びを得る https://www.producttalk.org/opportunity-solution-trees/

Authors 市谷 聡啓 #Agile #Product Management ユーザーストーリー INVEST ユーザーストーリーマッピング

Minimum Viable Product #Agile #Product Management 望まれる成果（アウトカム）を実現できる、最小のプロダクトのリリース。「最小」とは機能数の少なさではなく、仮説を証明・反証するための最小単位を指す。

#Product Management TEDの優れたリーダーはどうやって行動を促すかによって初めて解説された考え 円の中心から Why What How の順に並ぶ Howが一番外側にあるが優先度が低いというわけではなく、HowによってWhatに大きな影響を与えるケースもある

#Agile #Product Management #Documentation Jeff Pattonが考案したユーザーストーリーを洗い出すためのプラクティス。フラットなバックログの代わりに、ストーリーを地図（マップ）の形に並べてプロダクト全体を俯瞰する。 最終的なマップは、上位からアクティビティ、ユーザータスク、ストーリーの階層で構成される。 作成はこの完成形を上からなぞるのではなく、具体から始める。まずユーザータスクを書き出し、ナラティブフローに沿って並べて網羅したうえで、それらを集約してアクティビティを抽出する。 https://jpattonassociates.com/story-mapping/ https://jpattonassociates.com/the-new-backlog/

#Agile #Product Management 市谷 聡啓によるインセプションデッキを活用して組織を芯からアジャイルにするスライド https://www.docswell.com/s/papanda/ZYR1L5-shin-agile-deck

Product Requirements Document #Documentation #Product Management プロダクトに必要な機能・振る舞いを定義する文書。開発チームとステークホルダーの間で「何を作るか」の共通認識を形成する 主な構成要素として、目的・ゴール、ユーザーペルソナ、機能要件、非機能要件、成功指標を含む

Minimum Viable Platform #Product Management Luca Galante による Minimum Viable Platform の解説記事。プラットフォームの失敗は技術選定ではなく文化・プロセス（価値実証の遅さ）が原因とし、2週間で主要ステークホルダーに価値を示す MVP を説く Representative: クラスタ/コンテナ/VCS/単一DB/DNS/CI/CD 等の典型リソースを最小構成で含む Repeatable: 他チームのクイックスタートになるテンプレート Iterative: スケールを前提に設計する Innovative: 先行チームが新技術を試せる余地を残す 先行採用チーム（lighthouse teams）の賛同を起点にフィードバックを反復し、予算を確保する 抽象度は Platform as a Product で調整し、開発者ポータルと混同しない https://platformengineering.org/blog/what-is-a-minimum-viable-platform-mvp

AI-Driven Development Life Cycle #Product Management AWSが提唱するAI駆動の開発ライフサイクル手法。従来のSDLCをAIファーストで再設計し、AIがワークフローを主導し人間が検証する スプリントに代わる「Bolt」という短い反復サイクル（時間〜日単位）で実行 Inception・Construction・Operationsの3フェーズで構成され、各段階に人間の承認ゲートを設置 ドキュメントファーストで全成果物・意思決定の追跡可能性を確保 https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/

Behavior-Driven Development #Testing #Agile #Product Management Dan NorthがTDDのビジネス要件との乖離の課題を解消するために名付けた考え、2006年にIntroducing BDDによって紹介された その後のコミュニティの成熟でGherkin記法の実践だけではなく、どのようにビジネスチームと一緒に製品を作り上げていくのか、に焦点が当たっている 主に以下の3つのプラクティスを行う 発見 定式化 自動化 https://cucumber.io/docs/bdd/

#Product Management #Team Organization Developers・Users・Businessの3頂点と中心にProductを置く、プロダクトマネジメントのフレームワーク（Dan Schmidt, 2014） PMの役割は各要素間の隙間（white space）を埋め、相反する入力を統合（synthesis）すること https://productlogic.org/2014/06/22/the-product-management-triangle/

#Agile #Product Management 実際に作って試した結果から得られる、実証された学び。想定や意見ではなく、ユーザーの反応など観測された事実にもとづいて仮説の正否を判断する。 「構築・計測・学習」のサイクルを回して得られる。 構築（Build） 計測（Measure） 学習（Learn）

#Agile #Product Management 市谷 聡啓による仮説検証型アジャイル開発の資料 https://drr.red/

#Product Management プロダクトで取り組みうる「機会」。あるユーザーの課題やニーズと、それを解決したときに生まれるビジネス上の便益を、ひとつの検討単位として捉えたもの。フィーチャー（機能）から考え始める前に、まずオポチュニティ単位で取り組むかどうかを判断する。

#Agile #Product Management Alistair Cockburnが提唱した、ゴール（目的）の大きさをレベル（高さ）で捉える考え方。高いレベルほど要約的で大きな目的を、低いレベルほど具体的な手順を表す。

#Agile #Product Management #Documentation プロダクトバックログアイテムが完成したと判断できる条件

#Product Management アウトプットを用いて得られる成果、ユーザーに感じてもらう価値

#Agile #Product Management 市谷 聡啓によるアジャイル開発はWhyから始まるというスライド Docswell ゴールデンサークル ユーザーストーリー

Platform Engineering #Product Management Platform Engineering に MVP の発想を持ち込んだ概念。包括的な機能ではなく、ステークホルダーへ数週間で価値を実証できる最小限のプラットフォームを指す

#Agile #Product Management プロダクトに必要とされるもののリスト、優先度順に並べる

#Agile #Product Management ストーリーを、誰のためのものかというユーザー視点を強調して捉えたもの。 Whoとして、Whatをしたい。なぜならWhyだからだ のように Who What Why を含む形で書かれる、ユーザーにとっての価値を説明する文 INVESTであるストーリーが良いとされる