プロダクトマネージャーとは | セキュリティSaaSスタートアップの1年間
現在、LRM株式会社で情報セキュリティSaaS「Seculio」の事業責任者兼PdMをしている@alex_tsuboi です。
チームに参画して間もない頃、あるメンバーにプロダクトの方針が決まっていないから困っている。と言われた日がありました。
それまではベンチャーで好き勝手に開発をさせてもらったり、大企業の中で安定したバックログがあり、その中からPdMと相談しながら作ったりとあまり仕様がないことに悩んだことはなく、その日依頼悩んできた問題でした。
そもそも1エンジニアとして参画し、1年前には2名だったSaaS事業チームが、現在10名近くになった際に感じたこと、参考にした本、必要だと思うスキルについて書きました。
プロダクト開発の"方針"とは
"方針"と言われたとき、予め決められたことがあるような感じで言われ違和感を覚えました。
そもそもベンチャーでは正解がない領域でプロダクト作りをしていることが多くこれをやれば勝てるというような銀の弾丸はないはずです。そのため、プロダクトに関する方針を決めるのは、事業または会社の成功と失敗を左右することであり、誰のものかと言えば会社のものなので意思決定に関しては取締役レベルがする話のような気もします。
今まで触ってきたプロダクトはほとんど立ち上げから関わっていたり、すでにある程度出来上がっていたため、プロダクトの方針は自分で決めるか今までの開発スケジュールから推測すればある程度答えが出るものでした。
しかし自分が今目の前で開発しているのは、業界には存在しないプロダクトで、toBの領域でかつ情報セキュリティに関する領域で、どちらも自分に専門知識があるわけではありませんでした。
今でこそtoBの領域の面白さやビジネスモデルもちょっとづつわかってきましたが、当初は全くわからず、開発を頑張ってプロダクトを磨けば本当に顧客が取れるんだろうかと不思議でした。
方針を考える上で下記のように考慮すべきことがあると思います。
何を決めるべきか | "方針"と言っても色々なことがある
"方針"と言っても本当に色々なことがあります。スクラムは比較的経験があったため、それなら、バックログの整備から始めればよいのかな程度で考えていました。どの方針から整備すればいいのか、そもそも下記に列挙しているようなこともあまり理解していませんでした。
・プロダクト開発ロードマップ
・注力領域(新規機能の開発か、インフラ整備か、技術的な負債の解消か、既存機能の改善か、マーケとの連携か)
・採用言語・採用アーキテクチャ・採用基盤
・レビューの柔軟度
・Lint・コーディング規約の方向性
・採用(誰・どんな人と働きたいか)
・分業の方法(水平か・垂直か)
・利用規約・データ管理
・バグ対応
・問い合わせ対応
・セールスとの連携
・プライシング
・リサーチ
・顧客分析
・事業計画の作成
プロダクトマネージャがどんなことをやらなければいけないかについての、詳しい説明は「プロダクトマネージャーの教科書」という本の付録の職務内容書が参考になります。
"方針"は組織の大きさで変わる
組織の大きさでも方針は変わると思っています。今まで経験したプロジェクトでも下記のようなものがありました。
・学生ベンチャー
・メガベンチャー
・サイドプロジェクト
・少人数ベンチャー
・中規模ベンチャー
小さな組織では、プロダクト開発ロードマップは毎週のように変わりますし、注力領域も絞る必要があります。逆に大きい組織になれば、それでも毎月ロードマップは変わりますし、デザイン、フロントエンド、バックエンドなどのように分担が決まっているので連携を取りながらすすめる必要があります。
サイドプロジェクトではスパンを長めに取っていることが多いため一人で1機能の開発を任せることも多かったように思います。
LRMはすでに創業から14年を迎えており、若干特殊なのですが、事業部として、少人数ベンチャーから中規模ベンチャーに生まれ変わろうとしているタイミングでした。(後からわかったことですが)
誰が決めるべきか | "方針"の決定が可能なメンバー
下記のような人たちが"方針"を決定する可能性がありますが、組織の規模に応じて方針の意思決定を行う人も変わります。
・CEO
・PO
・PdM
・CTO
・リードエンジニア
・エンジニア
・デザイナー
・BizDev
立ち上げたばかりの会社ならCEOかCTOが、経営陣が開発に疎ければエンジニアのメンバーが、組織が大きくなるにつれてPOやPdMがといった感じです。実際にやってみるとそれには理由があることがわかります。立ち上げ当初は何もないところから始まるため、メンバー全員が一致して抱いている構想の内のほんの少しの機能を実現したり、自分が得意な分野のものを作れば良いため、誰かに説明することもなく、構想を形作っていく中で、元々深く知っている領域のサービスを開発したり、特に考えることもなく競合調査をしていたりするからです。
誰が何を決めるべきか | PdMの役割
誰が何を決めるべきかについては、これら"方針"や分担が不明確であることがコストになるタイミングでPdMという役職を設け、PdMが売上に責任を持つことで"方針"を決める、もしくは分担していく必要がありました。
そして、PdMとしてやっていく中で最も大事だと思ったことは、事業の手触り感を増えていく各メンバーに伝えていくことです。これはコロナという情勢にも関わりがありますが、リモートワークをする中で毎週の1on1 MTGを実施したり、毎週のエンジニアKPTやデザインスプリントで各メンバーからフィードバックを受ける中で感じたことです。
やっている上で考えたこと
・チームに足りない所を補う
とにかくあちこちであれが足りない、これが足りないとなるので、MTGを開催したり、文書化したりと部署間を横断してコニュニケーションする
・そんなに大量の仕事は出来るわけない
とにかく色々やり過ぎてボトルネックになりがちなので頑張って周りの人に助けを求める。全然うまく行かないですが。。。
・プロダクトとセールスの両輪を意識する
toCと違ったtoBの面白さは、フリーミアムではない限り、契約書を交わさないと顧客がプロダクトを使い始めない。セールスも意識しないとプロダクトを伸ばせない。というところだと思っています。顧客の声を今取り入れるか、開発コストを考えて、将来取り入れることにするかの議論は毎週行っています。
SaaSスタートアップの1年間
LRMに参画してから取り組んだことを箇条書きにすると以下のようなことです。どれも一人でやった訳ではなく、各部の力を借りて徐々に形になってきています。
・チームに合わせてのスクラムの分解、バックログリファインメントの実施
もともとスクラムをやっていましたが、より詳細に導入してバックログリファインメントを分離して、実施しました。
・KPI管理の整備
都度集めていたKPIをまずはSpreadsheetに、それからCRM上に実装していきました。
・どこまで仕様を明確化するべきか
バックログには何をやるかだけでなく、課題とベネフィットを追加しました。
・The Modelの採用と役割分担の明確化
インサイドセールス専門の人員を確保して、CRMの構築をしながら役割分担していきました。
・事業計画策定
事業部としての予算を作成し、徐々に予実管理出来るようにしていきました。
・プロダクトロードマップの見直し
元々合った、プロダクトロードマップをリーンキャンバスやバリュープロポジションマップ、ペルソナの作成を通して強化しています。
・DockerやVue、GraphQLの導入
技術的に新しい取り組みをするためにDockerやVue、GraphQLを導入しました。
・レビュー基準コーディング指針の整備
コーディングレビューが属人的で不協和音になりがちだったので文書化しました。
・採用
人員計画を作成し、業務委託エンジニア・正社員エンジニア・企画兼セールスの採用を行いました。
・CRM上へのKPIの可視化・自動化の促進
KPIの可視化や顧客セグメントの収集、ステップメールや商談のリサイクルなどの自動化を行っています。
・新規機能開発の機能要件定義
開発ロードマップにある機能をユーザーストーリやデザインに落とし込んで行きます。
・他部署連携
LRMは元々コンサル企業なので他部署のコンサル知見を取り入れるため、お昼時やチャットなどで顧客の課題について質問していました。
・障害対応フローの整備
顧客が増えれば問い合わせが増えます。障害対応もMTGや文書化を通してかなりスムーズになってきました。
・利用規約やポリシーの改定
利用規約の改定は思った以上に大変な作業で、開発をすすめるたびに改定が必要になります。
PdMに必要なスキル・フレームワーク3つ
PdMは第2のCEOと呼ばれたりするらしく、とにかく管掌範囲が広く、確実にタスクが管理しきれなくなります。個人的な見解を交え主要なフレームワークを説明します。
個人的に必要だと思うスキル
とにかく、必要なのは、
1. 全ステークホルダーへの質問力
社内メンバーへのヒアリングや顧客へのヒアリングは最重要になってきます。機能改善に取り入れたり、開発ロードマップに取り入れていきます。
2. 課題の設定力
とにかく大量のやることリストがある中で、今期の注力目標を決めていく必要があります。プロダクトなら新機能開発に比重があるのか既存機能の改善に比重があるのか、インサイドセールスなら架電状況に課題があるのかリードの獲得数に課題があるのかといったことです。
3. プロダクトに落とし込む上での知識
エンジニア出身、デザイナー出身、Biz出身、カスタマーサクセス出身のPdMの方を見てきましたが、今の所全員バックログリファインメントかそれに準ずる業務が出来る方でした。
4. アプリケーション設計に関する一般的な知識
その機能が将来技術的負債になる可能性が高いかそうでないかはプロダクトの優先順位を決める基準の一つになると思います。
5. toBビジネスに関する一般的な知識
見込み→商談→受注の流れを理解してマーケティング計画を考えたり、組織設計する必要があります。
6. 業界知識
その業界の知識があってこそのSaaSだと思っています。どの顧客までを対象にしているか、STPや4Pなどの基本を抑えるためにも、業界の理解・顧客の理解が永遠の課題です。
BTCモデル
デザインファームTakramの田川さんという方が作られたというフレームワークです。PdMになるひとは、B(ビジネス)、T(テクノロジー)、C(クリエイティブ)のどれかの職種・バックグラウンドから来た人が多いと思います。
どのバックグラウンドを得意分野としていても、3つのバランスを取る必要があると言われています。その人のバックグラウンドに応じて、リーンスタートアップだったり、アジャイルだったり、デザイン思考といった言葉として流行ってきたように思います。
プロダクトマネジメントトライアングル
BTCとその間にあたるものをより細かく解説したものがプロダクトマネジメントトライアングルです。
DoubleLoopというプロダクトを開発されているDan Schmidtさんという方が作れたそうです。
プロダクトマネージャー・スキルチャート・ヘクス
en-japanでプロダクトマネージャーの必要スキルを可視化するために社内向けに作られたものだそうです。
BTCに加え、PM(Project Management)、マーケ視点(Growth)、業界知識(Domain Knowlegdge)を加えて6つのチャートになっています。
プロダクトマネージャーとして活動する上で参考にした本
参考にした本としては以下のようなものがあります。
「ユーザーストーリーマッピング」
これ一つで十分なんじゃないかと思うぐらいどの本よりも役に立ちます。仕様を伝えるのではなくユーザーストーリ(顧客の課題やメリット)を伝えるというコンセプトで、プロダクトマネジメントの迷いがなくなります。スクラムは紙が良いと書いてありますが弊社では、Wrikeを使っています。
「The Model」
「インサイドセールスチームを立ち上げたいんですけど。。。」と先輩に相談した結果、「公開されているリソースも多いし、もう今の時代自社で立ち上げた方が良いんじゃない？」と言われて、読み始めた「The Model」。CRMを使う上でやはり参考になります。ちなみに弊社はSalesforceではなくZohoを使っています。
「カスタマーサクセス」
こんな会社にしたいという将来の状態をイメージ出来ます。
「進化的アーキテクチャ」
あんまり難しいアーキテクチャ採用するすると今後大変なんじゃないかという疑問に答えてくれる1冊。
「Effective DevOps」
最近当たり前になってきて、用語としては、SREの方が流行ってきたきもしますが、Techよりだけでなく、組織よりの話も多いです。
まとめ
PdMはとにかく色々やらなきゃいけないのでボトルネックになりがちなのが反省点ですが、プロダクトのすべての側面に関わるためとにかく面白いです。
・とにかく色々やらなきゃいけないけど時間的に無理なので周りの人の助けを借りる
・ビジネスと開発の両輪を意識して回していかないといけない
・色々やらなきゃいけないのでとにかく面白い！
お読みいただきましてありがとうございました！
スキ！とフォローをおねがいします！
Twitterはこちら
この記事が気に入ったらサポートをしてみませんか？