サービスメニューは多ければ多いほど良いという訳ではない。だけど、メニューがなく一つしか商品がないというのでは売れない。また、自由度が高ければ高いほど良いという訳ではない。だけど、自由度がなく、すべてお仕着せというのでも売れない。「わかりやすさ」が大事。
投稿
tweet
現実には、伝説のマーケッターなんぞいない。では、どうするのか。自分たちに出来ることは何か、冷静に見なおし、今ある資源で、テコを利かせる方法はないかと、頭を働かせるのみ。
tweet
インバウンドで、リード獲得を狙うなら、まずはブログを含むメディアでアウトプットしないといけない。アウトバウンドで狙うなら、まずは個別のヒアリングなどでインプットが十分でないと、うまくいかない。いずれにせよ、市場とのIOが重要なのだ。
tweet
時間で予定を組むと、パーキンソンの法則が発生して、その時間をフルに使ってしまうのは、もったいない。しかも、時間内で終わらず、ズルズルと伸びてしまう。大事なのは開始の予定でなく、締切の予定ではないか。
tweet
事業を始めて、お客さんの存在に感謝を覚え、事業を継続して、働いてくれるスタッフに感謝を覚えた。そして、事業を拡大しようとするときに、ビジネスパートナーに感謝を覚えている。一人では何も成し得ない。感謝が積み重なるばかり。以前はそんな簡単なことすらわからなかった。
tweet
ブルーオーシャン戦略もフリーミアムもロングテールも、後から外から見て分析して付けただけ。事業を考える際に、それを狙って事業計画を立てるのはナンセンス。結果として、ブルーオーシャン戦略だったと他人から分析される、だけ。そういう観点だとアジャイルも同じだ。
tweet
人数の少ないチームに必要なのは、規律と能力よりも、仲間意識と役割分担なんだろう。
tweet
技術者として、美しく拡張性の高いアーキテクチャ設計に傾倒しがちで、それも大事だが、市場にマッチしてるかどうかを判断基準にしよう。事業者として、儲かりそうなプラットフォームになる色気を出しがちで、それも大事だが、顧客のニーズにあってるかどうかを判断基準にしよう。
tweet
おそらく、エンジニアは、コスト構造がわかり過ぎているから、謙虚になり過ぎる。営業は、顧客の話で判断するから、市場にあう価格感がわかる。そこにギャップがあるが、エンジニアが損をしがちだと思うな。
tweet
ソフトウェアもどういう人たちが作っているかわかった方が、より多くの人に使ってもらえるということはあるだろうか。あるような気がする。
tweet
プロダクトやサービスの責任者、小さな会社であれば社長は、その顧客の代表者であるべき。「顧客の声」の代弁者でなければ、良いものは作れない。だから、自らがサービスの一番の利用者であるべきだし、より多くの顧客に会いに行かなければならない。
tweet
サービスのビジョンはあくまで将来像であり、明日すぐに実現するものではなく、そこに至るにはいくつかのマイルストーンが必要。マイルストーンを時系列に並べたら、それがロードマップ。その配置と道筋を考えるのが戦略。一つ一つの道をどう進むのか、それは戦術。
tweet
疲れているときに、どれだけ人にやさしくできるかどうかで、人間の器を試されている気がする。
tweet
自分がやらねばならないことか、そうでないかを見極めるのって難しい。どんなことでも、誰かが既にやってる、今後に誰かがやる、と考えたら何も出来ない。自分がやりたいことは何か、それしか基準はない。
tweet
自分たちの本業以外の力を伸ばそうとすることは無駄。なんでも自分たちでやろうとしてはいけない。資本のある大企業であれば可能な戦略だが、そうであっても社内に専門家を抱えることで実現している。人数の少ない企業で出来る訳が無い。
tweet
「彼を知り己を知れば百戦して殆うからず」孫子の言うことに実感と納得を持てるようになってきた。己の弱さを知り、弱さを認めた上で、補うために他者の力を使う方法を考える。プライドなんて要らない。事実をもとに戦略を立てよう。
tweet
今になって、改めて事業計画に関する本などを読むと、理解がまったく違う。言葉を知識で得ていた頃と違う発見がある。本を読み頭だけでわかる人がいたらすごいけど、凡人は進みたい方向があるなら、早く経験を積む選択をすべきなんだな。
tweet
全ての会社におけるソフトウェア基盤はSNSとなる、というビジョンを考えてる。会社は結局、人の集まりで構成されているので、プロセスを中心にシステムを作るのでなく、人の関係の上に機能が乗る。社内SNSがポータルでありプラットフォームに。