ゼロイチPO始めてました。その振り返り。

Ubie で ML Engineer をやっているくんぺーです。これまでアルゴリズム開発・分析に注力してきましたが、ここ半年くらいは新規プロダクト開発 (ゼロイチ) のプロダクトオーナー (PO) 業にもリソースを割いています。

ゼロイチ PO に若干慣れてきたか (?) というタイミングです。いくつかの学びや失敗を振り返ってみようと思います。できるだけ再現性のある内容を書きますが、ゼロイチの状況は多様なので、あくまで日記だと思ってほしいです。

ここでのゼロイチ PO とは「toC のユーザ体験を新規で立ち上げて PSF, PMF させるまでに責任を持つ役割」を指すことにします。小規模チームのマネージャー的な立ち回りの話が自然と混ざってくるかもしれません。

では、始めていきます〜。

スタートアップをやる

まずはやりたいことに対して最小の投資を受けて、アウトプットを出して期待値を上げて、見合った量の投資を受けて… と拡大していくプロセスを経る必要があります。ここでの投資とは主に (自分の稼働を含めた) 人的リソースです。リソースは有限なので、全体で注力分野を間違えないために、これが必要です。スタートアップがシリーズを登っていくのと似てるなあと日々思います。

社内のある人はこれを「ちょっと齧る」といっていて、またある人は「初手の札をまず見て、降りるかオールインする」といっていました。

既存事業がすでにいくつかある場合、各所から様々な期待値を背負ってしまうとアウトプットを示しにくいので、期待値の種類にも気を配る必要がありそうです。

「新規事業開発室」のような建付けは、タイミングによってリソースが余ってしまい何かを早急に初めてしまうのでワークし辛いのかなとも思います。大きい組織になっても、最初はひとりで時間を絞り出して初めるくらいが良いのかなあと。とはいえミニマムで技術的ハードルが高い場合はまた変わってきそうで難しいですね。

リソース配分は見直される (べき)

ほぼ上と同じ話なのですが、アウトプットがないと自然とリソース配分が縮みます。縮むべきです。やりたいことがあるなら、縮小を回避するために最速で何かしらの結果を出す必要があります。時間をロスしないために何を検証するのかを定めてその最短ルートを行く必要があります。

自分は「なぜ今それに張るのか」という当然の問いに答えるのに苦労しました (しています)。NPS や MAU などのメトリクスで明確に示せるならそれでいいですが、もっと粗い見積もりでもいいし、もし動くものを紹介するだけで組織の期待感が得られるのであればそれでも良さそうです。

もっというと、個人の信頼がそれを担保することがあるのかもしれません。弊社 quvo は人に投資するといいかも？みたいなことを言っています。

2つ目は事業ではなく、ヒトに投資するという考え方です。事業に投資するという意識の下では、その事業がうまくいかない、ROIが低いと判断された段階で投資が途絶えるということが起こります。しかし、ヒトに投資するという判断だと、仮に想定していた仮説が誤っていてもピボットすることが可能になります。
https://note.com/quvo_ub/n/n2acd8af1f0e0

自分はこれを盛大に間違えていて、既定路線を想定しすぎた結果議論を後戻りさせました。最近は実際に動くものを意識的に見せて回ったりしています。技術者としては、技術的アウトプットで人を動かしたいと思ってしまうフシがあり、もっとなんでも出していくべきだったと反省があります。

チームの関心はコトに

一方で、チームの関心を前述のリソース配分に向けさせるのはもったいないなーと思います。それは PO の仕事だなと。別に隠蔽するべきという話ではなくて、自分はデイリーミーティングでヒーヒー漏らしています。(もっと上手くやれや、と思われてる気はします。)

最強のチームで何かを作るのはお祭り的でサイコーに楽しいのですが、PO だけはずっと祭りに参加していちゃだめだよねという話ではあります。

