2016プロダクトマネージャーのキャリアはいかにして始まるかこの記事は、僕自身のプロダクトマネージャーとしてのキャリアがどうやって始まったのかを綴ったエッセイだ。経験を出汁にして創造をすることは、「創造行為の終着駅」と藤子・F・不二雄先生も語っていらっしゃるようだが、まさにその通りだと思う。人はゼロからストーリーを作ろうとする時に「思い出の冷蔵庫」を開けてしまう。自分が人生で経験して、「冷蔵保存」しているものを漫画として消化しようとするのです。それを由(よし)とする人もいますが、私はそれを創造行為の終着駅だと考えています。家の冷蔵庫を開けてご覧なさい。近所のスーパーで買ってきた肉、野菜、チーズ、牛乳・・・どの家の冷蔵庫も然して変わりません。本文は「終着駅的」であることに加え、9,000字以上に渡るダラダラと長い文章で、残念なほどにまとまりもない。殆どがsmarbyという、僕が創業から2.5年を共にしたスタートアップでの経験に関する記述になっている。興味のない方はここでブラウザを閉じることをオススメする。文末にこの記事から1.5年が経過した時点(2018年6月)の振り返りと心境の変化をまとめている。INTERNATIONALグループの末席に加えていただくことになった。時を同じくして僕はsmarbyを辞めた。今はフリマアプリを提供するメルカリでプロダクトを創っている。※さらに2018年6月現在、9ヶ月在職したメルカルを辞め、今は10Xという会社を創業してタベリーというプロダクトを創っています。発明を目指す会社です。2016年の初めから本腰を入れ始めたブログ執筆は、ありがたいことに多い時には万を超えるような人に見てもらうこともある。僕自身の身上話より、「プロダクトマネージャー」「スタートアップ関係者」にとって意味のある文章になればと思い書いてきた。僕(ら)の身の上話など、誰の役にもたたないだろうと思っていたからだ。今回だけは少しだけお付き合い頂きたい。プロダクトマネジメントは「死にたい」smarbyはママというユーザーに特化した子供服ECサイト&アプリとして2014年の11月末にスタートした。商品の掲載時間が1weekと短いことを除いては普通のECと変わらない。シンプルな機能にもかかわらず、以下のような理由からリリースまで超難産だった。着手からリリースまでに半年以上の時間を経て生み出されたプロダクトは、初日に想定の1/50程度の売上(数万円)をこしらえ、創業メンバー全員に死にたい気持ちをプレゼントしてくれた。リリース前、僕は悪手・奇手を絡めて3000人の事前ユーザーを獲得することに忙しくほとんどプロダクト開発に関わっていなかった。初日の売上とユーザーの動きを見て、このままでは死ぬということだけ理解した。創業時のメンバーの経歴だけ見るときれいだったが、僕を筆頭に誰ひとりとしてプロダクトがつくれる人材ではなかったことをここに保証したい。読んでおわかりの通り、この時のsmarbyにプロダクトマネジメントなんて存在しない。「死にたい」と思えるほどの現実と対面した時の、暗雲とした重い空気が、プロダクトマネジメント(プロダクトを前にすすめる力)だった。初日にしょっぱい売上を目の当たりした後、一切の余裕を無くした僕は各方面からどんな手を打つべきかとにかく探った。はじめにしたのはFacebook広告に金を突っ込んでユーザーを買ってくることだった。事業計画時には「CPOが...」「LTVが...」と綺麗事を並べたが、それらはすべてクソだと悟った。人が来なければ終わる。思って僕はFacebookに資金を投下した。結論、広告もクソだった。いうか運用者の僕がクソだった。焦燥からKPIを定点観測するという概念が吹き飛んでいたため、初日に平常値だったCPAが3日後に10倍になっていたことに気づけなかった。命の灯でもある資金で、よそ見しながらキャンプファイヤーをしていたこの時の自分にドロップキックしてやりたい。数百万円を溶かしたところで過ちを知った。その日を境に1分毎にダッシュボードを更新してCPAをモニタリングしながら命の灯(資金)を燃やす日が数週間続いたが、見るに見かねたエンジニアがスクリプトを書いてくれたため、Slackから自動でCPAを把握できるようになった。他にもECの要である商材(MD)から打てる手を探った。立ち上がったばかりの売上数万のプロダクトに商材を掲載したいと思う取引先はなかなか無く、毎日数百のメールを爆撃し、アポをこぎつけては怪しい人間力で商材を引っ張ることで凌ぐ日々だった。経歴のおかげで幾つかのお取引先が広がったこともある。いうパートナーに対して「思ったより売れなかった、smarbyには裏切られた」と思われるのが何より怖かった。今でこそ話せるが、なけなしの給料で、みんなで自社商品買いに勤しんだこともある。MDのなかで一つの成功体験がある。リリースしてから間もなく迎える年末年始のピークに合わせ、売れ残ったバラバラの商品をコーディネートセット(福袋)に組みなおして販売した。これがヒットし、売り切れが相次いだのである。商材の価値を高める(揃う、安い、わかりやすい)しっかり情報発信する(自社メディアでママライターに扮装し記事で訴求した)Facebook広告で2を拡散(関心層拡大)この3つの力で、smarbyは初めて見るに耐える月次売上を記録した(ただし、まだまだ微小)。ECのプロダクトは「狭義でのプロダクト(Webサイト&アプリ)」「MD」「マーケティング」の三位一体なのだ!と理解して鼻を長くしたものだった。リリースから3ヶ月、smarbyはやっと「自分たちの売り方」を学習しつつあった。この3ヶ月間、プロダクトのソースコードにはほぼ一切の変更を加えていない。かのエンジニアは僕らがMD情報をデータベースへ手入力しなくて済むよう、自動入力用のスクリプトを書いたり、ECで扱う大量の画像を軽量化するスクリプトを書いたり、サーバー監視で一杯一杯だった。それでも事業は前に進めることができる。プロダクトをマネジメントする方法は、ソースコードを修正することが唯一の手段ではないのである。社長は僕が金を溶かしてばかりいるので、追加の資金を集める必要があった。エンジニアは1ヶ月に1度しか家に帰らない生活をしていた。共同創業者はみんなのストレスを中和するマスコットだった。僕は2時に寝て、息子の夜泣きで3時に起きる生活だった。どれだけ夜が遅くなろうとも、僕は毎日きっかり10時に三軒茶屋にあったワンルームのオフィスに行くとエンジニアを起こして、一緒にファミマのコーヒーを買いに行く生活だった。リリース直後、台風のように過ぎた時期のプロダクトマネジメントの味は「苦かった」。「自分たちの売り方」を学習し、エンジニアとタッグを組んでオペレーションを効率化できるようになってきたことで、smarbyは初めて「未来に向けた次の一手」を考える体力を手にした。機能に修正を加えたり、機能追加をしたり、新しいプロダクトを検討したり、など。プロダクトっぽい話であるが、この時点で創業1年とか、そんな時期の話だ。1年もの間、俗に言うきれいなプロダクトマネジメントなんてなかった。アジャイルの「ア」の字も出てこなかった。運用が小慣れて売上も立ち始めた頃、更に売上を伸ばすために例えば以下のような「機能開発」を検討していた。新たな決済方法の導入PCサイトのリリース(smarbyはモバイル専用で、現在進行系)Androidアプリ(当初はiOSのみだった。振り返ると、これが僕のプロダクトマネージャーとして初めての仕事だったとも言える。荒削りではあるが、こうやって少しずつプロダクト自体に変化をもたらした。その過程は、思ったようなスピードが出ず、焦れて、意見がぶつかることは日常だった。smarbyのバックエンドはリリース時から幾つかの穴があったため、「買えない」「落ちる」「重い」などユーザーからのお問合わせとHotfix(緊急なイシュー)が日々飛び込んでくるような状況だった。Hotfixが生じたタイミングで、エンジニアの優先度はHotfixが1番となる。ところが、Hotfixを解く傍らで機能開発が進まない理由が、当時の僕には本当にわからなかった。すべての開発タスクは直列でないといけない、という当たり前の事実を、エンジニアを除いて誰一人理解していなかったのである。エンジニアという「クリエイター」の気持ちを理解できない未熟なプロダクトマネージャーだった僕は、上記のようなコメントを毎日のようにしていた気がする。幸いにも、この頃僕とエンジニアの彼は朝昼晩と全ての食事をほとんど一緒に過ごした。酒が飲めず、人となかなかパーソナルな関係を築くことが難しい僕にとって、この機会はとても貴重だった。仕事で産まれた「棘」は朝飯のパンをかじっている時にほぐれていた。本質的に「開発がわからない」という問題を解決したのは新たにジョインした別のエンジニアだった。基礎的な情報(や、情報源)を提供してくれた。これをきっかけに積極的に技術書を読み、terminalやgitを使い始め、エンジニアの言語を理解しようとした。彼から勧められてはじめて読んだ本は「UNIXという考え方」だった。クリエイターの気持ちを少しずつ理解できる様になると、プログラミングを通じて「ものづくり」をするプロセス自体が尊く楽しいものだと思えるようになった。プロセスにおける僕自身の行動指針を醸成していった。「創らずに解決」が最上の手段。そのプログラムを書く必要があるのか。あなたがそのプログラムを書くことにかける時間はどのようなリターンをもたらすのか。ソースコードへのコミットは自分にはできない。エンジニアがプログラムに集中できるようなパスを送るかに集中する。コントロールをエンジニアに渡したら、任せきる。Hotfixが飛び込んできたり、ユーザーの状況によって必要な機能の優先度はコロコロと変わる。テンポよく、そして誤解を招かぬよう、「Backlog(タスク)」の優先度を決めていく。エンジニアの手が止まる時間を最小化するよう、即レス・クリアな仕様・誤解のない言葉遣い。いった行動指針の多くは、例えば「リーン・スタートアップ」や「アジャイルサムライ」などのプロダクト開発のTipsを記す多くの書籍で当たり前のように書かれている。僕はそれらの本を通じてこういった指針を理解したわけではなかった。エンジニアと実際にプロダクトを創り、理想と現実・運用と開発の間で揺れ、精神を焦らし、時に喧嘩をしながら、一つずつ学んだものだ。Slack(チャットツール)で開発仕様についての情報を伝える際、口頭で話すような簡易・省略形の言葉で書くことを僕はしない。多少書き手の手間が嵩んだとしても、正確な言葉を使う。わずかなミスリードで大きな事故を招いた経験があるからだ。「もうすこしだけ丁寧に書けば避けられた事故」を繰り返さずに済んでいるのは、いろんな地雷を踏んだおかげかもしれない。プロダクトマネジメント)はチームの状況によって最適解が目まぐるしく変わる。それはサッカーやラグビーのようなものだ。新しいエンジニアが加わったり、業務委託やフルリモートのメンバーが加わったり、チームの布陣と個々のプロパティによって大きな影響を受ける。smarbyは、焦燥を抱えながらもきちんとマイルストーンに合わせて成長を続けていた。4人でスタートした会社は1.5年で30人を超え、取引先やユーザー、そして株主などステークホルダーは増加の一途を辿った。プロダクトに対して良く言えば「自由な」、悪く言えば「勝手な」意見が大量に集まるようになる。次の僕の大きな役割は、それらの殆どに「NO」を言うことであった。誰かの意見に対し「NO」を言うことはそれほど難しいことではない。「NO」を言い続けることはなかなかタフなゲームだということは余り知られていないように思う。〜は簡単に実装できるでしょ?競合にはあの機能がついているユーザーのAさん、投資家のBさんがあの機能は付けないの、と言っている。これらの僕に投げかけられるコメントは一見妥当であるように見えて、実は違う。プロダクト、そしてプロダクトを創るチームにとって考えるべきは「今、われわれのユーザーにとって本当に必要がどうか」という一点のみだった。特定の誰かが満足する機能が大事ではない、とは言わない。来月もユーザーの満足するような体験を届け、売上を2倍に、一年後に10倍にすることがECである僕らにとって最重要命題であり続けた。売上に責任を持つ身として、全ての意見に耳を傾けたり、懇切丁寧な説明を加えることは難しかった。「NO」を言い続けるために役に立ったことが3つある。1つは運動でストレスを消し去ること。1つは以下のIntercomという顧客マネジメントツールを提供するスタートアップのブログ記事。この記事を読むたびに、奮い立った。https://www.intercom.com/blog/product-strategy-means-saying-no/最後の1つは、今のプロダクトがどんな状況で、いつまでに何を成し遂げなくてはいけないのか。僕の目線から思ったことを社内のドキュメンツールに投稿することだった。時にはこのブログにもすこしマイルドな形で投稿した。大した推敲もせずに書きなぐる程度だったかもしれないが、意思決定のプロセスを最低限共有することで、「なぜYamottyはNOを言うのか」を理解してもらう助けになったように思う。テキストの力は偉大だ。プロダクトマネジメントは「楽しい」プロダクトや会社に対して行う意思決定が正しいかどうかは誰にもわからない。積み重ねによってプロダクトが理想とする状態へ近づけることができたか?で大まかに測ることができる。いった個々の施策評価に傾倒するのを僕は危険だと思っている。本当の役割は、そもそも理想ってなんだっけ?というプロダクトのビジョンを描ききる力にあると思っている。この3つの要素に答えるビジョンを描くこと。そこに人を巻き込むこと。NO」をし続けるより、ずっと胃が痛くなるハードワークだ。これほど楽しい機会も無い。プロダクトマネージャーは楽しい。プロダクトマネジメントは「千差万別」これまでの僕の話は「スタートアップのプロダクトマネジメント」についてだ。このケースはある程度規模のある企業のそれとは質的に異なるかもしれない。スタートアップにおいてプロダクトマネジメントは会社の死活をそのまま握ることになるからだ。「起業家」ではなく、「プロダクトマネージャー」という存在のキャリアを突き詰めると、「自分の意志の通ったプロダクトを創る」ことの難しさがある。企業務めのプロダクトマネージャーにとって、自分以外の誰かのアイデアでプロダクトがキックオフすることは稀ではないだろう。他人のアイデアをどれだけ自分のコンテクストで消化し、自分の意志を通わせたプロダクトを創っていけるか。それもスタートアップを始めるのと同じくらい大きなチャレンジだと思う。プロダクトマネジメントは、それ自体が目的化してはいけない手段である。プロダクトを通じてどんな世界を創りたいのか。その目的のためにとれる手段は、仕事やプライベートの環境・スキル・コンディションによってまちまちなはずだ。僕は自分以外のプロダクトマネージャーの話を聴くのは好きだ。参考にすることは殆ど無い。自分に当てはまることなど殆どないから。道の進み方は自分で考えて決めたい。手探りでやってきた僕のような人間にもこんな質問が寄せられるようになった。この記事はその問へのアンサーでもある。一言で言えば、「必要に迫られたことをやってきただけ。赤の他人に「Facebook広告で莫大な予算を溶かす」などのクソ経験を再現させたところで、良いプロダクトマネージャーを育てられる気がしない。逆説的だが、プロダクトマネージャーとは再現性のある仕組みで育てられるものではないのかもしれない。エンジニアをしていたら、周囲から頼られるハブとなりプロダクトマネージャーになる人もいるかもしれないし、カスタマーサポートとしてユーザーに尽くしていたら、ユーザーへのもっとも深い理解と愛情が育まれ、プロダクトマネージャーへ転身する人もいるかもしれない。いう人たちに、「大丈夫、僕も適当に歩んでこうなりました」と背中を押せる記事になれば、一筆の価値があったものだと思う。この記事を1.5年後に振り返る(2018年6月)あらためて振り返ってみると、プロダクトマネージャーへのキャリアパスに一切の普遍性がないこと。僕が多くの失敗を犯して来たことが蘇ってきてなんとも言えない気持ちになる。実はsmarbyを始める前、僕がプロダクトマネージャーを目指すきっかけを与えてくれた人物がいた。GEOチームのプロダクトマネージャーをしていた。彼との出会いはsmarbyを始める前に務めていた東北復興支援のNPO。仙台出身だった河合さんが、我々のファンドレイズに乗っかてくれ、大きなお金を任せてくれて、仕事を一緒にさせていただいた。当時限界区域であった福島の浪江町にストリートビューを走らせたり、東北の事業者とトウキョウのプロをマッチングするクラウドソーシングを立ち上げたりと、ずいぶんと自由にやらせていただいた。(以下のツイートは久し振りに河合さんとお会いしたときのもの)千万単位のMAUを世界で保有し、日米で成功した数少ないプロダクトの現役PMで、金言をもらった。・娯楽は国境を超えない。・鬼スケールでプロダクトマネジメントもクソもなかった。・スケールは全てを癒すタベリーも構想もいいねをもらった。「ユーザーのペインにあらゆる手段をつかって向き合い続けること」「同じ場所にとどまることをNGとし、10xをめざすこと」など僕の行動の指針は彼から学んだはずだったが、実はsmarbyをはじめる際にこういった指針を徹底できていたかというと、NOだった。smarbyでの失敗や成功体験を経て、やっといま手に馴染むようになったと感じている。プロダクトマネジメントの知識も近年ではかなりが体系化されつつある。それを本当に使いこなせる人材はごく僅かだ。リスクをとり、ポジションをとり、実際にプロダクトをハンドメイドする経験の中でしか培われないものがやはり存在する。smarbyのあと「本当の発明がどうやって生み出すべきか」について自分なりの答えを見つけたかった。そのためにうってつけの環境として選んだのがメルカリだった。素晴らしい成長率と、安定した職場環境、待遇が揃っている。「本当の発明」を自分で目指したいと思った時、僕にとっては10Xを創業することのほうがずっと近道だと思えた。つまるところ、発明は「チャレンジした人だけ」の特権だと気づいた。プロダクトにチャレンジしない限り、プロダクトマネジメントの知識が手になじまないのと同じように。僕の今の目標は、死ぬまで「人が欲しがるものをつくる」にアタックし続けることだ。そのスタートがsmarbyであったことは疑いようもない。本稿が参考になった方はコメント&Kyash投げ銭をお待ちしております。記事へのフィードバックとして糧にします。Kyashは常用していて応援しているプロダクトです。Offiline)は起こったかプロフィール矢本真丈(Yamotty)。2017年7月に株式会社10X(テンエックス)を創業。「献立と買い物の悩み」が過去50年解決されていないことに気づき、モバイルアプリ「タベリー」を開発・運営。日本における小売体験の10xを目指す。本サイトでは生活や経営の試行錯誤から得た気付きについて、言語化を試みている。(詳細)株式会社10Xについて紹介資料になります。採用ページも御覧ください。