見出し画像

スタートアップ創業初期に入って分かった、プロダクトオーナーに最も重要なこと

Ubie株式会社に1人目のビジネスメンバーとして入ってから、2年が経った。はじめは営業やカスタマーサクセスに軸足を置いていたが、直近1年間はAI問診Ubieというサービスのプロダクトオーナー(以下、PO)に軸足を置くようになった。

スクラム開発のPOという役割はまだまだ世の中的事例も少ない上、学びも大きかった。今回は、当時すったもんだした経験を踏まえながら、1年間役割を担う中で気付いたPOにもっとも重要なことを書き残してみたいと思う。

行間から垣間見える、弊社Ubieの雰囲気みたいなものもお伝えできたら嬉しい。

《こんな人に読んでほしい》
・POという役割に興味がある人
・スタートアップに興味がある人


スタートアップのPOとして最重要だった3つのこと

はじめに、弊社ではプロダクト開発手法としてスクラムを導入している。
(スクラム開発導入背景については、スクラムマスター @shikichee登壇資料をぜひ。)

スクラム開発POのミッションは、
「取り組むべき課題を明確に」し、「開発チームが作るものの優先順位を決めること」で、開発チームROI(Return On Investment)を最大化すること

世の中には、PMと呼ばれる人が、Why・What・Howまで決め、仕様書を書くようなスタイルも散見されるが、スクラムでは明確に、

Why・What(優先順位のみ) =     PO
What・How = 開発チーム(エンジニア、デザイナー等)

が理想的な役割分担と定義されている。
実際は、開発チームの成熟具合によって、What・HowにPOがどのくらい関わるべきかが変わってくる。なぜなら、開発チームのROI最大化は変わらずPOの責務であるためだ。

弊社では、1年前にスクラム導入をしてから、どんどん開発チームが成熟し(元々メンバーのスキルやマインドが崇高でした)、POと開発チームの役割分担がこの理想の形となっている。その前提で、POとして最重要だったことを書くとすれば以下の3点になる。

1.   2秒でぶれない意思決定をしていく力 
2.   顧客・全社戦略の圧倒的理解力
3.   不確実性を受け入れ、物事を検証したいことが出来る最小単位で切り取る力


1.  2秒でぶれない意思決定をしていく力

「2秒」

今この場で意思決定出来ないと、Returnが下がることやInvestが上がることが多くある。ましてや、開発チームの生産性を下げないためにも、意思決定の速さは重要になることが多い。

2秒という数字は、自分が今この場で意思決定出来ているかを振り返る指標として優秀だった。新幹線の中でSlackで相談を受けるがその場で返信出来ない。そんな時は、「どんな情報があれば(知っていれば)すぐに意思決定が出来たのか」を考え、次はその場で返信出来るよう、情報キャッチアップをする。その繰り返しだった。

「ぶれない意思決定」

意思決定がすぐにぶれていると、開発チームからの信頼度が下がり、チーム生産性を大きく下げてしまうことになる。ぶれない意思決定に加えて、意思決定の理由も明確に説明できていると、開発チーム自体が同じような意思決定が出来るようになっていくので、チームとしても成熟出来る。

ぶれない意思決定は、正確な現状の理解、と、理想の定義、を常に自分の中で持っておくことで実現出来ると思っている。

まず、正確な現状理解のためには、目で見た現象や聞いた話について、「なぜ×5」で、合理的な説明がつくまで深ぼることが重要だった。また、その過程で、顧客セグメントを分け、各セグメント毎にいくつかのペルソナを持っていたが、組織が大きくなってきて顧客の声を直接ではなく、二次情報として聞くことが増えた際に、「顧客の真の主張」のあたりを付けるのに有効だった。

次に、理想の定義をする上では、会社として将来やりたいロードマップ(ざっくり)と、顧客の理想ロードマップ(ざっくり)を描き、それをどう組み合わせるかを考えておくことが重要だった。
弊社の場合は、共同代表の2人がプロダクトアウトの考え方が得意で、会社として将来やりたいロードマップはどんどん出てくる。なので、POとして注力すべきは、顧客視点の理想を固めて、彼らの考えと組み合わせ、どうステップを踏むか考えることだった。
顧客の理想を描くために、よく商談の数時間前に病院(我々のメイン顧客)へ入り、待ち合いスペースで全体の流れを観察しながら、ぼんやりと考える時間を取っていた。日々の仕事は短期視点のものや顧客以外の視点で考えるべきことも多かったので、物理的な顧客空間で中期視点のことを考える時間を持つのは有効だった。


