見出し画像

失敗から学んだ、1人目プロダクトマネージャーのDo’s & Don’ts

この記事はPharmaXアドベントカレンダー2023の5日目の記事です。


こんにちは。オンライン薬局を運営するPharmaX株式会社でプロダクトマネ
ージャーをやっている稲垣慶典(@InagakiKay)です。

<プロフィール>
新卒でDeNAに入社し、『怪盗ロワイヤル』や協業開発プロジェクトなどでゲームプロデューサーとして従事。その後ヘルスケア領域に異動し、がんスクリーニング検査の研究開発プロジェクトや健診施設のDXプロジェクトで事業企画リーダーやプロダクトマネージャーを担う。2022年4月にPharmaX(旧YOJO Technologies)に参画。

本記事は、11月8日に開催したイベント「1人目PMが語る!toCプロダクトにおけるプロダクトマネージャーのリアルと面白さ」のLTで発表した内容をもとに作成しました。


1人目のプロダクトマネージャー(以降、PM)として、より良いプロダクトづくりを目指して、プロダクトマネジメントスタイルやPMの在り方を模索してきました。その中でたくさん失敗し、その結果で得られた学びについて書いています。
ちなみに「Do’s & Don’ts」というタイトルですが、ハウツー的な内容ではなく、具体的事例を挙げつつも比較的抽象度の高い内容となっています。

<想定読者>
・1人目PMとしてスタートアップで働いている方
・スタートアップでPMとして働いてみたい方
・プロダクトづくりに関わる方



1人目PMとして、どう動くと良いか?どう振る舞えば良いか?

経緯や具体的な取り組み事例を話す前に、最初に(!)簡単なまとめとしてDo’s & Don’tsを紹介します。

1人目PMとして、組織にプロダクトマネジメントをどう導入していけば良いか?どう振る舞えば良いか?という観点における、Do’s & Don’tsは以下のように考えています。

○ ”自分たち”を知ることから始める

プロダクトマネジメントのあるべき姿は組織やプロダクトによって大きく異なります。まずは自分たちの現状をメタ認知し、それに合わせて何をすべき、どうすべきかを考えていくことが大事です。

○ 叩きとして巷の知見や手法をガシガシ試してみる

どういうスタイルをとるべきか、どう在るべきかという議論は抽象的で、空中戦になりがちです。建設的な議論で深めていくためにも、具体的な叩きをベースに検討していくのがおすすめです。そのためにも、巷の知見や手法を、叩き台として「とりあえず」活用するというスタンスが良いと思います。

× 手法やツールや導入して終わり

一方で、巷の知見を叩き台として取り入れてみたものの、終わりにしてしまっては意味がありません。それを叩きとして、自分たちに合った形を模索していくことこそが重要です。

× プロダクトマネジメントやPMのあるべき像にこだわりすぎる

プロダクトマネージャーの振る舞いと言う観点では、一般論的なプロダクトマネージャーのあるべき像にこだわりすぎないほうが良いです。どうあるべきか、どう振る舞うべきかについても、組織やメンバー構成によって調整弁にした方が良いと思います。

それっぽくまとめとして言っていますが、よく言われるようなふわっとした話ですよね。
本記事では、そのニュアンスや温度感の部分をお伝えしたく、経緯や具体的な取り組み事例を紹介していきたいと思います。

入社当時のプロダクトチーム

まずは前提となる情報からお伝えします。

LINEを通じて、薬剤師などの医療アドバイザーとチャット相談しながら医薬品(漢方など)を購入できるというサービスを提供しています。

入社当時のプロダクトチーム体制は、アーリーフェーズのスタートアップによくある、創業者を中心にエンジニアとデザイナーがいる小さなものでした。

少し特殊なのが、ユーザーとチャットでやり取りをする薬剤師(社内ではペイシェントサクセス/PSと呼んでいます)のメンバーもプロダクトチームと密連携してプロダクト提供しているところです。

また、当時は専任のプロダクトマネージャーはおらず、副業的にプロダクトマネージャーの方がサポートしてくれていたり、エンジニアがそれっぽい動きをするという状態でした。

当初のプロダクトチーム

