読者です 読者をやめる 読者になる 読者になる

ninjinkun's diary

ninjinkunの日記

山種美術館

f:id:ninjinkun:20170302123848j:image

東京に住んで良かったことの一つに、山種美術館との出会いがある。恵比寿にある日本画専門の美術館で、自分は新しい展示が始まる度に通っている。

この美術館で好きなところは、作品との距離がとても近いことだ。たいていの作品は額まで寄って眺められる。細かい書き込みと大胆に省略されている部分を比較したり、絵筆の動きを想像すると楽しい。また、金箔が張られている作品などは光の当たり方で見え方が全然変わるので、体を動かしながら眺めると面白い。

今やっている日本画の教科書 東京編は山種コレクションの総力戦という感じで素晴らしかったのでお勧めしたい。

 f:id:ninjinkun:20170302124536j:image

基本的に写真は撮れないが、こんな感じでときどき許可されているものがある。

結婚退職無職

昨年11月に結婚し、2月に勤めていたFablicを退職して京都で暮らしている。

結婚

3年前に上京して、京都に住んでいる彼女と遠距離恋愛をしていたのだが、昨年末に結婚した。現在は京都で一緒に暮らしている。毎晩一緒にお酒を飲めるのが楽しい。

退職

会社を辞めた理由としては、会社が昨年夏に買収され、自分の中でスタートアップ欲求が一段落付いたというのが一つ。もう一つは妻の仕事が3月まで忙しいことがわかっていたので、せっかく結婚したのだし、しばらく一緒に居る時間を作ってサポートするのも良いんじゃないかと思い、このタイミングになった。

Fablicにはスタートアップの黎明期から拡大期に移るタイミングで入社し、フリルのiOSネイティブ移行、AndroidのMaterial Design対応、RIDEの開発など、様々な楽しいプロジェクトに関わらせて頂いた*1。また、自分のわがままを聞いてもらって、プロダクトマネージャー見習いをやるチャンスもいただいた。素晴らしい同僚と製品に深く感謝する。

無職

今のところは就職していない。妻の仕事がとても忙しい時期なので、自分が家で一通りの家事をやっている。と言っても二人暮らしなのでやることは知れていて、基本的に自分の時間は多い。知人には「僕が言う主夫は、主にAmazonビデオを見る夫の略です」と自己紹介している。

今後

今後については今のところ白紙で、時間はあるのでじっくり考えようと思っている。

東京はやはり仕事環境として魅力的なので、関西の会社を探しつつ、東京と京都を往復する生活をまた再開することも視野に入れているという感じである(東京勤務の場合、平日は普通に出勤、週末は京都に帰り、慣れてくれば週一くらいでリモート勤務できると嬉しい)。3月からは、いくつかの会社でお試し勤務をしてみる予定も入っている。

東京時代にお世話になった方々、ありがとうございました。また東京にも月一くらいで行くので、飲みに行くぞ。Skype飲みなら気軽に出てくるぞ。

関西の皆様、飲みに行くぞ。

Product Managers Japanは自分が幹事なのもあって、ときどき東京に行って続ける予定である。DroidKaigiのスタッフは幽霊部員になってしまってすみません…。

写真は退職記念に買った複製画*2。家で撮ると台無しな感じもありますが…

Amazonウィッシュリストこちらです。

*1:仕事でやったことはLinkedInに書いていこうと思っているので、細かいことはそちらで

*2:オリジナルは現在恵比寿の山種美術館で展示中なはずなので、そちらを見に行きましょう

アンダーグラウンドを読んだ

1996年の地下鉄サリン事件の被害者へのインタビューをまとめた本。今まで何度か読んでいるのだが、Kindle版が出ていたので読み返してみた。

この本の特徴は、地下鉄を使っていた被害者たちの日常に焦点を当てているところだと思う。インタビューに答えているのは主に会社に勤めている人、防衛省の人、営団地下鉄に務めている人たちなどだ。どういう経緯で東京の職場に務めることになったのか、毎日どの様に通勤しているのかといったそれぞれのストーリーが語られた後で、それがサリン事件によってどのように奪い去られたかが明らかになる。人々の日常を破壊する暴力を、六十数人のインタビュイー個人の視点から追想する。それは必然的に、一言で表現できない重層的な物語になる。

自分は当時名古屋に住む小学生だったので、この事件のことは曖昧にしか覚えていない。しかしこの本を読んでから東京で日比谷線に乗る度に、この事件のことを考えるようになった。被害者が救急搬送された神谷町や霞ヶ関、築地など、事件があった場所を所用で通ることは何度もある。もちろんそれらの駅には事件の痕跡を示すものは見当たらないが、この本の内容を覚えている自分には、車内でサリンが散布されてから駅が閉鎖されるまでの光景を想像することができる。怖いとかトラウマとは違う。それは(事件後に警備が相当強化されていることは重々承知しつつ)今ここで起こってもおかしくないことなのだと、ただ思うのだ。

自分の生活と地続きの暴力について考える機会になる、優れた本だと思う。後書きの部分に、一連のインタビューを通過した後の村上春樹の物語に対する姿勢というか、態度の表明が濃いめに書かれているのも興味深い。

ハイアールの冷蔵庫を買った

冷蔵庫を大容量のものに買い換えたいと思って色々見て回ったのだが、結局ハイアールの製品に決めた。

電気店では日本メーカーの冷蔵庫が強く推されているのもあり、自分も当初は日本のメーカーの製品を買おうと思っていた。カレーなどをたくさん作って保存しておく習慣があるので、シャープ製のものが冷凍庫が大きくて良いかなと思って、一度は購入までした。しかし家に搬入する際に入り口の部分で引っかかって、設置することができず返品になったのである。

その後、改めて入り口に入る寸法の冷蔵庫を探すうちに、冷凍庫が大きくて寸法がちょうどのハイアール製の冷蔵庫が候補に浮かんできた。自動製氷などの便利な仕組みは全くないが、値段は他の国産メーカーの半額である。省エネ性能に至っては国産メーカーより優れているらしい(スペックを信じるならば)。

購入して一ヶ月ほど経つが、元々高度な機能が皆無な冷蔵庫を使っていたせいか、不満は特にない。冷凍庫が大きいのは大変便利で、作り置きが加速している。高度な機能が不要な人は、こういうのでいいのかもしれない。

余談だが、急速冷凍機能は金属製のバットでシミュレートできた。

コンテナ物語を読んだ

少し前に知人たちの間で話題だったので読んでみた。物流で使われるコンテナをキーに経済のグローバル化を紐解く本という感じである。世界の港から湾口労働者が閉め出されていく様や、日本やアジアの国がコンテナによってサプライチェーンを構築したり、その一部になっていく様子が描かれている。

