Kuro | PdM

マーケ出身PdM | HR領域PdM ← PlayLifeStudio COO ← 博報堂 マーケ&PdM |累計ユーザーインタビュー700人以上 | 特にtoC領域 x 立ち上げ期プロダクトにおけるユーザーリサーチドリブンなグロースが得意 | お仕事依頼はDMまで | #PdM #プロダクトマネージャー

[Kuro | PdM @booksoccermark]

7回くらい読み返している『イシューからはじめよ』をプロダクトマネージャー向けに絞って要約しました

https://t.co/0Qx9grITpQ

[Kuro | PdM @booksoccermark]

チームが本当にユーザーを理解できているか？を確かめる、1つのシンプルな質問があります。
https://t.co/GJ2po3dyQu
「実在する〇〇さんの、先週1週間の生活を全員が語れますか？」

「30代・都内・共働き」といったフワッとしたペルソナではありません。 先週インタビューした「大阪在住の田村さん（仮名）」という実在の人物についてです。

・田村さんは月曜の朝、どんな気分で起きたか？
・通勤電車でスマホで何を見ていたか？
・仕事中にどんな上司の言葉にストレスを感じたか？
・夜、疲れ果ててベッドで最初に開いたアプリは何か？

この「生活のタイムライン（線）」**を、チーム全員が映像として思い浮かべられる状態。これこそが「ユーザー理解」のゴールです。

多くのPdMは、ユーザーを「自社プロダクトを使ってくれる都合の良いパーツ」として見がちです。 しかし、ユーザーには生活があり、感情があり、矛盾があります。 プロダクトを利用するのは、その長い生活のほんの一瞬に過ぎません。

その「一瞬」を最適化するためには、背後にある「24時間の文脈」を知る必要があります。 断片（点）ではなく、文脈（線）で理解する。 次回の定例で「私たちが一番詳しい実在のユーザーは誰？」と問いかけてみてください。

[月島くん @wancoro_xx]

🚨速報:Claude が「Council」という新機能をリリースしました！

通常Claudeは1つの頭脳で回答しますが、
これを使うと、5つの頭脳を戦わせて互いに議論を交わしてから最終的な答えをくれる。

このやり方と5つのプロンプトを公開↓
（保存必須）

[小池未樹 @mikipond]

「みんながそれぞれClaudeで作った一見整った資料を大量に投げ込むので結局意思決定のコストが上がっている」という話を複数方向から聞き、予想されていたことではあるが難しいなと思った。

[Kuro | PdM @booksoccermark]

ユーザー理解の「5つのスキルレベル」
https://t.co/GJ2po3e6G2
「ユーザー理解」という言葉はフワッとしていますが、分解すると明確に5つのスキルレイヤーが存在すると考えています。

Lv.1：仮説構築スキル（設計）
「とりあえず話を聞こう」ではなく、「何が分かれば意思決定できるか？」「そのための仮説と仮説のサポート / 棄却の指標と基準は何か？」という地図を持ってインタビューをするためのスキル。

Lv.2：深掘りスキル（実行）
「ドリルが欲しい」に対して「どんなドリル？」と聞くのではなく、「いつ/ どこで/どうやって/何がきっかけで/どういった手段で/その程度のコストをかけて穴を開けたいの？」など背景（コンテキスト）を掘り下げる力。

Lv.3：事実と解釈の分離スキル（分析）
「ユーザーは欲しがっていた」は自分の解釈。 「今の作業に週3時間かかると言った（事実）」と「だから自動化を喜ぶはずだ（解釈）」を明確に分けて記録できているか？

Lv.4：一般化スキル（結合）
N=1の強烈なインサイトを、ログデータやアンケート（定量）と突き合わせて「これは全体にどれくらいいる課題か？」を検証する力。

Lv.5：構造化スキル（接続）「いい話聞けたね」で終わらせず、インサイトを具体的な「UIUX」や「仕様書」に翻訳する能力。

[けんすう @kensuu]

やる前は「AIを使えば余裕じゃん」と思われたサービスの微調整が大変すぎて、全然楽になっておらぬ。80点までは今までの1/100で作れてしまうが、90点を取るのには、今までの50%くらいの労力がかかり、95点を取るのには、今までの80%くらいの労力がかかる印象。

