INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント [Kindle]

  • 日本能率協会マネジメントセンター
4.34
  • (16)
  • (8)
  • (4)
  • (1)
  • (0)
本棚登録 : 203
感想 : 14
本ページはアフィリエイトプログラムによる収益を得ています
  • Amazon.co.jp ・電子書籍 (396ページ)

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • プロダクトマネジメントで必要な視点が記載されている。
    実践というよりも、プロダクトマネジメントの組織、文化を作っていくにあたり必要になる印象をもった。

    読んでいる最中に仕事で考えていて、開発組織の今後の作り方に対して参考になったのは以下の箇所。

    ch64.良い製品開発チーム/悪い製品開発チーム
    ・良い開発チームは人を魅了する製品ビジョンを持っていて、伝道師のような情熱でそれを追求する。悪い開発チームは傭兵である。

    ---
    目次
    1 一流IT企業から学んだこと(優れた製品の背後にあるもの;ITに基づいた製品やサービス ほか)
    2 成功するための組織と人(製品開発チーム;スケールアップに必要な人々)
    3 成功するための製品(製品開発ロードマップ;製品ビジョン ほか)
    4 成功するためのプロセス(製品の発見;発見のフレーミングテクニック ほか)
    5 成功するための文化(良い製品開発チーム/悪い製品開発チーム;イノベーションが失われる最大の理由 ほか)

  • 製品開発に取り組む人の必読書。何度も読み返したい

  • - This is the book I want to keep on my shelf and refer to whenever I get lost as a PM.
    - Very specific advice on how to test your product
    - There are a lot of processes I want to try and change after reading this book. I have never taken so many notes.


    p58
    "Fight your temptation to provide your designer with you on design ideas. Give your designer as much room as possible to solve the design challenges him or herself."
    This is one of my biggest personal challenges as a PM. Will try harder.

    "Encourage your designer to iterate early and often. The best way you can encourage this is to not get all nitpicky about design details with the very early iterations. "
    You have to adjust the level of feedback you give to different stages of prototype maturity. This is definitely not an easy game. If you go too deep too early, they'll respond, "I'm not focused on that right now. If you give it too late, "Why now?"

    p130
    "Be stubborn on vision but flexible on the details. This Jeff Bezos line is very important. So many teams give up on their product vision far too soon. This is usually called a vision pivot, but mostly it's a sign of a weak product organization. It is never easy, so prepare yourself for that. But, also be careful you don't get attached to details. It is very possible that you may have to adjust course to reach your desired destination. That's called a discovery pivot, and there's nothing wrong with that."
    The frequency of discovery pivots is critical to success. That is kind of obvious. But the vision pivot is the trickiest. There is no right or wrong answer. Some companies have had great success by starting from scratch. Others did it by continuing without giving up.

    p198
    "We are looking to develop six reference customers in our specific target market or segment, so the idea is to find six similar customers. If you end up targeting two or three customers from two or three different markets, this program will not give you the focus you want and need."
    The magic number 6.

    "I do my best to persuade teams to not launch a product in the marketplace until after they have those six reference customers. We don't want to turn on the sales or marketing machine until we have evidence that we can help them be successful, and the reference customers are our best evidence."
    This will be a major milestone for pre-PMF.

    p213
    "Who should attend. My favorite is to bring three people to these interviews: the product manager, the product designer, and one in the engineers from the team (we normally rotate among those that want to attend)."
    I have only done 1:1 interviews, one PM and one user. Will start bringing engineer/designer.

    p247
    "Explain that she won't be hurting your feelings by giving her candid feedback, good or bad. You're testing the ideas in the prototype, you're not testing her. She can't pass or fail- only the prototype can pass or fail."
    Users are too nice to give negative feedback. Saying this up front is a good idea.

    "See if they can tell from the landing page of your prototype what it is that you do, and especially what might be valuable or appealing to them."
    Instead of pitching the product, I should make an LP and show it for 3 minutes and ask questions.

    "When testing, you'll want to do everything you can to keep your users in use mode and out of critique mode. What matters is whether users can easily do the tasks they need to do. It really doesn't matter if the user thinks something on the page is ugly or should be moved or changed."
    We are looking for a problem, not a solution.

    "During the testing, the main skill you have to learn is to keep quiet. "
    Even if you try to be quiet, it's natural for the user to want to talk. It becomes uncomfortable.

    p260
    "even more important, after a usability test the user knows what your product is all about and how it's meant to be used. Only then can we have a useful conversation with the user about value (or lack thereof)."
    Problem test (interview) → Usability test → Value test (Would you be comfortable recommending this to your team?) → User test → Alpha

    p282
    "I have seen many inexperienced product managers do a walkthrough with a prospective customer when they should have prepared a product demo. Or another really common rookie mistake is to do a product demo during a user test, and then ask the user what they think. Be sure to be clear about whether you're doing a user test, a product demo, or a walkthrough."
    Very important.

    p300
    "One of the most common mistakes product managers make with stakeholders is that they show them their solution after they have already built it. And, sometimes, there are issues because the product manager did not have a clear enough understanding of the constraints.
    Not only will the stakeholder be frustrated, but your engineering team will be frustrated as well with all the rework. So, commit to previewing your solutions during discovery with the key stakeholders before you put this work on the product backlog."
    We often avoid this because we don't want to be in disagreement even before we start. But as this part says, you can probably start faster, but you will not end well.

    "The other big mistake I often see being made is when situations boil down to the product manager's opinion versus the stakeholder's opinion. In this case, the stakeholder usually wins because he or she is usually more senior. However, as we've already discussed many times before, the key is to change the game by quickly running a test and collecting some evidence. Move the discussion from opinions to data.
    Share what you're learning very openly. It may be that neither of your opinions were right. Again, the discovery work is designed specifically as a place for these tests."
    This would be the only way for a PM to convince the team, since you are surrounded by a group of experts. Your expertise is the users. Make it the data.

    "Many product managers tell me that the way they deal with testing business viability with all their different stakeholders is by scheduling a large, group meeting and inviting all the stakeholders. The product manager then presents to them what they want to build, usually with a PowerPoint presentation.
    ...high-fidelity user prototypes are ideal for this. I plead with product managers in larger companies to not trust a sign-off on anything other than a high-fidelity prototype. I have seen far too many times where the execs agree to something based on a presentation, but when they see the actual product, they are completely shocked, frustrated, and often visibly angry.
    Instead, meet privately with each stakeholder, show them the high-fidelity prototype, and give them the chance to raise any concerns.
    This may sound like more work to you, but please believe me that, in the long run, it will turn out to be far less work, time, and grief."
    This is counterintuitive, and I tend to set up a one-time meeting to sign off. But this part is actually very compelling.

  • プロダクト開発の進むべき道が書かれており、1つ1つが詳細に書かれている訳ではなかった。
    まずは課題を見つけよう、ユーザーインタビューしよう、小さなプロトタイプを作ろうというよく言われていることが書かれており、一通り知りたい!っていう人にはオススメかも
    ユーザーインタビューってどうやるの?プロトタイプってどう作るの?みたいな具体的なことは書かれていない

  • プロダクトマネージャーの入門書としておすすめされていたので読んだ。経験がないせいかピンと来ない話も多く、すでにプロダクトマネジメントに精通している人が抜け漏れないか確認するために使う本という印象を受けた

  • プロダクトマネジメントの手法を解説した本。

    プロダクトマネジメントを知るのに役立つ一冊です。ボリュームがあるので時間をかけてじっくりと読むといいと思います。

  • プロダクトマネージャは実務家のスーパーマンじゃないと務まらないですよ、覚悟はあるか?と述べている本。

    そうだよなぁ、、、、でも、そんなスーパーマンは中々いないのが実態ではなかろうか・・・

  • INSPIREDの第二版。時代にあわせてアップデートされてた。

  • PMの役割はなんなのか。どんなチームを作り、それぞれに役割を与えるべきか。悪いチームはどのようにしくじるのか。PMの教科書と呼ばれる由縁がわかる一冊。
    全てのチャプターのテクニックをパーフェクトにできたら素晴らしいプロダクトを生み出せると確信しているが、それが難しいのだろう。何度も読みそう。

  • PMの教科書。PMってどんなことをやる人なの?と言うところから書いてあり、非常に丁寧な記述。
    内容は、もはやPMとしての心構え。きっとPMって職域が広いから、やった方がいいかなってことがたくさん出てくるのはわかるけど、それを全部やれよって話。

全14件中 1 - 10件を表示

著者プロフィール

ヒューレットパッカードやeBayなど、名だたるシリコンバレー企業で活躍し、製品やサービスの開発に色々な立場で携わってきた。その後、ユーザを魅了し、大きな成功を遂げる製品を作ろうとする人々を支援するため、シリコンバレープロダクトグループ(SVPG)を立ち上げ、コンサルティング活動を精力的に展開している。

「2021年 『EMPOWERED』 で使われていた紹介文から引用しています。」

マーティ・ケーガンの作品

この本を読んでいる人は、こんな本も本棚に登録しています。

有効な左矢印 無効な左矢印
ベン・ホロウィッ...
ダニエル カーネ...
クリスティーナ・...
有効な右矢印 無効な右矢印
  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×