見出し画像

プロダクト開発で意識していることのメモ

owano49 / PM

初noteです。普段はインタースペースという会社でRECOTORI（以下、レコトリ）という旅行特化SNS/クチコミアプリのPM＆ディレクターとして、グロースやらプロダクトマネジメントやらを担当しています。

これはなにか？

この記事は、レコトリを運営する中で意識していることを備忘録をかねてライトに書きました。リリースからまだ１年で手探りなので、あと１年もすれば全く別のことを意識しているかもしれません。なお、本記事では新規プロダクトの開発においても、運用・グロースフェーズで機能追加や改善するときのどちらでも応用が効く気がします。

なぜ書くのか？

初noteなので、なぜnoteをはじめたのか記載してみます。

・レコトリがリリース１周年を迎えてnoteを公開した
・社内でプロダクト開発プロセスなどの共有会をすることになった（！）
・Twitterの140文字では言いたいことが書ききれない

などが重なったので、これまでの経験からの学びも含めた棚卸しとして、まとめておこうと思いました。

前置きはこれぐらいにして、本題に入ります。

１．類似サービスを触りまくる

まずは類似サービスを触りまくります。これは業界に関わらず、事業構造が似ているサービス、似てないけどイケてるサービスも含めて調査します。立ち上げ前は少なくとも100個は触ったかも。

例えば投稿系サービスという軸で、Instagram, forsquare, 食べログ, Pinterest, Retty, WEAR, CARTUNE, LIPS, Roomclip, などをはじめとするCGM系のメジャーどころはほとんど触ったと思います。

あと、特定のサービスを深く知りたいときは取材記事を読み漁って参考にすることが多いです。こういう記事とか。

口コミグルメサイトの成長曲線

画像1

たくさんの"ろくろ回し"を見た気がする

２．ユーザーと話す

ユーザーさんと直接話すこともやってました。これはサービス構想段階から意図的に行っています。N1インタビューとか言われることも多いです。構想段階から振り返ると、グループインタビューも含めて100人ぐらいは話をしたかもしれない。

実装前に行ったプロトタイプの検証ではかなりのダメ出しをされて、何度もぶっ壊した記憶があります。

まるで筋肉トレーニングのように壊れては頑丈になり、壊れては頑丈になり、を繰り返した

なお、インタビューは目的によって全然手法が変わるので、
・ペインを探るのか
・解決策を探るのか
きちんと前もって明確にしておかないとごちゃごちゃになって危ない気がしました。

インタビューのHOWは『リーン顧客開発』『顧客起点マーケティング』『起業の科学』あたりが参考になりました。

あと、下記のyoutubeの動画(音声)を最近視聴したのですが、われわれも１段レベルをあげないといかんなと思いました。インタビューは参加した人しか手触り感が掴めずに属人化しがちなので、ドキュメント化してチームのナレッジとして展開できている10Xさんは凄い。スタチャさんもかなり勉強になります。

パートナーと共にユーザー価値を追求するProduct&Growth【10X Topic】

Startup Chat 8ユーザーインタビューで大事なことやHowを深ぼってみた

３．要件定義、仕様作成

これは意識していることというか、参考になった情報のメモです。最終的にはネット記事にあるPRDや仕様書のフォーマットを参考にして運用する中で改善をしていきました。こういう記事とか。

初めて書くPRD（プロダクト要求仕様書）

タベリーのグループ機能_仕様書

いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。

また、いわゆるユーザーストーリーのフォーマットをこれまで仕様書の最初に記載していたけど、無理やり感があってしっくり来ませんでした。なので最近は『ジョブ理論』にでてくる「job to be done」に基づいて施策を考えるように意識しています。

・自分の投稿を地図でみたい　☓
・自分がどこに行ったのか位置関係をパッと可視化したい　◯

みたいな感じ。ただ、まだまだ粗いので改善余地が多いと思っています。

参考記事：ジョブ理論(JTBD)の良い例と悪い例

４．リリース後は定量＆定性の両方を駆使する

これは言わずもがな。両方合わせてこそ価値がでると実感しています。

「キンキンに冷えたビール」と「アッツアツ鶏のから揚げ」（？）みたいな。

イメージとしては、

①定量分析で、サービスの課題をみつける（どこが問題か）
②定性分析で、①の原因をみつける（なぜそうなっているか）
という使い分けをするようにしています。定量で全体感と優先度を把握して、定性で深堀りするイメージ。下記からもだいぶ示唆を頂きました。

５．ファネルとリテンションをみる（定量）

定量のところは、主にファネルとリテンションを見ます。

ファネルの場合は例えば、

・会員登録のステップでどのぐらい離脱したか
・投稿するフローのどの項目で離脱したか

などのシンプルなファネルも水漏れがすぐにわかるので便利ですし、

・投稿した人のうち、何人が再投稿したか

などの特定アクションのリピート率などもファネル化するとわかりやすいです。

実務的には、ファネル分析機能のあるツールを活用したり、自社でダッシュボードを構築すると分析の省力化ができて良いです。

リテンションはとりあえずコホートリテンションを見ています。

なお、リテンションの期間ですが、まずはD1~D7、翌週ぐらいの短期的なリテンションにフォーカスするのが王道らしいです。なぜなら、短期でリピートしなかった人が、翌月とか３ヶ月後に戻ってくる可能性は極めて低いため。

あとは、イベント別のリテンション分析や、機能×リテンションのマトリックスも課題の優先順位付けに有用な示唆を得られるため重宝しています。

画像2

「マジックナンバーを見つけてアプリの継続率を上昇させよう(リテンション分析を用いたアプリのグロースハック③)」より引用
https://engage-mate.jp/article/know-how/retention-analysis-03/

