プロダクトの思想や土台を作りで僕がやったことと意識したこと

プロダクトの土台を構築していく際に、実際に僕がやったこと、意識したことなどを書いていきたいと思います。(主に note のプロダクト設計を参考にしています。)

自分の中で新しい情報や気付きがあったタイミングで、順次アップデートしていく予定です。

章立てにしていますが、各章は独立してません。

それらを行き来していくことで、プロダクトの土台が出来上がっていくはずです。

プロダクトのビジョンを明確にしよう。

プロダクトが提供する最高の体験と最低の体験について考えよう。

最高の体験に提供するための主軸をつくろう。

1.プロダクトのビジョンを明確にしよう。

「このプロダクトは、誰のための、どういう場所なのか？」を明確化しておくことが重要です。

プロダクトのビジョンがないと、施策の是非や優先度を決めることができなくなってしまいます。

ビジョンは、単に耳障りの良い言葉で終始しないようにしましょう。

実際に行動指針となるもの。

施策などに迷ったら照らし合わせることができるもの。

がよりよい状態のビジョンといってよいと思います。

ツール化できたビジョンによって、自律的に動くことができるチームを生み出すことができるはずです。

プロダクトのゴールって、数字に落とし込まれがち。でも、「数字を上げたい」というよりも、「こんな世界をつくりたい、こんな体験をつくりたい」とプロダクトのコアを言語化して伝えたほうが、みんなのテンションも上がりやすくブレにくい。深夜に書くポエムも、PM の仕事？BASE 神宮司誠仁の PM 論より

note のミッションは耳障りだけの雰囲気ワードではなく、「コンパスとして機能する」ことを大事に設計しています。誰のためのプロダクト、どうしてもらいたい、その結果どうなればいい？といったことが、ワードに織り込まれています。普段から note に限らず、全クライアントに「ミッションは北極星」と言っています。ビジネス、テクノロジー、クリエイティヴのバランスをとるには？より

最初は荒削りでもいいので、自分が関わるプロダクトが将来どういうプロダクトになってほしいのか。どういう人がどのように使ってくれて、どう感じてほしいのか。どういう風になってほしいのか。などをつらつらと書いてみてもいいと思います。

そうやっていくうちに、自分の頭の中が整理されてくるはずです。

そこから、チームの全員（欲言えばチーム外の人も）が「このプロダクトは、誰のための、どういう場所なのか？」を想像できるような表現に落とし込みましょう。

プロダクトは流動的なものなので、定期的に表現はブラッシュアップしていっていいと僕は思っています。

気をつける点としては、自分本意なドキュメントになってしまう可能性があります。

ドキュメントを作る目的は、

チーム内でのプロダクト思想の共有（＋チーム力のアップ）

チーム外の人に対しての宣言

自分の頭の整理

あたりにあると思いますので、目的に合わせて、ビジョンのサマリーと詳しい背景あたりの言語化の粒度は意識してもいいかもしれません。

2.プロダクトが提供する最高の体験と最低の体験について考えよう。

次にプロダクトが提供する体験のうち、「ユーザーがこうなってくれたら最高🤩」。逆に、「ユーザーにこう思ってほしくない。こんなプロダクトになってほしくない、、、😭」といった最高の体験と最低の体験についても言語化してみましょう。

「最高の状態」を定義できていなければ、現状とその理想状態を乖離を定量的に測ることはできず、また「最悪の状態」を定義できていなければ、その最悪の状態がどれくらいの割合で発生してしまっているかを定量的に測ることはできない UX 改善の第一歩は、"最高"と"最悪"のユーザー体験フローを描くことより

最高の体験？最低の体験？

プロダクトが提供する全ての体験について書いてもいいですが、「このプロダクトは、誰のための、どういう場所なのか？」が、ぼんやりとでも認識できていれば、「使ってくれた人が、こういう風になってもらうためには、こういう体験が最も重要だ！」と考えている体験について、まずは書いてみるのがいいと思います。

そして（理想論かもしれないですが）その体験が、よりスムーズに、より高品質にユーザーに提供できたときのことを考えてみましょう。

それが（少なくとも今時点での）最高のユーザー体験になると思います。

注意点としては、プロダクトの体験は、プロダクトを使用する前からのユーザー文脈から始まりますよね。（この辺については「UX 文脈」とかでググってもらった方がいいと思います。）

ユーザーがなにかを感じてから、実際にプロダクトを使い始めたときに、「ここではこういった体験をしてほしい。」のように要所要所で、提供したい最高の体験を言語化しましょう。

ざっくりというならば、例えば、気になる洋服をいくつかすぐに見つけられる体験を提供するファッション EC サイトの場合、

ユーザーが、かっこいいジャケットがほしいと思う。

サービスを使い始める。

気になるジャケットを「すぐに」見つけられる。

自分に似合いそうかどうかを想像しやすいので、納得した上で購入できる。

商品が届く。

着てみると、やっぱりかっこよかった。

みたいな感じですかね 🤔

この例でいうと

「2.すぐに商品を見つけられること」「3.自分に似合うかどうか判定しやすくすること」

が最高の体験に繋がるかもしれませんね。

この２点について、具体的にそれらを提供するにはどういう体験が必要になりそうかを言語化してみるとよいかもしれません。

最高の体験を提供しようとしたときに、それらを阻害してしまうような要因となりそうなことや、プロダクトのビジョンを根本から覆すようなことは、最低の体験に繋がってしまうと思います。

3.最高の体験に提供するための主軸をつくろう。

プロダクトのコアは、プロダクトの初期段階である構想していると思いますが、やっぱり時間が経過してくると、それがブレてきたり、チーム内での疎通が取れていなかったりすることが発生するので、きちんと言語化しておくことは重要だと思います。

前回のステップで、最高の体験と最低の体験を書き出すことで、最高の体験を提供するために必要な要素(=プロダクトの主軸)への解像度が上がってきていると思います。

この主軸は、コアを成立させるための主軸です。

主軸が太く頑丈になったプロダクトはユーザーに最高の体験を提供できているようにきっとなっているはずです。

また、この主軸は、施策の優先度などの指標にも有効活用できます。

この指標は、個別の施策を実施するときの優先度付けに役立つ。たとえば、投稿用エディターの改修（コンテンツパワーの強化）、AI レコメンドの精緻化（発見性の改善）など、3 つの指標のどれかに大きく寄与するならば、力を入れて良い。しかし、もし 3 つのどれにも当てはまらない新機軸は、実施の是非自体を検討する、もしくは最小限の工数に抑えて行うようにするという具合だ。インターネットの中の“街”を目指す――だれもが創作をはじめ、続けられる「note」の開発舞台裏より

気をつける点としては、軸を増やしすぎないことですかね。

「なんでもできる」は「なんにもできない」。

軸の多すぎるということは、プロダクトへの解像度がまだ足りていないからだと思いますので、前の章を何度か行き来し直してもいいと思います。

また、軸の増えすぎた弊害として、どこにどれだけリソースを投下するかの選定も難しくなるかなと思います。

これから

正解はないと思いますが、個人的には言語化できてよかったなと思っています。

本当は、このような土台や価値をプロダクトの成長モデルや、ビジネスモデルとして昇華させるところまでやってもよかったかもしれない。と思っているので、また機会があれば言語化しておきたいです。

（おそらくこの辺が参考になりそう...🤔）