日本語
スタートアップでのプロダクト思考
新機能を開発する必要があるかどうかを判断する方法。
Guamian
Product & Design
Product & Design
新機能を開発する必要があるかどうかを判断する方法。
2021年には、大手企業の製品デザイナーとしての仕事から、スタートアップチームの一員となるLogtoに移った。
ここでは、製品とデザインの両方を手がけています。この新しい役割は、プロセスと協業方法が明確な大手企業での経験とはかけ離れています。さらに、私の最も近い共働者であったプロダクトマネージャーがいなくなった。その結果、製品、デザイン、リサーチ、マーケティング、さらには自己プロジェクトマネージメントなど、さまざまな役割を担うことが求められています。
私や私のチームは、特定の製品機能を実装するかどうか、その範囲をどう定義するかという議論に多くの時間を費やしています。
このような状況では、私たちは皆、情熱的に関与し、自分の意見を積極的で固有の態度で表現します。その視点は、一見、複雑な機械が生み出した混合物のようにみえます。文書に書き留めておくのとは違って、整理や規律が欠けています。
これは、"直感"が構造化された表現よりも先にしばしば現れるためで、結果として哲学的な戦いになる長々とした議論が発生します。
本記事を書く動機は、意思決定のガイドラインを整理することです。これらの原則は、スタートアップ環境での私の個人的な経験と反省から生まれており、銀の弾丸のようなものではありません。私は、同じような起業家や製品、エンジニアリング、デザインに関わる人々に、インスピレーションや視点を提供したいと思っています。
以下の状況であれば、この記事を読むのに良い
✅ 0から1への製品開発に向けてスタートアップチームを立ち上げたり、特に国際展開を目指すGTM（Go-To-Market）戦略を考えたりしています。
✅ 10から100への製品拡大には、製品ロードマップの確立が必要です。
✅ プロダクトリードや計画責任者は、機会をすばやく見つける方法を学びます。
✅ ICsは、大組織内で新たなイニシアチブを推進する方法を身につけます。
以下の状況の場合、この記事を読むことは推奨されません
❌ リーダーやエグゼクティブが上から下に立ち上げた曖昧なプロジェクト。
❌ 事業目標から遠く、個々または独立チームの影響力を検証するために狙ったプロジェクト。
❌ 大口顧客を主な対象とした、高度にカスタマイズされた製品要求。
組織の規模にかかわらず、リソースは限られているため、私は絶対的な観点から集中を保つことを常識と考えています。
ここでのリソースとは、金融資源だけでなく時間も指します。時間の観点では、スタートアップチームと大企業は同じフィールドに立っていると言えます。
ほとんどの場合、私たちは、目標とするユーザーのニーズと顧客ペルソナと一致する、スケーラブルで必要な機能を作成することに注力すべきです。製品は「難病」ではなく、「ビタミン」であるべきです。
集中力を維持することで、製品の価値提案を明確にし、顧客理解を向上させることがより容易に、自然なことになります。製品は着実にそのビジョンに向かって進んでいき、問題解決のスペースを健全に拡大していき、有機的な成長を促進します。
すべての問題を解決する必要はありません。「この機能を開発する価値があるかどうか」についてのさまざまな「信号」を書き留めてみましょう。
この概念、「表面的な信号」は、参照として役立つものの決定を下すまでにまだ道のりがあるという浅い信号を表しています。
私自身、最近は政治学の学習を楽しんでいますが、比較する方法は政治分析に似ており、「可能性」を得ることを目指しています。この広い視点を持つことで洞察を得ることができるため、現在のコンテクストでは、さまざまな製品の学習が意味を持つことになります。
しかし、競争者分析に過度に頼ると、戦略的思考が欠けた製品決定につながる傾向があります。競争相手が特定の機能を導入していない理由を考慮することが必要です。それは彼らの価値観、ターゲットユーザー、戦略的優先順位、リソースに一致していないのでしょうか？
したがって、競争分析は絶対的な意思決定を提供するものではなく、意思決定のための情報収集プロセスの一部であるべきです。
ユーザーパースペクティブの理解とシナリオの推理に長けている製品の専門家は、新しいシナリオを迅速に検証するか発見することができます。しかし、これはあくまでも一つの提案であり、現実の市場展開環境でのさらなる作業が必要となります。
可能性のあるシナリオを推測することは価値がありますが、このアプローチにのみ頼ることは製品が市場適合性を達成する前に、「オールインワン」または煩雑な製品を作り上げることにつながり、その後の反復的な調整や適応が難しくなる可能性があります。
シンプルな例え話をするなら、推測したユーザーシナリオそれぞれを0-1のスタートアッププロジェクトと見なし、ミニ市場導入戦略を考え、マーケティングの視点を取り入れ、困難な質問をするということです。この多面的な評価は、ユーザーニーズと体験を超えたものです。
しばしば、ハイフリークエンシーユーザーフィードバックは、機能開発と製品設計の指針となります。しかし、この指針が時折落とし穴になることもあります。私が成長し、より多くのプロジェクトに関与するにつれて、ユーザーフィードバックを扱い、対処するためのフレームワークを設けるようになりました。
1。問題を定義し、自分をゆさぶり、_何度も何度も_フレームワークを再構築する
この過程には、多くの熟考、往復、議論が含まれており、多少の時間と労力を必要とします。このプロセスが無意味だと思わないでください。なぜなら、その議論を通じて、「氷山の一角」の問題が発見され、広がっていくからです。私のチームと私は、何が正しく何が間違っているのか、そして潜在的な解決策については容易に長く論争することがありますが、これは良いことではありません。現在では、私たちは、問題が何であるかを識別するところに多くの共感を持つようになり、問題解決に焦点を当てています。このプロセスは非常に価値があります。
2。Opinionのある vs. Opinionがない
この機能/シナリオはOpinionのあるアプローチでも、Opinionがないアプローチでも、どちらでも良いことを定義することは超必要です。例えば、NotionはOpinionのあるプロダクトで、Google DocsはOpinionがあるようなもので、Microsoft WordはOpinionがないです。舊的なパラダイムを刷新することを目指すSaaSメーカーとして、Opinionのあるアプローチを採用することがベターです。Opinionのある製品はユーザーを区別し、フィルタリングし、それに賛同する人々は熱狂的にその支持を表現します。これは初期段階の製品がシードユーザーを見つけ、易しいストーリーテリングを作成するのに非常に有用です。
Opinionのあるアプローチを採用する場合、1つの解決策だけで問題を解決しようとしてください。代替解が生じた場合（シナリオAに対する解決策B）、解決策Aが真に痛みの点を解決しているかどうかを考えてみてください。もしそうでないなら、再び解決策Aを見直すべきかもしれません。ふたつ目の解決策は単に導入するだけではありません。
このアプローチに影響を与えたIntercomの製品原則は次のようなものです。「デフォルトでOpinionのある製品を作り、柔軟性を持たせる。」
3。ユーザーが高度なJob-to-be-doneを提案することを認識する
一部のユーザーは、Scenario Bを解決するためにScenario Aの機能を使用することを提案するかもしれません。これらの落とし穴を見つけることは重要であり、価値のない問題に過度のエネルギーを投げ打つべきではありません。
注意に値する唯一の状況は、Solution Bが真の需要を示しているときです。これは、Solution BがSolution Aへの代替ではなく、製品のビジョンとミッションに密接に関連した「新しく生まれた問題」を解決します。これは企業がさらに成長したいと思い、次の大きな拡大フェーズを発見するときに価値のある信号となります。
製品を複雑にすることを避けるというのは、困難な問題を解決することを無視するという意味ではありません。それはむしろ、現実世界では、「複雑で万能な」製品と「シンプルでユーザーフレンドリーな」体験との調和をとることは非現実的なことを思い出させるリマインダーです。すべてがどのように動作するかを無視して（システム思考）分断されたユーザー体験の問題だけに焦点を当てて修正を行うと、結果として設計が悪い製品になります。
複雑な製品は連鎖反応を引き起こし、セルフサービスが難しくなり、製品の価値を見出すのに時間がかかるようになります。
ビジネス（2B）のためのツールを設計することはある意味で哲学的なものであり、ユーザーと並行してメンタルモデルを作り上げることや、ユーザーの行動を予見することができる構造を確立することを含んでいます。複雑さは、一貫性のない脱構築された設計から生じることが多く、インタラクションを組み合わせて要求を満たそうとするために、製品は「生存主義者」のようになり、素晴らしいユーザージャーニーを提供することはできません。
製品を複雑化する特徴は、要求から解決策まで、すべてが悪い信号です。
これがあなたに具体的に「No」と言える手助けとなるわけではありませんが、明確なトレードオフが求められる重要なポイントです。
言い換えれば、製品のポジショニングと一致しない特徴を作ることは、製品のイメージを損ない、曖昧にすることです。例えばLogtoは、現在のところはアイデンティティ管理に焦点を当てた開発者用ツールです。私が、「マーケティングツールの機能を作ろう」と言うとします。これは悪い戦略です。
この視点は、企業または組織のビジネス目標から導かれるものです。私は企業や大企業の環境で行われる多くの活動を見てきました。例えば：
これらのシナリオは、比較的安定した運用状態では価値があるものであり、推奨され、支持されるべきです。しかしながら、難しいスタートアップの環境では、これらのプロジェクトは大量のリソースと時間を必要とし、価値を検証するのに時間がかかることが示されています。このことは、専門的な追求ではなくビジネスの成功にコミットメントを示しています。この点は、個人的な追求、キャリア信念、商業目標の間のコンフリクトを強調しています。
プロジェクトを積極的に立ち上げることは称賛に値しますが、何かに過度に献身的であることが必ずしも価値のあるリターンをもたらすわけではないことを認識することも重要です。ハンマーを使って釘を打ったり、定規で深さや半径がどれだけあるか測ったりすることを示しているかもしれませんが、これは全体的な計画ではなく、本当に必要でしょうか。実際には、私を雇って釘を打つ人はただ絵を掛ける方法が欲しいだけで、私が釘を打つ技術がどれだけ上手いかを証明する必要はありません。
この抽象的でありながら重要な観点は、具体的に評価することができます： フィーチャーを検討するとき、製品がそれを持っていないとユーザーが大幅に失望し、それが彼らが去る可能性のある要因となるかどうかを尋ねます。 例えば、現在のLogtoの製品ポジショニングという観点から考えて、認証、承認、ユーザー/組織マネージメントの課題を解決することを目指しています。フィーチャーがこれらの側面に関連しているほど、その優先順位は高くなります。もしLogtoが特定の機能を持っていなかったら、ユーザーたちはどれくらいがっかりするでしょうか？返答がyesであれば、それは優先度が高く、そして私たちのミッションは、この課題に対する優れた開発者体験を提供することであることを示しています。
シリコンバレーでは、実用性と厳密性から、ユーザーリサーチと機会サイズの評価がしばしば強調されます。これらの２つの観点は、フィーチャーが探索と開発に値することを示しているときに、ポジティブな洞察を提供します。
この概念は、少ない労力で大きな喜びをもたらし、製品の個性やブランドの一部となる低リーチフルーツを示しています。
すべての分析の中で、理性的な考え方が必要ですが、直感に余裕をもつことも重要です。「もし、あなたがフィーチャーが未来であり、理性的なデータやマーケットの検証が欠けているにもかかわらず、それに確信を持っているなら、それは探索する価値があります。」
他の不明確なフィーチャーについては、それらが自然に発展し、時間をかけて「信号」を観察することができます。
製品開発や起業、製品の職務面接を通じて、特にシリコンバレーのような場所では、私たちがこの機能を作るべきかどうかという問題について多くの思考を刺激する質問に出会うことがあります。これらの質問は大きくて曖昧な問題を具体的な回答に分解するという能力は、ビルダーがキャリアを通じて洗練するスキルであり、素晴らしい製品を作るための超能力です。
私は、提供された洞察がスタートアップでの製品思考のアプローチに触発を与えることができることを願っています。Logtoでは、開発者が愛する製品を作ることを高く評価しています。私たちは同様のトピックについての自己紹介と視点共有を喜んでいただきます。