プロジェクト管理システムが進行中のオープンベータを持つ理由を学びましょう。
多くのB2B SaaSスタートアップはベータ版でローンチしますが、それには良い理由があります。これは、シリコンバレーの伝統的なモットーである*「迅速に行動し、物事を壊す」*の一部です。
製品に「ベータ」ステッカーを貼ることで、期待値が下がります。
何かが壊れた？まあ、それはただのベータです。
システムが遅い？まあ、それはただのベータです。
ドキュメントが存在しない？まあ…要点は分かりますね。
そして、これは実際に良いことです。LinkedInの創設者であるReid Hoffmanはかつて言いました：
あなたの製品の最初のバージョンに恥ずかしさを感じないのなら、あなたは遅すぎてローンチしたということです。
ベータステッカーは顧客にとっても良いことです。それは彼らが自己選択するのを助けます。
ベータ製品を試す顧客は、技術採用ライフサイクルの初期段階にいる人々であり、製品採用曲線としても知られています。
技術採用ライフサイクルは通常、5つの主要なセグメントに分かれています：
- イノベーター
- 早期採用者
- 早期多数派
- 後期多数派
- ラガード
しかし、最終的には製品が成熟し、顧客は安定した動作する製品を期待します。彼らは物事が壊れる「ベータ」環境へのアクセスを望んでいません。
それとも、望んでいるのでしょうか？
これが私たちが自問自答した質問です。
私たちは、Blueが最初にどのように構築されたかの性質からこの質問を自問したと信じています。Blueは忙しいデザインエージェンシーの派生として始まりました、そのため私たちはBlueを使用してすべてのプロジェクトを運営しているビジネスのオフィスの内部で働いていました。
これは、私たちが何年にもわたって本物の人々が—私たちのすぐ隣に座っている！—日常生活でBlueをどのように使用しているかを観察できたことを意味します。
そして、彼らは初期の頃からBlueを使用していたため、このチームは常にBlue Betaを使用していました！
そのため、私たちの他のすべての顧客にもそれを使用させることは自然なことでした。
これが、私たちに専任のテストチームがない理由です。
その通りです。
Blueの誰もが、私たちのプラットフォームが正常に安定して動作していることを保証する唯一の責任を負っていません。
これにはいくつかの理由があります。
最初の理由はコストベースの低さです。
フルタイムのテストチームを持たないことで、私たちのコストは大幅に削減され、業界で最も低い価格でこれらの節約を顧客に還元することができます。
これを具体的に言うと、私たちは競合が$30-$55/ユーザー/月で提供しているエンタープライズレベルの機能セットを、わずか$7/月で提供しています。
これは偶然ではなく、意図的です。
しかし、機能しない安価な製品を販売することは良い戦略ではありません。
だから本当の質問は、専任のテストチームなしで、数千の顧客が使用できる安定したプラットフォームをどのように作り出しているのかということです。
もちろん、オープンベータに対する私たちのアプローチはこれにとって重要ですが、これに入る前に、開発者の責任について触れたいと思います。
私たちはBlueで、フロントエンドとバックエンド技術の責任を分けることは決してしないという初期の決定をしました。私たちはフルスタック開発者のみを雇用または育成します。
この決定を下した理由は、開発者が自分が取り組んでいる機能を完全に所有することを確実にするためです。したがって、機能に対して共同責任があるときに時々見られる*「問題を庭のフェンスの向こうに投げる」*という考え方はありません。
これは、機能のテスト、顧客のユースケースやリクエストの理解、仕様の読み取りとコメントにも及びます。
言い換えれば、各開発者は自分が構築している機能について深く直感的な理解を築きます。
さて、私たちのオープンベータについて話しましょう。
私たちが「オープン」と言うとき、それは本当です。どの顧客でも、私たちのウェブアプリケーションのURLの前に「beta」を追加することで試すことができます。
したがって、「app.blue.cc」は「beta.app.blue.cc」になります。
これを行うと、通常のデータを見ることができ、ベータ環境と本番環境は同じデータベースを共有していますが、新機能も見ることができます。
顧客は、本番環境にいるチームメンバーとベータ環境にいる好奇心旺盛なメンバーがいても、簡単に作業できます。
通常、私たちは数百の顧客が同時にベータを使用しており、コミュニティフォーラムに機能プレビューを投稿して、何が新しいかをチェックして試すことができます。
そして、これがポイントです：私たちは数百人のテスターを持っています！
これらすべての顧客は、自分たちのワークフローで機能を試し、何かが正しくない場合は非常に声を上げます。なぜなら、彼らはすでに自分たちのビジネスの中でその機能を実装しているからです！
最も一般的なフィードバックは、小さくても非常に役立つ変更で、私たちが考慮しなかったエッジケースに対処しています。
新機能はベータで2〜4週間保持します。安定していると感じたら、本番環境にリリースします。
必要に応じて、ベータをバイパスする能力もあります。これは通常、2〜4週間待たずに本番環境に出荷したいバグ修正のために行われます。
結果は？
本番環境へのプッシュは…まあ退屈に感じます！何もない—私たちにとっては大したことではありません。
そして、これによりリリーススケジュールがスムーズになり、私たちが過去6年間、時計のように毎月機能を出荷できるようになったのです。
しかし、どんな選択にもトレードオフがあります。
顧客サポートは少し複雑になり、私たちはプラットフォームの2つのバージョンで顧客をサポートしなければなりません。時には、異なるバージョンを使用しているチームメンバーがいる顧客に混乱を引き起こすことがあります。
もう一つの痛点は、このアプローチが本番環境への全体的なリリーススケジュールを遅くすることがあるということです。これは、関連する機能に問題があり、さらに作業が必要な場合、特に大きな機能に当てはまります。
しかし、バランスを考えると、これらのトレードオフは、コストベースの低さと顧客のエンゲージメントの向上という利点に見合う価値があると考えています。
私たちはこのアプローチを受け入れる数少ないソフトウェア会社の一つですが、今や私たちの製品開発アプローチの基本的な部分となっています。