DIGGLE開発者ブログ

予実管理クラウドDIGGLEのプロダクトチームが、技術や製品開発について発信します

プロダクトマネジメント、時代の変化

DIGGLEのベルマです。DIGGLEではプロダクトマネジメントチームとして6月に組織化しました。立ち上げにあたってどのようにプロダクトマネジメントしていくべきかを考えるため、過去の文献や資料をリサーチしました。
今回のブログでは、リサーチを自分の考察も含めてまとめたものを下記にアウトプットすることにしました。

 

DISCLAIMER: 本記事は元が英語であるため、一部ニュアンスが正しく翻訳できていない場合があります

デジタル化の始まり、SaaSが台頭する前の時代

この頃の特徴

  • エンジニアのリソースが少なく、地理的にアクセスしにくい

  • コンピュータサイエンスに特化した教育・研究を行っている国が少ない

                             areppim AG, 2008, https://stats.areppim.com/stats/stats_unitopnbrxengx09.htm

  • 初期開発コストが高い（特に、サーバーの調達コストが高い）

                            2009年10月14日.https://www.rbbtoday.com/article/2009/10/14/62995.html 

  • 大規模な手動テストの実施やバージョン管理システムの未発達のため、開発の所要期間が長い

  • サーバーは物理的で、クラウドは一部の国でしか利用できず、技術スタックも柔軟性に欠ける

  • 製品はパッケージ商品であり、すべての機能が一緒に開発され、ユーザーからのフィードバックは最後にあり、カスタマーサポートが製品の成功の中心でない

  • マーケットはグローバルが対象であり、参入企業は少ない

 

            Scott Brinker, https://chiefmartec.com/2020/04/marketing-technology-landscape-2020-martech-5000/ 

 

この時代のプロダクトマネジメント

 

 

 

以前は2種類のコミュニケーションが行われていました。

マーケット・コミュニケーション

  1. 競合分析、社内SWOT
  2. 市場の展望、それに基づく
    1. インパクトマップ
    2. ステークホルダーマップ
  3. ユーザーのニーズ
    1. ユーザー要件
    2. ユーザージャーニーマップ
  4. 営業コミュニケーションをリードするためのプレイブックを作成する
    1. 営業パイプラインをベースに、お客様にサービスを提供するための契約書を作成する
    2. 営業はCRM、オンライン広告、パイプライン管理ツールを使用する
  5. マーケターは以下の情報を収集する
    1. 上記の情報をもとに、お客様へのセールスピッチを行い
    2. カスタマーサポートは、マーケティングや製品コミュニケーションに問題がある場合、以下の方法で修正します
  6. お客様のオンボーディング
    1. 機能のリリースをサポートする
    2. 既存顧客からのバグ、問題、要求の収集
  7. このコミュニケーションに関わるすべての人はプロフィットセンターである
  8. このコミュニケーションに参加する全員が、お客様（マーケット）と向き合います

プロダクトコミュニケーション

  1. CTOが率いるプロダクトチーム
    1. エンジニアが多いチーム構成
    2. 要件は技術的なもの
    3. CTOとシニアエンジニアは、営業やマーケティングから要件を聞き、迅速かつ効率的に生産することを目的としています
    4. 製品管理ツールはない
  2. DEVチームはCTOが率いる
    1. チームは製品ごとにチームまたは部門に分かれています
    2. プロダクトをまたいで人が動くが、タイムラグが長い
    3. DEVの要件は、シニアエンジニアからチームに伝えられ、実行される
    4. DEVは課題管理ツール、Github、Wikiを使って日々制作している
  3. QAチームはシニアエンジニアが中心
    1. CTOが設定したリリースの基準に合致しているかどうかを確認する
    2. 常にスコープクリープに対抗する
    3. チェック不足でリリースの妨げになったり、品質を低下させたりしている
    4. エクセルシートで行われる
  4. このコミュニケーションに参加する全員がコストセンターである
  5. このコミュニケーションに参加する全員が、顧客と向き合えていないことが多い

デジタル時代、SaaSの時代

特徴

  • エンジニアリングリソースが豊富で、地理的な問題が業務に影響しない

   


                              

                                                       ARWU (Academic Ranking of World Universities), 08/30/2019

  • 開発の初期費用が安い、サーバー、採用、マーケティングがすべてクラウド上にある

  • CI/CDによる自動テストやデプロイの自動化、バージョン管理システムの進化により、現在では開発プロセスは高度にコラボレーションできるようになりました

  • 開発プラットフォームはすべてデジタルで、プラグアンドプレイスタイル。多くの競合他社からオンラインのクラウドベースのサーバーを複数選択でき、技術スタックは市場の需要に追従する

  • プロダクトスタイルはアプリ重視で、各アプリはエンドユーザーの1つの「ジョブ」を解決することに焦点を当てる。カスタマージャーニーを通して常にお客様からのフィードバックを求める。カスタマーサクセスは、プロダクトを通じたカスタマージャーニーの実現を目指して行動する

  • 競争は広範囲に及び、常に進化しローカルである。アプリは簡単に複製でき、ニッチ市場を獲得するために展開できる

 