歴史やイノベーションの本として読むのが本筋なのだろうが、自分は主に現代の物流を解説する本として読んだ。自分が普段触れる物流というのは宅配便や小売店のトラックくらいだけれど、その向こう側に船、鉄道、航空機による輸送がある。そしてそれらの要素が自分の生活にどう結びついているかが、少しイメージできるようになった気がする。この本を読んでから、港に行くたびにコンテナドックを探してしまうし、貨物電車を見る度にコンテナの種類を数えたりしてしまうようになった。

知らない領域の仕組みや、その内側での変化を解説した話は大変面白いので、こういう本をもっと読みたい。

コンテナ物語

コンテナ物語

現在の自分とプロダクトマネジメント

PM

最近人に会うと、プロダクトマネジメントに詳しいと思われることが多い。確かにいくつか 関連するエントリも書いているし、Product Managers Japanのまとめ役*1 もやっているのでそう思われるのかもしれない。

しかし自分はプロダクトマネジメントについて座学で勉強はしたが、実際のプロダクトマネージャーとしての経験は合計9ヶ月くらいしか無いのだ。しかも誇れるほど数字を上げたという経験はほぼ無い。

プロダクトマネージャーは実際に関わった製品が成功することでしか評価されない職業だと思うので、残念ながら現状ではプロダクトマネージャーとしてのキャリアはだいぶ薄いと言わざるを得ない。もちろん今後はもっと経験を積んで実績を出していきたい思っているが、今の自分はプロダクトマネジメントの知識を持ったエンジニアと自己紹介する方が妥当だろう。

人と会った際に期待値がずれることを減らしておきたくて、なんとなく書いておいた。

*1:こちらはantipopさんに指名されたという経緯でやっている(もちろん楽しんでいるが)

「ボトムアップの見かけはとても重要」

PM

この記事はProduct Manager Advent Calendar 2日目の記事です。

先日Japan Product Manger Conferenceに参加して、ポケモンGOの開発元であるNianticでPMをされている河合さんのセッションの中で印象的な言葉があったので書き留めておく(セッションの詳細はプロダクトマネージャーに必要な資質って何ですか? 元グーグルのPM対談 | HRナビ by リクルートで読める)。

会場からの質問で、「開発者に仕事を任せる際に、上からやることをお願いするトップダウン型と、開発者が自発的にアイデアを出してくるボトムアップ型があると思うが、どちらがいいと思うか」(うろ覚えだけど、だいたいこんなニュアンスだったはず)という質問に対し、河合さんは一呼吸置いてからボトムアップの見かけはとても重要」と回答されていた。

これはPMの中では既に実現方法(おそらくUIや実装方法)が決まっていても、それをトップダウンで命令するのではなく、メンバーの口から「これをこういう形で自分がやりたい」と言葉にしてもらうことで、ボトムアップの形にするということのようだった。

その後に続く及川さんと河合さんの掛け合いの中で語られていたボトムアップ型のメリットとしては、

  • 開発者のモチベーションが上がる
  • 自分のアイデアが間違っていた場合にもメンバーが正してくれる

という点が挙げられていた。

自分も後から振り返って、あのときはうまくマネジメントをしてもらったな思う経験が何度かある。これらの経験には基本的にオーナーシップが自分にあると感じられて、自発的にアイデアを出すことで製品が前に進んでいる感覚が得られているという点が共通していたので、このボトムアップ型スタイルに近いものだったと思う。

まとめると、及川&河合流の開発チームとのつきあい方とは、ボトムアップで上がってくるアイデアを歓迎しつつ、トップダウンで進めたいこともできる限りボトムアップの形に変換することだと自分は解釈した。これがサーバントリーダーシップ呼ばれるものなのかはよくわかっていないのだが、メンバーの自発性と創造性を引き出すためのコミュニケーションに心を砕くスタイルなのだと思う。

いつもうまく行くわけではないし、絶対にメンバーの口からは出てこないような面倒な仕事の場合(例えば広告枠を増やすとか)は直にお願いする以外にないが、自分がマネジメントをする際にはできる限りこのスタイルを踏襲していきたいと思った。*1

余談だが、及川さんがセッション中で「色んなところでこの話をするので、だんだん会社のメンバーに仕掛けがばれてきてる気がする(笑)」と言っていたのが面白かった。種が明かされていても、メンバーが「俺の頭を使おうとしてくれているんだな」と思ってくれれば特に問題はなさそうである(逆に「俺にも脳みそついてるんだけどな」と思われたら失敗)。

*1:トップダウンで決められる方が良い人も居るとは思っていて、この手法は System of Record と System of Engagement // Speaker Deck で言うSoE向けのマネジメントと言うことになるのかもしれない

マーケティング戦争を読んだ

Webマーケターの知人に「マーケティング初心者に一番おすすめの本教えてよ」と尋ねてみて、この本を推薦してもらったので読んでみた。戦争で使われる戦略をマーケティングに当てはめて、実際のマーケティング戦略を解説していくという内容の本である。戦争の引用がどれだけ妥当なのかはわからないが、とりあえず歴史好きや小説好きであれば面白く読めると思う。自分は一気に読んでしまった。

印象に残ったことをかいつまんで箇条書きにすると

  • 基本的に戦いは人数が多い方が勝つ
    • なのでビジネスにおいては営業の人数や広告予算が多い方が勝つ事が多い
  • 防衛するのは攻撃するより容易だ
    • なのでトップの企業を蹴落とすのは容易ではない
  • 製品のイノベーション、品質の高さ、人材の優秀さだけで逆転できることはほとんどない
  • 規模が小さければニッチに特化したゲリラ戦を仕掛けろ

という感じだった。そしてビール戦争、コーラ戦争、コンピューター戦争と実際のケースに当てはめる章が続く。

競合との関係で自社をどこに位置づけるかを考え、そこから戦略を演繹しろというのはこの本に限らず色々なところで言われていることだとは思う。自分の会社も激しい競争の中に居るので、読みながら改めて考えさせられた。

一方で、明日から自分の仕事に使えるかというと、特にそういう感じはしない。話のレイヤーが経営レベルの製品戦略なので、毎日の施策をどうするかという戦術の話は省かれているからである。マーケティング関係の人の頭の中を覗くという意味では参考になった。

また、この本ではクライスラーを立て直したリー・アイアコッカマーケティングの天才と言って持ち上げているが、確か昔読んだビジョナリー・カンパニー 2 - 飛躍の法則 ではこの人はこき下ろされていたはずで、見る人や時代によって人物や戦略への評価も全然変わっていくものだなと改めて感じた。この手の本は小説のように読むくらいがいいのかもしれない。

