ざっくり解説 → "Practical Lessons from my Experience in Product"
こちらの「プロダクトマネジメントに関する教訓」の記事がPM界隈で少し話題になってます。
これに関して、とある日に会社のメンバーから
というおねだりをもらいました。英語苦手なのに…
というわけで、せっかくだから解読した結果をここにまとめます。そのまま翻訳するのは許可が必要な気がするので、あくまで自分の解釈と意見を書く形にしました。（間違ってたらごめんなさい）
1.MVPはユーザーセグメントを絞って作るべし
1.Being Minimalistic- Identify a target user base don’t be greedy for every possible user segment. Segments are not just demographics but can be a mobile user, a desktop user, a college student or just people in a specific timezone. Minimalism is not just on user selection, try developing MVP and extend the minimalism to day to day work. Do your homework right.
これはこの図を見るだけで十分な気もしますが、全てのリーチ可能なユーザーセグメントをターゲットにするMVPを作ると多機能になり、結局"Functional"な部分の検証しかできなくなります。ターゲットとするユーザーセグメントを絞り、その中で本質的に検証すべきことを検証できる必要最低限のMVPを作るべきということです。
元記事より引用
2.エンジニアリング無しでミニマルな機能を作るべし
2. Try building a feature with minimal or NO engineering support. Yes, you hear me right, it takes hell lot of time to go through tech designs, coding and testing so find ways to test your hypothesis through cheap vendors. There are so many who can help you out!
デザインを起こしたりコーディングするには時間もコストもかかるので、仮説を検証するためには安く早く、なるべくエンジニアリングをすることなくミニマルな機能を作ってすぐに検証に回すべきです。
最近はWebならSTUDIO、アプリならYappliなど、プログラミング無しで機能を作れるサービスが増えてきているので、使わない手はないでしょう。
とはいえ元エンジニアのPMの方などは「恥ずかしいからもっと作り込んでからお披露目したい…」という心理が働きがちなのも事実。そんな時は「ユーザーは小さい失敗をすぐに忘れてくれる」と自分に言い聞かせましょう。あとでイケてる機能に仕上げて忘れさせればいいのです。
3.機能の根拠となるデータを正しく理解するべし
3. Know Your Data: Important! Have them on top of your mind. — Usually, people who want to question your feature idea or just not convinced enough would ask this question. It sucked when a PM came to a meeting and told us about a feature which would be so interesting for people who would travel 6 months from now. Not knowing that bulk of our customer base usually books travel 0–30 days in advance. Do have relevant stats don’t just throw numbers which don’t make sense.
ちょっと原文の解読に苦しんだのですが…要は「機能の必要性の根拠は、一般論ではなくデータに基づかねばならぬ」ということでしょう。
データドリブンな意思決定は今や普通のことなので、今さら特に言及することはありませんが、「データを使えば何でもOK」というわけではありません。何かの意思決定をするために適した客観的データの取得・抽出・分析の方法を選択する必要があります。それを選択しましょう。
よく見かけるのは「こういう意思決定をしたいから都合のいいデータ都合よく加工する」パターン。それよくない。
4.ユーザーストーリーを書くべし
4. Write Good User Stories: It doesn’t matter how much you talk about a feature requirement through presentations, standups, chit chat over a coffee or messaging on Slack/WhatsApp or shouting your throats out. The feature that gets build is the one written in the Jira story.
個人的にはユーザーストーリーでもジョブストーリーでもリーンキャンバスでもサービスブループリントでもインセプションデッキでも、「ユーザーにとって本当に価値になるものは何か」「価値を適切に提供できているか」が整理できれば何でもいいと思っている派です。そしてそれをしっかり言語化（可視化）することが重要だと思ってます。毎日でもそれを見て、日々やっている意思決定やアクションがそれに基づいているのかをチェックしましょう。
5.障害時に悪魔にならない
5. Don’t be a Devil when there is a Disaster: Yes mishaps would happen on any e-commerce site. Do cover your teammates, send out communications, crunch numbers to evaluate the impact, be easy t look for solutions. Provide the cover to your tech team.
エンジニアをサポートし、インパクトの定量的な算出をし、シンプルな解決策を見いだすことがPMの役割です。怒ってる暇はありません。
（最初の会社にいたなあ。大規模な障害時に何もせず「ちゃんと報告しろ！」しか言わない上司。その報告コストが無駄なんですけど。）
6.エキスパートと会話するべし
6. Talk to Experts: Not just the ones on youtube or a page from the search results of Google. Talk to people who have been in the system for long, talk to the sales guy, the Customer support, the site operations, the network team. They can tell you more about features to improve customer experience than the customer themselves.
カスタマーサクセスやセールスの方々と会話をすることで、ユーザー自身も知らないユーザーのことを教えてもらえるかもしれません。
バックオフィスの方々と会話をすることで、コスト構造の問題が見つかるかもしれません。
社外のあらゆる人と会話をすることで、ビジネス上のヒントや組織の問題の解決方法が得られるかもしれません。
PMにとって人との会話から得られるものは多いと思います。
7.アイディアをPM依存にすべきではない
7. You are not the Idea Generator: Nothing restrictive about it. Be receptive and build a culture of innovation and creativity. Welcome ideas through Dogfoods or throwing problems on different platforms. You would be amazed.
PMの役割は「プロダクトに関するすべてのことを決める」と言われることが多く、責任感の強いPMは「全部決めるんだ！」と意固地になっちゃうかもしれませんが、アイディアを全てPMから出す必要はありません。むしろそれだとダメです。
ドッグフーディングや様々なプラットフォームを使ってアイディアを集めて受け入れ、フラットな視点で採用可否の意思決定をすれば、より良いプロダクトが生まれます。
8.ステークホルダーの都合に合わせるべし
8. 9 AM–5 PM can’t be done: Most of us work with stakeholders located in different timezones. That would mean late night or early morning meetings. There would be times you won’t have time for dinner and then there would be times where you can go out and have a sumptuous brunch.
ステークホルダーが多く都合を合わせないといけないので、9:00~17:00の間で仕事は完結しないよと。まあこれは普通のことですよね。
自分は基本的にどんな時でも即レスし、会議とかも自分の都合で遅らせることを避けるタイプです。とにかく自分がボトルネックにならないように心がけています。
が、その弊害として「自分の集中力を要するタスクがいつまでも終わらない」という問題が出てきます。戦略立てたりPRD作ったりするタスクです。その弊害を防ぐために、ステークホルダーから干渉されない時間帯を見つけて、そこを集中タイムに設定しています。
9.優先順位づけ！
9. Learn to Prioritize: You got as much budget and people. Always be on a lookout for a good prioritization technique.
PMの醍醐味ですね。優先順位づけ。やりましょう。
優先順位のつけ方の参考になるのが「狩野モデル」という考え方です。過去に狩野モデルに関する記事を書いたので、よろしければどうぞ。
10.背負い込み過ぎない
10. Don’t overwhelm yourself: There was a time I used to respond to every email or a text from my customer or stakeholders. It just can’t be a long term thing. It’s ok to slow down a bit and form a way to respond to people by not being anxious.
PMがカスタマーやステークホルダー対応の全てを背負い込む必要はありません。それだと一番重要なプロダクトのことを考える時間が奪われていきます。ローンチ直後はいいかもしれませんが、なるべく早くタスクを分散させる仕組みを導入する必要があります。
PMって割と馬力のある方が多いので背負い込んでも何とか回るし、ユーザーと触れ合うことが楽しいし、人件費も減らせるからという様々な理由でそのままにしておきたくなるかもしれませんが、長期的に見たらワークしないので、問題が顕在化してなくても早めに手を打つべきです。
11.予測は不可能
11. Predictability? — NO: My experience tells me that there is no Science in Product Management. Things would change often and what was important yesterday is no more a priority. We need to address the changing times and competition.
"there is no Science in Product Management"ってすごい言い切りw
この変化の激しい時代において予測は確かに難しくなってきています。なので「常に即時判断できるよう準備をしておく」のが求められます。それは意思決定フローだったりデータ分析基盤だったり優先順位づけの基準だったり。
個人的に思う「良いPM」は、情報のインプットを得てから結論を出すまでのスループットが早い人です。そうなりたい。
12.技術的負債を許容する
12. Allow Tech Debts: Yes, they are important. New versions of technologies and fixing architectural gaps are very important. It also inspires the geeky developers to put their hands on newer stuff and be motivated. Remember Tech Debts have outcomes drive those discussions around it. It can be like ‘Increased Quality’, ‘Efficiency’, ‘Faster Releases’ and so on.
ちょっと原文を正確に理解できてるか怪しいんですが…ある程度の技術的負債は許容して、負債が生まれたら常に解消していくべき、ということ？
うん、しましょう。
13.Why/What/Howを常に問う
13. Always ask these questions: Why am I doing this? What are different ways to achieve it? How will I measure it?
これはPMのルーチンにしないといけないですね。
そしてこれも言語化（可視化）して、チームメンバー全員の目が届く場所に置くべきだと思います。仮にPMに迷いが生じて間違った行動を取ってしまったときに、メンバーから指摘してもらえる可能性が高まるからです。
14.スピードは機能である
14. Speed is a feature: Yes, Don’t get mired in engineering telling you the page speeds. If the App doesn’t open fast or the page doesn’t come fast or the menu items are slow to render, its a feature problem. It doesn’t matter how much money you got if you go to the pizza place to buy pizza when its shut down.
表示スピードや挙動スピードが速いのは、もはや非機能要件ではなく機能要件である、ということですかね。（最後のピザのくだりはよくわかりませんw）
確かにモッサリしたUIのWebサイトやアプリは、この代替サービスが溢れる時代においては、それだけ離脱の要因になり得ます。データを正確に処理できるだけで満足される時代は終わりです。スピード命。
15.ハッタリをかませ！
15. FAKE IT: Not easy to build all the required features, some say to build 50% of the features it takes 90 working days. This may or may not be true and depends on the nimbleness of your org. So do a Demand test, put up dummy Campaign Banners, shell out Coupon Codes, Show off various Login Techniques, Add dummy Rewards Points and tell the user it’s coming soon. Not just that, faking also means introducing new product categories for which you may not have the inventory readily available, add them to your site and see what the response is going to be.
これも原文の理解が難しかったんですが、要はキャンペーンバナーやリワードポイントなどを駆使してハッタリ(=Fake)をかまして、ユーザーのリアクションを見るということでしょうか。
なかなかリスキーですが、時間をかけて機能を作り込んでからリリースするより、先にハッタリでもいいからユーザーに知らせて、リアクションのいいものに絞って作っていくというのは合理的な攻め方だと思います。あまり過激にやると炎上しそうですがw
16.ユーザーエンゲージメントを測定すべし
16. Metrics — Measuring not Chasing: Build relevant metrics it may not matter how many active users you got or visitors you got.
See their engagement levels- are customers doing various actions on your page?
or do they just drop off from the homepage?
Were you able to make people share your product to others? Does CTO/CTR matter? Go for real metrics which matter not swim in vanity.
PVやアクティブユーザー数、CTO/CTRなどわかりやすい測定値ではなく、ユーザーのエンゲージメントレベルを測定するよう努めるべきということです。
KPI設定をするときなど、GAを使ってすぐ取得できる数字にする方が楽だし、それでも何となく合理性はありそうな雰囲気を出せますが、それを追跡したからといってプロダクトのグロースのための測定にはならないかもしれません。しっかりユーザーのエンゲージメントを意味する数字を測定しましょう。
とはいってもエンゲージメントの測定は難しいです。プロダクトや業種によって測定対象は異なります。そこはPMが頭をフルに使って考え、仮説を立てて検証していくところです。
17.ステークホルダーと会話すべし
17. Talk, Talk and Talk Setup weekly or biweekly meetings with your stakeholders. It doesn’t matter if you don’t have much to talk. A few minutes of conversation can yield many important details and you keep the humane touch with your clients and stakeholders. I experienced that by only talking on days I need to and canceling all other scheduled meetings it builds some distance between individuals. I like to keep up on my meetings; maybe just talking about the status and weather and log off then.
明確な会議の議題がなくても会話の場を設けることで、ステークホルダーとの距離を広げずに済む、ということです。
これは「無駄な会議は減らせ」という世の中の風潮とのバランスが難しいところですが、やはりある程度の定期的な会話は必要だと思います。そんな時にオススメなのが、リクルートの「よもやま」という文化です。（参考記事はこちら）
特に議題がなくても気軽に相談や壁打ちなどする時間を設ける文化です。リクルート時代の自分は別部署の人とよもやまの場を設けたりすることで、様々な意見や情報を集めることができました。またその人とは良好な関係を築けたので、仕事が非常にやりやすくなりました。
といった感じで苦手な英語に負けず、自分なりに解釈してみました。
経験に基づく教訓をアウトプットしてくれるのはありがたいですね。自分もいずれやろうかな。
