タイミーのPMMって何してるの？
本記事は、Timee Advent Calendar 2023 10日目の記事です。
まず1年間を振り返って
「人生の中でもベストなくらい濃厚な1年だった」
アドベントカレンダーへ参加表明し、この記事を書くために自分の中で振り返りをし始めて第一に思った感想です。
色々なIssueに取り組み、頭を悩ませ方針のピボットやマーケットインを繰り返した結果、信じられないスピードで1年が過ぎ去っていきました。
「PMMは会社によって役割が違う」と言われることが多いですが、これまで何社か経験する中で、会社によってPMMの役割や干渉範囲、求められる成果もガラリと変わることを、自分自身実感してます
2023年1月にタイミーにジョインして、1年間PMMという役割を任せていただき、改めて「プロダクトマーケティング」について考えさせられる事が多かったので、全体間を振り返りつつ、ゆるりと感じたことを書かせて頂こうと思います。
自己紹介
開発組織とPMM
タイミーにおけるプロダクト開発で特徴的なのは領域分担型の体制だと思っています。
エンジニア向けのTimee Product Org Entrance Book にも記載はされていますが
「MatchingTribe」「SpotWorkSystem Tribe」に分割されており、その開発組織を支える「開発platform Tribe」という体制です（各領域の持っているテーマは長くなるので割愛します）。
そしてこの各領域に対してPMMが数名リソースを割き各フェーズの対応を推進していきます。
他にも「セールスイネーブルメント」「CRM」など固有のテーマに対して責任を持っているPMMもいます。
その中で私は「SpotWorkSystem Tribe」内でPMMの役割を担っており。役割は「Issue探索」「discovery」「Go to Market」の大きく3つのフェーズを担当します。
「Issue探索」「Discovery」「GotoMarket」
全てはここから始まるでお馴染みの「Issue探索」
タイミーだと各インタビューにPMM含め能動的に参加する文化があるのでクライアント様やワーカー様から直接UI/UXに対するフィードバックや、良かったところ、足りていない所などをお聞きしておりその情報がストックされています
あとは定期的な社内からの要望収集や、社内のセールスからも「この機能できませんか？」「この機能が出来たら受注できます」という嬉しい要望が沢山入ってきます（本当に嬉しいです）。
一度、PMMの方で課題のデプス調査や、クライアントが解決したい課題は何なのかを改めて検討しIssue設定を行います。
調査を繰り返す中の気付きとしては、クライアントが抱いている課題に対して「○○な機能が欲しい」という要望はあくまで課題に対して断片的な部分であり、本質的な課題は別にあるという事です。
なのでこの要望を間に受けて開発を進めて実装しても
想定していたよりも上手くワークしない、
ポジティブな効果には繋がらず事業インパクトも弱かった
という事象になる可能性があります。
その事象を防ぐためにも、SpotworkSystem担当の私ともう1人のPMMは
「本質的なIssueを設定し、そのIssueを解決するためのソリューションを何個か検討、開発された際の事業的なインパクトや効果を定量的に出し見比べ優先順位を決める」
上記のような手法をとっています。
実際に「プロダクト機能開発要望」として吸い上げたものが実はプロダクト改修しなくてもビジネス側で工夫すれば何とかなった、のような事例も存在しており、そういった解決方法考案の一次窓口としてもPMMが機能している部分もあります。
具体をより突き詰めていく「Discovery」
「Discovery」のフェーズではより解決すべきソリューションの手法や解決されるべき課題が詳細化され実際に開発を行うsquadのPdMと議論します。
この段階ではsalesやCSなどのステークホルダーへの頭出しや壁打ちなどを行い具体化を行なっていきます。with Engineerとなっている時でも「どうあるべきなんだっけ」という立ち返りの時にPMMがインサイトを返す役割をしています。
このフェーズが完了すると完全にsquadの手に渡り、スクラムイベントや各Sprintで進捗状況を見て「Go To Market」に入ります。
細かな機能リリースだと影響は少ないのですが、大きめの機能リリースやイベントの際は既存のクライアントやワーカーへの影響が考えられるため、社内で事前にOpsを組んだり、お知らせを行う前にSales経由でお伝えしたりなどしています。
「Go To Market」フェーズにおける実例
例えば毎年発生する「地域別最低賃金の更新」などはタイミーで求人を出しているクライアント様は全員関係しており、その数は万件規模になっています。
ここだけを見ると「システマチックに一括で引き上げたらいいのでは」となると思います（私はそう思いました）。
この対応を「最低限のテキストのお知らせのみ行い、一括で変更かけた」場合、どうなるでしょうか。
・弊社からクライアント様に請求する金額にも変化があり意図せぬハレーションの発生するのでは？
・契約頂いているクライアント数から見て影響範囲は？
・発生したハレーションに対して解決するための社内工数は？
・何も準備がされないまま問い合わせが各所に入って来た時どうする？
その摩擦を最低限にするために改定日の数ヶ月前から動き出し「クライアント様自身で改定日以降の時給の変更をかけて頂く」ことを第一優先として、セールス経由での提案や、メールでの複数回での案内や管理画面でのお知らせを数ヶ月前から定期的に送付した後に「変更がかけれていない求人の時給を一括で更新する」という手段を取りました。
もちろん事前に告知をすることである程度、クライアント側からの問い合わせは増えるでしょう。
しかしsalesやCSの工数は若干かかるものの、丁寧にやったからこそ摩擦も最低限で済みクレームも全くない状態でこのデリケートなイベントを終えることができ、この対応のおかげで「実際の改定日以前に時給を上げて他求人に差をつけたい」という企業様も現れるという嬉しい誤算もありました。
このような毎年発生するイベントへの対応ナレッジやTodoは「バトンツナギ」の名の下にドキュメント整備され来年以降、これを見たら誰でも対応できるものとして昇華されていきます。
このようなIssueや施作毎のGo to Marketを考え各ステークホルダー達と協力し進めていくのがPMMとしての役割になります。
難しいIssueこそ探索が楽しい
長くフェーズのことを書きましたが、やはり「設定するIssue」が何より重要であり、ここに時間をかけるべきだと感じています。
Issueを導き出すまでに定量面、定性面での調査や仮説立てしたIssueとソリューションの関係者との壁打ち等を経てやっと導かれるものであり、ここまで来ると「あとはやるだけ！」という状態になっています。
なので分析した内容から導き出した仮説の確度をいかに高めるか、最後まで視野を狭めずに時には大きくピボットする判断などがPMMとして大きく求めれている部分だと1年間活動し感じた所感です。
この「Issue探索」こそ、PMMとして一番苦しく楽しいところでもあるので沢山頭を悩ませていこうと思ってます（本当に楽しいと思ってますよ）。
さいごに
「はたらく」を通じて人生の可能性を広げるインフラをつくる
タイミーのミッションであり私が入社を決めた大きな理由です。
しかしインタビューをしていると「もっと色々な求人が見たい」「働きたい求人はすぐ埋まってしまって働けない」と必ず言われます。
労働力が不足している日本の中で「はたらく」ことの機会損失が生まれてしまっていて、悔しいと本当に思っています。
まだまだインフラとは言えません。
2024年も更に会社も自分自身も大きく成長しミッション実現に向けて動き続けていきます。
おそらく、この記事を読んでくださっている皆さんが思っている以上にタイミーというサービスには伸び代があるので、また1年期待して頂きたい！というのが中にいるPMMとしてお伝えしたいポイントです。