少し昔の人なので現役時代を知らなかったのだけど、アイアコッカのWikipediaを見ると経歴も評価も凄まじい感じで面白い。

マーケティング戦争 全米No.1マーケターが教える、勝つための4つの戦術

マーケティング戦争 全米No.1マーケターが教える、勝つための4つの戦術

UberEATS

会社がUberEATSの対象領域にあったので、数日使ってみた。単純に500円で美味しいものが食べられるサービスとして使っている。

お店の厨房に余裕がある時にしかリストされないようで、時間によって出てくるお店がどんどん変わる。食べたいもののイメージがあっても、その時間にお店が出て来ないことが多く、多少のストレスがある。12時から13時くらいまではお店が少ない傾向にあるので、その前後で注文するというハックが必要だった。

注文できるお店があっても、バグでよくこの画面が出る。画面自体もはみだして崩れている。

11/12追記

500円キャンペーンが終わって案の定使わなくなってしまった。しかし会社のメンバーはお昼に外食をしなくなり、お弁当を食べる習慣だけが残った。

【翻訳】プロダクトマネジメントトライアングル

PM

はじめに

プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、「プロダクトマネジメント」を正確な言葉で定義することは驚くほど難しい。自らを「プロダクトマネージャー」と呼ぶ人々は、企業ごとに全く違うことをやっている。彼らは異なるタイプのプロダクト、異なるタイプのチーム、異なる組織構造の中で働いている。このプロダクトマネジメントの立場の違いは、とても不毛だ。外の立場から見ていると、同じ肩書きの仕事を参照する際に、誤解を引き起こしているように見える。全てのプロダクトマネジメントの仕事を統合して、共通の話題を抽出しようとすると、価値を説明しようとしても最終的には極度に抽象化した言葉になってしまう。例えば、機能横断型チーム間におけるプロダクトマネジメントの責任について、部分的には正確だが曖昧な説明として、「空白を埋める」「糊の役割を演じる」などが含まれる。

このプロダクトマネジメントの役割についての曖昧さは、プロダクトマネジメントの本質に近い。一つの会社の中でも、プロダクトマネジャーの役割は根本的に、そして急激に変わりうる。プロダクトマネージャーは景色が根本的に変化する中で活動する。技術は変化し、チームの力学も変化し、社会も変化し、新たなビジネスの機会が予期せずやってくる。そういった変化が、プロダクトと自らの役割にどいういう意味を持つかを理解することは、プロダクトマネージャーの特別なスキルセットだ。その意味において、プロダクトマネージャーは自らのジョブディスクリプションを定期的に書き換えなければならない。

しかし、周りの世界の変化に合わせて、プロダクトが成長するためのニーズを特定し、実装するための確かな手法とはどんなものだろう?プロダクトマネージャーは、他のものとの間に立って、とても概念的なこと(例えば世界を変えるビジョン)ととても具体的なこと(例えばある一つのボタンの機能要求仕様)との間に橋を架けることを専門にしている。皮肉にもプロダクトマネジメント自身の領域には、この橋が見当たらない。我々には、毎日やっていることのリアリティを伴った、プロダクトマネジメントの高度な責務を繋ぐ明確なフレームワークが欠けている。私はこの橋となり、プロダクトマネジメントの話題を深く探求する基礎として、プロダクトマネジメントトライアングルというグラフィックモデルを考案した。

プロダクトネットワーク

このモデルを説明するための準備として、まずプロダクトマネージャーが活動する領域について説明する必要がある。以下のプロダクトネットワークの図は、私がソフトウェア製品のコンテキストで根源的な要素だと信じているものを表現している。プロダクトと、それを開発したり使ったりする人々の多くの傾向は変化するが、以下の要素は常に現れる。

network.png
図1: プロダクトネットワーク

プロダクトネットワークの中心に位置するのは、プロダクト自身だ。ソフトウェア会社におけるプロダクトは事実上、人々がアクセスできる環境にデプロイされたコードで構成されている。全てのプロダクトは三つのこと、開発者、ユーザー、ビジネスで繋がっている。

開発者(もしくはエンジニア)はコードを書いてデプロイできる人たちだ。会社にはたいていプログラミング以外のプロダクトの仕事をしている人たちが居るが、コードをアップデートする人たちこそが唯一厳密に欠くことのできないチーム要員だ。開発者は会社のすべての責務を担うことができる(常に効果的にとは行かないが)。

ユーザー(またはやや大ざっぱには「顧客」)はプロダクトを使う人、プロダクトを使うかもしれない人の両方だ。全てのプロダクトは人によって様々なレベルで使われるというゴールを持っている。

ビジネスはプロダクトへの投資と恩恵(例えば利益)を期待する存在だ。組織が営利であれ非営利であれ、限られた量の資金を持った部門が存在する。

whitespace.png
図2: 空白領域

この明白な一連の要素だけでも、ネットワークの中でプロダクトを成り立たせることは可能である。開発者と、ユーザーベースを築くという夢のために、会社が経済的に持続できるように資金を提供してもうことは可能だ。しかしそれは空白を無視している。「空白」はプロダクトネットワークのミッシングリンクを暗示している。この空白を埋める役割があれば、プロダクトネットワークはより良く機能し、そして最終的にはより成功するプロダクトへと導くことができる。具体的には、図2のA、B、Cに示されている3つの空白がある。

空白領域A

領域Aは開発者、プロダクト、ユーザーの間にある空白だ。開発者とユーザーは、プロダクトについて異なるメンタルモデルを持っている。一方の開発者は彼らが作ったプロダクトを使うことは可能だが、彼らのメンタルモデルにはプロダクトがどう実装されたかという知識が染みこんでいる。このため、将来的な機能強化を検討する際に、ハードワークする優秀なエンジニアたちは、比較的少ない労力で厄介な複雑性をコードベースに追加しない解決策を取るという、自然なバイアスを持っている。他方のユーザーは、画面の操作を通してしかプロダクトを知らない。彼らはプロダクトが裏側でどう動いているかを、教育による理解によって説明することも可能だと思われるが、彼は知らないし関心も無い。ユーザーは作るためにかかったコストやコードの美しさは気にかけず、自らの満足や抱えている問題を解決するためにプロダクトを使うのだ。

