Key Takeaways

  • AI coding agents make writing code cheap, but customer trust remains scarce and easy to destroy.
  • Traditional roadmaps score items by build effort and projected impact, an approach that breaks down when engineering capacity is unconstrained.
  • Shipping disposable software without clear classification confuses buyers and creates technical debt for go-to-market teams.
  • Product leaders must manage customer expectations by classifying every initiative under The Three-Tier Feature Commitment Hierarchy.

The Three-Tier Feature Commitment Hierarchy

When code generation costs drop toward zero, the bottleneck in software shifts. The constraint is no longer how fast an engineering team can build. The constraint is how much change your users can absorb before they lose confidence in your platform. As Claire Vo explained at the Lenny and Friends Summit: "Not everything we ship is a promise. Code is abundant. Customer trust is not."

To prevent teams from confusing buyers and sales reps with unvetted features, Vo separates product output into three explicit tiers:

  • Tier 1: Probes: Lightweight bets and exploratory deployments designed to test customer interest with no commitment to longevity or maintenance.
  • Tier 2: Experiments: Durable tests executed against a core conviction where the team iterates actively until the hypothesis is validated or disproven.
  • Tier 3: Promises: Hardened, reliable capabilities that customers and internal go-to-market teams can depend upon, sell in contracts, and compound upon long-term.

Vo points out that this replaces the old prioritization matrix. Instead of asking how hard something is to build, teams must ask: “How strong is our conviction here and how durable is this promise?”

When This Works (and When It Doesn't)

This hierarchy works best when your team ships fast with AI tools and your go-to-market team needs clear boundaries. Sales reps often spot a prototype in staging, pitch it to an enterprise buyer, and accidentally turn a weekend hack into a contractual obligation. Labeling every feature release gives sales, support, and marketing a common language.

It breaks down if you use Tier 1 as an excuse for sloppy engineering. If a probe breaks core user workflows, crashes your database, or exposes private customer data, users will not care that you labeled it exploratory. A probe must be safe to run and easy to remove. If your architecture cannot support clean rollbacks, do not ship probes directly to production.

What to Do With This

Audit your current product backlog before your next sprint planning session. Group every active project into one of the three tiers.

Take an AI-powered summary tool you built last week. If it is an unproven idea, tag it explicitly as a Probe in your release notes and disable it for enterprise accounts by default. For your core billing and workflow tools, label them Promises and set strict uptime SLAs. Then, train your sales reps: if a capability is marked as a Probe or an Experiment, it cannot appear in an enterprise contract or pitch deck.