◆問題を抱えている人に対応するとき、 あなたは「たいしたことじゃない」 というトークンか、 「世界の終わりだ！」というトークンを 選ぶことができる。 あなたがどちらを選んだにせよ、 相手はもういっぽうのトークンを手にする。 たとえば、 あなたがホテルに泊まっているところを 想像してほしい。 部屋のエアコンがきかなくて、 フロントに電話して故障していると訴えたとする。 フロント係は「ええそうなんです」と答える。 故障しているのは先刻承知で、 来週誰かが修理に来るという。 そして、「窓でもあけておいたらどうですか？」 と気楽に言う。 謝罪もなく、申し訳ないと感じている様子もない。 この例でいうと、 ホテルのスタッフが「たいしたことじゃない」 トークンを手にしたのは明らかで、 その結果、あなたは「世界の終わり」 トークンを手にした。 だが、ホテルは逆の選択をすることもできたはず。 「大変申し訳ございません。 それはまことに耐え難いことですね。 部屋が暑すぎて眠れないのがどんなものか、 よくわかります。 今夜、この問題を解決できない場合、 お部屋代を返金して、よろしければ 近隣の別のホテルをお探しいたします。 とにかく、解決策をお探ししている間に、 冷水のボトルとアイスクリームを お部屋にお届けいたします。」 こんなふうに答えが返ってきたら、 あなたは「たいしたことじゃない」 トークンをほぼ強制的に手にすることになる。 ◆ソフトの開発で重要なこと それは、新しいもの（バージョンアップ）は、 新規の顧客に売り、 これまでの顧客にはすでに使っているものを 使い続けられるようにすることだ。 古い契約を守り、 旧バージョンのソフトを維持するのは 無料ではできない。 それはいわば遺産の維持費だ。 あなたが成功しているのは、 最新のものをつくる前に、 あなたのことを気に入ってくれた 顧客がいたからだ。 それを喜ぼう！ 自分の遺産を誇りにしよう。 ◆市場で真実を知ろう ソフトを市場に出すときは、 さまざまなシミュレーションを行う。 また、ベーター版を試用してくれるユーザーを 募集して検証してもらうといったこともする。 でも、これらはリアルなフィードバック（答え） ではない。 リアルな答えは、 誰かが自分の意思であなたのソフトを買い、 その人自身の自然な環境で自主的にソフトを 使ったときにこそ、明らかになる。 それ以外はすべてシミュレーションであり、 シミュレートされた答えしか出てこない。 だから、ベストを尽くしたらソフトを市場に出そう。 そうすれば、 あなたのソフトを本当に必要としている、 リアルな顧客からもらったリアルなヒントと 答えに基づいて、 ソフトを改善していくことができる。 ◆会社単位 vs ユーザー単位 ソフトのサブスクで悩むのが料金を 会社単位にするか、 それともユーザー単位にするかだ。 会社単位とは社員数に関係なく月９９ドルとなる。 ユーザー数単位とは「月９９ドル✕ユーザー数」 となる。 あるソフト会社は、ソフトのサブスク料金を ユーザー単位ではなく会社単位とした。 なぜか？ 理由はいろいろあるが、 すば抜けて高い支払いをしている 顧客がなくなるからだ。 したがって、高額の支払いをしている 顧客の要望を優先させる必要がない。 つまり、さまざまな顧客の要望を聞いて ソフトの改善に反映させることができる。 結果的にこの戦略はソフト会社を成功に導いた。 ◆リスクにさらされずにリスクを冒そう 多くの起業家がリスクの虜になっている。 だが、リスクは冒すが、 会社を危険にさらしてはいけない。 こんな事例がある。 あるソフト会社はソフトの使用料を 月２９ドルから９９ドルに、 約３倍引き上げた。 ただし、すべての顧客に新しい価格を 適用したわけではない。 新規の顧客にのみ、この価格を適用した。 そして、この戦略はすばらしい結果を得た。 スマートな賭けとは、 危険にさらされていないときにもう一度、 賭けにでることだ。 ◆小さなチーム vs 大きなチーム 小さな複数のチームで大きなことはできるけれど、 大きなチームで小さなことを行うのは ずっとむずかしい。 小さなことというのは、 大事なことだけに削ぎ落とされた結果だ。 大きなことのなかにも重要なものはあるが、 多くの改善は小さなステップが積み重なって 成し遂げられる。 大きなチームは、 それら小さなステップを踏み越えてしまいがちだ。 ◆To Do リストは捨てよう より多くのことをやりとげるには、 すべきことを減らすしかない。 ピーター・ドラッカーは、 「いくら効率よくしても、 する必要のないことをしていたら意味がない」 と言っている。