ユーザー視点を通してプロダクトに対して適切な見方ができ、この空白を埋められるエンジニアたちも居る。その一方で成長するビジネスは、ユーザーと開発者の間の橋渡しになる専門の頭脳を必要としている。デザイナーの役割はこの最も明確な実例だ。デザイナーはユーザーのメンタルモデルを理解し、開発者の実装に合わせてユーザーインターフェイスを考える責任を持っている。しかし他の職種もこの空白を埋めている。Webアナリティクス、マーケティング、ユーザービリティ調査、IA(インフォメーションアーキテクチャ)、テクニカルサポート、コミュニティマネジメント、QAなどの名前が挙がる。この中のいくつかの職種は、開発チームにユーザーを理解させることに注力している。また他の職種は、プロダクトをより良くするために既存のユーザーと交流したり、新しくユーザーになる可能性がある人を呼び込むことに注力している。

空白領域B

領域Bはユーザー、プロダクト、ビジネスの間に存在している。これは(願わくば)人々がプロダクトを使うことを、ビジネスの利益(もしくは他の利点)に転換できる価値がある場所だ。この領域の複雑さは大まかに以下のどちらかで説明できる。

  1. ユーザーが直接プロダクトにお金を支払う、もしくは
  2. ユーザーのアテンションを広告主に売る

1の例はEコマースや、サブスクリプション型のプロダクトだ。この場合での空白領域Bの職務は、会社の資産を使って効果的に見込み顧客を惹きつけ(従来型の広告やSEO、営業などを通して)、それぞれのユーザーから可能な限りの収益を特定し、最も儲かる市場にプロダクトの拡大を導いていくことである。

2の例はソーシャルネットワークとメディアの会社だ。この場合は複雑だ。なぜなら、あなたはプロダクトネットワークの「ユーザー」を、二つに分けなければならないからだ。それは (A) プロダクトの表面上のユーザー(例えばFacebookに投稿する人、ニューヨークタイムズを読んでいる人)と、(B) そのユーザーにリーチするためにお金を払う広告主だ。この場合は空白領域Bのプレイヤー達の役割は、ユーザーの好み、人口統計的データ、行動、関心を特定するためにプロダクトデザインに影響を与えて、広告主の利益を最大化することだ。彼らはまた、見込みのある広告主にプロダクトを売り込み、利益に最適化した価格モデルをデザインしなければならない。

もしかするとここには第三のケースとして、はじめはユーザーベースの成長に取り組んで、マネタイズは後に回すという、ベンチャーキャピタルの資本を入れたスタートアップも入るかもしれない。このシナリオでも空白Bを埋める人々のニーズはある。その職務では、投資家を喜ばせ続け、プロダクトが未来にマネタイズ可能になることを世界に知らせる空虚な指標(ユニークユーザー、ページビュー)を成長させる必要がある。

空白領域C

領域Cはビジネス、プロダクト、開発者の間に位置している。ここは会社がどこに投資をして開発力を集中させるかを判断する場所だ。高い視点から見ると、これはプロジェクトを導く光の役割を果たすビジネスビジョンの策定と、それによるコミュニケーションを必要とする(ときによってはCEOが仕事として持つ)。低い視点から見ると、特定のエンジニアリング的な機能、雑用やバグ修正の優先順位付けを必要とする(ときによってはプロジェクトマネージャーが仕事として持つ)。技術的なニーズを埋める際には、「買収 vs 開発(buy versus build)」というハードな質問に答える必要もある。空白Cは会社がアイデアを実行に移す場所である。

参考までに、私は下の図3にそれぞれの領域の空白を埋める役割の例を含めておいた。これは網羅的なリストというわけではなく、それぞれの領域の雰囲気を手っ取り早く伝えることを意図している。

pillars_template_roles.png
図3: 空白領域それぞれを埋める職種の例

我々はプロダクトネットワークの基本的な要素の間にある、空白領域A、B、Cが何を示しているかを議論してきた。会社が成長するにつれて、これらの領域は要素を繋ぐ連帯によって埋められていく。デザイナーはユーザーと開発者を繋ぐ連帯を築くために採用され、ビジネス開発部長はユーザーとビジネスを繋ぐために採用される。

pillars_template_roles2.png
図4: プロダクトマネジメントの責任範囲

多くの役職が追加されるにつれ、プロダクトネットワークの要素たちは異なった方向から引っ張られるようになる。図4の領域AB、BC、ACは、しばしばプロダクトネットワークの要素ごとに矛盾したインプットが一度に集まる場所になる。私はこれらの各スペースを「融合領域」と呼んでいる。

融合領域AB

pillars_template_roles_ab.png
図5: 融合領域AB

融合領域ABは空白Aからのインプットが空白Bからのインプットと出会い、ユーザーに一貫したストーリーを形成する場所である。この領域の人々は、ビジネスのニーズを理解しながらユーザーにとって価値があるプロダクトを作ることに集中する。またこの人々は、プロダクトのユーザー体験パラメーターを理解しながらマネタイズをする責任も負っている。私は領域Bの複雑さは以下のように表せると前述した。

  1. ユーザーが直接プロダクトにお金を支払う、もしくは
  2. ユーザーの注目を広告主に売る

どちらの場合の運用も、融合領域ABの緊張関係の大きさに重大な意味を持っている。1の場合の緊張関係は相対的に少ない。なぜならユーザーにプロダクトを好きになってもらうのと、会社に多くの利益をもたらすことのは同じことだからだ。プロダクトを重要なものに改良していくことで、より多くの人が知り、お金を払うことになる。しかしながら2の場合は、一つのプロダクトを作る中でユーザーと広告主にとって価値を届けるという避けがたい対立が存在する。広告はユーザー体験を低下させ、企業広告主との結びつきは信頼をむしばむ。一方でユーザー体験の効率を上げることは、しばしば広告のインプレッションを下げることに繋がり、利益を減らす要因となる。これはトレードオフを天秤にかけ、会社全体のニーズに合わせたプロダクトソリューションを生み出すために、ビジネスとユーザーのニーズを組み合わせる人間にとっては重要である。

この融合領域のニーズは、隣接した空白領域からやって来る直交したインプットに限定されるわけではない。ときどき一つの領域からも、複数のインプットが調整を求めてくることがある。たとえあなたが空白領域Bからやってくるプロダクトへのビジネス的な要求を無視できたとしても、空白領域A内でインプット同士の衝突は起こりうる。例えば、それぞれのユーザーのニーズを代表する二人が、ユーザーに最適な体験をどう作るかで意見が一致しないことがあるだろう。ここにユーザー体験とチームメンバー同士の視点の対立を調整することに最終的な責任を持つ、独立した存在のニーズがある。

融合領域BC

pillars_template_roles_bc.png
図6: 融合領域BC