2.  顧客・全社戦略の圧倒的理解力

「顧客の圧倒的理解力」

これは言わずもがな、と思う。とはいえ、特にToBプロダクトにおいては、顧客を代表するだけではなく、顧客全体を客観的に把握することも重要だった。初期ターゲットとする病院を決めたり登り方を考える時や、オペレーションの違いをある程度考慮して開発をするかどうかの決断をする時などに役に立った。

本当に初期は、営業・カスタマーサクセスとして顧客の声を代表しつつ、客観的にその声を鑑み、時には残酷な判断をすることを1人2役で行っていた。ユーザーに会った直後に「顧客の声代表」としてのメモをチームに送りつつ(この時は顧客に寄り添っているので心苦しいし怒りさえ感じる)、帰りの電車で「今は対応しない」という判断をする(この時は真顔)ことも多々あった。

顧客理解は以下の手順で行っていた。
①業務や行動を細かく把握
②業務や行動をしている背景仮説を作る
③具体的な質問で確認

「①業務や行動を細かく理解」するフェイズでは、自分の思い込みを捨て、完全に行動をトレースすることが大事だった。AI問診Ubie利用開始してもらう際に、利用開始フォローの体で病院の受付内にお邪魔し、「お忙しいと思うのでこの業務やっておきますよ〜」という手法で、帰る際にはかなり多くの受付業務を習得することが出来た。

「②業務や行動をしている背景仮説を作る」フェイズにおいて、一番難しいのは、自分がトレース出来ない行動をしてるユーザーのことを考える時だった。AI問診Ubieは、ユーザーが、医師・看護師・事務と多岐に渡るのだが、この中では、医師・看護師がそれに当たる。そんな時は、自分の類似経験を踏まえながら、人間だったらどう思うかを考えていた。

医師行動:(教科書的には、診察時にはカルテに疑い病名を記載するように指導されるが)検査前のカルテに疑い病名をカルテ記載しない医師が多い
推察①:人間だったら、決定的事実が分かる情報収集前に、曖昧な状態で何かを結論付けることに抵抗あるのでは。そして、複数ある可能性を全て記載するのも面倒くさいと思うのでは
推察②:医師は、検査結果という特徴量が多いものの結果を見る前に、曖昧な状態で疑い病名を書こうと思わないのではないか

こんな調子だ。

「③具体的な質問で仮説確認」のフェイズでは、ユーザーは無意識でその行動をしてることが多いので、具体的に聞くということが重要だった。
直接医師行動を問うても、泥沼になることが多い。

PO「なぜ、初診カルテ(検査前)に疑い病名を記載しないんですか?」
医師「必要がないから」
PO「なぜ必要がないのですか?」
医師「・・・・(しつこいな)」

推察を持って、より具体的に聞くと、無意識下にある本当の理由をヒアリング出来ることがある。

PO「検査前の問診情報のみから疑い病名をどのくらい絞りますか?」
医師「5〜10つくらいかな」
PO「先生、検査前のカルテに疑い病名を記載しないのは、10個も記載するの大変だからですか?」
医師「そうだね、あとは、検査どうせするのに、今確実性が低い情報を残しておくメリットがないからねえ」

「全社戦略の圧倒的理解力」

こちらも言わずもがな、と思う。とはいえ、より重要なことは、

・全社戦略が変わりそうということにいち早く気づくこと
・プロダクト視点、時にはその他の視点から、全社戦略を変えに行けること

アジャイル開発をしているものの、プロダクト開発には若干のリードタイムが付きものなので、「いち早く気づく」ということが大事であると同時に、常に全社戦略も考え自ら変えにいけるのが一番良い。

これまでのUbieの場合、病院(医療機関)向けビジネスがメインだったこともあり、ここの状況が全社戦略に及ぼす影響が大きかった。病院向けビジネスの営業〜カスタマーサクセスまで足を突っ込みながらプロダクト開発をしていたため、このキャッチアップや連携には苦労しなかったものの、今後ビジネスの種類が多くなっていく中でどうキャッチアップ・連携していくかは次のチャレンジになりそうだ。


3.  不確実性を受け入れ、検証したいことが検証出来る最小単位で切り取る力

「不確実性を受け入れる」

