見出し画像

僕と会社とプロダクトマネージメント

EventHub  Advent Calendar 2021の24日目の記事です。昨日の記事は塚本さんの「なぜEventHubでチャレンジしようと思ったのか」です。


株式会社EventHubでプロダクトマネージャーをしている葛巻です。入社して今月で6ヶ月になります(無事、試用期間が終わりました)。

最近、プロダクトマネージメントが注目される事も多いので、キャリアパスを聞かれる事も多いのですが、自分の経歴を振り返ってみると、助言が出来る再現性のあるモノではありません・・・。

  • 20代前半:エンジニア

  • 20代後半:コンサルタント

  • 30代前半:プロダクトマネージャー?

  • 30代中盤:プロジェクトマネージャー・UXデザイナー

  • 30代後半:プロダクトマネージャー (←今ココ)

10年前、僕がプロダクトマネージメントの真似事を始めた時は、プロダクトマネージャーという職種を日本で聞く事はありませんでした。そもそも、プロジェクトマネージャーとして様々な業務に関わる中で、気が付いた時にはプロダクトマネージャーと呼ばれるようになっていたという感じ・・・。

最近は、多くの企業や有識者の間でプロダクトマネージメントの重要性が浸透し始めており、素晴らしい書籍や記事も当時と比べると増えています。一方で、市場にプロダクトマネージャーが少ないため、CEOやエンジニアが代行する企業も多いと思います。

今回はEventHubがどの様にプロダクトマネージメントを行っているのか?という具体的な事例をお話ししたいと思います。プロダクトマネージメントが何なのかは理解しているが、具体的に何をすれば良いか分からない・・・というプロダクトマネージャーの方、プロダクトマネージャーの採用に苦戦しつつも、今のメンバーで良いプロダクトを創りたい・・・という企業の皆様の参考になれば嬉しいです。

EventHubの概要


EventHubというプロダクトの事を少しだけ紹介します。EventHubは一言で表現すると「All-in-One Event Management Platform」です。

EventHubの特徴は2つあります。1つ目は、オンライン・オフラインを問わず企画から開催・活用を支援し、イベントマーケティングを効率化出来る事。

2つ目は、イベントに関するデータを一元管理・分析する事により、計測が難しかったイベントの成果を可視化出来る事。結果として、主催者の成功を中長期的に実現するお手伝いをします。

幅広いイベントタイプをカバーしているEventHubですが、「人がつながる、世界が近づく(Empowering connections that matter)」というEventHubのVisionの通り、発見・交流を主軸とするビジネス向けのカンファレンスや展示会・商談会がメインターゲットです。

因みに、関東限定ですがCMも・・・。

大切にしているコト


EventHubを語る上で全員が大切にしている価値観があります。個々の価値観の説明は、下記のスライドを見て頂ければと思いますが、3つの中でも特に大切しているのは、1つ目の「参加者体験の重視」です。

僕達が普段向き合っているのは主催者やイベント支援企業ですが、彼らが実現したい事が必ずしも参加者のためになるとは限りません。分かり易いように少し脚色していますが、以下は一例です。

背景・課題
主催者は参加者の声を様々な観点で収集しマーケティングに活用するため、複数のアンケートを作成し配信したいが、アンケートが複数あると参加者が気付かないので、回答率が低くなる。

要望
アンケートの回答率を高めるため、参加者にアンケートを配信する際、強制的にポップアップ出来る 等、アンケートが目立つようにして欲しい。

・・・。主催者の気持ちは痛い程、良く分かります。しかし、参加者の立場としては、動画に集中している中、ポップアップが表示されるのは迷惑です。アンケートに回答するとしても1つや2つの回答でお腹一杯です。

参加者が「あの主催者のイベントはアンケートが多くて楽しくない」「目的が露骨過ぎて参加したくない」と思ってしまったら、短期的にアンケートの回答率が上がっても、中長期的にはイベントに参加者が集まらず、結果として、参加者の声が収集出来なくなります。

主催者の要望を検討する際は、先ずは一度、参加者の目線に立って、顧客である主催者の課題を本当に解決出来るのか?をプロダクトマネージャーは当然ですが、全員が意識し続ける事を大切にしています。

現在のプロダクトマネージメント


BusinessとProductの2つのチームが様々なツールを利用し、EventHubのプロダクトマネージメントを行なっています。

Business(左側のサークル)

Business側は、Marketing、Inside Sales、Field Sales、Partner Sales、Customer Success/Customer Supportという5つのグループに加えて、売上や各種KPIを管理するRevenueというグループがあります。Revenue以外の各グループが収集した顧客の声(=Insight)をSalesforceやZendeskを介して、Productboardというツールに集約します。プロダクトマネージャーはProductboardで管理する課題一覧とInsightを紐付けます。

RevenueとEffortは開始したばかりのため未評価・・・

プロダクトマネージメントにおける一番の悩みは課題の優先順位付けです。EventHubは、課題を4つの軸で評価し、優先順位を設定します。Client Needs、Revenue、Product VisionはDriversと呼ばれ、3つの合計が100%になるように設定します。算出した値をEffortで割って、優先度を決定します。

(Client Needs x 50%+Revenue x 20%+Product Vision x 30%)÷ Effort

(3つの軸の重み付けは仮の数値です)

当たり前ですが、Drivers(Client Needs、Revenue、Product Vision)の合計が高く、Effortが低い課題の優先度が高くなります。