融合領域BCは、一貫したビジネス戦略を形成するために、空白Bにある帯と空白Cにある帯が一緒にならなければならない場所である。これはビジネスのアイデアがふるいにかけられ、ビジネスビジョンの中でリソース分配、優先順位付け、合併などを通して行動を始める領域である。空白Bを埋める人々は、プロダクトがどの様にビジネスの成長に寄与するのかについての仮説を立てる。ここには会社のミッション、目的、可能性についての物語を所有するニーズが存在する。新しいビジネスアイデアが発生するにつれて、融合領域BCはどんなコンセプトが会社の物語にフィットするのかを判断するものになる。強力なフィルターは、会社が市場と会社のコアコンピテンシーに基づいて、ベストショットを持っている開発分野に注力することができる。

融合領域BCは、会社の知識が体系化されている主要な領域である。プロダクトの仮説が成功するかどうかという学びが、会社の物語の中に組み込まれてることが不可欠だ。多くのスタートアップが彼らのコントロールの外で失敗している中、領域BCでの強いマネジメントに通じているスタートアップは、時間をかけて勝てるプロダクトアイデアを選び出す能力に磨きをかけることができる。

融合領域AC

pillars_template_roles_ac.png
図7: 融合領域AC

融合領域ACは、開発者とって明確で実現可能な計画を作るために、空白Aにある帯と空白Cにある帯が一緒にならなければならない場所である。空白領域Aからのインプットは、エンドユーザーの利益のためにプロダクトは理想的にはどう振る舞うべきかを説明してくれる。空白Cからのインプットは、与えられた利用可能な資源と、競合するビジネス上の優先順位を達成するために、何が可能かを決定づける。この2つの力が領域ACで出会ったとき、しばしばトレードオフが必要になる。理想的なソリューションは多くの場合、高価すぎるか、きちんと作るには時間がかかりすぎる。融合領域ACは理想主義のデザイナーの夢を打ち砕くところではない。それはビジネスのパラメータの範囲内で、ユーザーのニーズに叶うソリューションを考え出すところなのだ。

融合領域ACは実用最小限のプロダクト(MVP)という概念が生まれる場所である。MVPの開発とは、手元でビジネスの仮説を検証したり無効にしたりするための手法で、ユーザーがプロダクトに到達可能にするために最少量の労力を費やすことである。効果的にMVPを生み出せる会社の能力は、素早く反復し、学習し、究極的には成功するプロダクトを見つけ出す能力に等しい。MVPに機能を入れるのか入れないのかを決めることは、一種の芸術だ。このためには、何がユーザーにとって本当の問題で、プロダクトは発展のためにどのように位置づけられるかを感じ取る感覚が求められる。

プロダクトマネージャーの責任範囲

ここまでプロダクトネットワークとその様々な領域を見てきたので、我々はプロダクトマネジメントがパズルにどうはめ込まれるかを説明するためのコンテキストを手に入れた。最初にプロダクトマネジメント求められていないことが何かについて書いておくのは価値があることだ。幾人かのプロダクトマネージャーは、開発者の帽子を被ることができるにもかかわらず、プロダクトマネージャーの役割にはプロダクトそのものに手を触れること、例えばコードをアップデートすることは求められていない。それは開発者の仕事なのだ。プロダクトについて最も責任を持っている人間(プロダクトマネージャー)がプロダクトに直接手を触れることには責任を持っていないことが、プロダクトマネジメントの特筆すべき点である。

ではプロダクトマネージャーは何をすればいいのだろう?我々はこの謎めいた回答の正しい意味を知るための前提を既に手に入れている。

プロダクトマネージャーはプロダクトネットワークの全ての領域を健全に機能させることに責任を持っている

ここで言う責任は、ここまで話してきた空白領域と融合領域という2つの包括的なカテゴリーにマッピングされる。

  1. プロダクトマネジメントはプロダクトネットワークの要素間の重要な空白領域を認識し、埋めなければならない。すなわち領域A、B、Cのマネジメントだ。もし必須のリンクが見つからなければ、プロダクトマネージャーはそのリンクの役割を演じる、もしくは役割を埋める方法を探さなければならない。このために、プロダクトマネージャーはWebアナリティクスから顧客担当やプロジェクトマネジメントまで、プロダクトを取り巻く役割を曲がりなりにも適切に機能するくらいまでは務めることができなければならない。
  2. プロダクトマネジメントはプロダクトネットワークの各要素に影響を与えるために、異なるインプットを統合しなければならない。すなわち領域AB、BC、ACのマネジメントだ。プロダクトマネージャーはそれぞれの要素のための会社の物語を持っておく必要がある。開発者はやるべきことについての明快なストーリーを求める。ユーザーはプロダクトをどう使うかについての明快なストーリーを求める。ビジネスは世界に対するプロダクトの貢献についての明快なストーリーを求める。統合という役割を通じて、プロダクトマネージャーはこのストーリーたちの作者であり伝道者になるのだ。

これらの2つの機能はプロダクトマネジメントの陰と陽だ。プロダクトネットワークにミッシングリンクを追加することによって、プロダクトマネージャーはシステムに必要なだけの複雑さを追加する。これとは反対に統合は引き算だ。プロダクトマネージャーはプロダクトネットワークの各インプットが絡み合う複雑さを理解し、ユーザー、ビジネス、そしてエンジニアリングの要求という中核要素に向けてプロダクトを引き算していかなければならない。

私は上述したプロダクトマネージャーの責任は、会社やプロダクトシナリオを問わず常に真であると信じている。もしあなたがこれらの2つの機能を果たしていないなら、あなたは「プロダクトマネージャー」ではない。しかしながら、この説明はとても概念的なものだ。これらの2つの責任カテゴリの中で、プロダクトマネージャーによる活動は、状況に応じて幅広く存在する。イントロダクションとして、私は概念とプロダクトマネージャーの確固たる責務の間に橋を架ける努力をしてみたい。このエッセイの残りでは、ある会社のシナリオを上述の2つのカテゴリに分類されたプロダクトマネージャーの責務にどのように移すかを説明していく。

プロダクトマネジメントのシナリオ例

プロダクトネットワークを紹介したとき、開発者はソフトウェア製品を作る中で唯一求められる役割だと説明した。誰かがコードの出荷を必要とする。「空白」についての議論の中で、私は会社は成長のために、プロダクトネットワークの中の空白領域A、B、Cに描かれたより多彩な職務を満たさなければならないということを説明した。スタートアップが資金調達をするとき、こうした非開発者の職務の補充が始まる。もしビジネスがグロースに到達したら、組織はより専門性の高いポジションを増やしながらスケールする。しかしながら、非開発者の社員の役割を具体化する方法には大きな食い違いがある。いくつかの会社はすぐにプロダクトマネージャーを追加する。他の会社は最初のプロダクトマネージャーを採用する前に、デザインや営業の専門家を増やすことから始める。会社が非開発者の役割を追加する順番は、業務領域と現在のチームのスキルセットによる。