[ナゾロジー@科学ニュースメディア @NazologyInfo]

約100万年前、人類は1300人まで減り「絶滅寸前」だった
https://t.co/8wVHPG0C3J

米ISMMSらは新たなゲノムの多様性調査から人類の祖先がかつて人口を激減させ絶滅寸前に陥っていたことを発見。この危機を乗り切った後、現生人類やネアンデルタール人、デニソワ人などへ分岐した可能性がある

[Kuro | PdM @booksoccermark]

プロダクトマネージャーは、顔の見えないエンドユーザーに対しては、「どんな課題を持っているのか？」「どんな言葉が響くのか？」「どんな体験を求めているのか？」を必死に想像します。
https://t.co/58g3LCuC2p

でも毎日顔を合わせる身内のチームメンバーに対しては、その想像力が驚くほど欠如してしまうことがあります。

チームを動かすために必要なのは、メンバーを「『プロダクト開発』という体験を提供する対象ユーザー」と捉え直すこと。

☑️エンジニアというユーザーのインサイト：技術的負債を嫌う、美しいコードを書きたい、理不尽な手戻りを避けたい。
☑️デザイナーというユーザーのインサイト：ユーザー体験を損なう仕様を嫌う、クリエイティブへのリスペクトが欲しい。
※単純化のためにわかりやすいものを記載しています

彼らのインサイト（根源的な欲求）を理解せず、ただ自分の要望（仕様）だけを一方的に押し付けるのは、マーケティングの世界で言えば悪質な「押し売り」と同じです。

D・カーネギーは名著『人を動かす』で、「人の立場に身を置く」ことが全ての出発点だと説きました。これはPdMの実務にもそのまま当てはまります。自分の要求を、相手のメリットや価値観と接続する努力を怠ってはなりません（自戒の念を大いに込めて....）。

[OpenAI @OpenAI]

Building apps has never been easier.

With Sites, Codex can turn your work, ideas, and plans into an interactive website or app your team can explore, use, and share with a URL.

Rolling out to Business and Enterprise plans, before expanding more broadly.

[うちた @uchita_success]

https://t.co/T9P5Qn8T7C

[Kuro | PdM @booksoccermark]

「正解探し」でチームを止めるな。PdMの価値を最大化する『決める技術』と、泥臭く『前に進める』推進力
https://t.co/yImhLx9cTR
☑️「失敗したくない」という心理から、細かい論点潰しやデータ収集に時間を使いすぎ、結果としてチームの足を止めてしまう「分析麻痺」の状態は問題

☑️原因は 意思決定を「正解当てクイズ」だと誤解していること。そして、反対意見を持つメンバーや後輩PdMを納得させ、巻き込むための「具体的・政治的な作法」を知らないこと。

☑️解決のために 「撤退ライン」を握ることで反対派を合意させる技術、後輩PdMへの「権限委譲」の急所、そして開発フェーズでの「雪かき」による速度最大化が必要」。

[Kuro | PdM @booksoccermark]

ユーザーインタビューを設計、実施、分析する際のポイントとチェックポイント
https://t.co/Fwb1huoPSj

[Kuro | PdM @booksoccermark]

めちゃくちゃいいポスト

[Andy | ドラッカーを実践する参謀 @findurtalents]

https://t.co/wqHFYYixza

[Kuro | PdM @booksoccermark]

機能追加で失われたプロダクトのコンセプトを取り戻すリサーチ設計
https://t.co/7NkZy1w8kf

[Kuro | PdM @booksoccermark]

いいインサイトの条件（ストーリー性が鍵）

ありきたりに思える発見でも“いいインサイト”になる条件は以下のポイントに集約されます。

1 / 行動変容をもたらす
インサイトをもとに施策を行ったとき、ユーザーが実際に行動を変えてくれるか。変化が起きるレベルならば“当たり前”と侮れない

2/ プロダクトや事業の方向性と整合する
組織が目指すビジョンや方向性と矛盾がなく、むしろ深める役割を担う。ストーリーが一貫しているかどうかが重要

