ブログを書く理由
今年からブログを書き始めました。これまで人生で一度もブログを書いたことは無かったですし、書く必要性を感じたこともありませんでした。(エンジニアだったのでQiitaは書いてきたけれど)
そんな自分がブログを始めてみた理由を整理してみようと思います。
理由1. Scrapboxにまとめた情報を再構築し出力する場として
前々からScrapboxで本で学んだことや業務で経験したこと・学び、記事のメモを管理していました。
知的生産する上で欠かせないツールで、Scrapboxのお陰で得られた発想や知見は数多いです。
上記のように、Scrapboxに情報を書き出し、練り上げていく中で「こういった情報は一枚の記事に再構築した方が良いな」と思う場面がちらほら出てきました。複数のメモを横断している概念であったり、現時点の考え方をスナップショットとして残しておきたい場面です。(Scrapboxのメモは古いメモであっても定期的に更新が行われ、当時の認識が失われる場面が自分の場合多々あります。)
何かと何かの情報を結びつけたり、情報を深掘りするような知的生産にはScrapboxは抜群の効果を発揮しますが、その知的生産による精製物を管理するには向いてないと思いました。公開設定をPublicにして全ての情報を見せることもできますが、人に見せたく無い情報が混じっているのでそれはしたくありません。またそういった情報が入っていないか気にしながら書くのも体験を阻害するのでしませんでした。
そこで色々方法を検討した結果、無難にブログがいいのでは？という結論に達した形です。Scrapboxは知的生産の場、インプットとアウトプットの中間体を管理する場所として、ブログはScrapboxの情報を再構築したアウトプットを管理する場所として使うことにしました。
理由2. 第三者が見る記事を書くことで、ちゃんと書こうという圧が働く
誰かが見るかもしれないので適当な事は書けないという圧が働き、ふんわりとしか理解できていなかった箇所を自分の言葉で説明できるまで落とし込むきっかけが得られるのもブログを書く理由の一つです。
Scrapboxもリンク生成や深掘りの中でそういった箇所の炙り出しに効果を発揮しますが、第三者が見るかもしれないという意識が働くと更に効果的だと思っています。
この辺りはエンジニアの時Qiitaを書いていた感覚と同じです。当時もぼんやりとしか理解できてない箇所が鮮明になり土台的な技術力がかなり向上した実感がありました。
そういった理由でブログを始めました。Scrapboxで知識を練り上げ、ブログに再構築してという流れを続けていければと思います。
エンジニアからプロダクトマネージャーにキャリアチェンジする方法
最近エンジニアのキャリアの選択肢としてプロダクトマネージャーが注目されていると思います。
私自身エンジニア出身のプロダクトマネージャーということもあり、ちらほらご相談を受ける場面もあります。
そういったご相談に答えたり、他サービスのプロダクトマネージャーをされている方とお話しをする中でエンジニアからプロダクトマネージャーにキャリアチェンジする方法がある程度まとまってきたので記事に書き出してみようと思います。
結論
色々方法はあると思いますが、基本的には「社内でのプロダクトマネジメント業務経験、もしくは近しい業務経験を行い、経験値を貯めてから転職をする」が一番確度が高いと思います。
なぜ上記の結論か
上記の方法以外にもエンジニアからプロダクトマネージャーを目指す方法はいくつかあります。自分の思いつく範囲だと以下が挙げられます。
- プロダクトマネジメント未経験の状態での転職
- プロダクトマネジメント経験を副業、個人開発で積み転職する
- プロジェクトマネージャー経験を社内で積み、プロダクトマネージャーとして転職する
ただ、1番だと取ってもらえる可能性が限りなく低いですし、2番もあまり評価されない印象です。3番は本質的に全く異なるポジションですが割と聞く転職パターンではあります。ただ現在エンジニアなら、プロジェクトマネージャーになって数年経験を積んで、、と考えると長期計画になってしまうのでこちらも難しそうです。そのため消去法で「結論」に書いた方法が一番確度が高いなと思います。
具体的な方法
「結論」に「社内でのプロダクトマネジメント業務経験、もしくは近しい業務経験を行い、経験値を貯めてから転職をする」方法が良いと書きましたが具体的にどういった業務経験を積んでおくと良いかをまとめます。
1. プロダクト課題の洗い出しの経験
プロダクトを長く使ってもらうには「ユーザー体験の向上」「利益の向上」を継続して実現していくことが不可欠です。それらを実現するために現状のプロダクトに足りないことは何なのか、どういったところに課題があるのかを明らかにする経験です。
SaaSの例を挙げると
- 申し込み相談のCVRが下がっている
- 申し込み相談から申し込みへのCVRが下がっている
- 契約3ヶ月以内のチャーンレートが上がっている
- 1ヶ月を過ぎると徐々にログイン率が下げる
- LPへの流入が下がっている
- 特定のページでエラーが発生して操作ができなくなる
などです。
2. 課題の優先度の設定の経験
洗い出した課題をどのような優先度で解決していくかを設定します。優先度の判断基準は基本的には「ユーザー体験の向上」「利益の向上」に対してよりインパクトを与えられるものから優先して対応します。
1番に記載した例を考えてみると
- そもそも、申し込み相談のCVRが下がっているのはLPへの流入が下がっているのが原因かもしれない
- 特定のページでエラーが発生して操作ができなくなる問題は既存ユーザーのチャーンに影響するため、最も優先度を上げて対応する。ログイン率が下がったり、チャーンレートが上がっているのはここに起因するかも
など、課題の構造を考えながら優先度を振ります。
3. 課題の深掘り、課題を構成する要素の洗い出しの経験
解く課題の優先度付けを設定できたら、最初に解く課題の深掘りを行います。課題は表面に出てきている問題で、原因はもっと深くに存在します。
- 例: 「LPへの流入が下がっている」に対しての深掘り
- 流入チャネル周りに問題が起きている
- 技術的な問題が起きている
- LPの表示スピードが遅くなり、ユーザーの離脱率が下がった
- ビジネス的な問題が起きている
- 他社サービスにユーザーが流れている
このように課題が発生している原因を特定できるまで深掘りを行います。(本当は、具体的に改善すべき場所が特定できるまで深掘るべきです。この辺りのポイントは馬田 隆明さんの著書「解像度を上げる」に詳しく載っています。)
また、定量・定性データを交えながら、この要素は本当に存在しているのかも確認しておきます。
4. 課題を構成する要素を解く優先度の設定の経験
3番で深掘った要素をどのような順番で解いていくかを設定します。ここも課題解決においてのインパクトがある順で解いていくのが基本パターンです。
5. 課題を構成する要素を解決するための施策立案の経験
優先度の順位付けができたら、最も優先度の高い要素を解決するための施策を考えていきます。 施策案を練り、PRDに書き起こします。自分のチームではPRDは以下のような項目を書いています。
- 施策番号、タイトル
- 施策概要
- やる意図、期待する結果
- 具体的なタスク
- 計測対象のKPI
- 計測方法
- フィードバック
施策の指示書だけでなく、タスク管理、フィードバック管理も兼ねている作りです。こちらは会社によって異なると思いますが、自分たちはこのようにやってます。こうしろというわけではなく、各社にあった型をやりながら見つけていくのが良いと思います。 このフェーズでワイヤーフレームなども書きます。
6. 開発をリードする経験
エンジニア・デザイナーとコミュニケーションを取り開発を開始します。自分のチームだと、プロダクトマネージャーがワイヤーフレーム・PRDをデザイナーに共有し、デザインを作りつつ、エンジニア側でワイヤーを元に仮デザインを設定して実装、デザイン出来上がり次第反映のような手順を取っています。また広告・PRなどの部署とも必要に応じコミュニケーションを取ります。
7. 施策実行・フィードバックの経験
機能をリリースし、効果を計測します。課題が解消しきれていなければ別の要素へのアプローチを試みたり、要素の構成自体を見直します。課題が解消できたら次の課題の対応に移動します。
以上が基本的な業務経験になります。「自身で課題を特定して要素分解し、施策を立案・実行し数字を改善した」経験がとても重要なので、エンジニア業務をしながらそういったところに関われないかチャレンジしてみてください。これらの経験を積み成果が出せたと考えたタイミングで転職活動を行ってみて問題ないと思います。 面接のポイントなどはまた別記事で書ければと思います。
Scrapboxで読書メモを取るメリット
普段からアイデアを練ったり、学んだことを書き出すなど知的生産を行う際はScrapboxを使っています。
そういった運用に加えて半年ほど前から読書メモもScrapboxで取るようになったのですが、何冊分か読書メモを取っていく中で、自分の知識の引き出しに大きい変化があったので記事にまとめてみます。
ノート、PCのメモ、スマホのメモ、A4用紙など色々読書メモを取るために試してみたが、全然合わず未だ模索中・・そんな方に見てほしいです。
Scrapboxとは
まず、Scrapboxというサービスがそもそも何なのかまとめます。
ScrapboxとはWebで動作するノートサービスです。個人利用の場合は無料で使用できます。
こういったノートサービスはScrapbox以外にも沢山あります。Notionは有名ですし、Microsoftが提供しているOneNoteも使ったことがある方は多いでしょう。そういったサービスとScrapboxには決定的な違いがあります。
他ノートサービスとScrapboxの違い
Scrapboxが他のサービスと異なるポイントは
- 何かを考える
- 情報を練り回す
- 情報同士を繋げる
のような知的生産を行うことに特化しているという点です。
まず書いたメモを管理する方法が他サービスと異なります。
Notionなどのサービスは「階層構造」でメモを管理します。パソコンのディレクトリ構造をイメージして頂けると分かりやすいかもしれません。
対してScrapboxには「階層構造」がありません。一つの階層に全てのメモが配置されています。パソコンのディレクトリなら「デスクトップ」にメモがずらっと配置されているような感じです。メモ同士は「リンク」を用いて接続できる仕組みになっています。(自分用Wikipediaのようなイメージです。Notionのような階層型のサービスに対してネットワーク型のサービスと言われます。)
このようなネットワーク構造を形成する仕組みが知的生産を行う上で非常に強みを発揮します。Wikipediaのようにメモ同士を繋ぐことができるので、関連する事柄を横断・繋ぎ合わせながら発想することができます。(Wikipediaで何かのページからリンクを辿っていくようなイメージです。このメモとこのメモに関連性があったとは！のような発見があります)
また脳にある情報をテキストに書き出すことに特化したUX設計も強みです。
こちらはぜひ使って感じて頂きたいのですが、ぐんぐん書き出せる感じがあります。(すごく曖昧な表現ですみません、、でも本当にそうなのです！)
近い思想を元に作られた他サービスも使ってみましたが、何か動作をする際ワンクッション思考が止まってしまう瞬間があります。(リストを作る、リンクを作る、改行するなど)そういった思考を止める瞬間がScrapboxは限りなく少ない印象にあります。なので「ぐんぐん」思考を書き出せるという感じです。
上記のような強みがあるサービスで、Notionで再利用されないメモがあるのはとても勿体無いな〜と思っていたところにScrapboxを使っている方の記事を見て、自分も使ってみようかなと思い立った形です。
(Notionを始めとした階層構造型のサービスを批判している訳ではありません。知的生産系以外の資料はNotionで管理しています。知的生産をより良く行う上でScrapboxが今のところ適していると考えているという感じです。)
やっていること
Scrapboxを用いた読書メモを取る取り組みは以下のような手順でやってます。
- 本自体のメモを作成
- 著者名、タイトルなどの基本情報の書き込み
- 各章へのリンク設置
gyazo.com
- 各章のメモを作成
上記のような流れです。至ってシンプルだと思います。
変化
1. 自分の中でちゃんと定義しきれていない事が明らかになった
Scrapboxを使うことで分かっているつもり、説明できるつもりになっていたけれど、意外と理解できていなかった、定義できていなかったことに気づきやすくなりました。
Scrapboxのリンクを作ると、まだメモを定義できていないリンクは赤色のテキストで表示されます。(メモ下の「New Links」にまとめて表示もされます。)
このように自分の中でちゃんと消化出来てない箇所が明らかになりやすい仕様になっているので、分かった気になりにくく、さらに知識を深めていけます。
2. 本の内容・実体験・記事の内容など本来繋がることが無かった情報同士を繋げることが出来るようになった
リンク機能により、本の内容・実体験・記事の内容など、本来交わらなかった情報が紐づくようになりました。
これまでは本を読んでいても、他の知識と連結せず時間が経つと忘れてしまったり、記事もブックマークはしたが、読むのを忘れていたりといったことが多々ありましたが、自身の実体験と紐づくことでより記憶に残る、もしくは話したいタイミングで頭に浮かぶようになったり、関連する項目に記事へのリンクが表示されることでよく閲覧するようになったりといった効果がありました。
(記憶に残る部分については、こういった研究結果があるといったエビデンスはなく、私自身の感覚です。そういった論文などあればぜひコメントで教えてください！)
3. 既存知識の更新・積み上げができるようになった
メモを書いていると関連でだいぶ前に書いたメモが出てくることがあります。そういった古いメモに触れるきっかけを得られることで、当時の知識の更新や追記、振り返りができるようになりました。
こういった過去の知識に触れたり、アップデートを行うのは階層型のサービスだと意識的に行わない限り難しいと思います。わざわざ更新・積み上げする必要は無いのでは？と思われるかもですが、個人的には言語化して書き出す事に価値があると思っています。
頭にフワッと持っているだけでは「分かってない」状態です。(「1」にも記載しましたが書き出すことで分かってないポイントが明らかになると思ってます。)一度書いて終わり！ではなく都度更新する機会をScrapboxが作ってくれるおかげで更新・積み上げを行う習慣がつきました。
4. どんな本なの？と聞かれた時、すらっと口頭で要約が出るようになった
自分はあまり頭が良くなく、どんな言葉もすらっと出てくるタイプではありませんでした。本の要約なんてもっての他で、非常に浅い回答しか出せなかったです。ただScrapboxを用いてメモを取り出して以降、スムーズに比較的細かく要約を話せるようになりました。
また合わせて自分の体験など本以外の事象も例としてセットで出せるようになりました。(本を読んで、自身の行動をこのように見返した。自分にもこういう体験があって、本のこの部分に共感した。など)
こういう変化が発生した理由を考えてみると、「構造化してメモを取るので、頭で処理しやすい」「本のメモとして独立せず、自身の体験と関連付けることでより記憶に残りやすくなった」「説明が定義されてないリンクがわかりやすいので、そこをちゃんと埋めて行った結果、ふわっとでなく、深く本の内容を理解できた」あたりがポイントなのかなと思ってます。
最後に
Scrapboxを使ってメモを取るようにしたことで、より本の内容を自分のものにできるようになったと思います。また読む中で疑問に感じたこと、より深めてみたいことが分かりそうな本を買って、リンクを繋げてネットワークを広げていくような楽しみ方、学び方も見えてきました。
せっかく本を買って読んだが身にならない。読んだ気になっているだけという話はよく聞くと思うし、自分自身そうでした。読んだだけでばっちり身に出来る人は本当にすごいなと思います。
ただ自分は賢く無いから無理だと嘆くのではなく、賢く無いなりに取り組める方法を試行錯誤し乗り越えることに意味があるのかなと最近思います。そのまま取り組んで難しいのであれば、自分の解ける領域まで持っていく方法を考えるべきだと今回強く思いました。
ひとまず高校生の頃から思っていた、本を読んでもあまり身にならない問題を解決する自分にとってのバージョン1は見つかりました。さらにここから試行錯誤し、バージョン2、バージョン3を見つけていければと思います。人生は長い！
1人目PdMの壁
プロダクトマネジメント業務を主として行うようになったが、同じ業務を行なっているスタッフは会社に自分しかいない。つまり1人目PdMという状態だ。
1人目PdMというポジションを取ることはPdMのキャリアをスタートしたい方にとって悪くない戦略だと思っている。既にPdMが何人かいる組織で新たにポジションを取れるタイミングはPdMが退職するか、新規プロダクトが立ち上がりPdMを増やす必要がある場面に限られる。そう言った場面があったとしても自分が選ばれる保証は無い。
かと言って未経験での転職は鬼門だ。
どの会社も中堅PdMを欲しがっている。未経験可の場合もあるが、これはPdMの肩書きがなくても良いという意味で、同様程度の業務経験を積んでないと厳しい場合が多い。
そのような状況の中で1人目PdMであれば、誰とも競争することなくポジションを取って実務経験を積むことができる。
会社の中で経験を詰み、プロダクトを成長させシニアPdM、PO、CPOなどのポジションを目指すこともできるし、他者へ転職する足がかりとすることも出来る。(既に実務経験を持っているため、完全未経験で転職を試すよりずっと確度は上がる)
一方で1人目PdMが抱えがちな課題もいくつかあると考えている。
この記事では私自身が感じている1人目PdMとしての課題感をシェアし、PdMを目指している方、1人目PdMに挑戦している方の参考(もしくは「やっぱりみんなこんな辛み抱えるよね・・！」という共感)になるととても嬉しいです。
1人目PdMが抱える課題
課題1: 知識を正しく積み上げることの難しさ：
1つ目はプロダクトマネジメントの業務知識の正しい積み上げの難しさがある。 PdMとして仕事をする上で必要な知識・能力をざっと箇条書きしてみる。
- PdMの責任
- プロダクトの成功責任
- ユーザーに提供する価値の向上
- 収益の増加
- ビジョンへの前進
- プロダクトの成功責任
- プロダクトを成功させるためのコミュニケーション能力
- 各領域間の翻訳力・マネジメント力
- 異なる領域(開発・デザイン・営業など)の関係者まとめ上げ、各関係者で認識の齟齬が発生しないよう正しく情報を翻訳し伝達・牽引する
- 各領域間の翻訳力・マネジメント力
- プロダクトの階層意識
- Core / Why / What / How
- 階層を意識して仮説を検証していく
- ターゲットが抱えている課題が仮説と一致しているか検証するフェーズなのにページの表示スピードの改善をしても意味無いなど
- プロダクトを構成する分野の知見
- テック・ビジネス・ファイナンス・CS・UIUX・マーケ・PR・リーガルなど
- プロダクトの成功責任を持つPdMが知っておくべき知見を、各担当者と問題なくコミュニケーションが取れる解像度で持っておく
- プロダクト改善の一連の流れ
- 課題の洗い出し
- 優先順位の設定
- 課題の分解(サブイシューの定義)
- 分解した課題を解くための施策定義、PRDへの落とし込み
- チームへのPRD共有
- 開発・テスト・リリース
- 検証
- 検証結果のフィードバック、次施策への反映
- ドメイン知識
- プロダクトで解く課題関連の知識
上記の通り、必要な知識・能力は幅広い。
そしてどこから順番に積み上げていけばいいかも分かりにくいし、積み上げるにしてもどの程度の解像度があれば良いかも分からない。(「プロダクトを構成する分野の知見 > テック」であれば、コードを書いて自身で個人サービスをリリースできるくらいの知見が必要？それともざっとしたWebサービスの仕組みが理解出来ていればいい？など)
自分自身も積み上げ漏れによる失敗を数多くしてきた。
一番お金も時間も無駄にしたなと感じたのは「ひたすらHowの回収に熱中する」ことだ。
当時は良いプロダクト、イケてるかっこいいプロダクトを作れば、めちゃくちゃ使われて有名サービスの仲間入りだ！なんて甘いことを考えていて、「これまで見たことのない信じられない技術」や「感動的なUX」を提供することに躍起になっていた。結局、ユーザーは課題を抱えてないという結論になった。その結論に辿り着くまで上記のようなHowに対してのアプローチを延々と行なっていたが、今考えるとコツコツとWhyの検証「まず顧客は課題を抱えているのか？」に注力すべきだった。(プロダクトの階層意識)
こういった失敗をしながら力をつけていくのも良いが、効率はあまり良く無いと思う。こういうとき他にPdMがいて相談できればよかったなと思う。
補足: ちなみに今自分が駆け出しPdMの方にどのように知見を積み上げるべきかと問われたなら以下のように返答すると思う。
- PdMの責任
- まずあなたが就こうとしているポジションはこんなことをやるということの共有
- あなたが持っているイメージと相違ないかのチェック
- プロダクトを構成する分野の知見
- プロダクト改善の一連の流れ
- プロダクトの構造を理解した上で、どういうところに着眼してどういう手順で改善していくかの共有
- プロダクトの階層意識
- プロダクトには階層があり、フェーズによって改善する階層を見定めることが必要である旨を共有
- ドメイン知識
- こういう課題があって、こう解こうとしている。いままではこういう解決策があったんだけど、こういう問題があって・・
- いままで解かれてこなかったのにはこういう業界の理由があって・・など
- プロダクトを成功させるためのコミュニケーション能力
課題2: 課題の解像度が一定値以上上げられない
2つ目は課題の解像度について。PdMの最も重要な責任は「担当するプロダクトの課題を明らかにして、課題を構成する要素(サブイシュー)に優先度を振り、最もインパクトがあるところから改善、ユーザーに提供する価値の向上・収益の向上・ビジョンへの前進を行うこと」にあると考えている。
それらの手順を実行していく際の「課題を明らかにする」「課題を構成する要素(サブイシュー)を明らかにする」対応の確度が一定値以上上げられなくなる点も1人目PdMの大きな課題だと思っている。
確度が上げられない原因は主に課題やサブイシューを鮮明に捉えられていない、つまり課題に対しての解像度が低いからだ。
課題がぼんやりとしか見えてないので、それを分解してもさらにぼんやりするだけだし、施策を打っても当たらない(目が悪い人がメガネを外してダーツをするようなもの)
そうなると解像度を上げれば良いのでは？となるがこれがとても難しい。
「解像度を上げる」を読むと、課題に対しての解像度が低い場合基本的に課題の「深掘り」が足りていないとあるし、自分自身の実体験からもそう思える。
この深掘りが難しい。どこまで深ぼればいいか分からないし、自身の持っている知識の範囲で観測できない場合もある。(センサーが発達してないと言ってもいい。第三者にこういう路線は考えた？と言われると、あ！と一気に分かるが、自分一人だと一行に進まない)
自分は本からのキャッチアップ+失敗に失敗を重ねて解にたどり着いた(深掘りして失敗、ではもう少し別方向で掘って失敗を繰り返す。最後は良い解にあたる)がやはり効率が良くないし、いい結果が出来ないと気持ちも下がる。スタートアップなら資金的にそんなことをしている余裕が無い。
この課題を解決するにはメンターを付けるしか無い。ただそのまま社外の人に話してしまうと情報漏洩になってしまうので難しい所。会社がメンター・アドバイザーと契約してくれるのが一番望ましい。(ただこれも外側からのアドバイス程度に留まるので、結局は自分でやるしかない。それでも何も無いよりはいい)
まとめ
自分が一人目PdMを経験する中で感じた課題をまとめた。
うまくまとめきれなかったし、こう解決すればいいという方法もほぼ無く最後まで読んでくれた方がいたらちょっと申し訳ない・・
ただ、もし同じように挑戦し、同じような課題に直面している方がいるのならあなただけじゃないと言いたい。この記事では上記の通り、具体的にどう乗り越えて行くかはまとめられなかったが、これ以降の自分自身のPdM人生の中で乗り越え方を見いだせたらまた記事にしたい。この記事がそういった誰かの役に立つコンテンツの幹になれるよう、プロダクト・顧客と向き合い知見を貯めて行く。
Web上の信用を上げ、プロダクトを手にとってもらうには
自分自身、Web上での信用はあまりない方だと思う。
知名度のある会社の出身でなければ、知名度のある学校の出身でもない。強力なコネがあるわけでもない。
元々はそんな信用はいらない！社会的に意味のあるプロダクトを作ればきっと評価されると思っていた。現実はそうではなく、良いプロダクトであることは当たり前でそれプラス
- どんな人・どんな会社が作っているのか
- どんな実績があるのか
- どれだけ社会的に評価されているのか
が見られる。(当たり前だけど。自分自身も何か商品を手に取る時、品質が高そうで知っている企業の商品を手にとりがち)社会的な評価は実績の積み重ねだと思う。実績を作るには、「どんな人・どんな会社」の部分を上げる必要がある。
今回は「どんな人・どんな会社」の部分の信用をどのように上げて、プロダクトを顧客に認知してもらう(信用できる人・会社が作っている、良いプロダクトだと)か考えてみる。
自分のような状況で信用を貯めるアプローチは何があるかを以下にまとめてみた。
地道に営業、顧客に満足いただく、を繰り返す
当然だが地道に営業するし、プロダクトは改善し続ける。
利用してくださる方に喜んでもらい長く使ってもらえるよう取り組み続ける。
飛び道具よりまず先にこの土台を整える必要がある。少しずつだが信用は貯まる。ただ予算は限られているし、決まった期間内で結果を出す必要はある。このアプローチは土台として必要だけど、他のアプローチも同時並行で実行したほうがいい。
VCからの資金調達
VCからの調達は顧客にも他VCに対しての信用が上がる。
リードのVCが良いと後のVCが声をかけてくるというのはよくあることだし、(ITリテラシーが高い層向けにはなるが)調達していることでイケてるスタートアップ、聞いたことあるスタートアップくらいには信用ランクが上がる。
知名度がある企業にM&Aしてもらう
知名度がある企業に買収してもらい信用を上げる手はあるが、そもそも買収に値するレベルまで企業を成長させる必要があるのであまり使える手では無いと思う。十分に信用があるがさらに上げたい場合の手だと思っている。
SNSでのフォロワー数
これが最も手軽で再現性がある手だと思っている。
どこかの企業・学校に所属し信用を上げるのではなく自分のファンを作ってそれを信用とする。インスタグラムでものすごいフォロワーがいて、ファッションブランドを立ち上げている方がこの方法の成功例だと思う。(特段有名なブランドにもともと在籍していたり、というケースは少ない。自分で上げた画像によって信用を上げていく)
ファッションを例にあげたが別にファッションじゃなくてもいい。自分のプロダクトの領域でフォロワーを増やせばいい。
メディア露出
これもそもそもある程度信用がないと難しいのと、そもそもプロダクトの品質が元々高くないと結局メディアを見てプロダクトを触っても信用には結びつかない(こんな人がやってるんだ！->商品を触った->〇〇さんが作る〇〇最高！->信用)最後ブーストしたい時に使うくらいの気概でいいと思っている。
今の時点の知識で挙げられるアプローチはこんなところだと思う。スタートアップをやってる人、個人開発をやっている人なら割とぶつかりがちな問題だと思うけど草の根軍団が生きる道は絶対あるはず、もっとリサーチして自分なりの勝ち方を見つけたい。
エンジニア出身プロダクトマネージャーで良かったこと
最近は新卒でプロダクトマネージャーになる方も多いと思うが、CS、デザイナー、エンジニアなど何らかのキャリアが元々ありその延長でプロダクトマネジメントに関わっている方が多数だと思っている。
自分はエンジニア出身のプロダクトマネージャーだが、エンジニアというバックグラウンドがあって良かった点を考えてみた。
良かったこと1: 解決策の実装方法を深くコントロールできる
課題に対し、解決アプローチを決定し仕様を引いていくが実装するアプローチは複数考えられると思っている。
例えば、まず機能ニーズがあるか検証したいので簡易的に実装し、ニーズが確実にあると考えられる場合、正実装するようなアプローチ。また短期間のキャンペーンでの運用なので工数かけず実装したい。既に成功事例があるため検証せず、正実装したい。など。
そういった解決策の実装をエンジニアとすり合わせる際、認識がずれない点はとてもプラスに働いている。認識がずれない理由は
の2点によるものだと思っている。技術の知見がないと、思った以上の工数がかかっても「そんなにかかるのか〜」程度の認識で止まってしまう。結果思っていたより複雑な実装がなされてしまった、という失敗はよくあると思う。素早くPDCAを回す上でこういった不要なコストアップは命取りなので、そういった失敗を回避できる意味でエンジニアの経験があってよかったと思う。
良かったこと2: 技術的に実現できない、必要以上に難易度の高い仕様を設計する心配がない
技術の知見がないと既存の技術仕様を考慮していない仕様を作ってしまい、エンジニアと衝突する場面が考えられるが技術の知見があるとそういった問題起こりにくいし、起こったとしても解決アプローチを発想しやすい。
良かったこと3: SQL等分析業務のキャッチアップ工数がかからない
SQLはバックエンドエンジニアであれば当然使いこなせる。Pythton・Rなど使う局面があったとしても柔軟に対応できる。(自分は分析業務において使用したことはまだないが)
データエンジニア・データサイエンティスト・リサーチャー等いれば対応する場面は少ないが、規模が小さい組織ならプロダクトマネージャーが兼任している場面も多いと思うので、そういった場合はプラスに働くと思う。
強みと弱みは隣り合わせ
個人的に良かったと考えられるポイントは上記の通りだが、これは常に弱みに転じる可能性があることも強く認識しておきたい。
解決策の実装方法を深くコントロールできる点は、上手くコントロールできればプラスに働くがついついマインドが解決策をどう構築する側に傾いて、課題の分析がおろそかになってしまう危険がある。(自分は注意していないとたまに起こる、意識しないとプロダクトファーストになりがちなのはエンジニア->プロダクトマネージャーにキャリアチェンジして最初のうちの問題あるあるだと勝手に思っている)
技術的に実現できない、もしくは難易度の高い仕様を組まないという点は技術側にとっては好都合だが、その実装がもしかしたらユーザーにとって最も良いアプローチだった可能性も考えられる。常識の範囲内の凝り固まった仕様しか練れなくなるかもしれない。時には大胆に考えることをマイルールにしている。
分析業務が容易に実行できる点も、プロダクトマネージャーがチームのボトルネックになっているような局面ではマイナスに働くかもしれない。チーム状況によってはだれかに分析だけ任せる判断も必要。
このように強みと弱みは常に隣り合わせだと思っている。エンジニアとしての経験をプラスに発揮できるプロダクトマネージャーであれるよう日々気をつけて取り組みたい。