消費者向けスタートアップは、しばしば早い時期に専任のデザイナー(空白A)を採用する。なぜならビジュアルの印象は、限られたアテンションの期間の中でウェブ訪問者の注意を引くために決定的に重要だからだ。一方でエンタープライズ向けのスタートアップは、しょっぱなからビジネス開発の役割(空白B)を埋めたがる。この場合、製品の有効性を確かめる方法は、コアの機能性に基づいた組織に売れるかどうかにかかっている。優れたビジュアルデザインは常に大切だが、ゲームの序盤では重要性は低くなる。

これもさらに特筆すべきことなのだが、特にアーリーステージのスタートアップにおいては、開発者がプログラミングによる貢献の上に、さらに非開発者の役割も勤めている。開発者がデザイナー、プロジェクトマネージャー、CEOとして振る舞うのはよく見られる光景だ。開発チームのプログラミング以外の能力は、非開発者によって埋められる空白のどの部分に会社が注力するべきかに大きく影響を与える。いくつかの会社が熱心なデザイナーを理想的に採用したがっている一方で、開発チームがその分野に十分強ければ、その役割のニーズはそれほど緊急性のあるものではなくなるだろう。

以下の例は、プロダクトネットワークの中でリンクを形成する非開発者の役割の中でも際だったものである。プロダクトマネジメントの責任の特徴を説明する上では多くの変数が存在するが、製品に関わるチームの構造は、プロダクトマネージャーの日々の仕事に大きな影響を与える。

例#1: 開発者 + デザイナー + プロダクトマネージャー

pillars_template_d_bare.png
図8: 開発者 + デザイナー

ある会社が、デザイナーを最初の非開発職として採用したシナリオを考えるところから始めてみよう。私が描いているところでは、この役割は図8の空白A上の「デザイン」と書かれた黄色の帯で表されている。会社がユーザーと開発者をつなぐ役割を補強したいと考えて、プロダクトネットワークの最初のリンクにこの役割を選ぶのはよくあるパターンだ。収益化に注力する前の段階では、多くの会社がユーザーを彼らの価値提案に釘付けにしたいと思っている。すでに述べたとおり、特に消費者向けスタートアップでは、注意が移り変わる前、ほんの数秒だけプロダクトを見てくれる新規ユーザーに、印象を与えて明確に理解してもらえないと、プロダクトは市場で見過ごされることになるだろう。

そこでこう言ってみよう。会社はプロダクトマネージャーを二番目の非開発職として採用しよう。このシナリオでプロダクトマネージャーは何をするべきなのだろうか?繰り返しになるが、プロダクトマネージャーの責任における二つのハイレベルのカテゴリーは

  1. プロダクトネットワークの要素の間の重要な空白を認識し、埋める。
  2. プロダクトマネジメントトライアングルの三つの融合領域の中で、直交している異なるインプットを融合させる。

この例や他の例で、空白A、B、Cと融合領域AB、BC、ACについて考察する際の身近な意味を取り上げてみる。