3 / シンプルかつ強固である
複雑でコピーライティングされたおしゃれな文章で構成される仮説より、誰が聞いても理解できるシンプルな着眼点のほうが社内外で合意形成しやすい。シンプルが強力

ありきたりに見えるインサイトほど、実は多くのユーザーが共通して抱えている可能性が高い。そしてそれをビジネス上で突き詰めるためには、「一貫した物語を築きあげる」「競合もやっているかもしれないけどそのインサイトにフルベットする」ことが必須になります。物語の要素が欠けていると、「分かるけど何かピンと来ない」という曖昧な施策に留まってしまいがちです。

https://t.co/UTN1tsnqfH

[Kuro | PdM @booksoccermark]

「検索機能を実装する」 このユーザーストーリー1枚で開発に入ると、後半で必ず揉める。
・ 「え、検索履歴は残らないの？」
・「サジェストは？」

アジャイル開発であっても、PMBOKの「WBS（作業分解構成図）」の思考プロセスは極めて有効。 ストーリーを実装タスクレベル（API設計、DB構築、UI作成...）まで分解し、構造化する。

これにより、「今回はサジェスト機能はスコープ外（Out of Scope）」という線引きが明確になる。 WBSはガントチャートを引くためではなく、チームと「やらないこと」を合意するために使う。

https://t.co/VDPtf0Q6xr

[Kuro | PdM @booksoccermark]

claude codeをデータ分析、戦略策定、プロジェクトマネジメント、測定の自動化、slackコミュニケーション代理、ROI測定、プロトタイピングなどなどいろんなところに使えばアウトプット速度とか成果はめちゃよくなっているんだが、労働時間は伸びている気がする。。

他の職種とか他の人と壁打ちとか確認することなく勧められる部分が増えてきて、どんどん課題特定とかその課題解決のため推進を自分 x claudeで担う領域が増え、パーキンソンの法則を実感している。

[Kuro | PdM @booksoccermark]

「怖い人」「話しづらいリーダー」を卒業するための4つのポイント（自戒の念を込めて）。
https://t.co/58g3LCuC2p
1. 指摘の前に「クッション言葉」
リーダーや上司からの指摘は、本人が思っている以上に鋭利な「言葉のナイフ」になり得るもの。そのまま突き刺せば、部下やメンバーは深く傷つきます。クッション言葉を使ってください。

・「言いにくいことなのですが……」
・「急な変更で申し訳ないのですが……」
・「すみません、僕が理解できてなくてもう1回聞きたいです……」
この一言があるだけで、相手の心の防御壁が下がり、聞く耳を持ってもらえる確率が格段に上がります。

2. 尋問調の「Why」を、解決志向の「What / How」に変える
「なぜ（Why）」という言葉は、過去の原因追及に使われると、相手には「人格攻撃」として響きます。「なぜ遅れたんだ？」と聞かれれば、誰でも責められていると感じます。

これを未来志向の問いかけに変換しましょう。

☑️× Why：「なぜスケジュールが遅れたんですか？」（過去への責任追及）
☑️〇 What：「何がブロッカーになりましたか？」（事象への着目）
☑️〇 How：「どうすればリカバリーできそうですか？ 私にできることはありますか？」（未来への解決志向）

主語を「あなた」から「課題」に変えることで、対立関係ではなく、「一緒に課題に向き合うパートナー」という立ち位置をとることができます。

3. コミュニケーションでの「感情コスト」を払う
オンラインでのテキストコミュニケーションは、対面と比べて感情が3割引きで伝わると言われています。あなたが普通のテンションで打った「了解」という二文字を見て、相手は「怒ってるのかな？」と不安になるのです。

そこで、リーダーこそ、意識的にオーバーリアクションをとりましょう。「ありがとうございます！！！」と「!」を多用したり、感謝の絵文字（🙏）を添えたりする。これを「媚びている」「無駄だ」と思わないでください

「私は今、不機嫌ではありませんよ。安全ですよ」と可視化するためのコストを払うのも、チームを円滑に回すための重要な仕事です。

