t_wの輪郭

Feedlyでフォローするボタン
あれ

PLG

2022/2/7 22:20:00
『PLG　プロダクト・レッド・グロース「セールスがプロダクトを売る時代」から「プロダクトでプロダクトを売る時代」へ』あれPLGでは利用者獲得・顧客化・利用継続を製品が行うあれSESでPLGはできるか？Product Led Growth物理的な製品でPLG価値を素早く利用者に訴求できない製品はPLGに適さないPLGは販売/営業のDX？PLGではユーザーは購入前にプロダクトを試す
意思決定フレームワークバリューメトリクスPLGでは利用者獲得・顧客化・利用継続を製品が行うファネルボウリングレーン・フレームワークを使うと有料会員化率が上がるボウリングレーン・フレームワークストレートラインを構築オンボーディングプロセスフリーミアムサブスクリプションビジネス利用者自ら製品について学習するディスラプティブ型戦略はフリーミアムと相性が良い差別化型戦略はフリーミアムと相性が悪いフリーミアムは製品の部分的利用ディスラプティブ型戦略差別化型戦略GTM戦略とは標的顧客へ働きかける行動計画のことGTM戦略セールス主導型のGTM戦略の欠点ジョブ理論マトリクスUCDフレームワーク新規利用者の40%〜60%はサイトを再訪しないドミナント型戦略セールス主導型のGTM戦略営業部門だけが利用者に接すると、開発部門が利用者を学ぶ機会を失うクイック・ウィンマルチプライヤーの公式ビジネス成長の3つのレバービジネスの成長には解約率を下げ顧客平均単価を上げることが効果的マクロ・アウトプットARPU=MRR/ユーザー数10倍ルールMOATフレームワーク製品購入の３つの理由価値を素早く利用者に訴求できない製品はPLGに適さないPLGではユーザーは購入前にプロダクトを試す『Measure What Matters（メジャー・ホワット・マターズ） 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR 』カスタマーチャーンリテンション・ファーストカスタマー・リテンション・レートチャーンビーストクロスセルエンプティステートに必要な残設定を表示セールスサイクル差別化型戦略はフリートライアルやデモと相性が良いフリートライアルトリプルAフリートライアルは製品の一時的利用アップセルARR

あれ

2022/3/27 16:10:00

　月額100円のPKMSを作りたい。企業内へのPKMS導入において価格がネックあるならば、安価なPKMSを作れば普及させられるはずだ。
　PKMSの低価格化を目指すには、雇用をほぼ一人に絞る必要がある。雇用を一人に絞ったとき、浮かび上がってくるだろうわかりやすい問題は以下が考えられる。

■セキュリティ対応
　セキュリティ対応に関してはセキュリティを低廉化し、セキュリティホールがあっても情報を漏らさない体制を作ることができればいい。極端なことを言えば、サーバーに配置されるデータがすべて暗号化もしくはハッシュ化されていればセキュリティホールによる情報漏洩リスクはかなりなくせるはずだ。
　パスワードをハッシュ化するように、メールアドレスもハッシュ化すれば個人情報漏洩リスクをさらに低減させることができる。なぜ一般的なサービスでメールアドレスをハッシュ化しないというと、利用者に対するメールによる連絡が目的だからだ。つまるところ営業活動が目的である。これをすっぱり諦めてしまえばかなり安全側に倒すことができる。また、パスワードの再発行に関しては、メールアドレスを利用者に送ってもらい、そのメールアドレスに対してパスワード更新のURLを送付することで実現できる。もちろんメール送信の際にはハッシュとの突合を行う。メール送付機能が悪用されることを防ぐためだ。メールアドレスもハッシュ化は悪質な利用者の停止にも対応できる。利用停止した利用者のメールアドレスのハッシュさえ持っていれば、同じメールアドレスでの再登録を防ぐことができる。
　E2EEのPKMSというのも魅力的な考え方だ。PKMSに入力されるデータは社外秘や個人情報になりうる。これらを平文で持たず、サーバー内では暗号化されていることでかなり安全になる。ただ、多対多のE2EEを実装するのはどうも難しいらしい。要研究だ。

■悪質な投稿への対応
　PKMSの投稿が一般公開されている場合、普及するにつれて悪質な投稿に対する対応というものが必要になってくる。この対応は必ず人の稼働という形でコストを必要とする。そうであるならば、一般公開されず、個人・チーム内で閉じた空間での利用に限定し、さらに月100円(仮決め。正直いくらでもいい。)を支払わせることで悪質な投稿による影響や、そもそも悪質な投稿がされる可能性を低減させられる。
　一般公開しないという方針は利用者が入力した情報が漏洩する危険性を発生させるが、E2EE化し、暗号化した情報のみをサーバに持たせるようにすれば安全にできるはずだ。

■問い合わせ対応
　検討中。正直なところどんな問い合わせが来るか想像がつかない。安定拡大しつつ、対応する資料や仕組みを整えるしかないかもしれない。可能な限り問い合わせが来ない体制にしたい。PLGの考え方が役に立つだろう。人が問い合わせに対応するのではなく、PKMS自身に問い合わせ対応させる。そういうことができればよさそうだ。Helpfeelが参考になる。