未経験PdMが「スタンスを取れる人」になったコツ

未経験PdMが「スタンスを取れる人」になったコツ

こんにちは。TOKIUM でプロダクトマネジャーをしている加藤です。

未経験でPdMになって最初にぶつかる壁は何だろう？私の場合、初歩的ですが「スタンスを取れない」ことでした。

本記事では、その壁を超えるためのコツについて書きます。

どんな仕様にすべきかがわからず右往左往する日々

エンジニア出身ではないPdMとして2ヶ月前に参画した私は、こんな悩みを抱えていました。

「自分はプロダクトマネジャーになったばかりだから・・・」
「顧客への解像度も低いから、どんな仕様がいいかもわからない」

顧客に対してスタンスを取れない。つまり、「AとBのどちらが良いか」を根拠を持って判断し、チームに提案できない。これが最大の課題でした。

例えば、請求書と発注書の表記揺れをカバーして、お客さんが探している請求書をレコメンドする仕様を考えていたときのこと。

「どの項目を、どこまで深く表記揺れをカバーすべきか？」

取引先名、金額、商品名・・・全部が大事そうに見えていました。優先順位がつけられない。どこまでやれば十分なのかも分からない。

しかしながら、私が迷っている間にも事業は止まらず、日々仕様検討の場面は訪れます。でも、「こうすべき」が言い切れない。このもどかしさ、駆け出しPdMの方なら共感していただけるのではないでしょうか。

最初は、この悩みに対して、業務解説記事を読んだり、BtoB/SaaSドメイン領域のインフルエンサーをフォローしたり、業務解説本を読んだりといった方法で解決を試みました。顧客解像度が上がれば、「こうすべきだ」がわかるのではないかと。

ただそれをやっても、具体的な仕様としてAとBのどちらが顧客観点として良いのか？には自信を持って答えることができませんでした。

プロセスマップを描いてみた

この悩みの解決する助けになったのが 「プロセスマップ」 です。

プロセスマップとは、ある業務が行われる流れを登場人物ごとに分けて整理する手法です。

作成したプロセスマップ現物

プロセスマップを書くことを勧めてくれたのは、先輩PdM(@mura_massann)でした。

最初は「業務フローを整理するだけで、本当に判断できるようになるのか？」と半信半疑でした。でも、実際に書いてみると、頭の中でバラバラに捉えたいた情報が線でつながる感覚がありました。

プロセスマップを描いたら、スタンスを取れるようになった

プロセスマップを書くと、「誰が」「どのタイミングで」「何を見て」判断しているかが細かな粒度で見えてきます。

例えば、請求書と発注書の照合業務。プロセスマップを書く前は「取引先名も金額も商品名も、全部大事そう」としか思えまていませんでした。

でも、プロセスマップで経理担当者の動きを追ってみると、こんなことが整理できました。

• おそらく、経理担当者は、まず「取引先名」で請求書を探している
• そして次に「金額」が一致しているかを確認している

仮説なので間違っている可能性はもちろんあるのですが、業務フローから見て一番大事なポイントが見えてきたのです。

これが分かったことで、「どんな仕様であるべきか」が自然と考えられるようになりました。

今回では、取引先名が重要な情報になりそうなので、取引先名だけは基本的な表記揺れに加えて、ニッチなケースの表記揺れまで対応した方が良さそう、といった具合にです。（ニッチなケースの例：発注データにはカタカナで取引先名が、請求書には英語で社名が書かれているケース）

プロセスマップを描いたことで、仮説の強度が上がったことを実感しました。

プロセスマップ作成の2つのコツ

コツ①: 最も太い動線にフォーカスして書く

枝葉のところまで書くと、色々やりたくなってしまいます。一番使われるメインフローだけに集中します。

すべての業務パターンを網羅しようとすると、情報収集だけで数週間かかります。ただ、私たちが持てる時間には限りがあります。80%のユーザーが使う太い動線だけを押さえれば、十分に価値ある判断ができるので、思い切って削りましょう。

太い動線だけに絞ると、レアケースへの対応が漏れる可能性があります。でもそれでいいのです（完璧主義気味の私には、結構これが難しかったのですが）。まずは80%のユーザーが使うメインフローを理解することが、判断のスピードを上げます。残り20%は、実際にその要望を受けてから対処しても遅くありません。

コツ②: 一旦は自分の仮説で書き上げる

「太い動線」も、一旦は自分の仮説で良いです。「おそらくここはこうやっているんだろう」という想像ベースでプロセスマップを埋めていきます。

完璧な情報が揃うまで待つ必要はありません。正直よくわからん！状態でも、まず仮説を持つことが第一歩です。

同じ悩みを持つ方へ

この記事を読んでいるあなたも、もしかしたら私と同じ悩みを抱えているかもしれません。

「もっと詳しくなってからでないと、意見を言えない」
「間違ったことを言ったら、チームに迷惑をかけてしまいそう」

その気持ち、よくわかります。私もまだその渦中にいます。

でも、プロセスマップを書いてみて、少しだけ前に進めた気がしています。同じ悩みを持つ方に、少しでも届いたら嬉しいです。