プロダクトマネージャーとして最初にやっていること

新米プロダクトマネージャーのIwaoです。まだプロダクトマネージャーとしは2ヶ月くらいでペーペーなわけですが、最初に取り組むミッションを書いておこうと思います。

というのも先日「プロダクトが進捗していないと感じた時の…」記事に共感を覚えたため、僕も頭の中を言語化してしっかり掘り下げてみようと思いました。参考までにリンク貼らせていただきます＆ありがとうございます！

プロダクトが進捗していないと感じた時の戦い方 - hikoharu's PM blog

前提

プロダクトマネージャーはミニCEOであると言われますが、実際やってみると全然違うなという感じがしています。蓋を開けると製品開発の本で勉強した理想的な状態と実際のワークフローに大きなギャップがありました。なのでまずは製品開発できるスタートラインまで戻すことが最初のミッションであると感じています。まさに技術的負債を返済している感覚に近いです。

以前の記事で少し書いたんですがそのような状態を製品的負債と呼ばせていただいてます。今回は技術的負債をおさらいしつつ、製品的負債がどんなものかを伝えられたらなって思っています。

あ、負債というワードを使っていますが、私の解釈はdisではなく家や車と同じでメンテナンスしないと最初の品質は保てないよね的な意味合いです。だからどの製品にも存在するものなのでご安心を！

技術的負債

界隈では有名な「技術的負債」はメジャーなワードになりました。おさらいするという意味でwikiから抜粋しますね。

行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果

その原因は？

技術的負債の要因は余裕のない状況で開発したからで、その原因は納期が無理ゲーだったり、QCDの欠如だったり、設計に思想がなかったり、古いテクノロジーだったりと色々な原因がありますよね。

放置リスク

放置すれば永続的に開発者は品質と戦い、事業側は障害リスクを、人事側は採用リスクを負担します。顧客からすれば新機能の到着やバグフィックスに時間がかかるのでサブスク型でお金を払ってる以上は解約リスクが伴います。

一方で動けばいいじゃん側にはなかなか伝わらないもどかしさもあります。

解決策

個人的にはやらないと放置リスクを許容できないなって思っています。製品開発バイブルINSPIRED（旧版）では未然に防ぐアプローチが正しいよ的なことが書かれていました。

どうやってリスクヘッジするかですが、個人的にはオーナーシップ制にして製品の品質を担保する領域を明確化して定期的にクリーニングすることだと思っています。

このときにプロダクトマネージャーは誰が悪いではなくなぜ起こったのかでのアプローチが必要です。

製品的負債

ほとんど誰も使わない機能っていうのは存在していて、ユースケースがゼロということもありえます。では造語「製品的負債」を引用風に言語化してみます。

行き当たりばったりな機能追加と、価値を定義できない製品開発が引き起こす結果

技術的負債に比べると製品開発する課程では発見することが難しい分、結果が顕著に数字に出やすいと思います。

その原因は？

要因は価値を定義できない状況で製品開発したからで、その原因は特定の顧客の要望だったり、分析をしていなかったり、プランに思想がなかったり、競合との差別化ができないからだったりと色々な原因があると思っています。

放置リスク

誰も価値を理解できなくなってしまうと、開発者は言われたことだけを捌くだけになり、事業側は価値を伝えられずに売れなくなり、顧客からすれば要望を出しているのに使わない機能リリースを知るわけですからヘイトがたまりますので、解約リスクと組織崩壊リスクが考えられます。

解決策

こちらも技術的負債と同じように未然に防ぐことが最適解だと思ってて、まずは使ってもらえる機能をリリースするために粘り強くプロダクトマーケットフィットを推進していくことになると思っています。

機能単位でオーナーシップを付与して要件定義で価値のレビューを繰り返すアジャイル化と、リスクを最小限に留めて価値だけを実装するMVP化で着実に製品品質を上げていくことを考えています。既に出してしまった機能も改善しないとなので、それは別軸で考えなくてはいけません。

雑感

起業時に結構頑張って作った製品で恐ろしいほど少ないダウンロード数を叩き出したことがあるので、製品的負債を解消したい思いは強めですw

健康と同じように自分ごととして定期的に健康診断というレビューをして問題の早期発見をすること。そして問題に気づいた人が推進していって、周りがそれをリスペクトしてサポートする構造が、いい組織によるいい製品につながっていくと信じています！