4. 「業務外の雑談」で信頼残高を貯金する
「仕事の話以外は時間の無駄」と考えていませんか？それは、銀行にお金を預けず（信頼を作らず）、引き出し（要求）だけを繰り返すようなものです。

いざという時の「無理なお願い」を聞いてもらえる強固な関係性は、完璧な正論や指示書からではなく、日々のくだらない雑談から生まれます。1on1で週末の話を聞く、チャットツールで趣味の話に反応する。この一見「無駄な時間」こそが、最高のチームを作るための最も確実な投資なのです。

ビジネスにおけるコミュニケーションとは、極論すれば「他者への想像力」のことです。論理の先に、感情を持った人間がいることを忘れないでください。

[Kuro | PdM @booksoccermark]

顧客解像度をチェックするための質問リスト

[Kuro | PdM @booksoccermark]

リリース直前の修羅場で、プロダクトマネージャーの真の推進力が試されます。

開発が進むにつれ、「思ったより実装が難しい」「予期せぬバグが出た」などの理由で、スケジュール遅延が見えてくることはよくありますよね。

この時、失敗を恐れるPdMは「エンジニアに気合を入れ直す（残業をお願いする）」か「納期を延ばす」選択をしがちです。

でも真に推進力のあるPdMは、ここで「スコープを削る（Descoping）」という決断ができるもの。

【「勇気ある撤退」の3ステップ】
☑️コア価値への立ち返り
「今回のリリースで検証したい最大の仮説（コア価値）は何か？」にもう一度立ち返ります。それに直結しない機能は、すべて削減対象です。

☑️具体的な削減案の提示
・ 「この機能はマストじゃない。フェーズ2（次回のリリース）に回そう」
・ 「このアニメーションは凝らなくていい。標準の挙動でいこう」
・ 「レアケースのエラーハンドリングは、一旦汎用的なエラーメッセージで対応しよう」
このように、エンジニアと相談しながら、削減してもコア価値が損なわれない部分を具体的に特定します。

☑️ステークホルダーへの説明と合意
スコープを削ることは、当初の約束を破ることにもなりかねません。だからこそ、「なぜ削るのか（納期を守るため、コア価値を最速で届けるため）」を丁寧に説明し、ステークホルダーの合意を取り付けます。

捨てることは、作ること以上に勇気がいります。しかし、この「勇気ある撤退」こそが、Time to Market（市場投入までの時間）を守り、ビジネスを前に進めるのです。

[Kuro | PdM @booksoccermark]

後輩プロダクトマネージャーの「動きが悪い/遅い」を自分ごととして解決する

あなたが先輩として後輩PdM（ジュニア/ミドル層）にプロジェクトを任せる時、「なんでこんなに進捗が遅いんだ」「いちいち細かい確認をしてくるな」とイライラすることはありませんか？

それは多くの場合、後輩の能力不足ではなく、あなたからの「Why（判断基準）の共有」が不足していることが原因です。

「この機能のPRD作って / このテーマのプランニングをして」とWhat（やること）だけを渡すと、後輩は判断に迷うたびに、あなたに「これで合ってますか？」と確認しに来ざるを得ません。これが速度低下の原因です。

【後輩PdMを加速させるために必要なこと】
☑️「意思決定のロジック」をインストールする
タスクを渡す前に、Whyを徹底的にすり合わせます。 ・なぜこの機能が必要なのか？（背景・課題） ・誰のどんなペインを解決するのか？（ターゲット） ・成功は何で測るのか？（KPI・目標） ・意思決定の判断基準（トレードオフ）は何か？（例：リリース速度優先か、品質優先か）
☑️構造的なレビューを行う
PRD（製品要求仕様書）のレビューでは、てにをはの修正といった細かい指摘（Howへの口出し）は後回しにします。「課題の特定は合っているか」「ソリューションは課題に対して適切か」といった構造的な部分にフィードバックを集中させます。
☑️「失敗しても責任は持つ」と背中を押す
Whyを共有したら、あとはHowを任せます。「判断に迷ったら相談して。責任は僕が持つから、思い切ってやっていいよ」と心理的安全性を担保します。