プロダクト担当者が押さえておきたい、データ活用施策を成功に導く6つのステップ
編集部注 本記事は技術評論社の協力に基づいて記事作成しております。 はじめに はじめまして。ゆずたそ（@yuzutas0）と申します。私は業務支援ツールのプロダクトマネージャーとして活動する傍らで、データ基盤＆KPIダッシュボードの受託開発や、業務改善のコンサルティングを行っています。主な相談元は各社のCPO、CSO、CTO、VPoEといった方々です。 この寄稿記事では「データ活用施策を成功に導くステップ」について解説します。記事の内容は、拙著『実践的データ基盤への処方箋』（技術評論社）の1章9節「ユースケースを優先的に検討しツールの整備を逆算する」をもとに加工・編集したものとなります。 想定する読者は、担当プロダクトのデータ活用施策を検討する方です。「プロダクトの会員数ダッシュボードを用意しよう」「デジタル広告を見直して流入を増やそう」「クーポンメールを配信して売上を伸ばそう」といった施
再現性と質を高める「意思決定のフロー化」 ―― 開発畑のプロダクトマネージャーの失敗から学べ
はじめに こんにちは、ゆずたそ（@yuzutas0）です。この連載では、ソフトウェア開発者からプロダクトマネージャーに転向した筆者が、多くの失敗を経て重要性を痛感した「プロダクトマネージャーのマインドセット」を解説します。 主な対象読者としては、同じようにソフトウェア開発を出自とした方で、「同じような失敗経験のある方」「これから失敗を経験するであろう方」を想定しています。連載の前提条件の詳細、免責事項などについては、第1回の冒頭を併せて参照ください。 トレードオフが生じる場面 今回は意思決定について扱います。たとえステークホルダーの協力を引き出し、どれだけ試行錯誤しても、どこかでトレードオフが生じることになります。関係者全員が問題と向き合い、議論を整理した上で、それでも一つの結論にならないという場面が訪れます。そこではプロダクトマネージャーとして意思決定を求められます。 画面に表示するテキ
「Not for me」からの卒業――開発畑のプロダクトマネージャーの失敗から学べ
本連載は、ソフトウェア開発者からプロダクトマネージャーに転身した、ゆずたそ（@yuzutas0）さんが自身の経験を振り返り、切り替えるべきだったと考えるマインドセットを紹介していく連載です。第2回は、「責任から逃げてしまう」という問題を取り上げます。自身の責任範囲は想像以上に広くなるのだ、ということを認識しましょう。（編集部） はじめに こんにちは、ゆずたそ（@yuzutas0）です。この連載では、ソフトウェア開発者からプロダクトマネージャーに転向した筆者が、多くの失敗を経て重要性を痛感した「プロダクトマネージャーのマインドセット」を解説します。 主な対象読者としては、同じようにソフトウェア開発を出自とした方で、「同じような失敗経験のある方」「これから失敗を経験するであろう方」を想定しています。連載の前提条件の詳細、免責事項などについては、第1回の冒頭を併せて参照ください。 「Not fo
「早くリリースして、早く改善しよう」の落とし穴―― 開発畑のプロダクトマネージャーの失敗から学べ
はじめに はじめまして。ゆずたそ（@yuzutas0）と申します。私はソフトウェア開発者からプロダクトマネージャーへ役割を変更した後、多くの失敗を経て「マインドセットを切り替えること」の重要性を痛感しました。 この連載では、私が学んだ「プロダクトマネージャーのマインドセット」を解説します。 想定する読者・提供価値については、2つのパターンを想定しています。1つ目は「同じように失敗した経験のある人」です。自分の経験を振り返りながら「こうすればよかったのか！」と考える機会になるはずです。2つ目は「これから失敗を経験するであろう人」です。これから起きる課題について「こうすればいいのか！」と考える機会になるはずです。 注意・免責 ①本連載の内容は、筆者の個人的な見解にもとづきます。適宜ご自身の立場に置き換えて、読み進めていただければと思います。万が一、誤りや不快な点がありましたら、どうぞ筆者個人宛
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