画像元

この時代のプロダクトマネジメント

                   

 

  1. 社内全員が同じコミュニケーションチャネルで、同じ方向に向かって話している

  2. PdMは製品チームの一員ではありませんが、すべての部門のフィードバックと市場洞察を促進するために

    1. アイデア

    2. ストーリーからサブタスクに

    3. エピックは、ストーリーを組み合わせて大きな画にしたもの

    4. エピックを各機能に落とし込む

  3. PdMは、そのタスクを管理するための独自のツールを持っている

    1. PdMはマーケティング-セールス-CSのマーケティング・サイクルと連動しています

    2. PdMはDEV-QAと連携し、生産サイクルを回す

  4. どのメンバーも収益の創出を担う

    1. DEVとQAは、ユーザーデータとユーザー行動からアイデアを生み出し、ユーザーエクスペリエンスに付加価値を与えることもできます。

    2. DEVは常にシステムパフォーマンスを管理し、それが顧客維持、ひいてはMRR/ARRに影響を与える。

  5. どのメンバーも様々な情報を元にマーケットと対峙する

    1. DEVとQAは、マーケット側からの情報をすべて把握し、プロダクトの議論に積極的に参加します

* 実際の部門役割の定義は、各社で異なります。例：呼び方や分解されることもある。PdM/PMM、商品企画、事業開発など。

 

過去と現在の対比



                          これまで

                       現在

email

チャットツール

paid feedback

instant free feedback

高価なマーケティング

低価格なマーケティング

競合比較は難しい

競合比較サイトが無料でみられる

ストーリー 引き継ぎ時間が長く、面倒くさい

idea >> story >> epic >> feature

フィードバックは1つの大きなカテゴリー

既存顧客の声と潜在顧客の声を分離

全てのアプリケーションを内製化

3rd partyによる積極的な自動化



その結果、このような変化が生まれました。

 

  1. より迅速で効果的なコミュニケーション*を実現します。

  2. マーケットの変化に機敏に対応するプロダクトマネジメント

    1. CS/Salesからのインプットが重要に

      1. 既存顧客とのベータテスト

    1. マーケットベンチマーク

    2. マーケットに合わせた機能

  3. 最小限のアプリをプロダクトスイートとして開発することができる

    1. 市場シェアと普及率の向上

    1. サブスクリプションモデルに移行できる価格が目立つ

 

* コミュニケーションに深みがない、つまり返信は早いけれども、積極的なコミュニケーションに欠けることもあります。

 

この記事で使用している用語について
  • SaaS - サービスとしてのソフトウェア
  • テスト/QA - 顧客にリリースする前にソフトウェアをテストすること
  • リポジトリ - 一連のソースコードと、それらのファイルに対する変更の履歴
  • Git - リポジトリの分散バージョンコントロールのためのソフトウェア
  • バージョン管理システム - ソフトウェアチームがソースコードの変更を長期的に管理するためのソフトウェアツール。
  • デプロイ - ソフトウェアシステムを一般顧客が使用できるようにするためのすべての活動。
  • 技術スタック - ソフトウェアを構築し実行するために使用する技術の組み合わせ。
  • ユーザージャーニーマップ - ソフトウェアを利用するユーザの流れを視覚的に表現した図
  • CTO - 最高技術責任者
  • 課題管理ツール - チケットトラッキングとアジャイルプロジェクトマネジメントを可能にする課題追跡製品
  • スコープクリープ - プロジェクト開始後に、プロジェクトのスコープが変更されることを指します。
  • コストセンター - 利益を直接的に増やさないが、それでも組織のコストがかかる組織内の部門や機能
  • ジョブ - 人々がなぜそのような行動をとるのかを理解するための、ジョブ理論というフレームワークにおける用語
  • ハイパーローカル - 明確に定義されたコミュニティとその住民に向けられた主要な焦点
  • Ideas-Story-Epic-Feature - エンドユーザーの視点で書かれた、ソフトウェアシステムの機能に関する非形式的な自然言語による記述
  • PdM - プロダクトマネージメントまたはプロダクトマネージャー
  • MRR/ARR - 月間定期収入/年間定期収入