Driver 1:Client Needs
課題に紐付くInsightの数量・優先度、顧客の属性を元にProductboardが自動的に算出する。顧客と日々接するメンバーの想いの積み上げでもある。

Driver 2:Revenue
Revenueグループがマーケットの動向を参考にしつつ、中長期的な視点で売上や各種KPIへの影響をトップダウンで評価する。

Driver 3:Product Vision
実現したいVISIONへの影響を評価する。プロダクトマネージャーがユーザーリサーチやデータ分析の結果を元に、デザイナー・エンジニアと会話をし、参加者の声を代弁する事が多い。

Effort
エンジニアが開発の規模・複雑性を評価する。解決する価値のある課題でも、膨大な工数やリスクが発生する場合、より早く価値を提供出来る別の課題を優先する事ある。

自動的に算出するClient Needs以外は比較的曖昧な基準を採用しており、ある程度のロジックはありますが、課題を5段階で相対評価しています。重要なポイントは、正確な評価を行う事ではなく、様々な観点を総合して納得感のある優先順位付けが出来るかどうかというプロセスの合意です。

元も子もない話ですが、優先順位が本当に正しいかどうかは、リリース後も注意深くデータを観察し続けないと判断出来ません。スタートアップや新規事業においては、机上の議論に時間を掛けるよりも早くリリースしデータを集め、プロセスを改善する方が意味があると考えています。可能な限り労力を掛けず、各メンバーの納得感を醸成した上で優先順位を整理し、行動する事が大切と考えて今の基準に落ち着いています。

優先度を元に各チームの代表が話し合い、3ヶ月単位のプロダクトロードマップを作成します。原則、優先度が高い課題に取り組む事になりますが、優先度が高い課題を精査しつつ今期のテーマを決め、課題の整理とリソースの配分を行う事が多いです。テーマがあった方がロードマップの軸が揺れにくくなりますし、メンバーの共感も得易くなると思います。

プロダクトロードマップもProductboardで管理しており、誰でも閲覧・コメント出来るようになっています。3ヶ月単位で作成しますが、作成後もマーケットの変化や顧客の声に応じて、定期的に振り返り、見直しています。

Development(右側のサークル)

EventHubはスクラムを採用しています。プロダクトロードマップに沿って、プロダクトマネージャーとエンジニアがSprint Planningを行い、1週間のスプリントで開発する要件を話し合います。設計以降のチケットはJIRAで管理していますが、ProductboardはJIRAと同期する事が出来ます。設計を開始するタイミングでProductboardからJIRAへ課題をプッシュしています。

Productboardの範囲
顧客の声の収集・整理・優先順位付け、要件の整理

JIRAの範囲
設計・デザイン、開発・テスト、QA、リリース

要件の説明はプロダクトマネージャーが行いますが、デザイナーとエンジニアに同時に説明し、三者がFigma上でコミュニケーションしつつ、設計を進める事が多いです。

Sprint Planningはエンジニアは勿論、Business側の主要なメンバーも参加していますし、要件や開発の進捗もJIRAで公開しており、プロダクトロードマップ同様、閲覧・コメント出来ます。

スプリントの終わりには、Business側のメンバーも参加するProduct Reviewを行い、エンジニアが成果をデモしたり、設計中の仕様を説明しフィードバックを得る重要な場所となっています。Business側のメンバーも開発中の機能を早く知る事が出来ますし、理解も深まります。EventHubの充実したヘルプページも、Product Reviewの内容を元にCustomer Supportが作成します。

EventHubはフルサイクルエンジニアを前提としており、設計や開発・テストからテクニカルサポートまでエンジニアが対応します。エンジニアが顧客の声を直接聞く機会も多く、設計に活かされる事も多いです。

Customer Success/Customer Supportを中心に最近開始したのは、リリースの際、ProductboardのInsightを元に顧客を逆引きし、要望のあった顧客へアプローチするという取り組みです。諸事情により失注・解約してしまった顧客への再提案、既存顧客へのフォローアップを目的としており、今後の成果が楽しみです。

振り返り、そして、最後に・・・


入社から6ヶ月間で試行錯誤しつつ、ある程度、納得感のあるプロダクトマネージメントの型が構築出来たと思っています。しかし、イベントマーケティングは外部環境の変化を受け易い市場です。EventHubも急成長しており、会社の規模に合わせて継続的にアップデートする必要があります。

今回、ご紹介したEventHubのプロダクトマネージメントが少しでも参考になればとは思いますが、非連続の成長を成し遂げるプロダクトを創る上で、型通りの方法論に囚われ過ぎるのも良くないとも感じています。考え抜いたロジックを敢えて放棄し、直感で突き進むという判断が必要になる時もあります。しかし、(創業者ではない)プロダクトマネージャーが直感で突き進む場合、周りからの信頼が重要になります。信頼を得るため、納得感の積み上げを重視したのが、今のEventHubのプロダクトマネージメントです(本当に積み上がっているのか日々ドキドキしています・・・)。

最後になりますが、自分自身への自戒も含め。プロダクトマネージャーに一番重要なマインドは、あらゆる事象に好奇心を持ち自問自答を繰り返す事だと思っています。参考になる部分は取り入れつつ、合わないと感じた部分は聞き流す・・・くらいの気持ちで利用して頂ければ嬉しいです。

最後までお付き合い頂きありがとうございます!!


最後を飾る25日目の記事は、当社代表の山本理恵が魂を込めてお届けする10,000文字以上の超大作「EventHubの過去と現在、そして、未来」です。

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