第一歩としての”自分たち”を知ること

過去の経験がそのまま活きることはない

チームに入るにあたって、自分の過去の経験がマッチするようで、マッチしないチームだという印象を持ちました。
私自身、もともとtoCサービスをやってきていたし、医療・ヘルスケアの領域の経験はあるものの、メンバーのバックグラウンドやチームの熟練度など、過去の経験と違う部分が多そうだなという直感です。

1人目○○という役回りだと、自分の経験をそのままインストールしてしまいがちですが、その直感があったため、過去の経験と今のチームの差分を踏まえながら立ち回ろうと考えました。

変数に分解して、自分たちの組織やプロダクトの特性を捉える

自分たちのプロダクトチームの特性を把握するために、いくつかの変数に分解し、特徴を捉えてみました。

どんなプロダクト形態なのか、どんなフェーズなのか、チームメンバーはどういう構成か、どのくらい練度で、どのくらい共通言語化されているか…など。

それぞれについて自分の過去の経験と比較したりすることで、違いを明確化することができます。その差分を加味して立ち回ることで、自分の経験を活かしつつも、今のこのチームに合ったアンラーニング&ラーニングができると考えました。

ちなみに、世の中の事例や知見を参考する際にも、その前提となっているチームと自分たちとの違いを捉えることで、導入する際の注意点や工夫ポイントも明確になりやすいかなと思います。

自分たちを知ることを起点とした模索のサイクル

整理を踏まえ、自分たちのプロダクトチームの特徴を洗い出してみました。そして、それを元にどんなプロダクトマネジメントスタイルにしていくと良さそうか、そのためにどう動こうかと考えていきました。

今回はその中の3つに絞って取り組みを紹介しようと思います。

ちなみに取り組みのリストは、プロダクトフェーズの変化や組織の変化に伴ってアップデートされていくものです。定期的に自分たちを観察し、「今」の「自分たち」を捉えながら、すべきことをする営みこそが重要なのかもしれません。

より良いプロダクトづくりを目指す実際の試行錯誤

取り組みについて、もう少し背景を説明します。

1. プロダクト開発の練度が高くない→まずは基本的な方を導入してみる

当初、プロダクト運用経験のあるシニアなメンバーが少ないチーム体制でした。
また、ソフトウェア開発から縁遠い業界から来た薬剤師メンバーが多く、「プ、プロダクトマネジメント?」という状態。

プロダクトづくりのナレッジや枠組みがチーム内にあまりなく、各人があらゆる側面で未知を開拓しながらプロダクトづくりをしている状態だったため、基本的なプロダクトマネジメントの型を導入することから始めてみようと考えました。

2. 医療ドメイン×多職種混成チーム→関係者を巻き込みやすいチームに

プロダクトの特性上、価値提供の担い手がソフトウェアに完結せず、チャット対応する薬剤師メンバーや実際にお届けする商品の梱包・配送を担うロジスティクスのメンバーなど、様々な職種がプロダクトづくりに関与するチーム体制でした。

それぞれが重要な役割を担うと同時に、それぞれの職種にとっての部分最適に引っ張られがちなため、関係者の目線を揃えて巻き込みながら動ける状態にしたいと思いました。

3. プロダクトマネージャーが不在だった→関係者間での役割認識を揃える

もともとプロダクトマネージャーが不在だったという経緯もあり、プロダクトマネジメントやプロダクトマネージャーの定義が不明瞭な状態でした。

そのため、役割の重複やボールの取りこぼしが発生しやすい状況で、役割認識を揃えることでそれぞれが最大パフォーマンスを出せるようにしたいと考えました。

取り組み①:プロダクトマネジメントの型をインストールしてみる

各種フォーマットを作ってみたが、思ったように運用されない…

基本的な型を導入していこうということで、企画書・PRDドキュメントのフォーマットを作成したり、インタビューの要件設計をしやすくする設計テンプレートを作成したりしてみました。
それに則ってやれば、自然とプロダクトマネジメントの基本的なポイントを抑えられるように狙っていたのですが、思ったようには活用されませんでした。
使ってはもらえるものの、節々で「なんか違うな…」と感じることが多くなっていきました。

