プロダクトチームと、その成長｜小城久美子 / ozyozyo
プロダクトチームの目指す姿プロダクトを作るチームには、Biz、User、Techの3つの柱が必要です。この3つを使って広義と狭義のプロダクトの両方を作ります。狭義のプロダクトとはソフトウェアやハードウェアなどの「モノ（アウトプット）」を指します。そして、広義のプロダクトとはそのモノを使って実現した状態（アウトカム）です。 Biz、User、Techの3つの柱には「課題発見」と「課題解決」の2つの方向性が違う力が含まれます。また、ビジョンの実現のためにプロダクトを一気通貫させ、この3つの柱をコントロールする力があると、チームとして働くことができます。 まとめると、プロダクトチームは以下の7つの方向で力を発揮出来ている状態を目指すといいでしょう。 7つの力が偏っていると起きること 大きな絵は書けるけれど、それを実現する力が弱かったり↑ プロダクトとしては綺麗でも、その課題を持っている人がいなか
プロダクトマネージャーが書いたPRDの通りに機能をつくる？｜小城久美子 / ozyozyo
私はPRD(Product Requirement Document)が嫌いでした。概念としてのPRDは好きですが、ドキュメントとしてのPRDが苦手、という話を聞いてください。 😭 PRDの嫌いだったところ① プロダクトマネージャーの仕事はPRDを書くことです、という誤解 実際に会社によってはそれをプロダクトマネージャーの主な責務にしているところもあるでしょう。しかし、私はプロダクトマネージャーの仕事は「何のPRDを書くのか？」を決めることであり、PRDを書く作業はプロダクトチーム全体で実施するものだと思っています。プロダクトマネージャーが書いたPRDの通りにプロダクトチームが動く組織は好みません。 ② これ1枚でほんまに全部書くんか？ PRDは「検討すべき項目がすべて検討されているか？」を問うフォーマットとして秀逸です。しかし、例えばPRDに「競合分析」や「市場分析」を記載することもあ
プロダクト指標がMAUだけなのはおすすめしません🙅｜小城久美子 / ozyozyo
📢 今期はMAUを伸ばしましょう Aさん「ログインボーナスを配ろう！」 Bさん「キャンペーンでお安くして広告を打とう！」 Cさん「若者にとってもっと魅力的なプロダクトにしよう！」 Dさん「通知をたくさん送ってリテンションを上げよう！」 ユーザー「一回使って満足しました。もう使いません👋」 --- 完 --- 💣 問題: 軸のないプロダクトになり兼ねない 指標は、そのプロダクトが成功している状態を計測するためのツールです。MAUを指標においたことで、その成功が「月に1回以上つかうユーザーがたくさんいること」になってしまいます。どんな使い方で、どんな頻度で、どれくらいの時間、どの機能を、どんな人が、どんなシーンで使うかが含まれていないので、チームのメンバー各々が考える「良さ」を追求してちぐはぐになってしまう危険があります。 💪改善策: 「もう一歩具体的にする」プロダクトをつくる上で収益
PMとUXデザイナーのグラデーション｜小城久美子 / ozyozyo
プロダクトマネージャーとUXデザイナーの仕事は線引をすることが難しく、正解はないと思っています。プロダクトマネージャーがワイヤーを引くところまで担当する現場もあれば、アウトカムからアウトプットまで一貫してUXデザイナーが担当する現場もあり、様々なグラデーションが存在しています。そのグラデーションの具体⇔抽象のサンプルを作成しましたので、協業時のたたき台にご利用いただけますと幸いです。 例とするグラデーション フードデリバリープロダクトを例にして、「売上を上げる」という最終的な目標を達成するために「スタンプカード」という機能を実装する間のユーザー体験のグラデーションを取り上げます。 ① プロダクト指標を決める 売上を上げるための戦略が必要です。高級料理に特化するならプロダクト指標として単価を持つこともあるでしょう。今回の施策がプロダクト指標のどこに貢献するものであるのかを定めることが1つ目の
ロードマップに機能を書くべからず｜小城久美子 / ozyozyo
機能を書くならバックログにまず機能だけが書かれたロードマップから見ていきましょう。時系列に沿って、どんな機能を追加するのか並んでいます。 残念ながら、多くの場合、機能開発が遅延したり、差し込み案件が発生したりして、以下のようになってしまいます。 こうなると、もうこのロードマップは信頼できません。過去の実装がここまで遅延していると、次に取り掛かる機能がいつリリースされるのか分からず、どれの優先度がもっとも高いのかも判断するのが難しくなってしまいます。 こういった「機能」に近いものは、縦長のプロダクトバックログの形式で並べ、ユーザーストーリーに分解して見積もったものを上から順番に実施していくほうがスッキリします。 では、ロードマップがなぜ必要なのかプロダクトバックログはとても良いものですが、プロダクトの中期的・長期的な未来を構想するには少し見づらくなります。特に、会社の中で中期的・長期的な方針
アウトカムにつなげるIssue管理 - OKRとKPI(NSM)とPBL｜小城久美子 / ozyozyo
プロダクトマネージャーが責任を持つのはアウトプットではなく、アウトカムです。機能（アウトプット）を作って終わりではありません。「インタビューでユーザーが言っていたから」という理由だけでプロダクトに機能を付け加えるのもいけません。ユーザーの言いなりになるのではなく、ユーザーの期待を超えていく姿勢を持ちましょう！ このnoteの結論このnoteは、アウトカムとアウトプットの紐付けが難しいのであれば、OKRとNSMを活用してアウトカムを定義して、間にIssue Listを挟んでアウトプットの検討をするのがいかがでしょうか？という提案をするnoteです。 ■ このnoteで解決できるかもしれない課題 ・プロダクトが解決すべきIssueが多すぎて優先順位付がむずかしい ・PBL(=プロダクトバックログ)の優先順位に納得感がない、または、PBLに入っているアイテムに納得感がない ・抽象的なプロダクトの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