領域プロダクトマネジメントの責任
認識し、埋めるべきプロダクトネットワークの重要な空白
A 会社が専任のデザイナーを抱えているという事実は、一つの分野においてはこの領域におけるプロダクトマネージャーへの圧力を減らす。しかしながら、デザインリソースだけでは開発者、プロダクト、ユーザーの関係を良好に保つには不十分である。デザインプロセスが成功するためには、ユーザーリサーチやWebアナリティクスのような、他の役職からの支援が欠かせない。プロダクトマネージャーは、彼ら自身が埋めるもしくは誰かが埋めることを求めている役割に気づいて、埋めなければならない。専任デザイナーのスキルセットだけでは、全領域のデザインニーズはカバーできない。例えば、優秀なビジュアルデザイナーと働くときは、プロダクトマネージャーはインフォメーションアーキテクトの役割を果たすことを求められる。伝統的なデザインプロセスから外れた領域Aの埋めるべき空白が存在する。例えば、プロダクトマネージャーは検索エンジン最適化(SEO)、技術サポート、コミュニティマネジメントの任務を担ってほしいというニーズに直面することがあるだろう。
Bもし会社のモデルが事業の開始直後から収益の伸びを示すことを求めているなら、このシナリオの中で領域Bはプロダクトマネージャーが熱心に注力する領域になるだろう。この領域専任の同僚が居ない場合は、プロダクトマネージャーにはこの領域に配置されて埋める責任がある。この重要な存在、埋められていない領域Bの空白は、会社がMBAホルダーのプロダクトマネージャーを探す動機になっている。プロダクトマネージャーは市場の収益ポテンシャルを見積もり、ビジネスモデルを開発する責任を負うことになるだろう。しかし多くのアーリーステージのスタートアップは収益化に注力していない。彼らはユーザーからの大きな需要に応えることに集中している。しかしながら、これはプロダクトマネージャーが領域Bを無視していいということではない。会社が収益に注力していてもいなくても、現在のもしくは潜在的な投資家は会社の辿る道のりを理解したいと思っている。そのために、プロダクトマネージャーはユーザー、プロダクト、ビジネスをつなぐリンクを提供する必要がある。このためには、ユーザーに受け入れられることを、ビジネス価値があるという指標に翻訳することが求められる。リーンスタートアップの用語で言えば、これはプロダクトのエンジンと成長の可能性を定量化することを意味する。プロダクトの仮説が失敗したときは、プロダクトマネージャーは新しいプロダクトのコンセプトを提供するための理論的根拠を持っておかなくてはならない。
C領域Cはこのシナリオにおいても、他のシナリオにおいても、プロダクトマネジメントの責任の中でやりがいがある部分だ。プロダクトマネージャーはビジネスを効果的に推進するプロジェクトにおいて、開発チームに注力するという重要な役割を担わなくてはならない。ここで、プロダクトマネージャーはプロジェクトマネージャーに手を染めなければいけない。プロジェクトマネージャーはすべてのエンジニアリングタスクを調整し、明確にしなければならない。プロダクトマネージャーはプロダクトのすべての細かい変更するという戦略の末端に有りながら、プロダクトのビジネス的な道のりを、エンジニアリングチームを焚きつけて集中させる明快なビジョンとして語るという、抽象的な役割を実行しなければならない。そしてまた、プロダクトマネージャーは中間層としてプロダクトロードマップを持っておく必要がある。例えロードマップが変わることがあるとしても、投資家も開発者も、どのプロジェクトが開発パイプラインに降りてくるかについての長期的な展望を見ておきたいと思っている。
プロダクトネットワーク内の各要素に影響を及ぼす異なるインプットを融合させる
AB 専任デザイナーの存在によって、融合領域ABの重要性は増加する。デザイナーが居ることにより、会社はユーザーのニーズを代弁する強い声を手に入れる。これはもちろん良いことなのだが、ときどきは逆方向からのバランスが必要になることがある。デザイナーによって進められる施策の中には、ビジネスにはほとんど影響がないプロダクトの改善案というのが山ほどあるのだ。例えば、デザイナーが検索のUIを改善したがっているとしよう。しかしプロダクトマネージャーは、検索の欠陥は理想的とは言えないが、ビジネスの成長を妨げるものではないと考える。融合領域ABにおいては、プロダクトマネージャーはデザイナーをビジネスにインパクトがある領域の改善に集中させる役割を担う。そしてときには、デザインのエネルギーをユーザー体験を阻害することに費やさなければならないこともある。例えばユーザーは広告やペイウォールの追加を嫌うだろうが、ビジネスにとっては必要なときもあるのだ。たとえあなたがデザインとビジネスのゴール間にある緊張を無視できたとしても、プロダクトマネージャーはユーザー体験の改善についての様々な視点を融合させることに労力を費やす必要がある。さらにその上、プロダクトマネージャーはSEOの帽子をかぶるかもしれない。例えば、デザイナーがユーザーインターフェイス側の意見として、SEO最適化用のテキストをページから削除したいと言うかもしれない。緊張をほぐすためには、既存ユーザーの体験をシンプルにしたいという要求に対して、検索経由の新規訪問者の獲得という天秤を考える必要がある。できればこの種のコミュニケーションは、対立する部署に置かない方が望ましい。ユーザー層の拡大と、既存ユーザーの満足の対立両方に注力しているビジネス関連の部署は、成果を生み出すだろう。デザイナーが会社の方向性に沿うようにし向けるのは、この領域の責任のうちである。柔軟で現実的なデザイナーであれば、ビジネスの緊張関係をほぐすというプロダクトマネージャーの役割に寄り添ってくれるだろう。
BC 融合させる過程でのプロダクトマネジメントの職務は、外交とコミュニケーションに長けていることを必要とする。プロダクトに対して異なる視点を持つチームメンバーたちをまとめることが要求される。しかしこのシナリオにおいて、融合の仕事はプロダクトマネージャーの心の中で起こる。領域BやCの専任の役割は居ないし、同じページを奪い合う異なる人格の人間が居るわけでもない。それでも、プロダクトマネージャーが主体的に解決しなければいけない緊張関係は存在する。もしビジネスがもがいていたり、お金を使い果たそうとしていたら、どのビジネスアイデアにリソースを投入するかを決めることは、ますます困難さを上げる。次に賭ける場所を決めるのは、プロダクトマネージャーが毎晩考えなければならない。失敗したビジネスアイデアを止めることに失敗すると、会社は崖から飛び降りる方向に突っ走ってしまう。ビジネスを織り込んだ物語を磨いておくことと、その物語に合致するプロジェクトのみにリソースを投入することは、プロダクトマネージャーにとって重要だ。
AC 専任のデザイナーが居る状況では、領域ACにおけるプロダクトマネージャーの責任は、2つのことから構成される。それは (A) プロジェクトにおけるデザインのエネルギーを、最もインパクトのあるコードをリリースすることに集中させること、(B) デザイン主導の機能開発と、他のエンジニアリングタスクの優先度のバランスを取ることである。デザインエネルギーの価値を最適化するというのは、デザインプロセスのインプットとアウトプットの管理に携わるということだ。プロダクトマネージャーはロードマップ上の進行中のプロジェクトで、デザインの関与を必要としているものを特定しておかなくてはならない。デザインが関わるプロジェクトのために、プロダクトマネージャーはユーザーとビジネスゴール、そして現在のプロダクトの状態(実装の困難具合まで含む)についての知識を基にして、明確なデザインのパラメーターとフィードバックを生み出さなくてはならない。しかし、デザインプロセスに制約を加えすぎないことも重要だ。デザイナーはプロダクトマネージャーの想像力を遙かに越えるアイデアを生み出すことがある。デザイナーは局面を変えるような仕事をするために自由を必要とする。デザイナーがプロダクトのモックアップインターフェイスを作ってくると、開発チームが積極的に開発しているものを一足飛びに越えて、デザインのお披露目会が必然的に始まる。これは開発チームが数週間かけてデザインの実装に突き進むような、ウォーターフォールプロジェクトを作るという意味ではない。開発チームがインクリメンタルに実装していくために、最も重要なデザイン要素をプロダクトマネージャーが特定していくのは健全なプロセスだ。プロダクトマネージャーのゴールは、可能なのと同じくらい学びを分散させることである。これにより、デザインの欠陥をすぐに洗い出し、デザインのうち価値が低い機能を開発しないようにすることが可能になる。またプロダクトマネージャーはデザイン駆動の機能開発において、開発チームに精力的に注力させるように指示しなければならない。プロダクト発見の段階においては、プロダクトの仮説が良いか悪いかを検証するため、技術的負債を増やしながらも、多様なデザインの方向性を素早くプロトタイプすることが受け入れられる。しかしプロダクトが成熟してくると、開発チームのエネルギーを費やす先としては、新しいデザインコンセプトの実装は減らして、パフォーマンスやセキュリティ、クロスブラウザ対応、リファクタリングドキュメンテーションを増やすべきである。

例2: 開発者 + デザイナー + ビジネス開発 + プロダクトマネージャー

pillars_template_d_bd.png
図9: 開発者 + デザイナー + ビジネス開発 + プロダクトマネージャー

例2では、専任のビジネス開発の役割が加わっている点が例1と異なっている。この例では融合領域ABにおいて、プロダクトマネージャーが自身の内部でバランスを取っていたユーザーとビジネスのニーズが、外部の緊張状態に変わっている。今では2つの強い声が存在している。デザイナーはユーザーのニーズを代弁しており、ビジネス開発部長はユーザーから金銭的な価値を引き出すことを代弁している。話し合いにおいては、双方の見方が綺麗に揃うときもあるし、そうでないときもある。デザイナーとビジネス開発部長の関係を管理することは、プロダクトマネージャーの重要な仕事になるだろう。プロダクトネットワークの融合領域ABはホットスポットになりそうだ。

融合領域ABの緊張関係は、トライアングルの反対側まで大きな影響を及ぼす。その結果、空白領域Cもまたホットスポットになり得る。正しいビジネスのビジョンは、ユーザーとビジネス的価値の相乗効果を生み出す。プロダクトマネージャーはユーザー基盤とビジネスが共通のゴールを目指すようなビジネス的な物語をこしらえていくために、ビジネス開発部長によるビジネスアイデア(領域BC)を制御しなければならない。例えば、マーケットプレイスがすさまじく成長した理由がこれである。このようなネットワーク効果はインターネットに織り込まれているのだ。プロダクトマネージャーは常に魔法の公式を探そうとするべきだが、デザイナーとビジネス開発部長の手と手を取り合わせて、戦わせないことはそのうちの一つだ。

