あなたが開発しているものは間違えているたった一つの理由 「ビルドトラップを避け顧客に価値を届けるプロダクトマネジメント」解説
こんにちは。もぐめっとです。
最近田舎のヤンキーになりました。近所でおらついてたら注意してあげてください。
ところでみなさん、今開発しているものをリリースすることに専念してませんか？
そんな方々は今回説明するビルドトラップにハマってしまっています。
今回はメリッサペリというプロダクトマネジメントのプロが書いた下記の本を解説していきます。
本書はプロダクトマネージャーでの考え方や動き方に関して書いてある以外にも組織としてどう動くべきか、プロダクトとどう向き合うべきなのかということが書いてあるのでプロダクトマネージャー以外のものづくりに関わっている全職業の方々に読んでいただきたい一品になっております。
そもそもビルドトラップとはなんぞやと思ってる人が大多数だと思うので解説すると、組織がアウトプットで成功を計測するので、機能の開発とリリース（アウトプット）に集中してしまい、行き詰まっている状況を指します。
こうなると企業がユーザにとっての本当の価値を生み出さなくなるので、市場でのシェアを失ってしまいます。
では、そんなビルドトラップから抜け出すためにはどうしたらいいかというと、組織が顧客と向き合って顧客価値を生み出し、機能を出して顧客の問題を解決した結果（アウトカム）に集中するのです。
顧客が自分たちの問題が解決したり、要望やニーズが満たされたときに顧客が価値を認めてビジネス側に価値を返すので、これでようやくビジネス目標を達成することができるのです。
本書では具体的なビルドトラップの抜け出し方について記載されているのですが、忙しい方向けに最初に結論を書くと、
1. プロダクトマネージャーが、ビジネスと顧客を理解して価値を生み出す見極めをしチームの生み出すアウトカムを決める
2. 企業のビジョンと経済面でのアウトカムを結びつける戦略を作って企業全体に展開することで企業の方向性を決める
3. 適切な方法でユーザの課題に向き合って素早くアウトカムを出す
4. 組織全体でアウトカム主義になった上で戦略を立て、評価し、ビジネスを進める
つまり、ビルドトラップから抜け出すには最終的には組織ごと変えるために組織全体を見直す必要があるというお話になります。
今回は上記の流れで本書について解説した後、もぐめっと的補足とアクションを述べた上で締めさせていただきます。それでは早速解説してきます！
第一章/プロダクトマネージャの役割
プロダクトマネージャー（PdM）の役割を知るために悪いPdMの特徴と優れたPdMの特徴を説明いたします。
■悪いPdMの特徴/ミニCEO
スティーブ・ジョブズのような大きい夢を見てビジョンを語るのですが、その夢に固執するあまり顧客やチームと向き合わず、他の人の意見を全く取り入れないような人です。
本当にスティーブ・ジョブズのようなちゃんと顧客価値を出しているような夢ならばいいのですが、全員が全員スティーブ・ジョブズになれるわけではないので、大抵チームともうまくいかず失敗することになります。
■悪いPdMの特徴/ウェイター
大企業でよくありがちなのですが、上からの重要な人の要求が最優先になって取り組んでしまう人です。何がほしい？ときいて言われた通りのものを作るのですが、それは顧客価値を出していないため誰にも使われないものができあがります。
ソリューションを考えるのは顧客ではなくあなたなのです。
■悪いPdMの特徴/PMだった人
PMとPdMの違いについて他記事より引用させていただきます。
プロジェクトマネージャーとは、関わるプロジェクトの業務計画、進行管理、実行における責任者のことを指します。プロジェクトを成功に導くリーダーとしてふるまい、『PM』と呼ばれます。
プロジェクトマネージャーは、担当するプロジェクトに責任を持つため、プロジェクトを「いつまでに作るか(when)」、「どうやって作るか(how)」を考え、チームを束ねることが特徴です。
プロダクトマネージャーは、商品やサービス、プロダクトに対して責任が伴うため、 プロダクトの「なぜ作るのか(why)」にフォーカスを置く
プロダクトマネージャーとは、担当する商品、サービスの開発から販売まで戦略を立て、実行、意思決定をする責任者のことを指します。プロダクトを成長に導くためのリーダー『PM』、もしくは『PdM』と呼ばれます。
つまり、主にWhen、Howに責務を持つのがPM、Whyに責務を持つのがPdMといったことになります。そのためそもそもの考え方や進め方が異なってくるわけです。
PdMはPMと違い、顧客。ビジネス・マーケット・組織を理解した戦略的なマインドセットが必要になります。
PdMの役割としてはチームと協力してビジネスニーズとユーザの問題解決を同時に満たす適切なプロダクトを作ることになります。
そしてPdMがもつのは「なぜ」それをつくるのかという理由の部分で、目の前の目標を知って、会社の戦略に応じてチームがどの方向に向かうかを理解し、チームメンバーに方向性を伝えることが重要になります。
（１点だけ注意することとしては、「なに」に対する部分の持ち主はチームになるので、チーム全体で「なに」を作るかは考えるようにしましょう。）
次からは上記を踏まえて優れたPdMの特徴を紹介していきます。
■優れたPdMの特徴 / 技術とマーケットが(ある程度)わかる
PdMはコードをかけなくてもいいですが、開発者と会話したり、トレードオフの決定を下したり、機能や改善の複雑性を理解して開発者に正しい質問ができるくらいの技術の理解度は必要です。
また、マーケットアナリティクスがチームにいるなら、その人との会話の仕方、学習方法、その人のスキルの活用方法を知っておく必要もあります。
■優れたPdMの特徴 / 「なぜ」から始める
優れたPdMはウェイターのように、上から要求されたものをそのまま作ることからはじめません。一番初めになぜつくるのかを下記のような質問で問います。
・どうやって価値を判断するのか？
・マーケットでのプロダクトの成功をどのように評価するか？
・適切なものを作っていることを確認するにはどうしたらよいか？
・どうやってプロダクトをマーケットに投入するか？
・etc...
また、組織としての取り組みとしてもPdMが「なぜ？」に対する答えを見つけるためにプロダクトのビジョンを解釈したり、調査の作業に必要な時間を与えないといけません。
ビジネス目標と顧客目標を組み合わせて価値を実現することが重要なので、顧客の問題を解決する視点をもちつつ、ビジネス目標を達成するプロダクトを開発・最適化する方法を見つけることができるのも優れたPdMの特徴でもあります。
閑話休題：POとPdMの違い
ところで話は少しそれるので読み飛ばしても構わないのですが、プロダクトオーナー（PO）とプロダクトマネージャー（PdM）の違いについても理解を深めるためにも触れておきます。
POの役割としては下記になります。
・バックログを定義し、開発チームが理解できるようなユーザーストリーを書く
・バックログの手入れをして優先順位をつける
・完成したユーザーストーリーを受け入れて、基準を満たしているか確認する
一方PdMは下記の方法を学んでいきます。
・アウトカム思考の目標をもとに作業の優先順を決める方法
・顧客価値やビジネス価値を定義したり見つける方法
・マーケットでのプロダクトの成功について不確実性をへらすためにどんなプロセスが必要かを決める方法
プロダクトオーナーシップはプロダクトマネジメントの一部にしかすぎません。そのためPdMはスクラムに依存しません。
POはスクラムの中の役割で、PdMから見ると手段の一つにすぎないため、スクラムがなかったとしてもPdMはPdMのままなのです。
第二章/プロダクト戦略
ここからは企業としてどういった形でビジョンを決め、戦略を組んでいくのかといったことを解説していきます。
■戦略は意思決定を助けるフレームワーク
よくある間違いとして、機能の一覧とどうやって実現するかの詳細情報を構成した文書のことをプロダクト戦略と述べたりしますがそれはプロダクト戦略とは言いません。
プロダクト戦略は現在のコンテキストとの整合性を保ちながら現在の能力の制約のもとで望ましいアウトカムを達成するための行動を可能にするものになります。言い換えると組織を現在の場所からどう動かしてビジョンに到達するかといったものになります。
良い戦略はより高いレベルのビジョンや目標に焦点があたっているのですが、どういった形で良い戦略を作るかの例としてはspotifyがDIBBといったフレームワークを用いて作っている例が紹介されています。
簡単に言うとデータを分析して、状況を把握し、仮設をたてて、指標を建てるといったものになるのですが、詳細については小生のnoteに記載しているので良かったらご覧ください。
■戦略展開
戦略は作っただけで終わりではなく伝える必要があります。戦略が組織に伝わると、企業戦略を踏まえてプロダクト開発チームの行動が決まり、それによって生まれたプロダクトやデータに関する作業を実行することで解消の方向性が明らかになるといった循環が組織全体で生まれるので、開発とプロダクトマネジメントは同期しはじめます。
戦略展開とは組織全体を通じて適切なレベルの目標を設定し、チームが行動できるように活動範囲を狭めることになります。制約がないと、チームの方々は選択肢が多すぎて何も決められないと感じてしまいます。
この戦略展開ではビジョン、戦略的意図、プロダクトイニシアティブ、オプションの4つのレベルで展開が必要です。
下記のような範囲と役職の人がそれぞれ考えます。
ビジョン：5-10年でどうなりたいか、顧客にとっての価値、マーケットでのポジション、ビジネスがどうなっているかをCEO/シニアリーダーシップが考える
戦略的意図：ビジョンを実現する上で立ちはだかっているビジネス上の課題は何かをシニアリーダーシップ/ビジネスリードが考える
プロダクトイニシアティブ：プロダクトの観点で課題に取り組むには、どんな問題を扱えばよいかをプロダクトリーダーシップチームが考える
オプション：問題を解決して目標を達成する別の方法はないかをプロダクト開発チームが考える
ビジョンと戦略的意図が企業レベルでの展開で、残り２つは会社の特定のプロダクトやサービスのレベルになります。
次からはビジョン、戦略的意図、プロダクトイニシアティブの作り方について紹介します。
■ビジョンは組織全体で作っていく
ビジョンはマネジメントがトップダウンで決めるだけのものではありません。何をすれば目標に到達するかを学習して戦略を伝えるために組織時全体で情報を共有すべきです。
戦略をたてるにはチームが分析・テスト・学習を行ってそこで発見したことを同僚やマネジメントチームに伝える必要があるので、企業レベルで始めないといけないものになります。
ビジョンが出来上がった後は企業がどの方向に行動すべきかを判断するために戦略策定をします。そのため、戦略策定するには最初にビジョンやどこに行きたいのかを理解しなければいけません。
そんな行動指針にもなるビジョンですが、良いビジョンを作るためには、なにをするのか、なぜそれをするのか、どうやって勝つのかがまとまっていると企業の価値提案につなげやすいです。
Netflixの例ですと、
世界最高のグローバルエンターテイメント配信サービスになること、世界中のエンターテイメントコンテンツのライセンスを提供すること、映画制作会社のためのマーケットを創出すること、世界中のコンテンツ制作者がグローバルで閲覧者を見つける手助けをすること。 Netflix
と紹介されており、What, Why, Howがうまく入った例となっております。
もぐめっとが他に関わった会社を見てみると、以前小生のnoteでも事例紹介したFreCre Inc社もWhat, Why, Howがうまく入ったいいミッションでしたので紹介します。
インターネットに接続できるようになれば、誰でも情報が簡単に入手できる時代になりました。誰でも情報が簡単に入手できる時代になりました。なのに、僕たち人間は、昔に比べてあまり成長を感じられません。なぜでしょう？
僕たちは情報にアクセスできても、それを「楽しく」「仲良く」「成長する」ための仕組みがないからです。
FreCreはゲーミフィケーション・ソーシャリゼーション・エジュケーションの技術を融合させたサービスを、社会基盤として全ての人に提供し、人類を１００倍生産的にする事を目指し続けます。
なにをどうしてどうやってやるのかがうまくまとまっているので焦点が定めやすいです。
ただし、ここで気をつけてほしいのが、Howに関しては過剰に規定するのではなく、集中すべきところが明らかになるように焦点を定める必要があります。あまりにも具体的にすると幅が狭まって、選択肢がなくなり、追加や変更がしづらいものになってしまいます。
■戦略的意図は小さいリストで保つ
ビジョンは長期に渡って安定しているべきですが、企業の成長に伴ってビジョンに到達するための方法は変化します。戦略的意図は1~数年かけてビジョンの実現につながる現時点での重点分野を伝えるものになります。
ビジネス価値の本当の意味を理解しながら、CxOの人たちはひたすら上記を問い続けます。
ここでの注意点としては、この戦略的意図は適切なレベルで適切な数のリストを小さく保つ必要があります。
でないとリソースが分散して結局物事がすすまないとなってしまうので、全員が重要なことに集中できるようにしてあげましょう。
Netflixの戦略的意図はストリーミングをリードするという意図をもとにやっていましたが、それを達成したら次はそのポジションを揺るぎないものにするという方向性に柔軟に変更したりもしています。
■プロダクトビジョンの方向にプロダクトイニシアティブとオプションを定める
プロダクトイニシアティブはビジネス目標をプロダクトで解決する問題に変換するものになるのですが、PdMはプロダクトイニシアティブとオプションがプロダクトビジョンとポートフォリオに一致するようにする責務があります。（ポートフォリオは複数のプロダクトを包括したものになるのですが詳細の説明は原書に譲ります）
プロダクトビジョンは、なぜあなたが作っているのか、顧客に対する価値提案が何なのかを伝えるものになります。
Amazonは1-2ページの文書にユーザが直面している問題とソリューションがどうユーザの問題解決を可能にするかを記述しているそうです。
こちらも注意点としては、ビジョンを具体的にしすぎないようにして、ユーザにとって中心的な機能だけを含めるようにしましょう。後から追加が難しい自体に陥ってしまいます。
もぐめっと的にはインセプションデッキのエレベータピッチがわりとこのプロダクトイニシアティブの例に近いんじゃないかと感じてはいます。
第三章/プロダクトマネジメントプロセス
PdMは作るべき適切なものを明らかにするプロセスを活用して何の問題を解決するか決めていきます。その時に使えるのがトヨタのカイゼンのカタから着想を得たプロダクトのカタというものが活用できます。
下記の工程を繰り返すカタになります。
1. 企業のビジョン、戦略的意図、プロダクトイニシアティブから方向性を理解する
2. イニシアティブやプロダクトの現状など目指しているものの現状を分析する
3. プロダクトイニシアティブ、オプション目標など次の目標を設定する
4. 問題の探索、ソリューションの探索、ソリューションの最適化を行って、プロダクトプロセスのステップを選択する
このカタを使うことでチームが適切な実験思考のマインドセットを持てるようになり、ソリューションではなく、問題に向き合うようになります。次からはこの４つの具体的なやり方を紹介します
■1. 方向性の理解とプロダクトの成功指標の設定
よくありがちなのが、日時のPVとかログイン数で指標をはかったりしますが、それだけではビジネスの意思決定には役に立ちません。
そこに先月よりも今月のほうがユーザ数が多いか、何か違うことをしたかといった観点で見る必要があります。
そんな指標の見方として海賊指標（AARRRモデル）とHEART指標といったフレームワークが有効です。
海賊指標はAARRRモデルとも言われ、フリーミアムモデルのB2Cのプロダクトに有効です。下記の5つの観点の指標を見ることでプロダクトの成長を見ます。
・Acquisition（顧客）：ユーザ獲得のための施策でサイト訪問客数やサインアップ客数などを見る
・Activation（活性化）：より多くのユーザに利用してもらうための工夫として、トライアルユーザキャンセル率や継続トライアルユーザ数などを見る
・Retention（継続）：獲得したユーザに継続して利用してもらうための施策として有料会員数や再訪問ユーザ数、機能利用率などを見る
・Referral（紹介）：ユーザーから口コミや紹介で広がりを作る仕掛けとして紹介ユーザー数やメディア掲載数などを見る
・Revenue（収益）：収益の最適化・最大化としてユーザあたりの獲得利益、１サービスあたりの獲得利益などを見る
ただ、AARRRモデルは最近ではちょっと古いという噂で、よしなに入れ替えをした方法（ARRRA (アーラ) モデルなど）もケースによっては必要そうです。
話は戻しまして、AARRRモデルだけではユーザの満足度は測れないのでHEART指標でユーザの満足度を計測します。下記の5つの観点の指標を図ります。
・Happiness（ユーザがどれだけプロダクトに満足したか）
・Engagement（どれだけ頻繁にプロダクトを使っているか）
・Adoption（新たに使い始めている状態）
・Retention（使い続けている状態）
・Task success（プロダクトを使って意図したことを達成するのがどれだけ簡単か）
AARRRモデルと違い、Happiness、Engagement、Task successの観点でユーザ満足度を計測できます。
■2. 問題の探索
問題を探索する方法は簡単です。ユーザと話すだけです。ここで一点気をつけてほしいのが、ユーザー調査とプロダクトを触ってみせてユーザに操作してもらうようなユーザビリティテストと混同しないようにしてください。ユーザビリティテストは簡単にソリューションが使えるかどうかを確認するものになります。
解決したい問題を発見するために、多くの人にインタビューをして仮設が正しいかを検証するためにユーザと話して根本的原因を探る事にフォーカスを置いた問題ベースのユーザ調査を実施するようにしましょう。
よくあるミスとして、ユーザから〜〜の機能がないからほしいといった、機能がないことを問題であるとしてしまうことに気をつけてください。
自動車を普及させた立役者、ヘンリー・フォード氏の言葉として下記のようなものがあります。
もし顧客に、彼らの望むものを聞いていたら、彼らは「もっと速い馬が欲しい」と答えていただろう。
交通手段が馬車だった時代、自動車を知らない人々は、早い馬を求め、「自動車をつくってくれ」とは言うことはなかったでしょう。
客が欲しいと言う物ではなく、自分が欲しい物、客に欲しいと思わせるものを自分で考え見つけることが重要です。
■3. ソリューションの探索
問題がわかって仮設をたてられたら実際にその仮設が正しいかを実装する前に実験をしてソリューションを探していきます。やり方としてはコンシェルジュ、オズの魔法使い、コンセプトテストの３種類を紹介します。
・コンシェルジュ
システムの代わりに手動で価値をユーザに提供する実験で、ユーザは手作業で価値が提供されていることを知っています。
この方法のメリットとしてはシステム作らなくていいので安価に実験でき、多くのフィードバックをうけることができます。
・オズの魔法使い
コンシェルジュと違い完成しているように見えるが実体はハリボテのような状態で裏側は人が手動で動かしているようなシステムで実験をします。
例としてはwordpressでECサイトを立ち上げて、裏側では人が手動で商品を送るみたいなやり方です。
日本でもbotサービスを作りたいとかなったときにもLINE@を使えば似たようなサービスを検証することができるかなと感じたりもしました。
・コンセプトテスト
LPやワイヤーフレーム、プロトタイプ、サービスの動きを示す動画など色々方法があります。ここでの目的はアイデアをできるだけ軽量なやり方で説明し、ソリューションが問題を解決するかをユーザに訪ねてフィードバックをもらうことになります。
Dropboxのニーズ分析の仕方がいい例で、彼らは3 分のデモ動画を作ってそのニーズを分析することでDropbox作成に踏み切ることができました。
■4. ソリューションの最適化
実験を繰り返すことでプロダクトビジョンが明確化していきます。
プロダクトビジョンの方向が決まったらストーリーマッピングと北極星のドキュメントをもとにコンテキストと実行する作業を全員理解しているかを確認して、バージョン1を目指して実装をしていきますが、バージョン1に至るまでには優先順位を決める必要があります。
やり方はいろいろあるが本書では遅延コストの定性的評価をおすすめしています。
cf: Qualitative Cost of Delayより
緊急性と価値を組み合わせてインパクトがわかって優先順位をつけれるようになる手法になります。
例えば下記のようなケースで考えます。
・最初のリリース：リリースから得られる価値の総量とリリースまでにかかる時間のトレードオフを考慮して、最大の価値を得られるようにスコープを削る
・緊急性が高い場合：機能を顧客にリリースしなければ目標を達成する機会が失われたり、顧客のニーズを満たしておらず、毎週顧客や収益が失われていくような状況は緊急
・高価値の場合：顧客の一番大きな問題を解決したり要望を満たしたりしている
最近イーロン・マスクのロケット製造の記事がバズってましたが、本当に無駄なものをつけがちなので最初のリリースにあたっては無駄なものはガンガン削ぎ落としていく必要があります。削ぎ落とす時に遅延コストを使うことでより削ぎ落とす基準というのをつけることができるようになります。
第四章/プロダクト主導組織
いよいよ最終章です。
プロダクト主導組織とはアウトカム中心の組織文化になっていて、アウトカムに応じて戦略を評価するリズムを企業が持っています。
コミュニケーション、文化、方針、報酬などについて本書では語っていますが細かいところの説明は本書に譲って、今回はコミュニケーション、安全と学習・顧客中心主義に絞って解説します。
■アウトカムに着目したコミュニケーション
リーダーがチームの現状を理解できればチームに実行を任せるようになりますが、進捗を隠すと知識のギャップが大きくなってリーダは情報を要求しだし、そうするとチームが問題の探索にかける自由時間がなくなってしまいます。
それを防ぐために4半期ごとのビジネスレビュー、プロダクトイニシアティブレビュー、リリースレビューを定期的に行って、それぞれに応じて進捗を伝えます。
ビジネスレビューは、戦略的意図とアウトカムについて財務的な観点で進捗を議論します。最高プロダクト責任者とプロダクト担当VPはプロダクトイニシアティブのアウトカムがどれだけ戦略的意図を推進できたかを伝えます。
プロダクトイニシアティブレビューは、CPO、CTO、プロダクト担当VP、PdMが参加して、プロダクトイニシアティブに対するオプションの進捗をレビューし、戦略を調整します。PdMが実験・調査・リリース結果について伝えてフィードバックを受けます
リリースレビューは、チームの成果を見せて、成功指標について話す。機能リリース前に何がリリース予定なのかを紹介するので毎月やるべき。実施済みの実験・調査ではなく、リリース予定だけを紹介する。
もぐめっとも参画しているラグナロク株式会社では毎週今週作った機能を紹介する時間を設けており、これを実施することで現在の進捗や、同時にリリース前のバグや仕様漏れなどにも気づくことができるのでとてもおすすめなレビュー方法となります。
ただ、現状作った機能に関して指標がどうなったかなどを見る文化はまだできていないので今後の課題だなと感じてはいます。
■安全と学習
会社に安全が保証されてないとイノベーションはおきません。失敗の自由を与えれば早い段階から低コストで失敗でき、取り返しもつくようになります。
本書では各種マネージャの方々へ考え方やアクションを紹介しています
・PdMへ：メッセージをどうやったら上司に伝わるか、新しいやり方で仕事をすることでどうやったら信頼得られるかを考える
・マネージャーへ：新しい働き方の有益である可能性に目を向け、PdMに実験範囲の境界を作る手助けをできるようにする
・幹部へ：どうやったらみんなが学習できる安全な場所を作れるかを考えてください
信頼と安全の話にはspotifyにも通じるものがありますが詳細に関しては小生のnoteを御覧ください。
■顧客中心主義
プロダクト主導になるには学習を促し、それに報いる文化に加えて顧客に焦点を当てる文化が必要です。
amazonの例として、amazonの目標は地球上で最もお客様を大切にする企業であると公言し、実際に実施もしています。
どの立場や職業にも言えることですが、顧客の立場になって、どうすれば顧客が喜んでくれて、ビジネスを前にすすめることができるかを自問しましょう。
素晴らしいプロダクトをつくるためにできるいちばん重要なことは顧客を深く理解すること。それこそがプロダクト主導の核心になります。
まとめ
プロダクトマネージャーが、ビジネスと顧客を理解して価値を生み出す見極めをしてチームの生み出すアウトカムを決め、
企業のビジョンと経済面でのアウトカムを結びつける戦略を作って企業全体に展開することで企業の方向性を決め、
適切な方法でユーザの課題に向き合って素早くアウトカムを出し、
組織全体でアウトカム主義で進めて戦略を立てて、評価し、ビジネスを進める
上記を繰り返すことでビルドトラップから抜け出せます！
そのためには組織ごと顧客主義のアウトカム主義になろうというお話でした。
もぐめっと的補足とアクション
実際にプロダクトの運用をしてみると中々顧客の立場に立って本当の欲しいものは何かといったことを探るのは非常に難しいです。
そのため、わりとユーザの足りないといった意見やアイデアベースで仮設で進みがちになってしまうので、プロダクトにフィットしたフレームワークを元に指標や仮説検証をできるようにしていく必要があり、本書の知識だけでは全然足りないので別途勉強しておく必要があります。
また、一度プロダクトが走り始めると今回紹介したコンシェルジュやオズの魔法使いといったプロダクトの検証は出来上がってるものベースになってきて実施しにくいものもあるのでやり方を数をこなして考えていく必要もあるなと感じています。
そこで、もぐめっとのおすすめアクションとして2つ紹介します。
■今作っている機能が何の指標を目指しているかを確認する
今一度開発しているものに対して指標を確認してみましょう。そうすることでなぜその指標を選ぶことになったかということで核心についても触れることになるので全体像も見えるようにもなり、その後の作った機能に関してもフィードバックを見れるようになるのでプロダクトも推進するはずです。
■実装前に検証できないかを考える
大きい機能を作るときとかに特に検証の必要性が増していくのですが、せっかく作っても使ってもらえなかったら意味がありません。本当に顧客の価値に届けることができるかどうかを実装する前に代案として少ないコストで検証する方法をチームで一度考えてみるといいかもしれません。
そうすることで失敗を少ない形で抑えることができるはずです。
あなたが開発しているものは間違えているたった一つの理由
ここまで読まれたのでしたらタイトルの質問の「あなたが開発しているものは間違えているたった一つの理由」は何だったかわかりましたか？
そう、それは顧客価値に真に向き合っていないからなのです。
あなたが作っているものは本当に顧客に役に立ちますか？
御アウトカムありがとうございました。
最後に、ワンナイト人狼オンラインというゲームを作ってます！よかったら遊んでね！
他にもCameconやOffchaといったサービスも作ってるのでよかったら使ってね！
また、チームビルディングや技術顧問、Firebaseの設計やアドバイスといったお話も受け付けてますので御用の方は弊社までお問い合わせください。
この記事が気に入ったらサポートをしてみませんか？