STORES 株式会社
STORES プラットフォーム シニアプロダクトマネージャー
浅田 純史
(@break_an_egg)

相談料金

2,500円 / 1h

相談に乗れること

非エンジニア出身のプロダクトマネージャーがエンジニア、デザイナーと良い関係性構築、プロダクトマネジメントができるようになるか、についてお話することができます!

他に提供できること

・Scrumの導入、プロダクトオーナーとしての振る舞い
・0から1、1から10といったPhaseごとのナレッジ・ノウハウ
・海外版のプロダクト開発のナレッジ、ノウハウ

経験職種

営業、CS、PjM、デジタルマーケ、新規事業、事業責任者、組織のマネージャー

インタビュー記事

過去に回答したQ&A

A. 「アジャイル開発」と一言でいっても、それを行うためのフレームワークは多くあります。
「アジャイル開発」を選択された目的は何だったのでしょうか?
その目的によって選択すべきフレームワークが変わってきます。
開発チーム内で、なぜアジャイル開発を選択しようと思ったのか?を意思統一したうえで、チームにとって最適だと思うフレームワークを選択してください

A. Howというより、データを収集したあとの利用目的が重要だと思います。
収集したり、その結果をGraphにしてみても、結局、活用方法が決まってなければ、意味がありません。
それによってHowの内容も変わってくるでしょう。
PMとして気をつけることは、上記だと思います。

A. リモートワークではないときは、アナログを推奨していました。
タスク管理を付箋でやったり、バーンダウンチャートを手書きで書いたり。
一見、効率悪く見えますが、ツールの場合、ツールに自分たちを合わせなくてはいけないという制約が生まれます。

「ツールを管理する人」が出てくる、それを仕事とする人がでてきたとき、それはリソースを効率的に配分できていると言えるのでしょうか?

リモートワークとなった今、すべてをアナログで行うのは難しくなってますが、ツール選びのコツとしては、ツールに縛られない、ツールのカスタマイズが仕事にならないものを選ぶことだと思います。

A. 日本から世界に浸透するプロダクトを作るプロダクトマネージャーを目指しています。
車やゲーム機のように日本発信で世界で愛されているプロダクト(ソフトウェア)というのはあまり例がなく、乗り越えたい私の目標です。
例えば、Excelに勝てるプロダクトが創れたら良いと思ってます。
Excelは表計算のツールの域を超えて、様々な用途で使われています。ToB向けのソフトウェアを作っても、満足されずにExcelが業務に組み込まれているケースが多々あります。ターゲとユーザーがExcelを使わずに業務がすべて完結できるような未来を創れたら「勝てる」状態になるのかなと思っていたりします。

A. コアターゲットを明確にしたうえで、そのターゲットに5人(社)ほどヒアリングを行う。

そのターゲットの課題、課題を解決するソリューション、それを解決することで得るターゲットの価値が正しいかどうかを検証していきます。

特に価値については、お金を払っても得たい価値なのか、その価値を代替手段で行うときにかかるコストを把握することでお金を出しても解決したい問題なのかやプライシングに役立てることができます。

A. 「卓越した」というのが「ユーザーの期待を超えること」ということであれば、ユーザーの要望、意見をそのままプロダクトに落とし込むことではなく、その体験の目的が何かを明らかにすること、その目的を達成するためのベストソリューションが何であるかを考えることが重要でしょう。
そのために必要なことは
・ユーザーのやりたいことを目的、今行っている行動、その課題を明らかにすること
・ベストソリューションを導くために色々なプロダクトに触ること、AIなどの技術を学ぶこと
になると思います。

A. 自分自身が熱狂できる(例:このプロダクトはヒットする、世の中に役に立つ)もの、その理由をチームメンバーに伝えて納得できるものであるかどうか。

自分が熱狂できないもの、身近であるチームメンバーに説明しても納得してもらえないものは、第3者に公開しても、指示をえることはできないというのを何度かトップダウンでプロジェクトを行って失敗したことから学びました。

トップダウンのものであっても、なぜそれをやるべきなのかを自分の言葉で他者に説明して納得してもらえるまでは、本当にやるべきかどうかを考える方が良いと思います。PMというのは作ることだけでなく、やめることも決断する役割です。

A. 「ドラえもん」

読み返してみると、今の世の中で実現できているもの(ほんやくコンニャクとか)があり、これから実現できるものを考えたり、道具を決めて、プロダクトバックログや受け入れ条件を考える練習に役立ちます。

A.

「ユーザーにどのような価値を届けたいのか」と「その価値をどうやったら最短で届けられるか」の2点です。

ユーザーの課題を解決するための「機能」を開発することになるわけですが、ユーザーが欲しいのは「機能」ではなく、その機能を使うことで得られる「価値」になります。
ユーザー登録など価値を得るためにやらねばならないことがプロダクトとして出てきてしまうわけですが、価値が大きれば多少工程が複雑でも使ってくれます。
自分たちが提供する体験が、ユーザーの求める対価を超えるものであるかが、ユーザーが使い続けてもらうために必要だと思います。

ただどんなに素晴らしい価値であっても時間がかかりすぎて市場に出せなければ、競合に取られたり、期待していたユーザーが離脱してしまいます。
そのため、価値を提供するのに必要最低限、多少のリスクはとって最短で提供していく方法を常に意識してます。