企画書/PRDやインタビュー設計のフォーマット

根底の考え方を揃える

観察してみると、根底の考え方の部分で認識が揃っていないことが原因のようでした。
例えば、インタビュー設計ひとつを取ってみても、プロダクトづくりにおいてユーザーの声をどう捉えるべきかの考え方次第で、インタビューで何を/どう聞くべきかが変わってきます。

そのため、プロダクトチームにおける指針を策定しました。
永久的・普遍なものというよりかは、「今の自分たちはこういうことを大事にしたいよね」というものを言語化した、認識を揃えるためのカジュアルなものです。

まだ完璧に運用されているわけではないですが、この指針を通じてプロダクトマネジメントスタイルや型の狙い・目的を理解してもらいやすくなり、関係者内で「しっくりくる」という声も出てくるようになりました。

プロダクト指針。「最小のアウトプットで最大のアウトカムを出す」という指針がお気に入りなのですが、この言葉自体はTwitterかで見かけて良いなと思い、採用させていただきました。

取り組み②:いろんな職種を巻き込めるチームづくり

関係者への情報共有をがむしゃらにやってみたものの…

まずは安直に、プロダクトチーム関係者へ共有する情報量を増やすと動きをしました。各人が持っている情報量が多いほど、職種やバックグラウンドが違っていてもチームの動きを理解しやすいのではと思ったからです。

デイリーや定例の会議などで何度も、しつこく話をするだけでなく、毎週リリースの度にリリースレターと言う形で、背景・意図やリリースした施策の詳細をチームに共有したりしていました。

ただ、それでも、「その話は聞いてなかった」「何を目指しているのかわからない」と言われることがあり、ちょっと観察してみました。

「文脈」が理解されるかが重要

よく分析してみると、やってる施策自体はわかっているが、その文脈の部分があんまり伝わっていなそうでした。

もう一段踏み込んで捉えてみると、それぞれの職種が持つ特有の文脈構造があり、プロダクトづくりの文脈をきちんとすり合わせなければ、それぞれの文脈で異なる解釈をされやすいということも見えてきました。

例えば、人の健康を預かる医療者である薬剤師さんは、いかにリスクを最小化するかという目標意識を持つことが多く、その文脈でプロダクトづくりを解釈しようとしてくれます。
ただ、必ずしもリスク最小化を主の目的としてプロダクトづくりをしているわけではないので、認識のズレが生じやすくなってしまいます。

具体的な取り組みとして、プロダクトチームの文脈を理解しやすい施策(アクション)管理を導入してみました。
ここでの文脈とは、事業ゴールから解くべきイシュー、それに基づく施策群の繋がりのことで、Notionをフル活用して1ページでまとめたタスク管理表(ページ)をつくりました。

このページを用いて関係者と施策の話をすることで、自然とその背景や目的もセットで伝わるようになりました。

文脈のわかりやすさを重視した施策管理シート

巻き込めるようになることで、自発的な動きが増える

文脈が伝わり、関係者の目線が揃ったことで、副次的に良いこともありました。
チームの目標に向けて、「もっとこんなことやれると良いのでは?」という話も出てくるようになり、+アルファの動きが増えてきました。

例えば、薬剤師のメンバーがユーザー対応の質を上げるために自発的にSQLを勉強し、定量分析を活用しながら業務をしています。

もともとBIチームがデータ分析の布教活動をしてくれていたことが大きいのですが、普通の薬局で働いていた普通の薬剤師さんが、チームの目標のために一歩踏み込んだアクションをしてくれることで、プロダクトの価値提供に大きく貢献してくれています。

薬剤師メンバーがSlackでクエリのやり取り

取り組み③:プロダクトマネージャーの役割認識を揃える

「何でも屋」だからこそ、役割明確化が重要

プロダクトマネージャーはプロダクトを成功させる(成果を出す)ことがミッションでありつつも、それに向けて何でもやるため、具体の役割という観点では曖昧な存在になりがちだと思います。

プロダダクトマネージャーの役割問題を整理するために、エンジニアやデザイナーなど他職種との「横の役割分担」と、創業者や事業責任者などとの「縦の役割分担」と分けてみます。

