リーンキャンバスを実践してみよう

マネージメント

プロダクトで抱えている課題、機能のアイデア、追加等の整理はどのように行ってますか?
時間をかけて開発した機能が、あまり効果がでなかったり、いろんなところこから依頼を受けて、しかもすべて優先度Sという状況で、タスクをこなす!ということに注力して、本来のプロダクトの意味を見失ったりと、そういうことが起きていないでしょうか?

今回のプロダクトでは、いったんの状況整理と次からの戦略をどうするか?というのを考えるにあたって、ビジネスPM、システムPM、エンジニア等を巻き込んで、ホワイトボードを使って、みんなでディスカッションしながら、話し合うという機会を作ってみました。

そこで、みんな頭のなかにあるビジョンを書き出して共有するというところから始めてみました。
そのフォーマットとして利用したのがリーンキャンバスになります。

リーンキャンバス

上記を何枚書いても問題ないです。
その中から優先順位をつけても大丈夫です。

書いていく

けっこう何を書いて良いのかわからなかった。。
設計しやすい順序があるので、以下のような順番で埋めていくといいらしいです。

1.課題…上位3つの課題
2.顧客セグメント…ターゲットにする顧客
3.独自の価値提案(UVP)…差別化要因と注目に値する価値を説明した単一で明確な説得力のあるメッセージ
4.ソリューション…上位3つの機能
5.チャネル…顧客への経路
6.収益の流れ…収益モデルや顧客障害価値など記載
7.コスト構造…顧客獲得コストや流通、ホスティングにかかるコスト、人件費など
8.主要指標…計測する主要活動
9.圧倒的な優位性…簡単にコピーや購入ができないもの

感想

あくまでも、リーンキャンバスを書くことが目的ではなく、手段なので、他にいいやり方があるなら、試してもいいとは思っていますが、一般的な手法なのでトライしてみました。

なかなか枠が埋まっていきませんが、会を重ねるごとに良くなってる気がしますw

これプラス、デザインスプリントをやってもいいのかなと思っており、短期集中でいっきに考えて、仮説検証ができれば、時間を書けて開発して、成果に結びつかないなんてことは減るのかなと思っています。

この記事を書いた人

にょこた

PM(プロダクトマネージャー)目指して奮闘中、プログラムから、アーキテクト設計、サービス検討から、チームマネジメント、DevOps、いろいろやってます。