ただ、リテンションはあくまで結果指標なので、やはりグロースを目指す場合はもう少し手前の指標（例：マジックナンバーとか）にフォーカスする必要があると思います。下記の記事は参考になりました。

目標KPI設計時に意識すべき指標の2類型

６．インタビューとドッグフーディング（定性）

ファネルで問題箇所を特定できたら、「Why？」を探ります。自分たちは主にN1インタビューと、ドッグフーディングの２種類を駆使しますが、前者は２の項番に記載したので割愛。

「ドッグフーディング」とは、自分たちで自社の製品を日常的につかうという意味です。毎日触るのはもちろん、実際の旅行探しのときに使うことで、「うわ、ここ使いづらいな」とかに気づけるのが良いです。ただ、PMは仕様を理解している反面、検索などは意図的にハックできてしまうので、何も知らないユーザーから見たときの感覚を得ることは難しいと思います。なので先述のN1インタビューなどと組み合わせるとよい気がします。

余談：なぜ自社サービスを使いたおすことが「ドッグフーディング」という用語になったかの由来が面白かったので引用。

ドッグフードのセールスマンが犬用ビスケットを食べて質の高さをアピールした、というエピソードが由来となっている。

引用：シマウマ用語集

本当はユーザビリティテストもやりたいけど、まだリモート環境でうまくユーザビリティを検証する手法をよく知らない。。。

７．コップを大きくするのと、穴を塞ぐバランスを保つ

グロースはコップやバケツで喩えられることが多いですが、コップ自体をデカくする施策と、コップの穴を塞ぐ施策は全く別物であることが多いと思います。

そして、それらの優先度の判断は本当に難しいなあと思います。いわゆるMVPもミニマムすぎては到底価値を発揮できないし、そもそも最低限のサイズのコップじゃないと出しても意味ないのでは？と思うこともあります。

コップをデカくする、コップをバケツにする、バケツをバスタブにする、などのイメージはこの図がわかりやすいです。ショットグラスの小ささだったら、どれだけ穴を塞いでもほとんど水は溜まらないですね。

画像3

「まずは根性、そして「ユーザー体験の最大化」を考えろ！iQONの投稿数を40倍に急成長させたグロースハックの考え方-VASILYセミナー前編」より引用
https://appmarketinglabo.net/vasily-growthhack/

ちなみに、穴を塞ぐとことの概念は下記のARRRAモデル（アーラモデル）で説明されることも多いです。

画像4

「ほとんどの人が勘違いしているグロースハックにおける最適なフレームワーク」より引用
https://note.com/kajiken0630/n/n90ad20b31f65

どのようにバランスを保つのか？は非常に難しくて、自分たちもまだ答えを出せていません。

現状は、まだまだ水漏れがあることを把握しているが、コップのサイズを拡張しないと、そもそも戦えないという判断をしています。

８．ドキュメントに残す

運用していると１年前に決めた仕様が「いま、どうなってるっけ？」「なぜ、こうしたんだっけ？」のように忘れることが多く、かなり時間のロスをしている感覚があります。リリースして半年後ぐらいから新メンバーも増えてきて、そのあたりから、現状の仕様に関する確認が顕著に増えました。

なので、ここ最近はもっぱらMTGで話した内容など、意思決定の背景をあとから見返せるように、なるべくテキストで残すようにしています。

とはいえ、ここはまだ初心者なので、よい仕様の書き方、チケット管理のやり方、など改善の余地がかなりあります。例によって、10Xさんの事例はかなり参考にさせていただいてます。

62 ドキュメントシステムを整える　ゼロトピック - Zero Topic

1 ドキュメントの価値 Podcastを始めた理由

できてないこと（もっとやりたいこと）

以上が自分がプロダクト開発において意識していることのメモです。まだまだ、できていないことだらけなので、これから取り組みたいと思っている例をいくつか挙げてみます。

・マジックナンバーの発見⇒初回体験の改善
マジックナンバーらしき先行指標はある程度発見できているが、基本機能の実装などコップを大きくする活動を優先していたので、後回しになっている。。。

・データ民主化、分析効率化＆即時化（ダッシュボードを整える）
数値集計はFirebaseやadjustや広告管理画面など各所に散らばっていて、定点観測するにしても効率が非常に悪いです。なので、そろそろデータ分析基盤を整える必要があります。

・課題を見極める精度
解くべき問題を見極める精度をもっとあげないといけないです。例えば、ごく少数の人しか使わない機能の追加/改善よりも、オンボーディングやTOP画面などサービスの大通りの改善をするほうがレバレッジが効く。また、ユーザーとの対話は重視しつつも、「ドリルを欲しがっている」「速く走る馬を欲しがっている」ケースも多いため注意が必要です。

・全員で解決策を考える文化
PMが解決策や仕様をすべて落とし込むのではなく「この問題を解決したい」「ユーザーがこういう結果(状態)を得られるようにしたい」という単位でチケットを切ってみたい。例えば「検索のレスポンス速度を2倍にしたい（速度向上）」みたいな形で。たしか『INSPIRED』にも同じようなことが書いてあったような気がします。

先日、レコトリで画像高速化対応をしたのですが、エンジニア主導で進めていただいき、かなりの改善をできたので、非常にインパクトがあったと思います。少しずつ増やしていきたい。

編集後記

もっとライトな記事になる想定でしたが、意外と長くなってしまいました。いかんですね。

できてないことを挙げたらキリがないのですが、ほかの会社さんは具体的にどのようにやっているのでしょうか？もしよろしければコメント欄やTwitterなどで教えて下さい。感想やフィードバックもいただけたら嬉しいです。

ほそぼそとTwitterやってます⇓


いいなと思ったら応援しよう！