横の役割分担は、やれる/やれないという側面も出てくるので、比較的役割が明確になりやすいのではないでしょうか。
一方で、特に1人目PMがいるようなアーリーフェーズのスタートアップにおいては、縦の役割分担が重要になってきます。

その文脈もあり、まずはプロダクトやプロダクトマネージャーの定義など言語化して、それをベースに認識を合わせていくという動きをしてみました。

いろんなことを言語化し、それを元にすり合わせる

ただ、実際問題、綺麗に定義通りになることはなく、ケースバイケースでいろんなことが起きました。「その意思決定どっちがやるんですか?」「この件、PMが決める話では?」といった被りやお見合いが日常的に発生していました。

現時点で、この取り組みについてはまだ解はありません…。難しい…。
そのため、ここまでのプロセスにおける学びを共有したいと思います。

教科書的なプロダクトマネージャー像にこだわらない

縦の関係性における、どちらがどこまでやるかと言う線引きは難しい問題です。

教科書的なプロダクトマネージャーの役割で言うと、Discovery(課題の探索や設定)とDelivery(検証や実行)を両方やり、むしろDiscoveryこそがプロダクトマネージャーの仕事という捉え方もあります。

それはそうなんですが、一方で、その教科書通りの役割に固執してしまい、よいプロダクトづくりができなくなってしまうのも違います。

この話も、「今」の「自分たち」にあったやり方を考えることに尽きます。その点で、創業者とプロダクトマネージャーの関係性をいくつかの視点で捉えた上で、どんなやり方が良いかを考えると良さそうです。

創業者の「野生的ムーブ」をどう活かすか

1つ目は創業者の野生的ムーブをプロダクトづくりにどう活かすかと言う視点です。

創業者の野生的ムーブとは、創業者の直感に基づくプロダクトづくりのことで、その機動力の高さや合理を超えた強さはあると思います。

プロダクトマネージャーとして、プロダクトの成功確率を上げるためにどう野生的ムーブを活かすかということは、創業者とプロダクトマネージャーとの関係性において重要な視点です。

感情ときちんと向き合う

2つ目は、感情面でどういう関係性にすべきかという視点です。
創業者と1人目PMは、赤ちゃんに対する親と保育者の関係性に似ていると思います。

つまり、保育者は子育てのプロではあるけれど、その子と血は繋がってないし、感情的な繋がりは(一般的には)親ほど強くありません。
一方で、親は血と感情的な繋がりがあるものの、(場合によっては)育児の経験は初めてだったりします。

その親と保育者の関係性の中で、どう子供を預かり、一緒に育てていくかという点が似ています。

プロダクトの成功確率を上げるために、どういう距離感でプロダクトを「預かるか」という視点を持ち、プロダクトマネージャーとしての振る舞いを考えると良さそうです。

まとめ

「今」の「自分たち」に合うスタイルを模索し続けるしかない

取り組みの事例を紹介しつつ、1人目PMとしてチームにどうプロダクトマネイジメントを導入していくか、どう振る舞うかという話をしてきました。

細かい話はいろいろありつつも、「今」の、そして「自分たち」に合ったやり方・形を探し続ける営みなのかなと思います。
だからこそ、「今の自分たちってどういう状態なんだっけ」と現状の自分たちを捉え続けることをやめてはいけないし、アップデートし続けるのをやめてはいけないと思います。

また、1人目PMとしての難しさは、その営みがまだ行われていない状態から、型を作り、サイクルを回し始めることによる難しさです。

「PMあるべき論」や自分の経験・こだわりはありつつも、プロダクトの成功確率を上げるためにはどう振る舞うべきかと言う冷静な視点を持ちつつ、プロダクトづくりに関わる関係者と粘り強く認識を揃えていく部分は、とても泥臭く、教科書には載っていない努力を必要とします。

そうした積み重ねの先にこそ、ユーザーに価値提供ができる良いプロダクトづくりがあるんだろうなと思います。

というわけで、絶賛採用中です!

この記事が気に入ったらサポートをしてみませんか?