`Inspired: 顧客の心を捉える製品の創り方` を読んだ

読んだ本

Inspired: 顧客の心を捉える製品の創り方

気になった部分をピックアップ

第6章:プロダクトマネージャの条件

技術の進歩は急速なので、プロダクトマネージャーは、新しい技術を短期間で身につけることや、新しい分野で問題の解決に取り組むことが得意でなければならない。私がプロダクトマネージャーの候補者をインタビューするときは、すでに身につけているものは何かを見るのではなく、今までやってきた製品開発で、何を学ばなければならなかったか、学ぶのにどのぐらいの時間がかかったか、そして、身につけた知識をどのように活用したかを見るようにしている。

Engineer出身であると必然的にクリアしなければならない課題なのでEngineer的思考が十分に生かせるなーと感じた

第7章:プロダクトマネージャを管理する

ネットプロモータースコア(NPS)

ネット・プロモーター・スコア - Wikipedia

普段ネットサービスを使っててよく出てくるアレである。この指標がプロダクトマネージャの評価基準になりえるのは初めて知った。コレ系はSaasとして取り入れたいなぁーと感じた。でもあまり世の中に無い気がする。

すべてのユーザが直感的に回答できるし、回答内容も全社的に共有して問題無いし、やるべきだなーと思った次第。

第11章:製品の市場性評価

顧客を理解するという点からは、財務部門が持っている情報はものすごく役に立つのだ。 財務部門の人間というのは、だいたいはかなりもの静かであり、プロダクトマネージャーのデスクまでやって来て製品機会について説いたりするようなタイプではない。だいたいは、プロダクトマネージャーのほうが、彼らのところに出向かなければならない。

この本を読まなければ気づかなかった視点でした。財務部門で扱うデータは提供しているWEBサービスでは出てこないが、とても情報の信頼度が高いものが集まっている(支払状況・今までの取引の記録・信用度等々)。顧客を理解する上ではとても有効な情報だなーと思った。

何に活かすという明確な形にはなりづらいけど、頭に入れておくという意味で良いと思った。

また、人のタイプ的にプロダクトマネージャーからアクションすべしという所も納得感あった。

第13章:製品理念

プロダクトマネージャーは、意思決定のプロセスと理由付けをみんなに完全に見えるようにしておくことだと思う。プロダクトマネージャーは、直感だけに頼っているとチームのみんなから思われるようではダメだ。プロダクトマネージャーの設定した目標と目的、それらの優先順位、プロダクトマネージャーがそれぞれの選択肢をどう評価したか、といったことについては、チームのメンバー全員にわかるようにしておかなければならない。

議論が紛争している時こそ、決断しなければいけなし、決断したら100％その決断にコミットをみんながしなければいけないし、でもそこにはある程度の納得感が必要。その一役に見える化しておく事。

普段からわかりきった事でもなるべく丁寧にプルリクに説明やら背景やらを書くことにしてレビューしてもらっているが、同じことだなぁーと感じた。

第15章:ユーザモニター制度

プロダクトマネージャーは、ユーザーとの面談、ユーザビリティテスト、ユーザーモニター制度での打合せなど、自分が担当する製品に直接関係のあるものなら何であっても出席するべきだ、と私は思っている。

当たり前だけど専任でやる前提での話。ユーザに直接ヒアリングできる機会ほど有効な時間はなし、関連するMTGに参加して洞察力を磨く事も重要だなと思った。結局参加するMTGに意味があったが無かったなどは臨む心構えで変わったりする時ある。

第18章:製品仕様はどうあるべきかを考える

製品仕様の大半は、ハイファイプロトタイプとするべきだ。

Sprintを区切ってやるべきだし、何度も作り直し前提だし、デザイナーを含めた実際に手を動かせる開発者をいかに早く巻き込めるかが重要かもしれない。

早く巻き込む事で生じる人件費等のコストは必要経費だし、そうしないと良い製品開発はできないという事なんだと思った。最近だとハイファイプロトタイプを支援するツール類も充実してきているし、前よりも低コストで実現可能だと思うのでやるべきですね。

第21章:製品仕様の検証

フィージビリティ(実現可能性)の検証

ユーザビリティ(使いやすいかどうか)の検証

価値(買いたいと思ってもらえるかどうか)の検証

特に目新しい内容では無いけど、やっぱり基本的な部分なので改めて大切だなと思いながら読んだ

第29章:大きい会社でもイノベーションは不可能ではない

私が知る限りでイノベーションを起こすいちばん手っ取り早い方法の1つは、実際のユーザーが自社の製品やライバルの製品を使ってみようとするところを、じっくり観察する(そしてユーザーの話に耳を傾ける)ことである。こういう観察を何回かやれば、ユーザーの不満や期待のパターンが見えてくるだろう。

自分たちのプロダクトではなく競合他社のプロダクトを使ってるところを観察するの事の重要性はこの本で初めて知ったし、低コストで実現できるなーと思った。

ひたすら自分たちのプロダクトについて色々と考えていたけど、競合他社のプロダクトをうまく使うことは考えつかなかったなぁ

第32章:特別仕様には要注意

特別仕様の何が悪いのだろうか？製品を作る会社は、顧客の要求をあるべき製品要求と取り違えることで、まず間違いなく道を踏み外す。

この言葉の理由には下記3つ簡単に記されていた

• 顧客にとっては、実際にそのものを目にするまでは、自分が何を必要としているのかを理解するのはとても難しい
• 顧客はどんな技術が可能であるかを知らない
• 顧客は共通のテーマを確認するために顧客同士が交流することはめったにない

特別仕様を飲み込めば大口の契約という目の前のメリットに惑わされることなく、常に本質を求めて行かなけれいけないなぁーと感じたけど、実際の経営者の立場からすると会社の経済状況が思わしくないと色々と考えが存在するだろうなと感じた。

CEOレベルの明確な意思表示が必要とも書いてあったけど、会社としての意思決定レベルの話ですね。

個人向けインターネットサービス製品で大切なこと

でも、顧客サポートの費用を抑えることが大事なのではなく、サービスを利用する顧客にすばらしい体験をしてもらうことが目的なのだ。

最近はカスタマーサービスに力を入れる企業も当たり前に増えて来たし、また改めてZappos.comの本を読みたくなった。日本の企業でも従業員の7割がカスタマーサポートの企業もあるし、サポートエンジニアの重要性も高まってきていると個人的に感じているし、そーいう流れなんだろうなと。

最後に

読みやすい本でした。いろいろな人が読める本だと思った。