例3: 開発者 + デザイナー + ビジネス開発 + ビジネスビジョン + プロダクトマネージャー

pillars_template_d_proj2.png
図10: 開発者 + デザイナー + ビジネス開発 + ビジネスビジョン + プロダクトマネージャー

例3にはビジネスビジョンを持っている人間という、三番目の非開発者職が含まれている。この役割は一般的にCEOが担当する。ビジョナリー的なCEOは、開発チームに会社のミッションと戦略を伝える最も重要な人間になるだろう。しかしこれでプロダクトマネージャーが領域Cの責任から解放されるわけではない。ところどころでは、事態はよりややこしくなるだろう。プロダクトマネージャーはCEOのビジョンを、北極星を目指すためのプロダクトロードマップに翻訳しなければならない。もしそのビジョンの構成要素がユーザーやビジネスの立場から無価値だったときは、プロダクトマネージャーはCEOの期待をうまくコントロールし、ビジョンをふさわしいものに変更するように焚きつけなければならない。このように空白を埋めることを「上司をうまく使う(managing up)」と呼ぶ。

今や三種類の非開発職がプロダクトネットワーク上でリンクを形成している(デザイン、ビジネス開発、ビジネスビジョン)。ここまでプロダクトマネジメントの責務の変遷として、融合領域の割合が増え、空白を埋める役割を減らす方向へシフトしてきたことを見てきた。このシナリオで成功するプロダクトマネージャーの特徴とは、外交手腕に長け、感化を通してコントロールすることがうまく、共創的な問題解決のスキルを持っている人間である。

例4: 人が増えたプロダクト組織

pillars_template_d_full.png
図11: 人が増えたプロダクト組織

例4に示すのは人が増えたプロダクト組織だ。今や我々はアーリーステージのスタートアップの領域から、拡大したスタートアップや成熟した組織の領域にやってきた。このシナリオでは、会社は領域A、B、Cの空白にまたがる帯の職種を埋める社員を雇用している。デザイナー、ユーザーリサーチャー、技術サポート、コミュニティマネジメント、SEOスペシャリスト、営業、戦略提携担当、広報、プロジェクトマネジメント、経理、経営者によるリーダーシップなどの組織を想像してみてほしい。この環境では、プロダクトマネジメントの職責は空白を埋めるのとは逆の、融合領域の比重が高まる。製品の方向についての膨大で多様なインプットを捌くことが、プロダクトマネジメントの主なチャレンジになるだろう。プロダクトネットワークの各要素である開発者、ユーザー、ビジネスのために、展望の全体像を理解することと、物語を練り上げることがプロダクトマネージャーの仕事である。

このシナリオでは、衝突は容易に起こり得る。一つの領域でも、衝突の可能性はある(例えば、領域AでデザインがSEOと衝突する)。しかし隣り合う領域のもめ事を押さえつけても、有害な政治的戦いは続く。このような状況でのプロダクトの成長のためには、プロダクトマネージャーは衝突の矢面に立ち、ことが始まる前に決着をつけなくてはならない。これは、確立された物語によって、一貫性がないインプットをそっとフィルタリングし、新しい問題に敏感で、すべての視点を統合するプロダクトの方向性のフレームワークと、先を見越しながら対話することをプロダクトマネージャーに要求する。

プロダクトマネジメントトライアングルの応用

私はここまで上記の例たちを通して、プロダクトマネジメントトライアングルによる視覚的な語彙が、プロダクトマネジメントのパターンを説明するのに役立つツールであることを示してきた。プロダクトマネジメントの第一の責任は固めること(空白や融合領域を埋めること)であるのに対し、プロダクトマネジメント固有の職務は、会社の人々をプロダクトを磨くように組織した結果に現れる。

プロダクトマネジメントトライアングルという視覚的な語彙の適用により、プロダクトマネジメントをより正確に語ることができる。より具体的な詳細として、なぜ多くの異なった責任を果たすことについての話が「プロダクトマネージャー」というタイトルでシェアされているのかを、これを使って説明することができる。なぜ良いプロダクトマネージャーがいくつかの状況では活躍し、他の状況では活躍できないのかを明らかにすることもできる。一方の成功したスタートアップのプロダクトマネージャーは、広い空白を埋めることを求められる環境で活躍するために、自身の認識を順応させている。他方の卓越した企業のプロダクトマネージャーは、プロダクトネットワークの溝を埋めるための備えはあまりしていないが、複雑な政治的構造のインプットたちを融合させることに秀でている。プロダクトマネージャーそれぞれが、描かれたプロダクトマネジメントトライアングルとプロダクトネットワークの要素間を繋ぐ帯を通じて、組織の中の彼らの役割を表現している。このエクササイズを通して、プロダクトマネージャーはどこに注意を払えばよいのか認識することができる。それは空白A、B、Cか、融合領域AB、BC、ACか。

会社が求めるプロダクトマネージャーの職務要件は、採用したい会社がどのように構成されているかをトライアングルの図に書いて含めれば、より正確なものにできた。この方法では、MBAを持ったプロダクトマネージャーは、会社にユーザー、プロダクト、ビジネスの間に満たすべき十分な空白があるタイミングを明確に見ることができた。またユーザー体験が得意なプロダクトマネージャーは、ユーザーと開発者の間に溝がある好機を捉えることができた。

プロダクトマネジメントトライアングルは、プロダクトマネージャーが自分の役割を効果的に説明したり、自信の強みと弱みについてより良い認識を持つためにも使うことができる。自分の会社の構成についてのプロダクトトライアングルを描くことと、私が例1で作ったような表を書くことによって、プロダクトマネージャーはどの領域が吹き飛びそうかを認識することができる。これは例えば、デザインが営業と衝突しそうである(領域AB)などである。そしてそこがプロダクトマネージャーが融合のために注力するべき場所なのだ。またプロダクトトライアングルは、プロダクトマネージャーが組織の弱点を特定するためにも使える。彼らが領域Cに健全さを取り戻すには、おそらく彼らのアジャイルプロジェクトマネジメント原則を見直す必要があるだろう。

終わりに、私はこのエッセイがプロダクトマネジメントについてのより具体的な議論の発射台として役立つことを望んでいる。そのうちに、私はプロダクトマネジメントトライアングルの各領域についての「ハウツー」について書くつもりでいる。