このニーズは流石にあるでしょう、絶対こう使うでしょう。そう思ったら危険信号だ。「開発前のインタビューではニーズ確認出来てたものの、実際作ってみたら使ってもらえず、そこまでのニーズがなかったことが分かった。」「ご高齢の方に使ってもらったら、思わぬ使い方をしてた」等、幾度となく涙を飲んできた。まずは、自分の考えを思い込みではないかと疑うこと、そして自信があるものでも、その検証が出来る単位で切り取れるなら、最小単位で切り取る努力をすることが大事だった。

「検証したいことが検証出来る最小単位で切り取る」

検証出来る最小単位でのプロダクトリリースを考える時、どこかに歪みが生まれる。その歪みは、「技術的負債」「営業的負債」「現場事務オペレーション的負荷」など、色々ある。それでも、将来的負債の返済と検証から得られるリターンを考えた時に、検証から得られるリターンが大きいと考えられた場合は、勇気を持って負債を積むことやスケールしないことをやるを選択する必要があった。


さて、これらをどう身につけたか

勿論、これら全てが始めから出来たわけではなかった。3つの中でも特に、3つ目のアジャイル的考え方については、全くの無知だった。

それもそのはず、新卒でお世話になった前職では、複数の社外ステークホルダーと動くことが多く、それゆえ、仕事において「ゴールからの逆算」で進めていくことが理想的とされていた。この仕事の進め方で成功体験を積み重ねてきた私は、Ubieに入った当初、ロードマップが大好きだった。故に、ネクストアクションを考えるために中長期の議論をもっとしたいと思ったし(不確実性が高いこと今議論しても仕方無くない?と一蹴されたが)、大好きだったロードマップ的資料も当初は割と作ってた(状況が日々変わりすぎてメンテできなくなりすぐ形骸化した)。

そんな私でも着実に身につけていけたのは、振り返ると、実践出来る環境や自分自身の心得があったからだと思う。

1.   実践出来る環境
2.   Unlearningの心得

1.   実践出来る環境

意思決定をする機会が無ければ、意思決定力は磨かれない。顧客と向き合う機会が無ければ、顧客理解力は深まらない。同様に、アジャイル的考え方についても、実践する機会がなければ、身につかないと思う。自分がアジャイル的考え方をしようと思っても、周囲が同様の考え方をしていないとハードルは高い。弊社の場合は、当時から(今でも)アジャイル的考え方をすべきシーンが数多くあった上に、初期メンバー全員がその考え方を心得ていた。

入社してまだまもない頃、利用しはじめてくださった診療所の端で開発やデータ修正をしているのを見た時は、かなり衝撃だった。まさに、問診精度が良かった場合に利用してもらえるのかを検証するために、アルゴリズムの補足を人間(弊社医師)がその場で行いながら利用してもらっていた。「スケールしないことをしよう」が、当時の合言葉だった。

2.   Unlearningの心得

「アジャイル的考え方を身につけた。」と言っても、もともと持っていた仕事の一つの型(ゴールからの逆算)を捨てたり否定したわけではない。それよりも、「この場合はこの考え方を使う方が有効だ」という型をいくつも手に入れることが出来た、これまで1つの種類しかなかった考え方を昇華させられた感覚の方が近い。
これまで信じて来たことが使えない、そんな風に思うと人間は悲しくなったりパニックになったりするのかもしれない。私はこの、「これまでを否定せず、昇華させていく考え方」で、いくつもの異文化を柔軟に吸収していくことが出来たように思う。また、弊社の同僚も皆、目まぐるしい勢いで、時には本から、時には周囲から吸収し、自分の考えを昇華させていく。そんな同僚の影響も相まって、日々考え方を進化させようとする姿勢が強くなった上に、そうして新しい世界が見えるのが人生の醍醐味とも思うようになった。


まとめ

これまでの経験から、スタートアップのPOに最も必要だと思うことを3つ挙げるとしたら、以下だった。

1.   2秒でぶれない意思決定をしていく力 
2.   顧客・全社戦略の圧倒的理解力
3.   不確実性を受け入れ、物事を検証したいことが出来る最小単位で切り取る力

当初無知だったことや出来なかったことは、実践や周囲から刺激を受けることで身につけてきた。


最後に

スタートアップのPOに最も重要だと思うことを主なテーマとして書いたものの、合間のエピソードで弊社ならではの雰囲気等、伝えられていたら嬉しく思います。今回紹介した3つの力は、PO以外の役割でも実践&身に付けられるものです。そして、我々Ubieにはその環境があります。

少しでも興味を持って頂けた方は、ぜひご連絡ください!

@NishimuuuuR

画像1

Ubie株式会社HP

終わり。

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