Web AppShut Down

Tiers

Tiers は SaaS pricing experiments 向けに launch され、early attention を得ました。しかし founder は、price testing が十分頻繁ではなく、teams の workflow に入り込むのが難しいと分かり shut down しました。

元のストーリーを見る

プロダクト概要

何だったか

Tiers は SaaS teams が pricing tiers を test and manage するための pricing experiment tool でした。

誰のためか

SaaS foundersSaaS teams considering pricing changesgrowth or product teams working on pricing

課題 / 価値

teams が static price pages からの guesswork ではなく、pricing changes を more systematically に test できるようにすること。

中核ワークフロー

teams が pricing tiers を設定し、pricing experiments を管理し、価格変更を検証する。

プロダクト形態

web appSaaS pricing experiment toolpricing workflow software

競合または代替手段

billing toolsanalytics toolsdocsspreadsheetsstatic pricing pages

何が起きたか

概要

Tiers は SaaS teams が pricing tiers を more systematically に test and manage するために作られました。

結果

founder は price testing が十分頻繁ではなく、SaaS company workflows に入り込むのが難しいと判断して shut down しました。

中核リスク

A valuable but rare workflow may not support a dedicated SaaS tool.

終了理由

public shutdown post は product awareness ではなく、low workflow frequency と adoption friction を示しています。

作る前に確認すること

なぜ重要か

Tiers は pricing が重要でも、teams が頻繁に行わない workflow なら separate SaaS tool として定着しにくいことを示しています。pre-build question は、buyer がどれだけ頻繁に pricing changes を行い、既存 process に別 tool を入れる理由があるかです。

主な確認事項

pricing experiment software を作る前に、pricing changes が十分頻繁に起き、teams が separate workflow を採用するかを証明してください。

チェックリスト

  • 過去 90 日で pricing を変更した teams は何社いるか。
  • pricing work は誰の calendar and process に入っているか。
  • standalone app ではなく template or integration で足りないか。
  • Low-frequency workflow を build 前に見抜く evidence は何か。
  • buyer はこの workflow をどれくらい頻繁に行うか。
  • 現在この workflow を所有している existing tool は何か。
  • buyer が separate product を追加する理由は何か。
  • workflow がすでに起きる場所に tool を embed できるか。

参考になる場合

  • 低頻度だが重要な business workflow 向け SaaS を作っている。
  • Product Hunt attention や early users はあるが recurring workflow frequency が不明。
  • existing billing、analytics、docs、spreadsheets に workflow が残っている。

参考になりにくい場合

  • buyer が毎週または毎月この workflow を行い、既存 process に組み込む意思がある。
  • billing or analytics integration により workflow が自然に発生する場所に入れている。

開発前テスト

  • last 90 days に pricing を変更した teams に interview する。
  • 3 teams の pricing test を manual に支援し、software を求めるか確認する。
  • full app の前に integration or template を試す。

応用できる学び

  • dedicated tool を作る前に workflow frequency を測る。
  • buyer の existing process 内で adoption を test する。
  • topic importance と recurring product usage を混同しない。

今作るなら

pricing experiment software を作る前に、teams が直近 90 日で pricing change を行った頻度と、既存 workflow に入れる integration or template を確認してください。