ちなみに、自分は ML Engineer なのでケイパビリティとしてはデータ絡みで祭りに貢献できます。でもアプリケーション開発やデザインのように常にタスクがあるわけでないので、PO は兼任する役割としてちょうど良かった感もあります。スモールチームでワイワイやりたいデータ人材は PO とかやろうぜ！

広い雑談大事

これまで情報のアウトプットの話をしていましたが、インプットの重要性にも目を向けます。多くの人とラフに雑談するのがかなり重要だなと思いました。思いがけないヒントや足りない視点のアドバイスを貰って前進することが多かったです。例えば toC サービスに強い人からはファネルや広告の話を、ドメインの猛者からはユーザの声の肌感をもらいました。また、ゼロイチ PO の先駆者に姿勢のアドバイスを貰うこともありました。

ただし、みんな好き勝手なことを言う点には注意です。雑談なのでそれはそう。

この雑談がオトクなのは、インプットだけでなくアウトプットを兼ねる点です。自分たちの現状を話すことになるので、自然と期待値が浸透します。Ubie は情報の透明性を保つ文化ではあるのですが、現状のアウトプットを浸透させるためにはやはり意図的にプッシュする労力が要ります。あと単純に、「めっちゃいいじゃん！」といってくれる人が現れると心理的にもいいです。

最適解よりスピード

ゼロイチでは、アイデアが間違えていないか？だけを検証するべきだと思いました。もっと良い解がないか？を問うのはまあ必要なのですが、たまに目を向けるくらいが良さそうです。それよりも時間が貴重です。

データサイエンスのクセで十分な情報から最適な解を探したくなるのですが、不完全な情報 (例えば数件のインタビュー結果) からこれはいける！と意思決定してそれを前提にしないと話が進みません。暗闇の中を進むようで勇気がいるのですが、手応えを得られたときはたいてい少し飛躍していた気がします。

このスピードでデータが溜まるなら数週間待てばいいか〜と思ってリリースを放置して様子見していたことがあるのですが、それは結果的に誤りでした。データ待ちでタスクが滞っていたためです。データが足りないなら増やすための施策を打つなり、リスクを取って早く結論を出すなり、もしくは早く仕込んでおく必要がありました。

体験と集客を往復する

教科書的には、一部のユーザに刺さるコア体験を作って (PSF)、太い集客チャネルを確立して (PMF)、双方を継続的に改善して… と書かれがちかと思います。その順番はさておき、万人に刺さる体験はファンを作れないし、ニッチ過ぎる体験はスケールに成功しません。双方に目を向けつつどこから検証するかのバランス感覚が求められると思いますし、今やるのはどちらなのかを見直し続けるべきです。このバランスはチーム全体で意識できていると思います。(デザインに着手したデザイナーが最初にキーワードプランナーを集計し始めたときは頼もしいなあ…と思いました。)

社内のゼロイチではガチの更地とは違って PMF に使える武器があります。例えばある程度成長した既存サービスのユーザや、広告に使えるお金などです。既存サービスからの流入を頼れるのであれば、それを前提にしたプランニングをするべきです。結果的に取り組むべきことが少し体験側に寄るのかもしれません。

ドメイン知識大事

データは常に足りません。そこで指針になるのはドメイン知識だと思いました。事前情報ですね。ここでのドメイン知識は事業領域・ビジネス・ユーザの理解などを指しています。

これまで自分はドメイン知識を軽視していたフシがあった気がします。ML Engineer として動く上では、What を誰かが決めてくれる以上そこまで困ることはありませんでした。しかし、正しい意思決定をするためにはこれが貴重な武器でした。

振り返ると、チーム全体で明確に足りなかった知識 (事業領域、ビジネス) は、シンプルに勉強して補いました。あとは社内の専門家の意見をラフに聞きに行くなどしました。これは振り返って良いムーブだった気がしています。

最後に

全然上手くできてねえ。40点くらいです。
ガンガン助けてもらいながらなんとか成していきたいね。