これまでは独学でやって来たけれども、他でも通用するようなPdMとしてのスキルが身についているのかというのが自分でも懸念としてはある。
セルフチェックのためPdMの採用面接の想定質問に答えてみる、という自己分析をやってみた。
- 今の自分の仕事はなんなのか？
- プロダクトチームの最新状況
- 想定質問に答えてみる
- 質問への答え方
- プロダクトのコア
- プロダクトのWhy
- プロダクトのWhat
- プロダクトのHow
- そのほか素質的な質問
- まとめ
今の自分の仕事はなんなのか？
一応会社取締役なのだが、フルタイムの正社員がいないベンチャー（というか零細企業？）ということもあり事実上はほぼ執行側の仕事しかしていない。
さらにその執行の中でもロールとしては多岐にわたっているけれども、重要度で言うとプロダクトマネージャー(PdM)的な業務が一番多いような気がする。
仕事歴は7年目で、会社としては3社目になる。 経歴の出発点はエンジニアだが、4年前にエンジニアとして入社した3社目で入社後すぐに事業がなくなることになった。
なのでプログラムを書かずに事業開発（今風に言えばBizDev）を始めざるを得なくなって、１年間はそんな仕事をしていた。 その一年の中で生まれた事業の一つがプロダクト化しつつある。 で、そのまま自分がプロダクトマネージャーになったというのが簡単な経歴だ。
プロダクトチームの最新状況
●PdM
自分
●開発
学生インターン3名 業務委託1名が今月から増える予定
●デザイナー
業務委託1名
●マーケティング
アルバイト社員1名 学生インターン1名
想定質問に答えてみる
果たしてプロダクトマネージャー(PdM)として成長しているのか？
これまでは独学でやって来たけれども、他でも通用するようなPdMとしてのスキルが身についているのかというのが自分でも懸念としてはある。
セルフチェックのためPdMの採用面接の想定質問に答えてみる、という自己分析をやってみた。 今の自分では答えられなかった質問もあったのだが、それこそ世間的にPdMが考えなきゃいけないのに自分が考えてこなかった事項なのだ、とわかる。 「プロダクトマネジメントのすべて」を復習しながら、あらためて考えた答えもある。
※自分の今担当しているプロダクトはB2B SaaSに近いものなので、質問の答えもB2B SaaSを前提にする。
質問への答え方
出どころは伏せるけれども、実際にいくつかの会社のPdM採用面接で出題された質問である。 それらを、なるべく意味は変わらないように言葉を置き換えたものとしている。
また、質問自体はいろんなテーマがあるが、明確に「プロダクトマネジメント」に関する質問は自分なりに「プロダクトマネジメントのすべて」で使われているプロダクトマネジメントの４階層に振り分けて整理した。
- プロダクトのコア
- プロダクトのWhy
- プロダクトのWhat
- プロダクトのHow
プロダクトのコア
プロダクトのTAMをどのように考えますか？
新しい概念を持ち込むようなプロダクトの場合、MVVをどれだけイメージできるかが結果TAMの計算につながると思う。 また、できれば効率化によって削減できる人件費・・・といった他の支出を減らせる余地といったネガティブな計算より、ユーザーが新しい売り上げを得られる余地などポジティブな計算にしたいというのはある。
プロダクトのMVVが100%実現され少しでもターゲットとしている層の100%に使われている世の中をイメージして、ユーザーに自分たちのプロダクトが新しくいくら売り上げをもたらすか、というのをTAMとして考えるのが良いと考えている。
社員を解雇するのが難しい日本では、RPAのようなわかりやすく工数削減できるプロダクトであったとしてもコスト削減には繋がりにくいらしい。 なぜなら、RPAでいらなくなった作業も対応する人員をクビにすることはできないので、結局雇い続ける必要があるから。
プロダクトのWhy
プロダクトが対象とする業界の情報をどのように入手していますか？
手段としては業界新聞の目次だけでもチェックする。 何に注目して調べるか？と言われたら次の２点。
- 業界に大きな影響を与える法規制の変化（例えば、物流の2024年問題）
- 地方の中小企業が工夫していいことがありました系の好事例
特に後者はまだその企業だけが工夫しているというものであれば、その工夫を簡単に自分たちでもできるツール作っときましたよというのはそのままプロダクトになりうる。
プロダクトのWhat
プロダクトの利用拡大のためにとった施策を教えてください
（まだ対して利用拡大を実現しているわけではないが）
顧客がプロダクトの価値を得るためには顧客の顧客にプロダクトを使わせる設計とする。
その時点では顧客の顧客は自社の顧客ではないが、ユーザーとして連絡は取れるようになるしプロダクトの価値について体験してもらうことができる。
顧客のカスタマーサクセスが顧客の顧客（＝自社にとっての潜在顧客）のリードナーチャリングに直結する構造とした。
Skypeの成長戦略を参考にしてます。
顧客がプロダクトをいつ使うのかどう分析して来ましたか？
質問の意図としてはカスタマージャーニーやユーザーストーリーマッピングといったことをやってますか？ということだと思う。
が、現状そこまではとても手が回っていないというのが正直なところ。 これからこの部分は実践して使いこなせるようになりたい。。
プロダクトのHow
プロダクトに関する情報の整理にどのようなフレームワークを使っていますか？
プロダクトに対してリーンキャンバスを一枚、プロダクトのマーケティングの企画ごとにバリュープロポジションキャンバスを一枚というのがコミュニケーションの基本として使っている。
それ以上は現状できてない。
担当してきたプロダクトのGo To Market戦略を教えてください
自社の場合、ベンチャーと言いつつも創業から長く資金調達をしているわけではない、外から見たらベンチャーではなく「小企業」という状況であった。。一方で、過去の実績もあり大企業とのリレーションはあった。
この中で結果として良かったのは自社プロダクトが十分に機能したら大金を払ってくれる余地のある顧客（当然大企業）を見つけること。向こうにとってはまだ成長途中のプロダクトなので割安で買うことになり、その割安の価格でも自社にとっては大きなお金なのである。
言葉を変えて説明すると、本来一ユーザーあたり1000円/月とりたいSaaSを10人しか社員がいない会社に売っても10000円/月になる。一方で、それを1000人社員がいる会社に売れば、仮に割引して半額で売ったとしても500000円/月の売り上げになる。
というわけで、最初は将来エンタープライズ案件に化ける余地がある企業を意識して企画書を作り、プレスリリースを打ち、それらを顧客化したい企業に送付するプッシュ型の営業を行うことがGTM戦略でした。
プロダクトに関する開発タスクの管理について何を考えているか教えてください。
「プロダクトマネジメントのすべて」でも、プロダクトバックログでアイテムにストーリーポイントで重みをつけましょうというような話がある。 ただ個人的に思うのは、開発の案件ってそれ自体の重さと、他の案件との同時開発のしやすさっていうのがある。
サーバーサイドの開発ではDBスキーマの変更だったり、広く使われているのにDRYになっていないコードのリファクタリングだったり、Railsのアップデートだったり。 フロントエンドではデザインシステムの導入など。
こういったタスクはなるべく並列にならないようにするべきだと思う。 例えばDBスキーマ変更を伴うし規模が大きいタスクは、API的には互換性を保ちつつスキーマ変更だけを行うタスクを切り出してそのタスクだけは先に完了しておくといったことは検討したほうが良いだろう。
また、ユーザーとのコミュニケーションについても、バックエンドで思いタスクがあるときはフロントエンド側で軽くて見た目がわかりやすく変わるタスクを優先したり、ユーザーから見て機能開発が止まっている感を出さないようにすることも考えることがある。
そのほか素質的な質問
開発チームに対して負荷がかかるお願いをしなければいけなくなりました。どのように説明しますか？
これもチーム開発をしていないので、実際の経験に基づくものではないけれど、何を要素として落としたのかを丁寧に説明するかなぁ。
昨日の納期が守れないことがわかりました。ステークホルダーに何をコミュニケーションしますか？
これも同じような話で、、最大限省けるものを省いても無理だったというのを説明するしかないのでは。
特にスタートアップのような場合、社員に無理をさせて離職されてしまうようなことがあればそれこそ大打撃だし、納期を守るために無理をさせることが自分たちが大事にする価値観に違反しているということを伝えるのかなと。
まとめ
結局これらの答えがPdMとしてちゃんと考えられている答えなのかはわからないのだが、考えてみるだけでもいいエクササイズになったと感じてる。 また１年後に同じ質問を見直してみるとか、他の質問も見つけて答えてみることをやってみようと思います。
