プロダクトとは何か?

この記事は、へそ曲がりのようなものではないことをお約束します。 これは、重要かつ基本的なトピックに関する非常に現実的な記事となります。

*この記事は「What is a Product?」を、著者の了承を得た上で翻訳したものです。

著者: Marty Cagan
翻訳者: 渡辺圭祐

権限を与えられたプロダクトチームに関する以前の記事が人気を博した結果の1つは、プロダクトに関して混乱しているいくつかの重要な領域が明らかになったことです。

プロダクトとは何かという一般的な話題には多くの重要な側面がありますが、この記事では、真に機能横断的なプロダクトチームであることが、単なる業界の流行語ではなく、なぜ非常に重要なのかについてお話したいと思います。

少し背景を説明すると、プロダクトが初めて説明されたとき、私は非常にエンジニアリング中心の会社(HP Labs)でエンジニアをしていました。 もしあなたが何らかのエンジニアでないなら、一般的に頭でっかちだと思われていました。 デザイナーでさえ、自分のことを「ヒューマンファクターズエンジニア」と呼んでいました。

私がテックリーダーとしての指導を受けていたとき、エンジニアリング・マネージャーは、実世界に向けたプロダクトを作るときにはエンジニアリングだけでは不十分であることを理解するよう求めました。 彼はホワイトボードに、非常にシンプルですが重要な方程式を書きました。

プロダクト=カスタマー×ビジネス×テクノロジー

そして、成功するテックプロダクトは、顧客の課題を解決し、我々のビジネスの課題を解決し、技術の課題を解決しなければならない、と説明したのです。

この方程式は、テックプロダクトにおける4つの大きなリスクに対応しています。ユーザビリティ・リスクへの対応は、顧客に対するソリューションの一部であり、実現可能性リスクへの対応は、技術に対するソリューションの一部であり、事業実現性リスクへの対応は、事業に対するソリューションの一部なのです。 そして、価値リスクは、この3つすべての関数です。

さらに、この3つのうち1つでも対処できなければ、結果(プロダクト)は失敗に終わることを指摘しました(数学が苦手な人のために、ゼロの何倍でもゼロである)。

そして、ビジネスを解決するプロダクトマネージャーの役割、顧客を解決するデザイナーの役割、そして、技術を解決するエンジニアの役割について、私はすでにかなり熟知していると説明しました。

さらに、この3つの領域は深く絡み合っていると説明しました。

技術的な決断は、デザイナーができることに(良くも悪くも)劇的な影響を与えます。 同様に、デザイン上の決定は、ビジネス上の考慮事項に大きな影響を与える可能性があります。 そしてもちろん、ビジネス上の制約は、デザインやテクノロジーの選択肢に影響を与える可能性があるでしょう。

私が技術責任者になったことで、彼は私に、私の仕事はもはやエンジニアリングだけではない、と強調しました。 私は、プロダクト・マネージャーやデザイナーと協力し、効果的な解決策を見出さなければならないのです。

願わくば、ほとんどの皆さんにとって、これが「プロダクト101」のすべてだと思います。 いずれにせよ、もうお分かりだと思います。 しかし、プロダクトの世界にいる多くの人は、そうではないと言えるでしょう。

私は常に、ビジネスモデルが全てだと考えているスタートアップの創業者やプロダクトマネージャーに会っています。 彼らは、大金を稼ぐことが確実な美しいビジネスを示す、すべて記入された(しかし検証されていない)ビジネスモデルのキャンバスを持ってきます。 価格設定、コスト構造、価値提案、市場参入戦略など、すべて考え尽くされています。 必要なのは、アプリを作成できる代理店の名前だけです。 今書いたことが大げさであればいいのですが。

また、私はあまりにも多くのデザイナー、そして一部のデザインリーダー(そして少なからぬプロダクトマネージャー)に出会いますが、プロダクトはユーザー体験がすべてだと考えています。 彼らは、顧客を満足させれば成功すると信じているのです。 そんな簡単なことならいいのですが。 彼らは、収益、コスト、販売、マーケティング、法律、プライバシーなど、経済やその他のビジネス上の考慮事項について、関心があるふりをすることさえしません。

また、プロダクト管理にも設計にも意味を見出さないエンジニアがたくさんいることも周知の事実です。

プロダクトマネジメント、ユーザー・エクスペリエンス・デザイン、エンジニアリングの各リーダーが、このプロダクトの基本的な方程式を深く理解し、プロダクトマネージャー、デザイナー、エンジニアにも積極的に指導することが絶対に必要です。

この点を強調するために、ここではっきりと言います。

もし、あなたの会社のCEOが、プロダクトマネージャーの一人または数人が、ビジネスの本当の仕組みを全く理解していないと考えたら、その人は信頼され、力を与えられる望みはほとんどないでしょう。 CEOは、この点に関してプロダクトマネージャーを判断しており、もし彼らがナイーブであるとか、もっと悪いと思われたら、その認識を覆すのは非常に難しくなるでしょう。 ですから、私は新任のプロダクトマネージャーには、絶対に下調べをする必要があると、かなり執拗に言っています。

さらに、もしCEOがプロダクト、デザイン、エンジニアリングのリーダーの一人または複数を、ビジネスの解決に何が必要かを理解していないと見なすなら、そのリーダーは重要な決定がなされるときにテーブルにつくチャンスはほとんどないでしょう。

だから、ビジネスがすべてだとか、顧客がすべてだとか、技術がすべてだとか、そんなことは言わせません。 プロダクトはそれよりも難しいのです。 この3つがすべてなのです。

この記事の原稿を手伝ってくれたSVPGパートナーのクリス・ジョーンズに特別な謝意を表します。


この記事の著者であるMarty Caganは、PMにとって有名な一冊である『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』の著者でもあります。PMについて興味のある方は、こちらからご確認ください。


Marty Caganの他の記事を読む👀

👉 Marty Cagan

フォローして最新情報をチェック!

広告

投稿者: PM Library

Cofounder and product manager at Glasp.

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト /  変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト /  変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト /  変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。