バックログのサイズは、顧客と話す頻度に反比例します。

ここ 1 年は空き時間をすべて仕事に費やしていたので、あまり書いていませんでした。 私が始めたベンチャー コミックのイベントおよびチケット管理サービスを提供します。 数万枚のチケットが販売され、他の顧客を紹介する顧客も満足しており、比較的成功しています。 この投稿は、今回の学習の一部をまとめたものです。 これらは決して網羅的なものではありませんが、この怠惰な日曜日の朝に私の頭の中にあるものにすぎません。 これは、1年間冬眠していた後、クモの巣を破って執筆している私です。 我慢してください。

他のものと同様、これらは絶対的な真実ではありませんが、私の経験から生まれました。

ロードマップの計画や作成に時間を費やす代わりに、現在の顧客または潜在的な顧客と彼らの生活をどのように改善できるかについて話し合い、それによって次の機能を決定することに置き換えてください。 ソフトウェアを使用する実際の顧客を開発プロセスに参加させることが、価値を生み出す鍵となります。 開発者と顧客の間にプロキシが増えるほど、製品が顧客のニーズを満たせなくなります。

バックログが大きくなればなるほど、検証されていない仮定が多くなり、顧客価値を生み出す可能性が低くなるため、バックログを大きくしても意味がありません。 誰も気にしていないのに、何かが価値があると思い込んで、私はあまりにも多くの間違いを犯してきました。 大規模な未処理の案件は、非常に懐疑的な見方をする必要があります。 バックログのサイズは、顧客と話す頻度に反比例します。。

計画の時間は、何を構築するかではなく、機能を構築する方法に重点を置いて使用するのが最適です。 ソフトウェア開発プロセスでは、顧客への直接の物理的な回線が必要であり、プロキシは必要ありません。顧客から直接提供されるべきものです。

UI の設計にはあまり時間をかけないでください。バックログと同じように、UI には仮定が蔓延しているからです。 顧客がアプリをどのように使用するかについての現在の理解を活用した基本的な UI をすぐに入手できます。 による 基本を守って、それは60％正解であり、必要なのはそれだけです。 残りの部分は顧客からのフィードバックを通じて磨きをかけることができます。 UI をデザインできないと思っていても、できます。 私たちは皆、消費者向けアプリを使用しており、20 年前よりも UI がどうあるべきかにずっと慣れています。

そのフィードバックの実装は、UI コードがどの程度適切に設計されているかによって決まります。ワイヤーフレーム/ビジュアル デザインではなく、適切なコンポーネント設計に重点を置くと、十分な時間がかかります。 UI 顧客からのフィードバックを実装する製品の能力は、製品の初期 UI よりも重要ですが、私たちは前もって重い設計をし、後者に焦点を当てすぎてしまう傾向があります。 変更が容易な UI では、小さなコンポーネントと低レベルの再利用性が重要です。

技術的負債を低く抑えることで、顧客が必要とする変更を加えることができます。 速度は技術的負債の関数です。

顧客がアプリを使用しているときは、必ず観察するようにしてください。 私が使う ポストホッグのセッション リプレイ機能を使用しており、私が考えている製品の使用方法と比較して顧客がどのように製品を使用しているかをビデオで見て驚きました。 必要なすべての指標を追跡できますが、ユーザーが何かを見つけようとして上下にスクロールしたり、戻るボタンを押したり、待ったり、クリックできないものをクリックしようとしたりする様子は、何か非現実的です。これらの定性的測定は、ほとんどの人が追跡する定量的な尺度。

私はこれをその接線として見ています ハイラムの法則そして、大胆にも当然の結果を提案できるとしたら、次のようになります。 クリックできないように意図したものがクリックされてしまいます。 ここで問題となるのは、ユーザーがクリックした意図は何だったのかということです。

特定の顧客が本番環境で何を確認しているのか疑問に思う場合があります。 これをテスト環境で再現しようとしても意味がありません。 代わりに、アカウント スプーフィング、つまり、管理者ユーザーが特定の運用ユーザーであるかのようにアプリを使用できる機能に多額の投資を行います。 これにより、テストが容易になり、問題を効果的に診断できるようになり、常にある程度の信頼性の低いテスト データの必要性が減ります。

スプーフィング中はすべての書き込み操作 (支払い方法の更新など) を実行できるわけではありませんが、ほとんどの操作は読み取りであり、書き込み操作でさえ元に戻すことができます。 これを怖がらせる必要はありません。受け入れてください。

顧客がアプリにアクセスしたときに最初に目にするものは、その顧客にとって最も関連性の高い情報であり、コンテンツはまばらである必要があります。 1 ページ目にあまりにも多くの内容を詰め込みすぎる傾向は、認知負荷を増大させ、潜在的に大きな出発点を無駄にする可能性があります。 ここでのエンゲージメント数がどのようなものであるかについて、さまざまなタイプの実験を実行することは、時間をかける価値があります。 ユーザーが 1 ページ目のメニューに手を伸ばしている場合は、UI に問題があります。

それでも NPSには批判もある, 顧客があなたの製品に対して自分の評判を賭けるほど強く感じているかどうかを示す良い指標であることがわかりました。 私たちは皆、いつかは広告費を費やす必要があるかもしれませんが、そこから始めるべきではありません。 各顧客を満足させて他の顧客に製品を勧めてもらうことは、完全に堅実なマーケティング戦略です。 これにより、粘着力のある顧客を生み出す可能性も高くなります。 Airbnb ブライアン・チェスキーが語る:

「100 万人があなたに好意を寄せてくれるよりも、100 人があなたを愛してくれている方が良いのです。だから、あなたの製品を気に入ってくれる 100 人を見つけることができれば、同じような人が世界中にもっとたくさんいる限りは。」

私は強く信じています 社会的証明 粘着力のある顧客を生み出すことができるため、大規模な顧客ベースに網を掛けるよりも、少数の顧客を満足させて製品を推奨し続けることに重点を置くことが、健全な戦略的決定であることが判明しています。 また、お客様の幅広いリクエストに応えて優先順位を付けるのではなく、より少数のお客様に当社の製品を気に入っていただくことに注力できるようになり、より集中力が高まりました。

この図 私にとっては MVP の終わりでした。 このコンセプトが促進するはずだった俊敏性とフィードバック ループは、誰も同意できなかった他の 4 つの構成要素の一部として文脈化されたときに、私にとっては消滅しました。

MVP は、ほとんどの組織が MVP を使用しているように、日付のプレッシャーに直面して手を抜いて、質の悪い顧客エクスペリエンスを提供する言い訳にはなりません。 これは、別の反復が必要かどうか、必要な場合はどのようなものになるのか、という具体的な質問に答えるためにあります。 この質問はめったに尋ねられず、ましてや答えられることはなく、その結果、メリッサ・ペリーのような質問が生まれました。 フィーチャーファクトリー。

MVP を次のように定義すると役立つことがわかりました。

MVP は、次のことを教えてくれる機能として十分です。

• これには投資を継続するのに十分な顧客価値があるでしょうか?

• この機能を拡張したい場合、技術的な実装を改善する必要があるのは何ですか?

• この機能は私たちの重要な目標に影響を与えるのでしょうか、それとも気を散らすものでしょうか?

これらの質問は、本番環境に何かを出荷することなしには答えることができません。 何ヶ月も続けて計画を立てて戦略を立てても、答えには一歩も近づきませんでした。 ユーザーの前で実稼働状態にする必要があり、「リリース」が最終状態になることはほとんどありません。