PMにとって苦渋の決断「機能を消す」を実行した話
自己紹介
スマートバンクでPMをしている bnbn（ぶんぶん）です。入社から半年経ち、無事に試用期間を卒業しました。 入社エントリを貼っておきます。
スマートバンク社に入社しました & 転職活動の振返り｜國分佑太 | Yuta Kokubun｜note
今年は地味PM Advent Calendarに参加させてもらって、この記事を書いてます。12/16に記事をアップすることにコミットしておりましたが、〆切がある方が人間って頑張りますよね（小並感）
機能を消す is 地味 of 地味な仕事
このエントリを読み始めている地味PMクラスタのみなさんであれば、リリースした機能を消した経験もあるかと思います。機能を消す = 結果が出てないということなので、細かい経緯は社内だけで共有されることが多く、インターネットの海に知見が放流されることは少ないです。
今回はそれを敢えて、記事に書いて公開してみます。SNSを見ていると、各社のPMがキラキラした実績を出していて、世の中には成功者しかいないような錯覚を覚えますが、そんなことはありません。みなさん記事に書かないだけ、Tweetしないだけで、結果が出ない経験を数多く積んでいます。思い通りにならない結果すらも糧にして、良いプロダクトを作る術を身につけてきたのです。
どんなサービスを作っているか
B/43（ビー ヨンサン）という、チャージ式Visaプリペイドカードと家計簿アプリがセットになったサービスを作っています。俗にいうFinTechサービス。この3つが特徴です。
支払うだけでリアルタイムに家計簿が記録される
ICチップ付き/タッチ決済対応カードで、キャッシュレスで支払い可能
残高や消費ペースがひとめでわかるから浪費が防げる
この3つの特徴を有しながら、1人でも使える・パートナー同士でも使える・親子でも使える、サービスを提供してます
どんな役割を担っていたか
「細かな施策を積み上げ、ペアユーザーのウォレットシェアを獲得する」というのが、自分が属していたPJのミッション。ユーザーの皆さんは、現金・クレジットカード・スマホ決済など、色々な支払い手段を持っています。そんな中、支払い時にB/43ペアカードを選んでもらえるか、選んでもらう回数を増やせるか、というのが重要な命題でした。
目標KPIは1人あたりの決済金額です。1人あたりの決済金額 = 決済回数×単価で分解できますが、自分達でコントロール可能なのは決済回数の方。なので、この決済回数を伸ばすためにどんな論点があるのか、図のように整理しました。
目的→課題仮説のツリー（一部抜粋）
どんな施策を打ったか
ウォレットシェアを獲得するためにやった施策はいくつかあるのですが、成果が出た施策は割愛します。本記事では実装したけど結果が出なくて最終的に消した機能、残高2000円以下になったら入金促すプッシュを打つについて書きます。
目的→課題仮説→機能仮説のツリー（一部抜粋）
「決済したいときに十分な残高がある」は少し補足。
B/43はプリペイドカードなので決済をする前に必ず入金が必要です。なので、決済回数を上げるその前に、ユーザーの入金額を上げないと、そもそも決済回数が増えない = GMVが増えないよねという話です。
施策の目的・背景
実際に書いたNotionのキャプチャ貼っておきます。
実際に送ったプッシュ
送る対象・送らない対象の数が半々になるよう、ユーザーIDが奇数のグループにだけ通知を送りました
良い結果は出ず
具体的な数値・チャンネル名・メンションした社員名は隠しますが、実際に社内で共有した内容がこちら。
PMをやっていると「自分が考えてリリースした機能が良い結果を生まない」事態に遭遇することがあります。考えた打ち手が全てヒットすることはないので、結果が出ない時にどんな学びを得られるか、どんなネクストアクションが取れるか、がとても大事です。
結果が出ないと、やはりガッカリします。良い結果を出すために施策考えますからね。自分も今回の施策が成功するはずと思って進めましたし、結果が出なくて落胆もしました。ただ、答えを出すのはユーザーです。PMにできることは、出された答えを真摯に受け取って、より良いものを次に提案することだけ。
今回のケースでは、結果が出ない機能は消した方がプロダクトのシンプルさがキープされるので、ユーザーのためになるという判断を下しました。
「機能を消す」を実行するための条件
スタートアップを数社経験していますが、「機能を消す」を実行に移せないケースも多く見てきました。実行に移せるケースとそうでないケースで、違いはなんでしょうか。「機能を消す」を実行するために、欠かせない条件が3つあります。
「シンプルさを保つ」ことの優先順位が高い
機能を消せる想定で設計・実装をする
結果を明確に判断できる効果検証をする
1. 「シンプルさを保つ」ことの優先順位が高い
1番大事なのがこれです。会社の中で、プロダクトのシンプルさを保つことの価値が認識されてなかったり、優先順位が高くなかったりすると「結果が出てない機能を消す」行為は時間の無駄と認識されます。
👱♂️「そんなことに時間使うなら新しい施策やろうよ」
👱♂️「それやってKPI上がるの？」
上司に↑のようなことを言われた経験があるのは、自分だけではないはず…。売上・数字を盾に取られると、かなり反論難しいんですよね 😢
自社のプロダクトが複雑怪奇になってる経営者の方は、ご自身の価値基準や優先順位の伝え方が原因になっている可能性があるので、この記事を読んで一度セルフチェックしてもらえると嬉しいです。
ちなみに弊社では、CXOのtakejuneがブランド定義を明文化していて、シンプルさを追求することを宣言しています。文書として明文化されていて、なおかつシンプルさを追求する文化になっていて初めて、機能を消す仕事に意味があると解釈されます
会社の全体会議で自分が発表した時も、takejuneがこんなコメントをくれました。結果が出てないことは自覚してるので、こういうコメントをもらえると救われます😭
2. 機能を消せる想定で設計・実装をする
次に大事なのはこちら。最初から機能を消せる想定をしてないと、実装が密結合化して機能を消すこと自体不可能になってしまいます。それを防ぐためにはPMが「結果が出なかったら機能を消すこともある」と明言することが必須です。「結果が出なかったら機能を消すこともある」を明言することにより、以下のような具体的な議論が生まれます
実装観点
どんな実装にすれば、後から機能を消しやすいか
逆に全てがうまく行った場合、どんな機能が今後実装されそうか
どんな設計をすれば、拡張機能の実装が容易か
事業メリット & ユーザーメリット観点
ユーザーが行動を起こしてくれそうな仕掛けになっているか
施策に気付いてくれるユーザーが充分量存在するのか
ターゲット外のユーザーが触れて、嫌な気持ちが生まれないか
こんな観点で議論をした結果、実装の追加削除が容易なプッシュ通知でターゲットユーザーに訴求し、入金件数やアプリ来訪数が増えるのかを検証することになりました。
3. 結果を明確に判断できる効果検証をする
最後に効果検証です。「結果が出てない！」「改善しても可能性ない！」と明確に答えが出てないのに、機能を消すとか絶対できないですよね。なので、この工程をしっかりやり切ることが大事です。
まずは結果を判断する指標を、事前に設定することから始まります。PM自身に手を動かして分析した経験があると、本当に分析可能なのかを精度高く見極めることができます。
次に分析です。この施策では入金額・件数・リードタイムは有意に改善しませんでした。しかし、1回の分析で諦めてはいけません。改善する余地が本当にないか、ポテンシャルを示す指標が他にないかを議論しましょう。今回のケースでも、可能性を探る議論をしました。その結果、以下のようにプッシュのタップ率を見てから、最終決断を下すことに。
そして2週間ほど後に効果測定をした結果、以下のような結論になりました
失敗から学び、事業の成功確率を上げる
以上が「施策立案→リリース→機能を消す」の経緯です。結果が出なかったこと自体は残念ですが、学びは得られたし次やってみたい施策も出てきました。社内Slackに結果・経緯を共有した際の、みんなのリアクションが印象的だったのでキャプチャを貼ります。
弊社のバリューで Be Open というものがありますが、Be Openマインドを持つ人が多いな〜と改めて思いました。新しいプロダクトを作っていく上で、全部成功続きなんてことはやっぱりないんですよね。失敗からどう学ぶか、1人がした失敗をみんなの知恵に転化できるか、が本当に大事なんです。それを理解してくれている人が多くて、改めてスマートバンクいい会社だなと思いました。
狙いが明確な挑戦をする→そこから学ぶ→挑戦→（以下ループ）を愚直に回すことで、事業の成功確率を高めることもPMの重要な役割だと思っています。結果は出る時もあれば、出ない時もあります。重要なのは、狙いを明確にして結果の良し悪しを鮮明に出すことです。たとえ失敗したとしてもそれが将来の布石になるよう、手筋を組み立ててしっかり実行すれば、そのうち結果はついてきます。
重い開発は仮説検証を厚めにやろう
今回は既存ファネルをグロースさせる目的だったので、「手数を多く出す + ダメなら消す」というアプローチを選択できました。しかし、全部の開発でこのアプローチが有効なわけではないです。
プロダクトのファネル構造を変える大改修だったり、全くの新規プロダクト作りに関しては「作ってダメなら消す」はお勧めしません。実装工数が大きい開発で作って消してをやると、多くの時間を無駄にするし、チームのテンションが大幅に下がります。「開発する前にちゃんと検証しとけよ」ってみんな思いますし、確実に雰囲気が悪くなります。
弊社で今週リリースしたジュニアカードに関しては、PJ発足から1年弱の時間を掛けていたので、価値検証・仮説検証に多くの時間を投じました。「本当にニーズがあるのか」という価値検証から「カードに同封する説明書が分かりやすいか」というユーザビリティテストまで、多くの検証をしました。この辺に関しては、また別途記事を書きます。
採用してます！
スマートバンク社はジュニアカードも出して、ますます面白いフェーズになっています。この記事を読んだ地味PMクラスタの方は、ぜひPMの募集要件を見てみてください。
PM以外の職種も絶賛募集中です
「応募するほどではないが興味はある」という方は、ぜひカジュアル面談で色々お話ししましょう
この記事が気に入ったらサポートをしてみませんか？