評価スコアが低かった開発アイテムをロードマップに載せるまでの道のり

tebiki現場分析のPdMのこみやまです。
Tebikiに興味を持ってくださっているPdM職はじめ開発職の皆さんに、優先順位付けや試行錯誤の状況、また社歴やPdM歴が浅くても、考えたことを実践する機会を得られるということが伝われば幸いです。

自己紹介: こみやま 2024年11月入社。夫と 2歳半の息子と3人暮らし。
前職では5年間、新規事業とWebアプリケーション開発のプロジェクトマネジメント(QCD管理、スコープ調整、業務オペレーション構築など)を行っていました。
「何を作るか」「なぜ作るか」の領域に、より積極的に関わりたく、現職からPdMとして働いています。今年の8月から「tebiki現場分析」プロダクトに参画しました。

背景と課題:

プロダクトの状況

「tebiki現場分析」は2024年1月に正式リリースしたプロダクトです。 prtimes.jp

これまでは以下の開発アイテムを中心にどんどん作ってリリースしてきました。
・必須だと自覚のある機能
・お客様からの要望の多い機能

狩野モデルでいうところの「当たり前品質」と「一元的品質」の機能。 (エンプラのお客様にも契約いただいており「当たり前品質」の水準が高い!本望です!)

画像はhttps://service.shiftinc.jp/column/10933/ からお借りしました。

開発アイテムの優先順位付けの方法

優先順位付けにはLayerXさんのアウトカム計算を参考にしたものをベースとして活用しており、スコアが高いものが開発予定の俎上に乗っていました。(記事タイトルの「評価スコア」はこれです。この記事内では「スコア」と呼びます。)
プロダクトのフェーズとの相性が良く、納得感のあるラインナップになっていたように思います。

findy-code.io https://speakerdeck.com/shnjtk/layerx-improve-development-productivity-of-product-engineers?slide=21

また、ビジネスサイドが各開発アイテムに対する「契約」「失注・解約」「アップセル」への影響を取りまとめてくれており、バックログの並び順に反映してきました(以下のラクスさんの記事のp.2に近い活動)。

productzine.jp

解決すべき課題

そんな中で「スコアは低いが、価値がとてもありそう」と感じるEpicが出てきました。スコアが低かった理由は、顧客からの要望がなかったからです。

既存の優先順位付けは、要望(=顕在化した顧客ニーズ)の評価に適していた一方、「価値提案」や「潜在的な顧客ニーズ」の評価を行うためには仕組みが不足していました。 該当のEpicがプロダクトにとってプラスなのは間違いないが、スコアが高いアイテムが複数残っている中で、「本当に今 組み込むべきか?」「価値がとてもありそうの”価値”とは?」を自分自身でも、ロジカルに説明ができないという状況でした。

取り組み:

「このEpicに価値がある / やるべきだ」という仮説を検証するために、やったことを書きます。

ビジネス指標への影響をヒアリング

既存の評価軸と方向性が異なる指標だと、他のアイテムと比較しづらいため、ビジネスへの定量的な影響をベースに取りまとめることにしました。

マーケティング、セールス、カスタマーサクセスに、色々なビジネス指標を並べて影響をヒアリングして回りました。
プロダクト参画直後で仮説を持ってヒアリングするために、以下をよく読み込んで仮説を立てました。
・契約前:セールスのPipeline、商談スライド、商談のきっかけ施策
・契約後:カスタマーサクセスのPipeline

これまでビジネスサイドが開発チームに連携する情報は「不足機能とその詳細」が主でしたが、今回は価値提案なので「訴求が変わるか?」「この機能は商談のどのフェーズで見せる?」なども聞いて、新しい発見がありました。
トンチンカンな仮説を当てても丁寧に正してくださったビジネスチームの皆さんのおかげで理解が深まりました。

Pipelineを研究したときの何も見えないFigJam。Pipelineはすごい。

解像度を高めて認識合わせする

なお、ビジネス指標の数字変化は「スコープや体験がどんな感じか?」「どういうレベル感なのか?」に大きく依存します。PdMとステークホルダーが同じものを想像して話せてなかったり、それを見越した結果、「不確実性が高い」という結論になりがちです。

それを防いでくれたのは、開発チームの動きでした。
・デザイナーが要件ゆるゆるにも関わらず、爆速で素晴らしい松竹梅のプロトタイプを作成
・エンジニアが「サッとできたんで動くもの作りました」と PoC作って爆速でSprint Reviewに持ち込み

これらのおかげでビジネスサイドと機能や体験のイメージをかなり早期に合わせることができ、また期待を持ってもらえました(ここで「近い時期にGo」の空気感が醸成できていました)。

その後、「レベル感」の認識をあわせるために、Epic単位で目指す「定性ゴール」と「定量ゴール」を設定しました。
・定性ゴール:「初回商談の顧客に、XXXと感じさせる」「契約直後の顧客が、自分でXXXできる」など
・定量ゴール:上記を実現するために必要な要素と数値の具体。「XXをYY%削減」「XXをYヶ月以内に2倍にする」など

結果、他の開発アイテムと並べてもインパクトが大きそうだし、他の要因を考えても早めにやる意味がある、ということで無事に次四半期のロードマップに組み込むことができました。

まとめと展望:

・現時点では、ロードマップに組み込んだ段階なので、リリース後に以下の検証と振り返りが必要
 ・Epic単位の定性・定量ゴールが達成できたか?
 ・期待したビジネスインパクトが得られたか?

・今回は一連の取り組みにおいて、問いの順序が前後したりヒアリングが五月雨だったりと時間がかかったが、次は2週間くらいで「情報収集 → 今やる理由の整理」までを完成させたい

・デザイナー、エンジニアの自主性にとても助けられてうまく進んだが、強いメンバー頼みにならぬよう、不確実性が高い案件をドライブできるようにしていきたい

・今回はEpicを途中で引き継いだが、今後は「価値の高そうなアイデアを生み出してDiscoveryするフェーズ」から一人で完遂できるようになりたい

案内:

Tebiki社では一緒に働く仲間を募集しています!
ぜひ採用サイトをご覧ください。
tebiki.co.jp

興味のあるポジションがありましたら、カジュアル面談からぜひ!
6. PdM の求人一覧 - Tebiki株式会社
3.エンジニア の求人一覧 - Tebiki株式会社
4. デザイン の求人一覧 - Tebiki株式会社

補足:

1.優先順位付けにおいてビジネスインパクトの存在は大きいですが、以下と矛盾するものではありません。
プロダクトの提供価値のイメージをチームで共通認識として持てている感覚が明確にあり、バックログを見て違和感を感じることは全くない。 techblog.tebiki.co.jp

2.「やるべき開発アイテムがたくさん残っている」と書いたが、開発はとても速いし、顧客価値やビジネス影響をすごく考えて動いてくれる文化で心強いし背筋が伸びます。

私は、開発チームの外にいる利害関係者(お客様はもちろんプロダクトを現場にお届けしてくださるセールスチームやマーケチーム、ひいては全社、投資家)にとって価値のあるものを提供することを最優先すべき だと考えています。

techblog.tebiki.co.jp

3.「取り組み」にあたっては、勉強会や読書会に参加して 会の内容にかこつけて他社の事例を教えてもらいました。フェーズやビジネス状況によって適切な指標は違うということを、生身の人と会話することで実感とともに理解しました。 進行形で学ばせていただいている読書会はこちらです。

productkintore.connpass.com